PIMを使ってEntraIDとAWS Identity Centerのプロビジョニングユーザの権限を制御する
はじめに
こんにちは。コンサルティング部の津谷です。
みなさんは、EntraIDとIdentity CenterのSCIM連携を実装し、ユーザの自動プロビジョニングをした経験がありますでしょうか。外部IdPを使ったAWSとのID連携はよくある話かと思うのですが、運用の際は「認可」の部分をどう実装するか重要になってきます。例えば、運用時にAWSアカウントで何か操作権限を伴う作業をしたとします。この時に、他リソースを間違って編集してしまったり、その後の対応でだれがいつ・どんな目的で作業を実施したかトレースできないといったリスクが孕んでおります。
この時に、特権IDの管理などを企業ごとに行っていることも多いでしょう。運用作業時に、アクセス管理簿を作成して、作業目的を書いて承認をもらってから、強い権限で作業して、終わったら動作確認とアプリチーム等の関係者へ動作確認依頼、問題なければ管理簿に作業完了を記載して確認してもらうというフローを私も経験したことがあります。アナログな手法ですが、平常時は読み取りしかできない権限でアクセスして、承認をもらってから特権で作業することはミス防止やミスした後の挙動の迅速化にもつながります。もちろん外部のPIMサービスを使っているケースもあるでしょう。
クラウドでこのようなフローを作りこむとなったらどうするのでしょうか。AWSの認証認可では、つくりこみ次第で権限を昇格させて有効期限付きでアクセスさせることも可能ですが、Identity Center単体の機能では、このような一時的な特権アクセスを許可する仕組みは提供されておりません。最近では、TEAMのような承認フローのアーキテクチャを組むことも可能ですが、AWSでの経験にたけていないと導入するのもなかなかコストが掛かるでしょう。基本的に、認証と認可は同時に行われるため権限を持っていれば常にユーザは権限を行使してアクセス可能になってしまいます。
なるべくこの特権利用についてもクラウドネイティブに実装したい、その後の認可もスムーズに与えたい、アナログの負担を少しでも解消する、そんな希望をもって今日検証をします。
やりたいこと
EntraIDを社内共通基盤として使っているならば、PIM(Privileged Identity Management）の機能が利用できます。PIMはP2ライセンスが必要という制約がありますがエンタープライズであればP2ライセンスを持っていることが多いかと思います。
やりたいことは以下の図のような形です。
PIMでは、グループ管理もできます。Administratorのような特権を利用する場合は、Azure側でPIMによる承認フローを挟んでからAWS上で権限を付与するということを実現します。運用の形として、基本的なリソース調査等はRead権限があればよいかと思います。なので、Azure側でSAML連携するエンタープライズアプリケーションには、2つのグループ「Administratorグループ」と「ReadOnlyグループ」の2つを割り当てしておきます。前者は空の状態にしておき、後者には運用メンバーを入れておきます。前者は、PIM管理のグループとして指定することで、ユーザがアクティブ化の申請を出し、管理者が承認することで初めてAdministratorグループに追加されます。PIMではセッション期間も選択することができるため、一時的な権限付与が可能です。グループに追加されたメンバーは、EntraIDのエンタープライズアプリケーション（IdP)とIdentity Center（SP)で自動プロビジョニングを行っているので、動的にIdentity Center側のAdminグループに追加される仕様です。
今回の検証ではSCIMでのユーザプロビジョニングは割愛します。以下のAWSドキュメントに設定方法が記載されていたり、他の方が大変わかりやすいブログも書いているためそちらにお任せします。
PIMについても機能詳細はAzureのユーザガイドに記載されているのでお任せします。
権限昇格をやってみる
前提として、Identity CenterとEntraIDはSAMLで信頼関係を結んでいる状態です。（お互いのメタデータファイル（.xml形式）を登録済みで、Identity Center側で払い出したSCIMエンドポイントとアクセストークンもAzureに共有済みです。
まずはテスト用のユーザを作成してみます。ユーザプリンシパルは「tsuya-test1@テナントドメイン」としました。表示名は「津谷テスト1」にしています。
次にグループ作成をAzure側でやっていきます。[ホーム]-[グループ|概要]-[新しいグループ]から追加していきます。AdminグループとReadグループの２つを作成していきます。
Readグループには、作成したユーザを追加しておきましょう。
Adminグループ：津谷テスト管理グループ
Readグループ：津谷テスト読み取りグループ
グループが作成されていることを確認します。
[ホーム]-[EntraID]-[エンタープライズアプリケーション]の設定に移動します。既にAWS Identity Center Center（successor to AWS Single Sign-On）を登録しているので、「ユーザとグループ」で割り当てを行います。
ここで割り当てしないと、Identity Center側に自動プロビジョニングはされないので注意です。Identity Centerで確認してみます。グループがプロビジョニングされていることを確認できました。現在Adminグループのユーザは空の状態です。
Identity Centerでは事前に許可セットを作成し、グループに権限を付与した状態にしております。
Adminグループには「AdministratorAccess」の権限、Readグループには「ReadOnlyAccess」の権限を付与しております。アクセス対象になるアカウントと一緒に設定しておきましょう。
ここからPIMの設定をしていきます。
[ホーム]-[Previleged Identity Management]にアクセスします。左タブの「グループ」を押下します。
グループの検出を行います。
左にチェックボックスがあるので、PIMの管理対象にするグループを選択して保存します。今回は作成したAdminグループ「津谷テスト管理者グループ」を指定します。
これで、対象のグループがPIM管理下に置かれました。このグループを押下し、メンバー割り当ての設定ルールを定めていきます。
左タブの[管理]-[割り当て]を押下します。上記の「割り当ての追加」を押下しましょう。EntraIDユーザに対してグループに追加する資格を割り当てることで、EntraIDユーザ側でアクティブ化申請をできるようになります。
[割り当ての追加]を押下して、設定に進みます。リソースが対象のAdminグループになっていることを確認します。ロールはMemberを選択します。メンバーとして、「津谷テスト1」のユーザを追加して、保存します。
資格の割り当てができていることを確認しました。次に、グループにユーザを追加した際の承認フローの設定を行います。
[タスク]-[管理]-[設定]からメンバーを押下します。アクティブ化（グループへの追加）時間を設定できます。ここはデフォルトの8時間にしておきます。ここでは、なぜ権限昇格を行うのか、申請者側に理由の記載をさせることが可能です。こちらは有効化しておきます。MFAもここで必須にすることが可能ですが一旦無効化にしておきます。
承認を有効にすると、承認者の選択が可能です。ここでは、ユーザからのアクティブ化申請を承認する管理者を選択しておきます。
アクティブ化申請があったら、誰に通知を飛ばすのか決定できます。今回は検証で承認者にのみ通知させるようにしました。
ここまで実装したら、今度は作成したテストユーザでポータルにログインしてアクティブ化申請を挙げてみます。[ホーム]-[Privileged Identity Management|自分のロール]-[自分のロール]を開いて、[アクティブ化]-[グループ]を選択します。
資格の割り当ては実施済みなので、Adminグループが表示されるはずです。操作から「アクティブ化」を押下します。
アクティブ化申請の画面に遷移します。セッション時間と申請理由を記載する必要があるので、デフォルトは8時間ですが1時間で設定してみます。理由は「テストのため」としました。
管理者のメールアドレス宛に、申請通知が届きました。
ここからリンクを押下して、承認待ちの申請を確認します。
[申請の承認]-[グループ]から確認します。
承認を押下します。
承認理由を記載できます。「テストを許可する」と記載してみました。
Adminグループを確認すると、ユーザが追加されていました。EntraIDとIdentity Centerのデフォルトのプロビジョニング間隔は40分なので、待つことにします。
しばらくして、Identity Center側で確認してみると、
無事管理者グループに追加されていました。１時間後にセッションが切れてグループから自動で削除されているかも確認してみます。
削除されていますね。
さいごに
今回はPIMを使って、EntraIDからIdentity Centerへのユーザプロビジョニング時に権限昇格を制御するという仕組みを検証してみました。社内基盤でEntraIDを使っていて、AWSにユーザ情報を適用したい場合は運用時の権限管理が重要になってきます。特権を扱う場合は、適切な承認フローを整備し、誤操作による事故がないような仕組みをあらかじめ検討できておくとよいですね。本日もお読みいただきありがとうございました。
