Security Center は、GitHub の公開ソースコードをリアルタイムで監視し、Alibaba Cloud アカウントまたは RAM ユーザーに属する AccessKey ペア (以下、AK) が漏洩していないかを検出し、アラートを提供します。このトピックでは、AccessKey ペア漏洩検出の仕組みと、漏洩への対処方法について説明します。
仕組み
範囲
-
検出プラットフォーム:GitHub の公開ソースコードにおける AccessKey ペア漏洩の検出のみをサポートします。その他のコードホスティングプラットフォームはサポートされていません。
-
検出対象:Alibaba Cloud アカウント (メインアカウント) および RAM ユーザーの AccessKey ペア。AccessKey ID と AccessKey Secret の両方が含まれます。
通知方法
Security Center は、漏洩した AccessKey Secret (以下、SK) が有効かどうかに応じて、異なる通知方法を使用します。
第三者がアカウント配下のすべてのリソースを制御できるようになるのは、AccessKey ID と AccessKey Secret の両方が漏洩した場合のみです。
|
通知条件 |
通知方法 |
|
AccessKey ID が漏洩した場合 (AccessKey Secret の有効性に関係なく)。 |
[AccessKey Leak Detection]ページでのアラート |
|
AccessKey Secret が漏洩し、かつ有効な場合。 |
|
AccessKey 漏洩アラート通知の設定
Security Center は、デフォルトで AccessKey 漏洩アラート通知を有効にしています。アラートは、SMS、音声通話、メール、およびサイト内メッセージで送信できます。
通知方法の変更
-
Security Center コンソール - システム設定 - 通知設定にアクセスします。ページ左上部で、保護対象のアセットが配置されているリージョンを選択します:[中国本土] または [中国本土以外]。
-
メール / サイト内通知 タブで、AccessKey Leak Detection を見つけ、必要な 通知方法 を選択します。
AccessKey の漏洩は高いリスクをもたらします。タイムリーな通知を確実にするため、すべての通知方法を選択することを推奨します。詳細については、「アラート通知の設定」をご参照ください。
通知受信者の追加
デフォルトでは、アカウントの連絡先のみが通知を受信します。他の受信者を追加するには、次のいずれかの方法を使用します。
-
SMS、メール、およびサイト内メッセージ:
基本受信管理ページで、[セキュリティメッセージ] > [Cloud Shield セキュリティ情報通知] セクションのメッセージ受信者を変更します。
説明ここでメッセージ受信者を変更すると、Security Center の他の通知項目、および Anti-DDoS や Web Application Firewall などの製品の通知項目にも変更が適用されます。
詳細については、「イベントアラートの設定」をご参照ください。
AccessKey ペア漏洩イベントへの対処
AccessKey ペア漏洩アラートを受信したことは、お使いの Alibaba Cloud アカウントまたは RAM ユーザーの AK および SK 情報が漏洩したことを意味します。次の手順に従って対処してください。
ステップ1:漏洩の手動処理
Security Center は AccessKey ペア漏洩イベントの自動処理をサポートしていません。まず、次の操作を外部で完了する必要があります。
-
GitHub で漏洩したコンテンツを削除または非表示にする:関係者に連絡して、AccessKey ペア情報を含むファイル、リポジトリ、またはコードを削除または非表示にします。
-
RAM コンソールで漏洩した AccessKey を処理する:漏洩した AccessKey を削除または無効化し、新しいものを作成します。コアビジネス運用に影響がないことを確認してください。詳細については、「RAM ユーザーの AccessKey ペアを削除する」および「RAM ユーザーの AccessKey ペアを無効化する」をご参照ください。
漏洩した AccessKey を処理する際は、次の点に注意してください。
-
AccessKey の無効化は即時に反映されます:RAM コンソールで AccessKey ペアを無効化すると、変更は即座に反映されます。AccessKey は API 呼び出しに使用できなくなり、それを使用した操作は即座にブロックされます。
-
AccessKey を無効化した後もアラートを受信する場合があります:AccessKey を無効化した後も、それを使用した呼び出しは失敗しますが、キーレコードがまだ存在するため、Security Center は漏洩リスクを検出し続け、アラートを送信する場合があります。AccessKey がもう使用されていないことを確認した場合は、無効化した後に AccessKey を [削除] して、アラートを完全に排除することを推奨します。
-
ビジネスへの影響を評価し、ローテーション戦略を計画する:AccessKey を無効化または削除する前に、Kubernetes (K8s) クラスターやその他のサービスの認証情報として設定されているなど、キーがビジネスでまだ使用されているかどうかを確認してください。AccessKey がまだ使用されている場合は、まず新しい RAM ユーザー AccessKey を作成し、関連するビジネス設定で置き換え、新しいキーが期待どおりに機能することを確認してから、古い AccessKey を無効化および削除することを推奨します。これにより、オンラインサービスへの影響を回避できます。
-
ローテーションが不可能な場合の一時的な制御:特定の理由で AccessKey ローテーションを完了できない場合は、ビジネス要件に基づいてアクセス制御ポリシー (IP アドレスホワイトリスト) を設定し、指定されたビジネス IP アドレスからのアクセスのみを許可することで、一時的な軽減策とすることができます。
説明ここで言及されている IP アドレスホワイトリストは、ネットワーク側のアクセス制御ポリシーを指します。これは、コンソールで誤検知イベントをマークするために使用されるアラートホワイトリスト (このトピックの「AccessKey ペア漏洩イベントへの対処」で説明されている [ホワイトリストに追加] 対処方法) とは異なります。両者を混同しないでください。
-
ステップ2:コンソールでの処理ステータスのマーク
手動処理を完了した後、Security Center コンソールで AccessKey アラートイベントのステータスをマークします。
-
対象イベントの 処理 列で 操作する をクリックし、次のいずれかの処理方法を選択して、今すぐ処理 をクリックします。
|
対処方法 |
適用シナリオ |
|
手動で削除しました |
漏洩した AccessKey は使用されなくなり、削除されました。 |
|
AK を手動で無効化しました |
漏洩した AccessKey はまだ使用する必要がありますが、一時的に無効化する必要があります。この方法を選択した後、RAM コンソールで AccessKey を再度有効化できます。 説明
AccessKey が RAM コンソールですでに無効化されている場合、Security Center は無効化状態を自動的に同期し、AccessKey 漏洩イベントのステータスが 手動で無効化済み に変更されます。 |
|
ホワイトリストを追加する |
イベントは誤検知であるか、安全に無視できます。このオプションを選択すると、ステータスが ホワイトリストに追加済み に変更され、イベントは処理済みリストに移動します。 検出を再開する必要がある場合は、処理済みリストから AccessKey ペア漏洩詳細ページに移動し、ホワイトリストを削除します。 |
AccessKey 呼び出し記録の確認
AccessKey 呼び出し記録を確認することで、漏洩した AccessKey が攻撃者に悪用されたかどうかを判断し、影響の範囲を把握できます。次の手順では、ActionTrail を使用して AccessKey 呼び出しイベントを時系列で確認する方法について説明します。
特定のクラウドサービスにアクセスする AccessKey の呼び出し記録を確認するには、ActionTrail の AccessKey 監査機能を使用できます。詳細については、「AccessKey ペアのログをクエリする」をご参照ください。
-
Security Center コンソールの AccessKey Leak Detection ページで、クエリする AccessKey ID を取得します。
-
ActionTrail コンソールにログインします。
-
左側メニューで、 を選択します。
-
上部メニューで、イベントをクエリするリージョンを選択します。
-
クエリタイプを AccessKey ID に設定し、クエリする AccessKey ID を入力して、時間範囲を指定します。
-
AccessKey ID によって呼び出されたイベントのリストを確認します。対象イベントの [操作] 列で [詳細を表示] をクリックして、詳細なイベント記録を確認します。
管理イベントのパラメータの詳細については、「管理イベント構造」をご参照ください。
呼び出し記録を確認する際は、次のアプローチを使用して潜在的な攻撃を調査し、その発信元を追跡してください。
-
発信元が内部 IP アドレスかどうかを確認する:AccessKey 呼び出しの発信元 IP アドレスが Alibaba Cloud 内部 IP アドレスである場合、クラウドホストが侵害され、ゾンビマシンになっている可能性があります。関連するクラウドホストのセキュリティステータスを直ちに確認し、ホスト保護を強化することを推奨します。
-
悪意のある RAM ユーザーの作成を追跡する:攻撃者が漏洩した AccessKey を使用して悪意のある RAM ユーザーを作成したと疑われる場合は、ActionTrail の詳細またはアラートメール (異常な AccessKey、IP アドレス、および時刻) を使用して、API 呼び出しを通じて RAM ユーザーを作成するために使用された AccessKey を確認し、RAM ユーザーがコンソールログインによって作成されたか、API 呼び出しによって作成されたかを判断できます。
-
アラートに表示された API タイプが期待する製品と異なる場合があります:異常な AccessKey 呼び出しアラートに表示される API タイプ (例:
Ecs:DescribeInstances) は、期待する製品 (例:OSS) と異なる場合があります。アラートに実際に表示されている API を使用し、ActionTrail で対応する製品の呼び出し記録をクエリしてください。そうしないと、誤った製品のログを確認し、潜在的なリスクを見逃す可能性があります。 -
リスク評価の境界:呼び出し記録で、攻撃者がリソース情報をクエリするために API 呼び出しのみを使用した (例:
Describe操作のみを呼び出した) ことが示されている場合、これは通常、さらなる侵入に直接つながることはありません。これを使用して、漏洩の影響を合理的に評価できます。
-
異常な AccessKey 呼び出しの監視
AccessKey ペア漏洩イベントを処理した後、異常な AccessKey 呼び出しを継続的に監視して、同様のインシデントを防止し、漏洩が発生したときに迅速に対応し、影響を最小限に抑えることを推奨します。
呼び出されたAPIの説明
呼び出されたAPIは、AccessKey を使用した API 呼び出しを通じてアクセスされる特定のクラウドサービス操作です。API 名は {製品プレフィックス}:{API名} の形式を使用します。ここで:
-
製品プレフィックス:Alibaba Cloud 製品名に対応します。例えば、Ecs は ECS に、Oss は OSS に、Rds は RDS にマッピングされます。
-
API 名:特定の API 操作に対応します。例えば、DescribeRegions は利用可能なリージョンのクエリにマッピングされます。
次の表に、一般的な API 名とそれに対応する製品を示します。
|
API 名 |
製品 |
操作の説明 |
|
Ecs:DescribeRegions |
ECS |
利用可能なリージョンをクエリする |
|
Oss:GetBucket |
OSS |
バケット情報を取得する |
|
Rds:DescribeDBInstances |
RDS |
データベースインスタンスのリストをクエリする |
攻撃者の視点からの異常な AccessKey 呼び出しの検出
Security Center は、セキュリティ攻撃・防御の経験と大規模モデルに基づいて、一般的な異常な AccessKey 呼び出しを検出できます。例えば、AccessKey を呼び出す IP アドレスが最近攻撃を開始した、IP アドレスがクラウド上の複数のユーザーの AccessKey ペアを一括で呼び出した、呼び出された API が機密性が高く、AccessKey が以前に漏洩したことがある、などです。AccessKey ペアが珍しいリージョンの IP アドレスから呼び出され、機密性の高い API にアクセスした場合、システムはその呼び出しを異常な動作として識別し、アラートをトリガーします。アラートが正常なビジネス動作によってトリガーされたことを確認した場合は、ActionTrail コンソールを使用して AccessKey ペアの呼び出し記録を確認してください。呼び出しを確認した後、アラート詳細ページでアラートステータスを [誤検知] に設定してください。この機能では、信頼できる IP アドレスを設定することはできません。
-
Security Center コンソールにログインします。
-
左側メニューで、 を選択します。コンソール左上で、保護対象のアセットが配置されているリージョンを選択します:[中国本土] または [中国本土以外]。
説明Agentic SOC を有効化している場合は、 を選択します。
-
アラートタイプ を 不正なプロセス (クラウドスキャン) に設定し、異常な AccessKey 呼び出しアラートがないか確認してください。
説明異常な AccessKey 呼び出しアラートが存在する場合は、その詳細を確認し、AccessKey 呼び出しが正常な動作であるかどうかを速やかに確認してください。
-
(オプション) アラート通知を設定する:システム設定 > 通知設定 に移動し、[通知項目] 列で 通知プロジェクト を見つけ、希望する方法を選択してください。
説明Basic Edition は、サイト内メッセージ通知方法のみをサポートします。
Alibaba Cloud アカウントによる異常な AccessKey 呼び出しの監視
ActionTrail は、Alibaba Cloud アカウントによる AccessKey 呼び出しおよび異常な AccessKey 呼び出しを監視するための組み込みアラートを提供します。ActionTrail コンソールで組み込みアラート [AccessKey使用頻度の異常アラート] および [ルートアカウントAccessKey使用検出] を有効にして、異常な AccessKey 呼び出しが発生したときに通知を受け取れるようにします。詳細については、「Insightsイベントをクエリする」をご参照ください。
過去の動作に基づく異常な AccessKey 呼び出しの検出
ActionTrail が提供する Insights 機能は、過去の動作に基づいて異常な呼び出し率を持つ AccessKey ペアを分析し、異常なアクティビティをタイムリーに検出するのに役立ちます。Insights イベントを有効化して確認する方法の詳細については、「ActionTrailコンソールでInsightsイベントをクエリする」をご参照ください。
推奨事項
-
Alibaba Cloud アカウント (メインアカウント) の AccessKey ペアを使用しないでください。
-
コードに AccessKey 情報をハードコーディングしないでください。環境変数を使用して AccessKey ペアを管理できます。詳細については、「AccessKey ペア漏洩を防止するためのベストプラクティス」をご参照ください。
-
プライベート GitHub リポジトリを使用してコードを管理するか、企業内に内部コードホスティングシステムを構築して、ソースコードと機密情報の漏洩を防止してください。
よくある質問
サードパーティ SDK を使用してローカルでファイルアップロードをテストすると、AccessKey 漏洩が発生しますか?
サードパーティ SDK を使用してローカルでファイルアップロードをテストしても、直接 AccessKey 漏洩は発生しません。AccessKey 漏洩は通常、アプリケーションコードまたは公開コードリポジトリに AccessKey を平文でハードコーディングし、それが後に他者によって取得されることによって引き起こされます。
次の対策を講じることを推奨します。
-
漏洩した AccessKey と対応する RAM ユーザーを削除してください。
-
AccessKey ペアを定期的にローテーションしてください。
-
AccessKey ペアなどの認証情報を、コードに平文で保存するのではなく、環境変数を使用して管理してください。