Resource Access Management:Access Analyzer を使用した権限の管理

行動前の調査

修正アドバイスはアルゴリズムとアクセスデータに基づいて生成されるため、お客様のビジネスコンテキストを完全に理解することはできません。推奨事項を適用する前に、対象の ID またはリソースが問題の権限を本当に必要としなくなったことを確認してください。

• 本番環境で重要な ID (運用ロール、CI/CD ロール、またはコアアプリケーションで使用される RAM ロールなど) については、担当のビジネスオーナーに連絡して確認してください。

• ポリシー削除の推奨事項については、検出結果詳細ページの [アクセスしたサービス]、[付与されたサービス]、[最終アクセス日時] を確認し、権限が本当に未使用であるかどうかを判断してください。

• 外部アクセスの検出結果については、詳細ページの特定の外部プリンシパルを確認し、そのアクセス関係が業務上必要であるかを確認してください。

適切な変更ウィンドウの選択

権限収束は、実行中のワークロードに影響を与える可能性があります。以下を推奨します：

• ビジネスのピーク時や重要なリリースウィンドウ中に権限の変更を行うことは避けてください。

• オンラインの本番アプリケーションで使用される RAM ID については、まずテスト環境で同等の権限変更の影響を検証してください。

• クロスアカウントリソース (リソースディレクトリのシナリオ) については、事前に対象アカウントの管理者と変更ウィンドウを調整してください。

ロールバック手順の準備

権限収束操作を実行する前に、迅速にロールバックできることを確認してください。具体的な対策は次のとおりです：

• 変更前の状態を記録する：ポリシーを削除する前に、対象の ID に現在アタッチされているすべてのポリシー (ポリシー名とタイプ (システムまたはカスタム) を含む) を記録してください。

• カスタムポリシーのコピーを保持する：カスタムポリシーを削除する前に、ポリシー定義が誤って削除された場合に再権限付与が失敗するのを防ぐため、ポリシーコンテンツをエクスポートしてバックアップしてください。

• ID をすぐに削除しない：非アクティブな RAM ユーザーについては、まずコンソールログインと AccessKey を無効にしてください。エラーが発生した場合に迅速にアクセスを復元できるよう、一定期間様子を見てから削除するかどうかを決定してください。

• ロールバックコマンドを把握しておく：コンソールで実行した権限剥奪操作については、必要に応じて RAM OpenAPI (AttachPolicyToUser, AttachPolicyToRole) を使用して迅速に権限を復元できます。詳細については、このトピックの「ロールバックと回復」セクションをご参照ください。

検出結果

検出結果は、Access Analyzer によって生成されるデータオブジェクトで、以下を含みます：

• 検出結果タイプ：検出結果のカテゴリ。例：

  • スーパーユーザー/ロール

  • 特権ユーザー/ロール

  • 非アクティブなユーザー/ロール

  • 過剰権限を持つユーザー/ロール

• ステータス：検出結果のステータス。有効な値：アクティブ、解決済み、アーカイブ済み。

• リソース情報：対象リソースの名前、タイプ、所有者。

• タイムスタンプ：作成日時、分析日時、更新日時。

• 検出結果 ID：検出結果の一意の識別子。

修正アドバイス

修正アドバイスは、Access Analyzer が検出結果に対して生成するソリューションです：

• 権限の置き換え：広範な権限を付与するポリシーを、より制限的なポリシーに置き換えます。例えば、スーパー管理者権限 (AdministratorAccess) をシステム管理者権限 (PowerUserAccess) に置き換えることができます。

• 権限の削除：未使用のポリシーを削除します。

• ID 管理：非アクティブな ID を無効化または削除します。

• 検出結果のアーカイブ：意図した権限付与の動作に関連する検出結果をアーカイブします。

決定ロジック

Access Analyzer は、以下の優先度で過剰権限アクセスを分類します。RAM ID が複数の条件に一致する場合、最も優先度の高いタイプが適用されます。

