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 のログインを行っています。

aws.typepad.com

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

Amazon WorkSpaces

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

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

IAM は AWSサービス の要

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

docs.aws.amazon.com

docs.aws.amazon.com

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

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

IAM Policies

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

docs.aws.amazon.com

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

docs.aws.amazon.com

IAM Role

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

docs.aws.amazon.com

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

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

Lambda resource access permissions - AWS Lambda

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

IAM Groups

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

これはAWS も同様です。

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

docs.aws.amazon.com

IAM Users

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

docs.aws.amazon.com

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

docs.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時間後に強制ログアウトされます。

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

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

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

docs.aws.amazon.com

dev.classmethod.jp

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

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

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

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

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

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

まとめ

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

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

*1:Delegate