tech.guitarrapc.cóm

Technical updates

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

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

AWS Directory Service(Active Directory のホスティングと管理)| AWS

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

blog.serverworks.co.jp

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

目次

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

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

f:id:guitarrapc_tech:20151210081104p:plain

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

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

Amazon WorkSpaces

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

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

f:id:guitarrapc_tech:20180312154147p:plain

IAM は AWSサービス の要

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

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

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

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

f:id:guitarrapc_tech:20151210075431p:plain

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

IAM Policies

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

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

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

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

IAM Role

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

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

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

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

AWS Lambda Permissions - AWS Lambda

そして、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.htmldocs.aws.amazon.com

IAM Users

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

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

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

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

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

dev.classmethod.jp

azuread.net

どの手法も 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時間後に強制ログアウトされます。

f:id:guitarrapc_tech:20151210083002p:plain

これは、インスタンスの操作途中だったり、サポートとのやり取りの最中だったりした場合、かなりのストレスです。一年前にフィードバックしていますが、今でも sts タイムアウトは延長されていません。

同一ブラウザでの Switch Role によるRole変更

グラニでは、Switch Role を使うことで、複数の AWS Account を容易にスイッチできるようにしています。

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

dev.classmethod.jp

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

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

f:id:guitarrapc_tech:20151210083002p:plain

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

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

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

モバイルアプリ - AWS コンソール | AWS

f:id:guitarrapc_tech:20151210083524p:plain

まとめ

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

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

*1:Delegate