前提条件

以下の要件が満たされていることを確認してください：

• Access Analyzer コンソールに、過剰な委任 タイプのアナライザが存在します。

• 必要な権限を持っていること。オペレーターには AliyunRAMAccessAnalyzerFullAccess と AliyunRAMFullAccess ポリシーを付与することを推奨します。

操作手順

1. 検出結果の特定

   1. RAM コンソールにログインします。

   2. 左側のナビゲーションウィンドウで、Access Analyzing > Findings を選択します。

   3. 上部のナビゲーションバーで、アナライザーが配置されているリージョンを選択します。

   4. Findings > データの概要 タブで、非アクティブなユーザー タイプの [アクティブ] な検出結果を見つけ、数字をクリックします。
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      

2. 修正アドバイスの表示と適用

   1. Findings リストで、不要であることを確認した RAM ユーザーを選択し、対応する Finding ID をクリックします。

   2. Findings 詳細ページで、「アクション」列の Advices タブをクリックします。しばらく待つと、システムに「未使用のIDを削除」という提案が表示されます。[ガバナンスに進む] をクリックします。

3. RAM コンソールのユーザー詳細ページにリダイレクトされます。ビジネス要件に応じて、コンソールログインの無効化、AccessKey の無効化、またはユーザーの削除ができます。

4. 結果を検証します。Access Analyzer コンソールに戻ります。検出結果をアーカイブできます。そうしない場合、次の分析サイクル後にステータスが自動的に Resolved に変わります。

特権ユーザー/ロールの修正：未使用の高リスクポリシーの削除

特権ユーザー/ロールの場合、修正アドバイスは未使用の高リスク権限ポリシーを削除することです。手順は「スーパーユーザー/ロールの修正：未使用の権限ポリシーの削除」と同じです。

非アクティブなユーザー/ロールの修正：ID の無効化または削除

非アクティブな ID は、指定された未使用アクセス期間内にアクセスアクティビティがありません。有効な認証情報を持つ長期間アイドル状態の ID は、潜在的なセキュリティリスクです。

行動を起こす前に、次の点を確認してください：ID が季節的または定期的に使用されているか (月末の財務決済や四半期ごとの監査など)。スタンバイまたはディザスタリカバリアカウントであるか (通常は非アクティブですが、フェールオーバー時には重要です)。RAM ロールの場合、バックエンドサービスが例外的な条件下でのみロールを呼び出すか (緊急操作やアラート対応ロールなど)。これらのいずれかに該当する場合は、ID を削除する代わりに検出結果をアーカイブしてください。

ID が不要であることを確認した場合、ベストプラクティスは、まず無効化し、様子を見てから削除することです：

1. Findings > データの概要 または Findings > Findings タブで、非アクティブなユーザー/ロール タイプのエントリを見つけ、特定の Finding ID をクリックします。

2. Findings の詳細ページで、「操作」列の Advices タブをクリックします。

3. Advices パネルで、Remove Unused Principals という提案を探します。

4. リソース所有者に基づいて適切な操作を実行します：

   • 現在のアカウント: Go for Governance をクリックします。RAM コンソールのユーザーまたはロールの詳細ページにリダイレクトされます。ログイン設定をクリアしたり、AccessKey を無効化または削除したり、ID を削除したりできます。

     

   • クロスアカウント: Copy Resource URL をクリックします。ターゲットアカウントにログインし、URL にアクセスしてリクエストを処理します。

     

5. (オプション) アナライザーが修正アドバイスを提供しない場合は、「検出結果に修正アドバイスが表示されないのはなぜですか？」をご参照ください。

過剰権限を持つユーザー/ロールの修正：未使用のポリシーの削除

過剰権限を持つユーザー/ロールの場合、修正アドバイスは未使用の権限ポリシーを削除することです。手順は「スーパーユーザー/ロールの修正：未使用の権限ポリシーの削除」と同じです。

調査ワークフロー

