Resource Access Management:AccessKey の漏洩対応計画

Alibaba Cloud アカウント (ルートアカウント) の AccessKey ペアが漏洩した場合の対応

• AccessKey ペアが使用されなくなった場合 — [AccessKey 管理] ページに移動し、AccessKey ペアを直ちに無効化して削除します。

• AccessKey ペアが使用中の場合 — [AccessKey 管理] ページで AccessKey ペアをローテーションします。

  1. 新しい AccessKey ペアを作成し、AccessKey シークレットを安全に保管します。

  2. 元の AccessKey ペアを新しいものに置き換えます。

  3. すべてが正常に動作することを確認した後、元の AccessKey ペアを無効化して削除します。

元の AccessKey ペアを削除する前に、「AccessKey ペアの使用範囲の特定」で説明されているように、その使用範囲を特定します。AccessKey ペアをローテーションまたは削除した後、「不正なアクティビティの調査」と「不正な課金の確認」の手順を完了します。

RAM ユーザーの AccessKey ペアが漏洩した場合の対応

適切な対応は、AccessKey ペアがまだ使用中であるか、また、もし使用中であれば短期間でローテーションできるかによって異なります。AccessKey ペアをローテーションできる場合は、ローテーションが推奨される対応です。

AccessKey ペアが使用されなくなった場合

RAM コンソールに移動し、AccessKey ペアを無効化して削除します。手順については、「RAM ユーザーの AccessKey の無効化」と「RAM ユーザーの AccessKey の削除」をご参照ください。

AccessKey ペアを無効化する際、コンソールでは [セキュリティ認証] (多要素認証、MFA) を完了する必要があります。認証が成功した場合にのみ、AccessKey ペアのステータスが [無効] になります。AccessKey ペアが過去 60 日以内に使用されている場合、コンソールは無効化するとビジネスに支障をきたす可能性があると警告します。続行する前に、その AccessKey ペアに依存するビジネスがないことを確認してください。

AccessKey ペアが使用中で、ローテーションが可能な場合 (推奨)

できるだけ早く AccessKey ペアをローテーションしてください。

1. [AccessKey の作成] をクリックします。[シナリオ] ダイアログボックスで、[CLI]、[ローカル開発]、[ECS]、[ACK]、[サードパーティアプリケーション]、[その他] の中から実際の使用状況に合ったシナリオを選択します。

2. 新しい AccessKey ペアを作成し、AccessKey シークレットを安全に保管します。

3. 元の AccessKey ペアを新しいものに置き換えます。

4. すべてが正常に動作することを確認した後、古い AccessKey ペアを無効化して削除します。

   手順については、「RAM ユーザーの AccessKey のローテーション」をご参照ください。

AccessKey ペアを削除する際は、[AccessKey ID] を手動で入力して 2 回目の確認を完了する必要があります。AccessKey ペアが無効化されてから 7 日未満の場合、コンソールは削除するとビジネスに支障をきたす可能性があると警告します。続行する前に、その AccessKey ペアに依存するビジネスがないことを確認してください。削除された AccessKey ペアはすぐには破棄されません。[ごみ箱] に移動され、30 日間保持された後、自動的に消去されます。AccessKey ペアを復元するには、保持期間内に操作してください。

AccessKey ペアは使用中だが、短期間でのローテーションが不可能な場合

AccessKey ペアが使用中であることを確認したものの、短期間で円滑にローテーションできない場合は、以下の図に示す手順に従って不正利用の影響を軽減してください。その後、できるだけ早くローテーションを完了してください。

ステップ1：AccessKey ペアの権限の縮小

まず、ビジネスシナリオを特定します。現在の運用を中断することなく、疑わしい AccessKey ペアの権限をできるだけ早く縮小してください。高リスクの権限を制限して、ビジネスや請求への損害リスクを低減します。この制限ポリシーは、AccessKey ペアが無効化され削除されるまで解除しないでください。

制限を推奨する高リスクの権限には、RAM での新規 RAM ユーザーの作成や権限付与の防止、ECS、RDS、OSS、SLS リソースの解放のブロック、SMS 送信のブロックなどがあります。

以下の例は、高リスクのアクションを拒否するカスタムポリシーを示しています：その影響を十分に評価し、ビジネスニーズに基づいて調整してください。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ram:AddUserToGroup",
        "ram:AttachPolicyToGroup",
        "ram:AttachPolicyToRole",
        "ram:AttachPolicyToUser",
        "ram:ChangePassword",
        "ram:CreateAccessKey",
        "ram:CreateLoginProfile",
        "ram:CreatePolicyVersion",
        "ram:CreateRole",
        "ram:CreateUser",
        "ram:DetachPolicyFromUser",
        "ram:PassRole",
        "ram:SetDefaultPolicyVersion",
        "ram:UpdateAccessKey",
        "ram:SetPasswordPolicy",
        "ram:UpdateRole",
        "ram:UpdateLoginProfile",
        "ram:UpdateUser"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "ecs:DeleteInstance",
        "ecs:DeleteInstances",
        "ecs:DeregisterManagedInstance",
        "ecs:ReleaseDedicatedHost"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "rds:DeleteAccount",
        "rds:DeleteDatabase",
        "rds:DeleteDBInstance",
        "rds:DestroyDBInstance"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "oss:DeleteBucket",
        "oss:DeleteObject",
        "oss:PutBucketAcl",
        "oss:PutBucketPolicy"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "log:DeleteLogStore",
        "log:DeleteProject",
        "log:PutProjectPolicy",
        "log:DeleteProjectPolicy"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "dysms:CreateProductNew",
        "dysms:CreateSmsTemplateNew",
        "dysms:AddSmsTemplate",
        "dysms:SendSms",
        "dysms:SendBatchSms"
      ],
      "Resource": "*"
    }
  ]
}

