はじめに
Microsoft Entra が発表され、Office 365 をはじめとした様々なクラウドサービスの ID 基盤である Azure Active Directory や、顧客 ID アクセス管理 (CIAM) ソリューションである Azure Active Directory B2C を含む新しいブランドの ID およびアクセス管理製品が提供されていくことになった。
Entra の発表前から、Cloud Infrastructure Entitlement Management (CIEM) ソリューションとして注目度の高い新機能の Entra Permissions Management (旧名 CloudKnox Permissions Management) について、記事を書くことにした。
組織のゼロトラスト戦略の推進に関わる者として、ゼロトラストの原則である最小特権アクセスの使用を実装可能な製品を検討する時に、本記事が少しでも役に立てば本望だ。
Entra Permissions Management は、Azure だけでなく AWS と GCP を合わせたマルチクラウドに対応している点が注目されている理由の 1 つであると考えるため、AWS アカウントを追加して管理できるようになるまでを試してみた。
本記事の前提条件
- Azure AD テナントおよびその管理者権限
本記事の執筆した 2022 年 7 月 7 日時点では Azure AD Free で Permissions Management の構成を行うことが可能
- Azure サブスクリプション
Azure ポータル上の Cloud Shell の実行に必要
- AWS アカウントおよびその管理者権限
CloudTrail を利用するため作成済みの証跡が必要
AWSアカウントのオンボード
Permissions Management は日本語に対応した専用のポータル画面が提供されており、このポータル上での管理操作と AWS 管理コンソール上での操作によってオンボードが完了する。（AWS 管理コンソール上の操作は設定時のみ）
Permissions Management のダッシュボード上に AWS アカウントの情報が表示され、分析ができるようになるまでの初期設定手順について公開されたドキュメントがある。(リリースされたばかりの製品は、アップデートが頻繁に起こり得るため、英文の方の公開ドキュメントも合わせて参照することをお薦めする)
その中に動画による解説がポイントされており、英語ではあるがとても参考になった。特に、AWS のコンソールにおける操作になれていない場合は役に立つだろう。
以降では、公開文書および解説動画に沿った形で、AWS アカウント追加の流れを確認していく。
- ① Permissions Management トライアル版 (90日間) の開始
Permissions Management をまだ有効化していない場合はトライアル版を試行すると良いだろう。
https://aka.ms/TryPermissionsManagement
トライアル版を購入すると、以前は手動実行が必要であったサービスプリンシパル (ID:b46c3ac5-9da6-418f-a849-0a07a10b3c6c) の作成が自動的に行われるようになっていた。
トライアル版を購入した後で、Azure 管理ポータルへログインし、Azure Active Directory の概要から 「CloudKnox のアクセス許可の管理」を選択すると、Permissions Management の管理ポータルへ遷移できた。
ポータルのインフォメーションで表示されている新しい Microsoft Entra 管理センター（プレビュー）https://entra.microsoft.com からも同様に Permissions Management の管理ポータルへ遷移できる。
- ② Azure AD へアプリ登録を実施
Permissions Management に最初にログインした時点では何も情報がないため、データコレクターの構成の作成を開始する。
最初に Azure AD OIDC アプリの作成を求められる。このステップで、画面に表示されたコマンドによって Azure AD アプリ登録をするように管理画面上の指示が出るが Azure CLI のバージョンによってはエラーになるため注意が必要だ。
Azure ポータルの Cloud Shell で現在利用可能なバージョン Azure CLI 2.37.0 からコマンドの引数が変更されているため、Azure ポータルから実行する場合はコマンドがエラーになる。
Microsoft Graph の移行ページ より抜粋
az ad app create/update
--available-to-other-tenants を --sign-in-audience に置き換えます。
下記のようにコマンドを変更して実行するか、上述した動画で解説されている通りに手動による操作での登録を行えばよい。アプリ名は任意で変更可能だが、デフォルトで設定されている既定値 mciem-aws-oidc-connector を使っても設定を完了することが出来る。
az ad app create --display-name "mciem-aws-oidc-connector" --sign-in-audience AzureADMyOrg --identifier-uris "api://mciem-aws-oidc-app"
- ③AWS 管理コンソールからスタックを作成
AWS 管理コンソールで分析対象のアカウントIDや情報収集のための権限ロール設定を行っていく。ここではAWS 側の管理・運用シナリオに合わせていくつかの分岐が存在するが、上述した動画で解説されている構成に沿って、２つのスタックを作成した。
テンプレートを起動ボタンから、AWS 管理コンソールへ遷移可能だ。
この作業で必要となるパラメータについて一覧で纏めておく。ロールについてはステップ②と同様にデフォルトで設定されている既定値とした。
| スタック名 | パラメータ名 | 値 | 情報を入力する画面 |
|---|---|---|---|
| mciem-oidc-(テナント ID) | OIDC アカウント ID | (AWS アカウントID：12 桁の数字) | Permissions Management 管理ポータル |
| mciem-oidc-(テナント ID) | OIDC アカウント ロール | mciem-oidc-connect-role | Permissions Management 管理ポータル |
| mciem-member-(テナント ID) | メンバーアカウントID | (AWS アカウントID：12 桁の数字) ※OIDC アカウント ID と同じでも良い | Permissions Management 管理ポータル |
| mciem-member-(テナント ID) | メンバーアカウントロール | mciem-collection-role | Permissions Management 管理ポータル |
| mciem-member-(テナント ID) | CloudTrail Buchet Name | (CloudTrail の名前) ※予め用意 | AWS 管理コンソール |
| mciem-member-(テナント ID) | Enable Controller | false | AWS 管理コンソール |
mciem-oidc-(テナント ID) のスタックを作成するための AWS OIDC アカウントのセットアップ画面。
テンプレートを起動から、AWS 管理コンソールへログインが完了したら、「AWS CloudFormation によって…承認します。」へチェックを入れて、スタックの作成を行う。
AWS マスターアカウントの詳細の画面では Enter Authorization Systems を選択し、次へ。
AWS 集中ログアカウントの詳細の画面では何も行わず、次へ。
AWS メンバーアカウントの詳細の画面で Permissions Management の対象とする AWS アカウント情報を入力する。（複数ある場合は最大 10 個まで）
テンプレートを起動から、AWS 管理コンソールへログインが完了したら、CloudTrail の名前を入力し、「AWS CloudFormation によって…承認します。」へチェックを入れて、スタックの作成を行う。
CloudTrail がない場合は、このタイミングで新規に作成する（課金について留意しておくと良い）。
また、今回は Enable Controller については false に設定したが、true に設定変更すると AWS アカウントに対する書き込み権限を付与することになり、検知したリスクを緩和するために修復作業まで行えるようにする場合は true 変更すると良い (動画でも同様の解説がある)。
- ④構成を保存して調査を開始
ステップ①～③を正常に完了させると下記の画面が表示され、保存ボタンを押すことで情報収集が開始される。
調査結果の表示
データコレクターの構成後、15 分程度でオンボードした AWS アカウントのステータスが ONLINE（オンライン）となった。
さらに 15 分程度経過すると、オンボードした AWS アカウントの ID やリソースに関する調査結果がダッシュボード上に表示されはじめた。
ユーザー ID だけでなく、マシンおよびサービスとしての ID とリソースが分析に含まれていること、ロールおよびアクセスキー等のアクセス許可がチェックされ、PCI（Permission Creep Index）という名前の指標がスコアとして表示される。
権限クリープ インデックス (PCI) とは何ですか?
権限クリープ インデックス (PCI) とは、付与されたアクセス許可と行使されたアクセス許可を比較して決定される、ID またはロールに関連付けられるリスクの定量的測定値です。 ユーザーはこれを使用することで、ID とリソース全体での未使用または過剰にプロビジョニングされたアクセス許可の数に関連したリスク レベルを即座に評価できます。 ID に付与されているアクセス許可に基づいて、それらの ID が原因でどの程度の損害が発生するか測定されます。
この AWS アカウントはしばらく使っていなかった検証環境であったため、非アクティブなユーザーやサーバーレス関数、アクセスキーなどが検出されていた。調査結果を見るまでこのまま放置される可能性が高いアクセス許可があったので、権限の棚卸しに活用できる情報を網羅的に得られたことは有用であった。
詳しく調査結果を見たい場合は、分析のページからユーザー、グループ、リソース、タスク、アクセスキー、サーバーレス関数の単位で詳細情報を表示させることが可能だ。
まとめ
• Microsoft Entra Permissions Management の対象へ AWS アカウントを追加する手順の紹介
• AWS アカウントの情報採取の前提条件、予め確認しておきたいポイントの解説
• Microsoft Entra の公開文書および解説動画によって、Permissions Management のダッシュボード上に AWS アカウントの情報が表示されたことを確認
最後まで読んでいただきありがとうございました。
