こんにちは、システム技術部アプリ基盤shiromi(id:kc-shiromizu)です。
はじめに：IDパスワードの管理
ID/パスワードの管理、面倒くさいですよね。
個人としても、たくさんのIDとパスワードを覚えておくのは大変ですし、登録の手間もあります。 私も愛用するLastPassによる2017年のレポートによると、従業員個人は平均して191ものパスワードを管理しているようです。少し古いレポートにはなりますが、私個人のLastPass vaultも172のサイトが登録してありましたので、納得感があります。
企業で管理する側として見た時も、多くのID/パスワードを管理するのは手間もコストもかかります。異動があれば追従させる必要があるし、サービスのポリシーによっては定期変更を強制させられるし（定期変更についてはNIST、総務省からも不要という話出てますね）、使いまわしされるとリスト型ハッキングが怖いのでパスワードポリシーをガチガチにしたり・・・
AWS管理コンソールに対するシングルサインオンを導入
ということで本題ですが、AWSシングルサインオンについてをお伝えします。
カブコムでは、AWS管理コンソールを操作できる要員は一定の条件を付けており、社内申請・承認を行って登録する運用を行っています。
全員に等しく権限を与えるわけではないので、スモールスタートした当初はAWSアカウントに紐付くIAMユーザ払い出しによる単純なID/パスワード認証から始めていました。現在はそこからAWS活用度がアップし複数AWSアカウントを活用していますので、AWS OrganizationsのマスターアカウントにIAMユーザを作成しSwitch Roleを行う形で運用しています。
前述の通り、サービス独自でID/パスワードを管理したくありませんので、この運用をシングルサインオンに対応させることにしました。
AWSシングルサインオン（以下AWS SSO）が東京リージョンに対応しましたので、AzureADと組み合わせて、以下図のような方式に変更。
カブコムでは社内コミュニケーション基盤にMS365を使用していますので、社員のユーザ情報はAzure ADに登録されています。
このAzure ADをIdP（IDプロバイダー）として、AWS SSOのポータル画面にシングルサインオンでログインし、さらにAWS SSOポータル画面から子AWSアカウントにシングルサインオンする。という形になりました。
AWS SSOを使った運用への変更に伴い、role情報の管理先・管理方法も変わります。変更前のSwitch Role型の運用では、子AWSアカウントにroleを作成し親AWSアカウント上にあるIAMユーザを信頼関係に登録する。という作業を行っていました。
AWS SSOでは「アクセス権限セット」という汎用ロール的な権限情報を作成し、子AWSアカウントに割り当てる仕組みで権限管理を行います。（実態としては子AWSアカウントのroleとしてデプロイされるわけですが、AWS SSOサービスの中で操作することで完結します）
従って、権限の管理主体が以下のように変わります
- Switch Role方式 ：子AWSアカウントの管理者が管理
- AWS SSO方式 ：マスターAWSアカウントの管理者が管理
2020/12時点では、「IAMユーザ+Switch Role」と「AWS SSO」の両方式を併用しているため大きな混乱はありませんでしたが、権限の管理元が変わる点は意識しておいた方が良さそうです。
ユーザ情報はAzure ADとSCIM連携を設定し、定期的に同期されます。退職等でAzure ADからユーザ削除されれば、AWS SSOのユーザも自動的に無効となります（削除されるわけではなく無効）
構築には、こちらの情報を参考にしています
AWS Single Sign-On の次の進化 | Amazon Web Services ブログ
得られたメリット
この運用に変更することで、次のようなメリットを得ました
- 独自のユーザ情報（IAM ID/パスワード）を管理する必要が無い
- 子AWSアカウントのroleを一元管理できる（善し悪しある）
- 各自がスイッチするroleArn情報を覚えたり、利用者に展開しなくていい
- 社内ポータル画面のアプリケーションとして表示できる（URLを見失わない笑）
管理者・利用者双方にとって少なくないメリットがありました。AWS Organizationsで複数のAWSアカウントを管理するケースでは、積極的に導入した方が良いと思います。
ただし、子アカウント側でユーザの権限管理を行っている場合は少し考える必要があるかもしれません（カブコムは一元管理で問題なかったため、大丈夫でした）
今後
シングルサインオンでの運用は始めたばかりですので、使ってみてどうかという効果測定と課題の洗い出しなどは今後行っていこうと思います。
また、カブコムではAzure ADで管理してないBP様などもいるため、実はこの運用では全方位カバーができていません。AWS SSOで独自のユーザ追加ができれば手早く解決できそうなんですが、Azure ADと連携していると出来ないみたいですね。
今後は上述の例外ユーザ対応のために別IdPを連携させたり、属性ベースのリソースアクセスコントロール（ABAC）モデル併用に進化させる、といった事に挑戦したいと思っています。
では、今日はここまで。