手順については、「カスタムポリシーの作成」と「RAM ユーザーの権限管理」をご参照ください。

AccessKey ペアが必要とするビジネス権限を明確に定義し、不要な権限はすべて削除してください。

ステップ2：RAM ユーザーの MFA を有効化

ベストプラクティスとして、コンソールにアクセスする Alibaba Cloud アカウント (ルートアカウント) 配下のすべての RAM ユーザーに対して、多要素認証 (MFA) を有効化してください。

• ルートアカウント配下の RAM ユーザーがコンソールにログインする際に MFA を要求します。手順については、「RAM ユーザーのログインに MFA を要求」をご参照ください。

• ユーザーに MFA デバイスをバインドします。手順については、「RAM ユーザーへの MFA デバイスのバインド」をご参照ください。

  権限を縮小し MFA を有効化した後、「不正なアクティビティの調査」、「AccessKey ペアの使用範囲の特定」、および「不正な課金の確認」の手順を完了します。その後、できるだけ早くローテーションを完了してください。

不正なアクティビティの調査

漏洩した AccessKey ペアに不正なアクティビティがないか確認し、他のアイデンティティにも漏洩の疑いがないか調査します。ビジネスに不要な、異常なソース IP アドレスやリソースの作成・削除操作に焦点を当ててください。

漏洩期間中に調査すべき危険な操作は以下の通りです：

• アイデンティティと権限の変更：RAM ユーザーの作成 (CreateUser)、AccessKey ペアの作成 (CreateAccessKey)、アクセスポリシーのアタッチ (AttachPolicyToUser)、ロールの作成 (CreateRole)、コンソールログオンの有効化 (CreateLoginProfile)。CreateLoginProfile、AttachPolicyToUser、CreateUser などのイベントは、通常、攻撃者がバックドアアカウントを作成したり、権限昇格を行ったりしていることを示します。これらの呼び出しのソース IP アドレスと UserAgent に細心の注意を払ってください。

• リソースの削除と解放：ECS インスタンスの削除 (DeleteInstance)、RDS インスタンスの削除 (DeleteDBInstance)、OSS バケットの削除 (DeleteBucket)。

• データ窃取：OSS バケットのアクセス権限の変更 (PutBucketAcl)、OSS バケットポリシーの変更 (PutBucketPolicy) など、類似の操作。

• 異常な呼び出し動作：短期間での大量の API リクエスト、通常とは異なる IP アドレスやリージョンからの操作、および業務時間外のバッチ操作。

  確認するには、RAM コンソールで、RAM ユーザーの AccessKey リストを見つけ、リスト内の操作記録を表示するか、ActionTrail コンソールの [AccessKey 監査] ページで AccessKey ID を入力して、操作記録を直接照会します。

ActionTrail に加えて、Security Center コンソールにログインして、悪意を持って作成された RAM ユーザーの名前や不正な呼び出し元 IP アドレスなど、AccessKey 漏洩アラートの詳細を表示できます。

ActionTrail の AccessKey 監査機能は、指定された AccessKey ペアの過去 90 日間のすべての API 呼び出し (呼び出し時刻、アクション名、ソース IP アドレス、アクセスしたクラウドサービスを含む) を表示します。手順については、「AccessKey 監査」をご参照ください。

OSS や SLS のように、ActionTrail に接続されていないデータプレーンの操作ログについては、各クラウドサービスのログ機能を使用して照会します。

既知の漏洩リスクがある AccessKey ペア以外に、他の RAM ユーザーや AccessKey ペアに不正なアクティビティがないか、さらに調査します。不正な動作が見つかった場合は、関係者にその操作が本人によるものか確認してください。漏洩が疑われる場合は、以下のように対応します：

• RAM ユーザーを引き続き使用する必要がある場合は、直ちに RAM ユーザーのパスワードを変更し、多要素認証 (MFA) を有効化します。

• RAM ユーザーが正規に作成されたものでないか、不要になったアイドルユーザーであることが確認された場合は、削除します。削除された RAM ユーザーはごみ箱に移動されます。ビジネスに影響がないか監視してください。影響がある場合は、RAM ユーザーを迅速に復元できます。

• AccessKey ペアの不正なアクティビティについては、まず権限を制限し、その後ローテーションします。