外部アクセスの検出結果を修正する前に、以下の調査手順に従ってください：

1. 外部プリンシパルの特定：検出結果詳細ページで、特定の外部プリンシパルを確認します。OSS バケットの場合、匿名ユーザー (AllUsers) または特定の Alibaba Cloud アカウントが含まれているかを確認します。RAM ロールの場合、信頼ポリシー内の信頼されたエンティティを確認します。

2. アクセスが業務上必要かどうかの判断：外部アクセスが通常の業務連携 (パートナーアカウントのアクセス、グループ内の部門間リソース共有、マルチクラウドアーキテクチャでのクロスアカウントデプロイメントなど) の一部であるかを確認します。

3. 権限範囲が適切であるかの検証：外部アクセスが想定内であっても、付与された権限が最小権限の原則に従っているかを確認します。例えば、パートナーに過度に広範な操作権限が付与されていないかなどです。

4. アカウント間の調整：外部アクセスが他の Alibaba Cloud アカウントを伴う場合、ポリシーを厳格化する前に、アクセス側とリソース所有者の両方とビジネス上の依存関係を確認し、パートナーの業務を中断させないようにします。

OSS バケットの外部アクセスの修正

OSS バケットへの外部アクセスは、通常、バケットポリシー、バケット ACL の設定、または「公開アクセス禁止」設定の欠如に起因します。

外部アクセスが想定内である場合 (例えば、パートナーが特定のバケットを読み取る必要がある場合)：

1. 現在の権限付与が最小権限の原則に従っていることを確認します。例えば、バケットレベルの完全な権限ではなく、必要なオブジェクトレベルの操作 (例：GetObject) のみが付与されていることを検証します。

2. バケットポリシーの権限付与範囲をワイルドカード (*) から特定のアカウント ID または RAM ロールの ARN に絞り込みます。

3. 検出結果をアーカイブして、繰り返しのアラートを防ぎます。

外部アクセスが想定外である場合 (例えば、バケットがパブリックアクセスに設定されている場合)：

1. OSS コンソールに移動し、バケットレベルの「公開アクセス禁止」機能を有効にします。これにより、バケットへのパブリックアクセスがグローバルに防止され、最も迅速な修正措置となります。

2. バケットポリシーを確認し、意図しないクロスアカウント権限付与や匿名アクセス (プリンシパルが * に設定されている) の設定を削除します。

3. バケット ACL を確認し、「パブリック読み取り」または「パブリック読み書き」に設定されていないことを確認します。

4. 変更後、外部アクセスアナライザーが再分析するのを待ち (通常、ポリシー変更後 3～5 分)、検出結果のステータスが「解決済み」に変わることを確認します。

RAM ロールのクロスアカウント信頼の修正

RAM ロールの信頼ポリシーは、どの外部 ID がそのロールを引き受けられるかを決定します。過度に寛容な信頼ポリシーは、クロスアカウントの権限昇格リスクを生み出します。

クロスアカウントの信頼が想定内である場合 (マルチクラウドアーキテクチャでのクロスアカウント権限付与など)：

1. 信頼ポリシーの Condition 要素を確認します。可能な限り制約 (ソース IP 範囲の指定や MFA の要求など) を追加し、認証情報漏洩の影響範囲を縮小します。

2. ロールにアタッチされている権限ポリシーを確認し、それらが最小権限の原則に従っていることを確認します。

3. 検出結果をアーカイブします。

クロスアカウントの信頼が想定外である場合：

1. RAM コンソールに移動し、ロール詳細ページを開き、信頼ポリシーを編集します。

2. 信頼ポリシーの Principal の範囲を、必要なアカウント ID またはサービス識別子のみを含むように絞り込みます。

3. 不要なワイルドカード権限付与や、期限切れのアカウントに対する権限付与を削除します。

4. 変更後、依存する業務システムを監視します。特に、他のアカウントからこのロールを引き受けるアプリケーションに注意してください。厳格化された信頼ポリシーが STS AssumeRole の失敗を引き起こした場合、直ちにポリシーを復元してください。

