AWS Directory Service を使った AWS Management Console へのログインと制約

AWSにはDirectory Serviceという、マネージドなディレクトリサービスがあります。

https://aws.amazon.com/jp/directoryservice/

これを使うことで、次の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へのログインについて記事を書かれています。

http://blog.serverworks.co.jp/tech/2015/12/04/Microsoft-ad-aws-console-access/

この記事では、従来のIAM UsersやADFS + IAM UsersでのログインにはないDirectory Serviceを用いた場合の制約について触れていないので、簡単に紹介したいと思います。

グラニでの Directory Service を利用した AWSログインの制御

グラニでは、昨年Directory Serviceが出てすぐに、AWS上に構築しているMicrosoft Active DirectoryとAD Connectorでつないで、AWS Management Consoleのログインを行っています。

http://aws.typepad.com/aws_japan/2014/10/aws-directory-service.html

設定などについては、ServerWorksさんが行っているMicrosoft ADとあまり変わりません。基本的には、AWS Documentを見ればわかります。

http://docs.aws.amazon.com/ja_jp/workspaces/latest/adminguide/prep_connect.html

グラニでは、PowerShellで設定を自動化しています。

全体的なフロー図はこんな感じで、Active Directoryがすべての認証の要になっています。AWS Directory ServiceはADDC内部のディレクトリへの制御を委譲されているので、ユーザーの走査が可能です。(user/computer objectに対するread/write権限)

IAM は AWSサービス の要

AWSの権限制御はIAMがベースです。そしてIAMを利用する目的とメリットは、権限の適切な設定とstsによる委譲*1です。

http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/introduction.html

http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp.html

IAMには、適用対象に応じて種類があります。Groups / Users / Roles / Policiesです。

この記事はIAMを理解しておく必要があるので軽く見てみましょう。

IAM Policies

IAMで実行できる範囲を、テンプレートを用いて設定できます。この設定1つ1つがポリシーであり、IAM RoleやIAM Groups、IAM Usersにテンプレートを適用できます。

http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html

現在は、Managed Policyがあるため、特別に制御したいという理由がない限りはCustom Policyを書く必要がなくなりました。

http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html

IAM Role

RoleはIAMで最も重要な考えと役割を果たします。これは、AWSリソースに対する権限の委譲制御であり、IAMの要です。

http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles.html

例えば、インスタンスロールに関してはIAM Roleを使った権限の委譲が可能です。こうすれば、ログインしているユーザーにかかわらずインスタンス自体が利用できるAPIを適切に制御できます。

Lambdaなどで頻繁に出てくるPermission ModelもIAM Roleを使っているので身近でしょう。

http://docs.aws.amazon.com/lambda/latest/dg/intro-permission-model.html

そして、Directory Serviceでは、このIAM Roleで権限委譲を制御します。

IAM Groups

Windowsや *nuxなど、どのOSでもユーザーで直接権限制御するのではなくグループで権限制御を行い、そのグループにユーザーを紐づけるでしょう。

これはAWSも同様です。

グループに適切にIAM Policyを紐づけて、必要なIAM Usersを紐づけることで、IAM Users個別の設定を極小化できます。

http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_groups.html

IAM Users

個別のIAM Userごとに、Managed ConsoleのログインであったりAPI Keyを発行できます。IAM Groups単位では当然API Keyは発行できません。

http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_users.html

AWSでは、相当の理由がない限りRoot AccountでのAPIキー発行、利用は非推奨です。

https://docs.aws.amazon.com/ja_jp/general/latest/gr/root-vs-iam.html

これは、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個作る必要があります。

http://dev.classmethod.jp/cloud/aws/adfs-aws-sso/

http://azuread.net/2014/12/04/adfs％E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%A6aws%E3%81%AB%E3%82%B7%E3%83%B3%E3%82%B0%E3%83%AB%E3%82%B5%E3%82%A4%E3%83%B3%E3%82%AA%E3%83%B3%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95/

どの手法も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を容易にスイッチできるようにしています。

http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_use_switch-role-console.html

http://dev.classmethod.jp/cloud/aws/switching-to-a-iam-role/

非常にいいのですが、実態がIAM RoleのためDirectory Serviceでのログインはもろに影響をうけます。

ブラウザで、Directory ServiceによるAWS Management Consoleログインをしている状態のタブを複数作ってみてください。そのうちの1つのタブでSwitch RoleでAWSアカウントを切り替えると、Switch Role前のアカウントを開いていたタブではReloadを必ず求められます。

作業をしていても、していなくても強制的にReloadを求められるため注意が必要です。

AWS コンソールモバイルアプリで利用できない

そのままです。iOSやAndroidで利用できるモバイルアプリは、Directory Serviceによるログオンをサポートしていません。

https://aws.amazon.com/jp/console/mobile/

まとめ

Directory Serviceによる、 Management Consoleのログインは一年近く使ってますが最高です。が、SSOと違い認証を求められたり、二段階認証にはRADIUSを使ったりする必要があったりします。stsによる認証タイムアウトは、デメリットに近い制限といえるでしょう。

この記事が、AWS Management Consoleをどのような方式でやるか決める際の材料となれば幸いです。

*1:Delegate