AccessKey ペアの使用範囲の特定

ActionTrail によって記録されたソース IP アドレスは、OSS の管理操作 GetService や GetBucketInfo などの管理系イベントの呼び出しのみを反映します。OSS オブジェクトのアップロードやダウンロードなど、ActionTrail に接続されていないデータプレーンの操作は、デフォルトでは記録されません。したがって、ソース IP リストだけでは AccessKey ペアの完全な使用範囲を明らかにすることはできません。元の AccessKey ペアを無効化または削除する前に、以下の各環境で AccessKey の設定を確認してください：

• ローカル開発マシン — 開発者の環境変数、SDK 設定ファイル、CLI 認証情報ファイル。

• CI/CD パイプライン — ビルドジョブの環境変数、認証情報ストア、デプロイスクリプト。

• サードパーティおよび SaaS アプリケーション — Alibaba Cloud API を呼び出す外部プラットフォームに付与された認証情報。

• コンテナとイメージ — コンテナイメージレイヤー、Kubernetes Secrets、オーケストレーションテンプレート内の認証情報。

• スケジュールされたジョブと運用スクリプト — サーバーの crontab エントリ、バックアップスクリプト、監視コレクター。

• メッセージングおよび通知サービス — テキストメッセージを送信するためにショートメッセージサービスを呼び出すアプリケーションなどの呼び出し元。

  これらの環境すべてを新しい AccessKey ペアに置き換え、ビジネスが正常に動作することを確認した後、元の AccessKey ペアを無効化または削除します。これにより、見落とされた呼び出し元による業務中断を防ぐことができます。

不正な課金の確認

課金管理で、不正な課金が発生していないか確認します。影響を受けたサービスについては、調査中に特定した不正なアクティビティに基づいて保護措置を講じます。

AccessKey の漏洩が原因で RAM ユーザーがログインできない、またはアカウントが凍結された場合はどうすればよいですか？

Alibaba Cloud セキュリティシステムが AccessKey ペアの漏洩リスクを検知すると、関連する RAM ユーザーがコンソールにログインするのを制限する保護メカニズムが自動的に作動します。その結果、Authentication.Block.AccountFrozen や "The current account is not allowed to log on." のようなエラーメッセージが表示されることがあります。

この問題を解決するには、以下の手順を実行します：

1. Alibaba Cloud アカウント (ルートアカウント) で RAM コンソールにログインします。漏洩した AccessKey ペアを直ちに無効化または削除し、新しい AccessKey ペアを作成してローテーションを完了します。AccessKey ペアを無効化するだけでは、制限が解除されない場合があります。削除またはローテーションする必要があります。

2. AccessKey ペアを処理した後も RAM ユーザーがログインできない場合は、チケットを起票してセキュリティリスク管理の制限解除をリクエストしてください。

AccessKey ペアをプライベートリポジトリ、Nacos、またはオフラインデータベースに保存しているにもかかわらず、漏洩が検知されるのはなぜですか？

AccessKey ペアを安全に保管していると考えていても、以下の一般的な経路を通じて検知または窃取される可能性があります：

• コードリポジトリ — プライベートリポジトリが以前に公開されていた、フォークされた、または協力者がコードを別の場所にアップロードした場合、AccessKey ペアはスキャンサービスによって検知される可能性があります。

• 設定センター (Nacos など) — 設定センターにアクセス制御がない、脆弱性がある、またはサーバーが侵害された場合、プレーンテキストで保存されている AccessKey ペアが窃取される可能性があります。

• オフラインストレージ — AccessKey ペアを読み取るアプリケーションやスクリプトが API を呼び出すためにインターネットに接続する場合、キーが送信中に傍受されたり、ログレコードに書き込まれたりする可能性があります。

• アプリケーションの脆弱性 — リモートコード実行 (RCE) や任意のファイル読み取りの脆弱性により、攻撃者がサーバー上の設定ファイルから AccessKey ペアを窃取する可能性があります。

  将来の漏洩を防ぐには、以下の対策を講じます：

• AccessKey ペアをハードコーディングするのではなく、認証情報ツールを使用して認証情報を管理します。

• AccessKey ペアのネットワークアクセス制限 (IP ホワイトリスト) を設定する。

• AccessKey ペアをソースコードや設定ファイルに直接書き込まないようにします。

別のアカウントに属する AccessKey ペアの緊急無効化をリクエストできますか？

プライバシー保護と権限の分離のため、Alibaba Cloud は、漏洩報告に基づいて、現在ログインしているアカウントに属さない AccessKey ペアを直接無効化することはできません。以下のように対応してください：

1. AccessKey ペアを所有するアカウントがわかっている場合は、アカウント所有者に連絡し、対応を依頼してください。

2. AccessKey ペアを所有するアカウントにアクセスできる場合は、DeleteAccessKey API または RAM コンソールを使用して、ご自身でキーを削除してください。

3. アクセスできない他のアカウントに属する漏洩した AccessKey ペアについては、法務またはセキュリティコンプライアンスのチャネルを通じて対応を調整してください。