デタッチされた権限ポリシーの復元

Access Analyzer コンソールを使用してポリシーをデタッチした場合、以下の OpenAPI コマンドを使用して再アタッチします：

• RAM ユーザー：aliyun ram AttachPolicyToUser --PolicyType <System|Custom> --PolicyName <PolicyName> --UserName <UserName>

• RAM ロール：aliyun ram AttachPolicyToRole --PolicyType <System|Custom> --PolicyName <PolicyName> --RoleName <RoleName>

• ユーザーグループ：aliyun ram AttachPolicyToGroup --PolicyType <System|Custom> --PolicyName <PolicyName> --GroupName <GroupName>

無効化された ID の復元

• RAM ユーザー：コンソールログインと AccessKey のみを無効にした場合、ログイン設定を再作成 (CreateLoginProfile) し、AccessKey を再有効化 (UpdateAccessKey --Status Active) します。

• RAM ロール：信頼ポリシーとアタッチされたポリシー情報をバックアップせずにロールを削除した場合、手動で再作成および設定する必要があります。

変更された RAM ロール信頼ポリシーの復元

信頼ポリシーの変更がクロスアカウントの業務上の問題を引き起こした場合、直ちに元の信頼ポリシーを復元してください：

1. RAM コンソールに移動し、ロール詳細ページの [信頼ポリシー] タブを開きます。

2. 元の信頼ポリシーをバックアップしていた場合は、それを直接貼り付け直します。

3. バックアップしていなかった場合は、誤って削除した信頼されたエンティティを手動で再追加します。不明なアカウント ID については、ActionTrail で最近の AssumeRole 呼び出しレコードをクエリして、どの外部 ID が最近正当にロールを引き受けたかを確認します。

アーカイブされた検出結果の復元

誤って検出結果をアーカイブした場合、検出結果リストを [アーカイブ済み] ステータスでフィルターし、エントリを見つけて [アーカイブ解除] をクリックします。検出結果は [アクティブ] ステータスに戻ります。

• アナライザータイプ：この機能は [過剰権限アクセス] タイプのアナライザーのみをサポートし、[外部アクセス] タイプのアナライザーはサポートしません。

• サポートされる粒度：過剰権限アクセスアナライザーは、権限監査情報に基づいて、リソースディレクトリまたは現在のアカウント内のサービスリンクロールを除くすべての RAM ID の権限を分析します。サポートされるポリシータイプ、クラウドサービス、および粒度は、権限監査と同じであり、「権限監査機能と連携するサービス」に記載されています。ポリシーにサポートされていないサービスの権限が含まれている場合、アナライザーは権限削除の修正アドバイスを提供できません。

• ポリシータイプ (スーパー管理者置き換えのみ)：スーパー管理者の権限を置き換えるための修正アドバイスは、AdministratorAccess システムポリシーのみをサポートします。カスタム管理者ポリシーはサポートされていません。

• ポリシーコンテンツ：ポリシーに Deny または NotAction ステートメントが含まれている場合、アナライザーは権限削除の修正アドバイスを提供できません。

• 権限付与範囲：管理者権限の権限付与範囲が アカウント ではなく Resource Group である場合、その ID はスーパー管理者として識別されません。

• 権限付与方法：権限はユーザーまたはロールに直接付与されるか、ユーザーグループを通じて継承されます。アナライザーは両方の権限付与方法を識別できますが、ユーザーグループから継承された権限に対する自動修正アドバイスは提供しません。これらの検出結果は手動で修正する必要があります。

• データ遅延：修正アドバイスは検出結果から生成され、最大 24 時間のデータ遅延が発生する可能性があります。アドバイスの適時性が重要な場合は、検出結果詳細ページで Rescan をクリックして手動で再スキャンをトリガーし、再度アドバイスを確認できます。

  

よくある質問