AzureADからAWSへのSSOしてみたら、めちゃめちゃCTOが喜んだお話
今回は、AzureADからAWSへSSO / プロビジョニングしたお話で、技術的なこと以外の課題とその解決にフォーカスしたお話です。技術的なお話はQiitaの方に書いていきます。
技術的なお話はこれ
今回は2つの示唆が含まれています
1つ目がこういった課題をAWS SSOを使って解決したよって話
2つ目がコーポレートITと別部門の人が尊重し合いながら、仕事をするとこんなにスムーズに楽しく仕事できるよって話です。
また本プロジェクトは、メインは私とプロダクトのインフラ担当、他にCTOやセキュリティアドバイザーも関わっており、私だけで達成したことではありません。
背景
弊社プロダクトのインフラはAWSを使用しています。複数のAWSアカウントを持っており、各自IAMユーザを使用していました。
課題
そんな中での課題として、
1. ログインがシームレスにできなくて面倒
2. 社内サイドのIdPと紐付いていない
3. AWS内の権限管理がきちんとできていない
などの課題がありました。
体制
メインは私とプロダクトのインフラ担当の2名ですすめることになりました。
実はつい最近まで、弊社にはプロダクトのインフラ担当がいなかったのですが、5月頃にインフラ担当が入社しました。
まずは信頼を得るため、一緒にやったプロジェクトが脱VPNのときです。
このときは少し探り探りな部分がありつつも、とてもスムーズに進めることができました。めちゃめちゃ優秀な人です！
その後、7月に入って本プロジェクトを一緒にすすめていくことをお願いしました。
解決のための選択肢
解決のための選択肢ですが、2つあります
1. AssumeRoleを使用する方式
2. AWS SSOを使用する方式
1. AssumeRoleを使用する方式
こちらの方式でたくさんの事例がありますが、サイボウズさんの事例が有名かと思います。こちらはAWS SSOを使わずに認証用のアカウントを用意して、そこからAssumeRoleするという方式です。
2. AWS SSOを使用する方式
こちらはAWS SSOというサービスをつかう方式です。
今回は 2. AWS SSOを使用する方式 をとりました
理由は、コンソール以外にAWS CLIにも対応しているからです。
運用
AWS SSOの方式を使った運用はこんな感じです。
入社 / 新規利用
1. 入社のタイミングでAzureADにアカウントを作成
2. エンジニア属性を付与することで、自動でエンジニアグループの参加
3. 自動でAWS SSOにプロビジョニング
4. プロダクト・インフラ担当が手動で権限付けする
退社 / 削除
1. 退社のタイミングでAzureADのアカウントを停止（直接削除でもOK）
2. AWS SSO上のアカウントが自動で停止
3. 一定期間後、AzureAD、AWS SSOでアカウント削除
結果
某社CTOから、こんなコメントいただきました
これだけで、やってやった感あります
また課題の解決という意味では、
1. ログインがシームレスにできなくて面倒
→ SSOでシームレスにログインできるようになった
2. 社内サイドのIdPと紐付いていない
→AzureADとAWS SSOが連携している（プロビジョニング、プロビジョニング解除）
3. AWS内の権限管理がきちんとできていない
→IAMユーザの権限整理をしはじめることができた
と解決していくことができました。
情シスの理想を見た
プロダクト・インフラ担当が入社したことで劇的に仕事がしやすくなりました。開発メンバーの環境面に関して気軽にお願いをすることができるようになったのです。
お互いに尊重しあうことで、情シスはすごく仕事しやすくなる、と感じました。
おわりに
脱VPNのときも、本プロジェクトも非常に気持ちよく進めていくことができました。
情シス同士で会話すると、あるあるな愚痴話になることがあります。
- とある部門で勝手にシステム / SaaSが導入されていた
- 勝手にシステム / SaaSを導入したのに、運用放棄されて、結局途中から運用を押し付けられた
- なぜかBPR / 業務改善のプロジェクトに呼ばれない
- 勝手にPC壊れたと言われたが、よくよく話を聞いてみると・・・
みたいな話は盛りだくさんです。
上記のような他の部門の従業員と一方的な関係ではなく、尊重しあい、持ちつ持たれつの精神でいることでが重要だなぁっと改めて認識できたプロジェクトでした。
この記事が気に入ったらサポートをしてみませんか？