AWS には Directory Service という、マネージドなディレクトリサービスがあります。
これを使うことで、次の3つの形態をとることができます。
種類 | 概要 |
---|---|
Simple AD | Samba 4 Active Directory Compatible Server を利用したディレクトリサービス提供 |
AD Connector | 既存のオンプレミス Microsoft Active Directory に AWS リソースを接続 |
Microsoft AD | AWS Directory Service for Microsoft Active Directory (Enterprise Edition) |
ServerWorks さんが Microsoft AD を使った AWS Management Console へのログインについて記事を書かれています。
この記事では、従来の IAM Users や ADFS + IAM Users でのログインにはない Directory Service を用いた場合の制約について触れていないので、簡単に紹介したいと思います。
目次
- 目次
- グラニでの Directory Service を利用した AWSログインの制御
- IAM は AWSサービス の要
- なぜ IAM Users や ADFS + IAM Users を使わないのか
- Directory Service を使った Management Console ログインに存在する制限
- まとめ
グラニでの Directory Service を利用した AWSログインの制御
グラニでは、昨年 Directory Service が出てすぐに、AWS 上に構築しているMicrosoft Active Directory と AD Connector でつないで、AWS Management Console のログインを行っています。
設定などについては、ServerWorks さんが行っている Microsoft AD とあまり変わりません。基本的には、AWS Document を見ればわかります。
グラニでは、PowerShell で設定を自動化しています。
全体的なフロー図はこんな感じで、Active Directory がすべての認証の要になっています。AWS Directory Service はADDC 内部のディレクトリへの制御を委譲されているので、ユーザーの走査が可能です。(user/computer object に対する read/write権限)
IAM は AWSサービス の要
AWSの権限制御はIAMがベースです。そして IAM を利用する目的とメリットは、権限の適切な設定とsts による委譲*1です。
IAM には、適用対象に応じて種類があります。Groups / Users / Roles / Policies です。
この記事は IAM を理解しておく必要があるので軽く見てみましょう。
IAM Policies
IAM で実行できる範囲を、テンプレートを用いて設定できます。この設定1つ一つがポリシーであり、IAM Role や IAM Groups、IAM Users にテンプレートを適用できます。
現在は、Managed Policy があるため、特別に制御したいという理由がない限りは Custom Policy を書く必要がなくなりました。
IAM Role
Role は IAM で最も重要な考えと役割を果たします。これは、AWS リソースに対する権限の委譲制御であり、IAM の要です。
例えば、インスタンスロールに関しては IAM Role を使った権限の委譲が可能です。こうすれば、ログインしているユーザーにかかわらず インスタンス自体が利用できるAPIを適切に制御できます。
Lambda などで頻繁に出てくるPermission Model も IAM Role を使っているので身近でしょう。
そして、Directory Service では、この IAM Role で権限委譲を制御します。
IAM Groups
Windows や *nux など、どのOS でもユーザーで直接権限制御するのではなくグループで権限制御を行い、そのグループにユーザーを紐づけるでしょう。
これはAWS も同様です。
グループに適切に IAM Policy を紐づけて、必要な IAM Users を紐づけることで、IAM Users 個別の設定を極小化できます。
IAM Users
個別のIAM User ごとに、Managed Console の ログインであったり API Key を発行できます。IAM Groups 単位では当然API Key は発行できません。
AWS では、相当の理由がない限り Root Account での APIキー発行、利用は非推奨です。
これは、IAM User に適切な IAM Policy をつけて権限を制限、制御することで そのAPIキーでの実行も透過的に制御できるためです。
IAM Users は、IAM Groups とは別に IAM Policy を紐づけれますが、理由がないなら IAM Groups を使ったほうがいいでしょう。間違いないです。
なぜ IAM Users や ADFS + IAM Users を使わないのか
グラニでは、IAM Users をいかにシンプルに保つかが大事だと考えています。この視点において、IAM Users や ADFS + IAM Users を使わずに、AD の認証のみでログイン制御ができる仕組みは好ましいといえます。
IAM Users でのログイン制御
IAM Users は必要最低限が原則です。AWS において IAM Users は便利ですが、乱用すると爆発的に増えてしまう危険性があります。
例えば、IAM Uses を用いたログイン制御は、IAM Users に別途ユーザーを作ることを意味します。つまり、ログインする個人ごとに IAM Users が増えるわけです。IAM Users ですべてのログイン制御を管理しようとすると、あっという間に数十~数百に増えかねません。それだけ増えた場合、本当に必要なユーザーの照合管理など余計な手間が増えるでしょう。
IAM Users + ADFS でのログイン制御
Active Directory を利用しているなら、そのディレクトリ情報で AWS にログインしたいでしょう。IAM + ADFS は、IAM Users と AD の照合でシングルサインオンを提供するものです。これも、IAM Users に各自を追加する必要があり、従業員100人をSSOさせたかったら、IAM Users をその分100個作る必要があります。
どの手法も AWS Management Console へのログイン提供という意味では、決してスマートなやり方とは言えません。
Directory Service によるログイン制御
Active Directory にユーザーとグループが適切に設定されているなら、AD Connector や Microsoft AD を利用することで、IAM Users を作る必要なく AWS Management Console へのログインを提供できます。
AWS Management Console 上で、AD のユーザー、あるいはグループと IAM Role を紐づけるだけで、そのユーザーでログインできるのです。ここにIAM Users や IAM Groups は一切関与しません。
グラニでは、もう一年近く AD Connector を使った Management Console のログインを行っており、控えめに言って最高です。 また、IAM Users は API 制御や SES や Librato の制御にしか用いていないため、常に最低限の数を維持できています。アカウントによっては、IAM Users も IAM Groups も 0 です。
Directory Service を使った Management Console ログインに存在する制限
Directory Service を使って、IAM Rolesの制御下で AWS Management Console のログインを提供する場合、IAM Usersや ADFS + IAM Usersにはない制約がかかります。
Amazon STS のタイムアウト仕様による強制ログアウト
AWSサポートからの公式回答があります。
AWS Directory Service を使用したマネジメントコンソールへのアクセスは Amazon STS による権限移譲の仕様としましてタイムアウトの上限があります。本設定値は現在は変更できません。
具体的には、1時間で sts セッションはタイムアウトします。つまり、Directory Service でログインした Management Cosnole セッションは、ログインして何か操作をしている/していないに関わらず必ず1時間後に強制ログアウトされます。
これは、インスタンスの操作途中だったり、サポートとのやり取りの最中だったりした場合、かなりのストレスです。一年前にフィードバックしていますが、今でも sts タイムアウトは延長されていません。
同一ブラウザでの Switch Role によるRole変更
グラニでは、Switch Role を使うことで、複数の AWS Account を容易にスイッチできるようにしています。
非常にいいのですが、実態が IAM Role のため Directory Service でのログインはもろに影響をうけます。
ブラウザで、Directory Service による AWS Management Console ログインをしている状態のタブを複数作ってみてください。そのうちの1つのタブでSwitch Role で AWSアカウントを切り替えると、Switch Role 前のアカウントを開いていたタブでは Reload を必ず求められます。
作業をしていても、していなくても強制的に Reload を求められるため注意が必要です。
AWS コンソールモバイルアプリで利用できない
そのままです。iOS や Android で利用できるモバイルアプリは、Directory Service によるログオンをサポートしていません。
まとめ
Directory Service による、 Management Console のログインは一年近く使ってますが最高です。が、SSO と違い認証を求められたり、二段階認証には RADIUS を使ったりする必要があったりします。sts による認証タイムアウトは、デメリットに近い制限といえるでしょう。
この記事が、AWS Management Console をどういう方式でやるか決める際の材料となれば幸いです。
*1:Delegate