アクセスキーペアは、Alibaba Cloud API を呼び出す際にアイデンティティを認証するための認証情報です。アクセスキーペアが漏洩すると、アカウント配下のすべてのリソースが危険にさらされ、予期せぬ請求や身代金の要求、さらには深刻な場合には Alibaba Cloud や他のユーザーに損害を与える可能性があります。認証情報の不正使用リスクを軽減するために、漏洩が疑われる場合は以下の手順に従って対応してください。
Alibaba Cloud のセキュリティ対策
Alibaba Cloud は、クラウドサービスのセキュリティを継続的に強化し、お客様のアカウント保護を支援しています。外部からの情報に基づき、お客様のアクセスキーペアが公に漏洩したことを Alibaba Cloud が検知した場合、登録された連絡先を通じて速やかにお客様に通知します。お客様のビジネスとデータを保護するため、Alibaba Cloud は侵害されたアクセスキーペアに対して制限的な保護を適用し、特定のクラウドサービスの高リスク API の呼び出しをブロックします。詳細については、「AccessKey の制限的保護」をご参照ください。
テキストメッセージ、メール、およびコンソール内のメッセージで送信される通知を監視してください。ビジネスニーズに基づいて迅速に対応し、サービスの中断を避けるためにクラウドリソースの異常なアクティビティに注意してください。
Alibaba Cloud は、すべてのお客様のアクセスキーペアのセキュリティ状態を監視することはできません。責任共有モデルに基づき、アクセスキーペアはお客様のアカウントのアイデンティティ認証情報の一部であり、そのセキュリティについてはお客様が全責任を負います。常に警戒を怠らないでください。
AccessKey の漏洩により RAM ユーザーがログインできなくなったり、アカウントが凍結されたりした場合はどうすればよいですか？
Alibaba Cloud が AccessKey の漏洩リスクを検知すると、セキュリティシステムが自動的に保護メカニズムを発動し、関連する RAM ユーザーのコンソールへのログインを制限することがあります。この場合、Authentication.Block.AccountFrozen や "The current account is not allowed to log on." のようなエラーメッセージが表示されることがあります。
この問題を解決するには、以下の手順を実行します。
Alibaba Cloud アカウント (ルートアカウント) で RAM コンソール にログインします。漏洩した AccessKey を直ちに無効化または削除し、新しい AccessKey を作成してローテーションを完了します。AccessKey を単に無効化するだけでは制限が解除されない場合があるため、削除またはローテーションする必要があります。
AccessKey の処理を完了した後も RAM ユーザーがログインできない場合は、チケットを起票してセキュリティリスク管理による制限の解除をリクエストしてください。
Alibaba Cloud アカウント (ルートアカウント) の AccessKey 漏洩が疑われる場合の手動対応手順
AccessKey が既に使用されていない場合は、AccessKey 管理ページに移動し、直ちに無効化または削除します。
AccessKey がまだ使用中の場合は、AccessKey 管理ページに移動し、ローテーションします。
新しい AccessKey を作成し、AccessKey シークレットを安全に保管します。アプリケーション内の古い AccessKey を新しいものに置き換えます。すべてが正常に動作することを確認した後、古い AccessKey を無効化して削除します。
RAM ユーザーの AccessKey 漏洩が疑われる場合の手動対応手順
AccessKey が既に使用されていない場合は、Resource Access Management (RAM) コンソールに移動し、RAM ユーザーの AccessKey を無効化または削除します。手順については、「RAM ユーザーの AccessKey の無効化」および「RAM ユーザーの AccessKey の削除」をご参照ください。
AccessKey が使用中であり、すぐにローテーションできる場合は、できるだけ早くローテーションします。
新しい AccessKey を作成し、AccessKey シークレットを安全に保管します。アプリケーション内の古い AccessKey を新しいものに置き換えます。正常な動作を確認した後、古い AccessKey を無効化して削除します。手順については、「RAM ユーザーの AccessKey のローテーション」をご参照ください。
AccessKey が使用中であるものの、すぐにローテーションできない場合は、以下の手順に従って潜在的な損害を最小限に抑えます。その後、できるだけ早くローテーションを完了してください。
ステップ 1：AccessKey 権限の縮小
ビジネス要件を特定し、現在の運用を中断することなく、疑わしいアクセスキーペアの権限を迅速に縮小します。高リスクな権限を制限することで、ビジネスと課金への潜在的な損害を最小限に抑えます。この制限的なポリシーは、アクセスキーペアを無効化して削除するまで維持してください。
制限を推奨する高リスク権限：RAM ユーザーによる 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 デバイスをバインドします。
手順については、「RAM ユーザーへの MFA デバイスのバインド」をご参照ください。
ステップ 3：AccessKey の異常な操作の確認
アクセスキーペアの異常なアクティビティを確認し、他のアイデンティティも侵害されている可能性がないか調査します。異常なソース IP アドレスや、通常の業務外でのリソース作成・削除アクションに焦点を当ててください。
漏洩が疑われる期間中に調査すべき危険な操作：
アイデンティティと権限の変更：RAM ユーザーの作成 (
CreateUser)、AccessKey の作成 (CreateAccessKey)、ポリシーのアタッチ (AttachPolicyToUser)、ロールの作成 (CreateRole)、およびコンソールログインの有効化 (CreateLoginProfile)。CreateLoginProfile、AttachPolicyToUser、CreateUserなどのイベントは、通常、攻撃者がバックドアアカウントを作成したり、権限昇格を行ったりしていることを示します。これらの API 呼び出しのソース IP アドレスと UserAgent に細心の注意を払ってください。リソースの削除または解放：ECS インスタンスの削除 (
DeleteInstance)、RDS インスタンスの削除 (DeleteDBInstance)、および OSS バケットの削除 (DeleteBucket)。データ窃取アクション：OSS バケット ACL の変更 (
PutBucketAcl) またはバケットポリシーの変更 (PutBucketPolicy)。異常な API 動作：短時間での大量の API 呼び出し、見慣れない IP アドレスやリージョンからの操作、または通常の業務時間外のバッチ操作。
確認方法：Resource Access Management (RAM) コンソールで、RAM ユーザーの AccessKey リストを見つけ、操作記録を確認します。または、ActionTrail コンソールの [AccessKey 監査]ページに移動し、AccessKey ID を入力してその操作履歴を照会します。
ActionTrail に加えて、Security Center コンソール にログインして、悪意を持って作成された RAM ユーザー名、異常な呼び出し元 IP アドレス、その他の関連情報など、AccessKey 漏洩アラートの詳細を表示できます。
ActionTrail の AccessKey 監査機能は、特定のアクセスキーペアが過去 90 日間に行ったすべての API 呼び出し (呼び出し時刻、アクション名、ソース IP アドレス、アクセスされたクラウドサービスを含む) を表示します。手順については、「ActionTrail を使用した AccessKey 使用状況のモニタリング」をご参照ください。
説明OSS や SLS など、ActionTrail の対象外であるデータ関連の操作については、各クラウドサービスのロギング機能を使用して調査してください。
漏洩の範囲を確認するには、セキュリティメール、テキストメッセージ、またはコンソール内メッセージで送信された通知を確認し、漏洩した特定の AccessKey ID を特定します。通知が 1 つの AccessKey のみに言及しており、他のアラートが発生していない場合、通常はその特定の AccessKey のみが漏洩しています。
また、既知の侵害されたキー以外に、他の RAM ユーザーやアクセスキーペアに異常なアクティビティの兆候がないか確認してください。不審な動作が見つかった場合は、関連担当者にそのアクションが承認されたものか確認します。漏洩が疑われる場合は、以下の措置を講じてください。
RAM ユーザーをアクティブにしておく必要がある場合は、直ちにパスワードを変更し、多要素認証 (MFA) を有効化します。
RAM ユーザーが正規に作成されたものでない、または不要になった場合は、削除します。削除された RAM ユーザーはごみ箱に移動します。ビジネスへの影響を監視し、必要に応じてユーザーを迅速に復元します。
AccessKey の異常なアクティビティについては、上記のように権限を制限し、キーをローテーションします。
ステップ 4：異常な請求の確認
費用とコスト で、予期せぬ請求がないか確認します。前のステップでの調査結果に基づき、影響を受けたサービスに対して的を絞った保護措置を講じます。
悪意を持って作成された RAM ユーザーを削除するだけでは、漏洩リスクを排除するには不十分です。中心的なリスクは、Alibaba Cloud アカウント (ルートアカウント) または高権限の RAM ユーザーの AccessKey が既に漏洩していることです。攻撃者は漏洩した AccessKey を使用して、継続的に新しいユーザーを作成したり、権限昇格を行ったりする可能性があります。AccessKey をローテーションする必要があります。つまり、新しいキーを作成し、すべてのアプリケーションで古いキーを置き換え、その後、古い AccessKey を無効化して削除します。また、ソースコード、設定ファイル、サーバーのセキュリティ脆弱性など、漏洩経路を調査する必要もあります。そうしないと、リスクは存続します。
プライベートリポジトリ、Nacos、またはオフラインデータベースに保存しているにもかかわらず、AccessKey が漏洩として検出されるのはなぜですか？
AccessKey が安全に保管されていると考えていても、以下の一般的な経路を通じて漏洩する可能性があります。
コードリポジトリ：プライベートリポジトリが以前に公開されていた、フォークされた、または協力者がコードを別の場所にアップロードした場合、AccessKey はスキャンサービスによって検出される可能性があります。
設定センター (Nacos など)：設定センターに適切なアクセス制御がなく、既知の脆弱性がある、またはサーバーが侵害された場合、平文で保存されている AccessKey が盗まれる可能性があります。
オフラインストレージ：AccessKey を読み取るアプリケーションやスクリプトが API を呼び出すためにインターネットに接続する場合、キーが送信中に傍受されたり、ログに記録されたりする可能性があります。
アプリケーションの脆弱性：リモートコード実行 (RCE) や任意のファイル読み取りの脆弱性により、攻撃者はサーバー上の設定ファイルから AccessKey を盗むことができます。
将来の漏洩を防ぐには、以下の対策を講じてください。
AccessKey をハードコーディングする代わりに、認証情報ツールを使用して認証情報を管理してください。
AccessKey にネットワークアクセス制限 (IP 許可リスト) を設定してください。
ソースコードや設定ファイルに AccessKey を直接埋め込むことを避けてください。
長期的な AccessKey 漏洩防止戦略
「アクセス認証情報を使用した Alibaba Cloud OpenAPI 呼び出しのベストプラクティス」をご参照ください。
別のアカウントに属する AccessKey の緊急無効化をリクエストできますか？
プライバシー保護と権限分離ポリシーのため、Alibaba Cloud は漏洩報告に基づいて、現在ログインしているアカウントに属さない AccessKey を直接無効化することはできません。推奨されるアクションは以下の通りです。
AccessKey がどのアカウントに属しているかわかっている場合は、アカウント所有者に連絡し、対応を依頼してください。
AccessKey に関連付けられたアカウントにアクセスできる場合は、
DeleteAccessKeyAPI または RAM コンソールを使用して、ご自身でキーを削除してください。アクセスできない他のアカウントに属する AccessKey については、法務またはセキュリティコンプライアンスのチャネルを通じて対応を調整してください。