AWS セキュリティサービスでアクセスキーの漏えいリスクを最小限に抑える実践的な手順

漏えいした長期的な認証情報は、AWS Customer Incident Response Team (CIRT) が観測したセキュリティインシデントで、現在も脅威アクターに最も多く使われる侵入経路となっています。長期的な認証情報やアクセスキーが漏えいし、脅威アクターに使用されると、クラウド環境にセキュリティリスクが生じます。さらに、キーのローテーションが不十分な運用、複数のユーザー間でのアクセスキーの共有、未使用の認証情報の取り消し漏れによって、システムが危険にさらされたままになる可能性があります。

長期的な認証情報は使用しないことを強くお勧めします。これを機に、AWS Identity and Access Management (IAM) ロールとフェデレーションアクセスへの移行を進めることができます。AWS が推奨するベストプラクティスは、お客様が長期的な認証情報から脱却することです。ただし、すべての組織がこの移行をすぐに実現できるとは限らないことも、AWS は認識しています。

長期的な認証情報への意図しないアクセスに対して包括的な防御を構築するには、戦略的な多層アプローチが必要です。このアプローチは、理想的なセキュリティプラクティスと現実の運用上の制約との間のギャップを埋めることを目的としており、長期的な認証情報を必要とするレガシー AWS ワークロードを管理するチームに、すぐに実行できる手順を提供します。

この記事では、防御を構築する方法を順を追って説明します。まず、Amazon Q Developer や AWS IAM Access Analyzer などのサービスを使用して既存のリスクと潜在的な露出を特定し、環境全体の認証情報リスクを可視化します。次に、サービスコントロールポリシー (SCP) とデータ境界によって厳格な境界を確立し、認証情報を作成および使用できる方法と場所を制御します。これらの仕組みを整えたら、ネットワークレベルのコントロールによって防御態勢をさらに強化し、アクセスキーが使用される可能性のあるインフラストラクチャを保護します。具体的には、AWS WAF や Amazon Inspector などのサービスを使用して、脆弱性の悪用からの保護に役立てます。最後に、シークレットの自動ローテーションなどの運用上のベストプラクティスを実装して、基本的なセキュリティ対策を継続的に実施し、侵害が発生した場合の影響を最小限に抑えます。

既存のアクセスキーの監査

包括的な監査を行うために、組織は認証情報レポートを定期的に生成する必要があります。このレポートを使用すると、長期的な認証情報を所有する IAM ユーザーを特定できるほか、キーの最終ローテーション日時、最終使用日時、最後に使用されたサービス、最後に使用されたリージョンなどの関連情報も確認できます。これらのレポートにより、認証情報の全体像を把握するために不可欠な可視性が得られます。長期間アクティビティがないアクセスキー、ローテーションポリシーで定めた期間を超過しているキー、見慣れないリージョンからの予期しない使用パターンに着目することで、未使用の認証情報や侵害された可能性のある認証情報を発見できます。

漏えいしたアクセスキーの検出

認証情報が侵害される一般的な原因の 1 つに、パブリックリポジトリへの不注意なコミットがあります。開発者が誤って認証情報をパブリックリポジトリにコミットすると、攻撃者が使用する自動スキャンツールによって、その認証情報が収集される可能性があります。コードスキャンは、こうした重大なセキュリティ問題を早期に発見するための基本的なステップです。機密性の高い認証情報が誤ってコードリポジトリにコミットされたり、本番環境にデプロイされて悪用の危険にさらされたりする前に、問題を発見できます。

Amazon Q Developer を使用すると、セキュリティの脆弱性やコード品質の問題がないかコードベースをレビューし、開発サイクル全体を通じてアプリケーションのセキュリティポスチャを改善できます。ローカルのプロジェクトやワークスペース内のすべてのファイルを分析してコードベース全体をレビューすることも、単一のファイルだけをレビューすることもできます。また、自動レビューを有効にすると、記述中のコードをその都度評価することもできます。

Amazon Q は、次のような問題がないかコードをレビューします。

SAST (静的アプリケーションセキュリティテスト) スキャン – ソースコード内のセキュリティの脆弱性を検出します。Amazon Q は、リソースリーク、SQL インジェクション、クロスサイトスクリプティングなど、さまざまなセキュリティ問題を特定します。

シークレットの検出 – コード内の機密情報が露出するのを防ぎます。Amazon Q は、コードファイルとテキストファイルをレビューして、ハードコードされたパスワード、データベース接続文字列、ユーザー名などのシークレットがないか確認します。シークレットの検出結果には、保護されていないシークレットに関する情報と、その保護方法が含まれます。

IaC の問題 – インフラストラクチャファイルのセキュリティポスチャを評価します。Amazon Q は、Infrastructure as Code (IaC) のコードファイルをレビューして、設定ミス、コンプライアンス上の問題、セキュリティの問題を検出できます。

訳注: 原文公開後の 2026 年 5 月 15 日に、Amazon Q Developer の新規登録は停止しました。また、Amazon Q Developer IDE プラグインと有料サブスクリプションは、2027 年 4 月 30 日にサポートが終了する予定です。移行先として Kiro をお勧めします。詳細は「Amazon Q Developer のサポート終了に関するお知らせ」を参照してください。Kiro を使用したセキュリティレビューの例については、「Kiro と Amazon Q でセキュリティポスチャを強化する 5 つの方法」を参照してください。

AWS Trusted Advisor には、漏えいしたアクセスキーのチェックも用意されています。このチェックでは、広く利用されているコードリポジトリで公開されてしまったアクセスキーがないかを確認します。また、アクセスキーの侵害が原因と考えられる、Amazon Elastic Compute Cloud (Amazon EC2) の異常な使用がないかも確認します。

これらは有用なセキュリティツールですが、ローカルの開発マシンや外部システムなど、スキャン範囲外の場所に保存されたシークレットやアクセスキーは検出できません。認証情報の露出を特定して防止する唯一の手段としてではなく、より広範なセキュリティ戦略の一部として使用してください。

侵害された可能性のあるアクセスキーに対処する場合は、直ちにキーをローテーションすることをお勧めします。手順については、IAM ユーザーのアクセスキーをローテーションする方法を参照してください。

漏えいした認証情報の特定に加えて、未使用のアクセスキーを検出することでも、アタックサーフェスを最小限に抑えられます。IAM Access Analyzer には、未使用のアクセスを検出するアナライザーがあります。このアナライザーは、過剰に付与されているアクセス許可や、使用されなくなったアクセス許可を検出します。対象には、未使用の IAM ロール、IAM ユーザーの未使用のアクセスキーとパスワード、アクティブな IAM ロールおよび IAM ユーザーで使用されていないサービスとアクションが含まれます。組織全体またはアカウント固有のアナライザーが生成した検出結果を確認した後、不要なアクセス許可を削除または変更できます。未使用の認証情報とアクセスを特定して取り消しておけば、脅威アクターに認証情報を取得された場合でも影響を抑えることができます。

これらのツールを導入すると、環境全体の認証情報リスクに関するインサイトを得られます。これらの機能を組み合わせることで、埋め込まれたシークレット、漏えいしたアクセスキー、削除が必要な認証情報を洗い出すことができます。

漏えいした認証情報や未使用の認証情報を特定する方法がわかったところで、次は SCP とリソースコントロールポリシー (RCP) を使用してデータ境界を作成する方法を見ていきましょう。データ境界は、信頼できるアイデンティティだけが、想定されたネットワークから信頼できるリソースにアクセスできるようにするのに役立ちます。AWS 環境に予防的ガードレールを実装することは、不正アクセスやアクセスキーの侵害から環境を保護するうえで不可欠です。データ境界の概要と確立方法の詳細については、ブログ記事シリーズ「Establishing a Data Perimeter on AWS」を参照してください。

例えば、次の SCP は、企業の Classless Inter-Domain Routing (CIDR) や特定の仮想プライベートクラウド (VPC) 以外の想定外のネットワークから IAM ユーザーの認証情報が使用されることを拒否します。このポリシーでは、除外しないとサービスへのアクセスに影響が出る複数のアクションを NotAction 要素に含めています。SCP と RCP の例は、data-perimeter-policy-examples で公開されています。このリポジトリは、最新の改訂版ポリシーの正規の情報源です。次の例は、想定外のネットワークからユーザーの認証情報が使用されるユースケースに対応するように更新したものです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceNetworkPerimeterOnIAMUsers",
            "Effect": "Deny",
            "NotAction": [
                "es:ES*",
                "dax:GetItem",
                "dax:BatchGetItem",
                "dax:Query",
                "dax:Scan",
                "dax:PutItem",
                "dax:UpdateItem",
                "dax:DeleteItem",
                "dax:BatchWriteItem",
                "dax:ConditionCheckItem",
                "neptune-db:*",
                "kafka-cluster:*",
                "elasticfilesystem:client*",
                "rds-db:connect"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:ViaAWSService": "false"
                },
                "NotIpAddressIfExists": {
                    "aws:SourceIp": [
                        "<my-corporate-cidr>"
                    ]
                },
                "StringNotEqualsIfExists": {
                    "aws:SourceVpc": [
                        "<my-vpc>"
                    ]
                },
                "ArnLike": {
                    "aws:PrincipalArn": [
                        "arn:aws:iam::*:user/*"
                    ]
                }
            }
        }
    ]

このネットワーク境界を実装すると、認証情報の侵害が不正アクセスやデータの露出につながるリスクを軽減できます。盗んだ認証情報をコーヒーショップや自宅のネットワークから使用しようとする脅威アクターはブロックされるため、認証情報への意図しないアクセスによる影響を抑えることができます。

多層防御をさらに強化するには、RCP を使用してデータを保護できます。例えば、RCP を使用すると、どのアイデンティティがリソースにアクセスできるかを制御できます。組織内のアイデンティティには組織内のリソースへのアクセスを許可し、組織外のアイデンティティによるリソースへのアクセスを防止したい場合は、RCP でこの制御を適用できます。RCP を使用すると、リソースに対して利用可能なアクセス許可の上限を設定し、組織の内外を問わず、どのプリンシパルがリソースにアクセスできるかを指定できます。一方、SCP が影響を与えられるのは、AWS 組織内のプリンシパルの有効なアクセス許可に限られます。

次の RCP を実装すると、長期的な認証情報が誤って漏えいした場合に、組織外の権限のないユーザーがその認証情報を使用して重要なデータやリソースにアクセスしようとしても、確実にブロックされるようにするのに役立ちます。このポリシーは、企業の CIDR 範囲 (NotIpAddressIfExists と aws:SourceIp) または VPC (StringNotEqualsIfExists と aws:SourceVpc) からのリクエストでない限り、Amazon Simple Storage Service (Amazon S3) のアクションを拒否します。対応サービスについては、RCP をサポートする AWS サービスの一覧を参照してください。SCP と RCP の例は、こちらの GitHub リポジトリで公開されています。このリポジトリは、最新の改訂版ポリシーの正規の情報源です。次の例は、この記事で取り上げたユースケースに対応するように更新したものです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceNetworkPerimeter",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
		"s3:*",
		"sqs:*",
		"kms:*",
		"secretsmanager:*",
		"sts:AssumeRole",
		"sts:DecodeAuthorizationMessage",
		"sts:GetAccessKeyInfo",
		"sts:GetFederationToken",
		"sts:GetServiceBearerToken",
		"sts:GetSessionToken",
 		"sts:SetContext",
 		"aoss:*",
 		"ecr:*"
		],
      "Resource": "*",
      "Condition": {
        "NotIpAddressIfExists": {
          "aws:SourceIp": "<0.0.0.0/1>"
        },
        "StringNotEqualsIfExists": {
          "aws:SourceVpc": "<my-vpc>"
        },
        "BoolIfExists": {
          "aws:PrincipalIsAWSService": "false",
          "aws:ViaAWSService": "false"
        }
      }
	 }
    ]
  }

長期的な認証情報からの移行を始める準備ができている場合は、SCP を使用してアクセスキーの作成と既存キーの更新を拒否することで、IAM ロールやフェデレーションアクセスなど、より安全な認証方法の使用を徹底できます。次のポリシーは、プリンシパルによる AWS アクセスキーの作成と更新を拒否します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "iam:CreateAccessKey",
			 	"iam:UpdateAccessKey"
            ],
            "Resource": "*"
        }
    ]
}

データ境界のコントロールを確立したら、次はネットワークコントロールによって、アクセスキーが使用されるランタイム環境を保護する方法を見ていきましょう。

データ境界を構築し、SCP と RCP を使用するだけでなく、これらのアクセスキーを使用するコンピューティングおよびネットワークのインフラストラクチャを保護することも不可欠です。悪意のある攻撃者は、不正アクセスを目的としてこうした環境を標的にすることが多く、侵害されたランタイム環境を通じて認証情報が露出するリスクがあります。そのため、インフラストラクチャの保護は、アクセスキーのセキュリティにおいて重要な要素となります。

インスタンスレベルやサブネットレベルなど、さまざまなレベルでファイアウォールとして機能するネットワークレベルのセキュリティ保護を使用して、不正アクセスの防止に役立ててください。

• SSH (ポート 22) や RDP (ポート 3389) などの重要なポートは、不正なシステムアクセスを狙う悪意のある攻撃者の主な標的となるため、制限することが不可欠です。セキュリティグループで管理用ポートを開放したままにすると、アタックサーフェスとセキュリティリスクが増大する可能性があります。AWS Systems Manager Session Manager を使用すると、インバウンドポートを公開せずに安全なリモートアクセスを実現でき、踏み台ホストの使用や SSH キー管理の必要性を軽減できます。
• NACL は、サブネットの境界でステートレスなパケットフィルターとして機能し、サブネットレベルでアクセスを効果的にブロックします。個々のインスタンスを保護するセキュリティグループとは異なり、NACL はインバウンドとアウトバウンドの両方のトラフィックに対する明示的な許可/拒否ルールによって、サブネット全体を保護します。NACL は、トラフィックがインスタンスに到達する前にフィルタリングする、重要な境界防御レイヤーとなります。多層防御アプローチの一環としてデプロイすると、NACL はアプリケーション層間をサブネットレベルで分離し、ネットワークエッジで悪意のあるトラフィックパターンをブロックします。また、他のセキュリティレイヤーが侵害された場合でも保護を維持します。これにより、複数の独立したコントロールポイントによる包括的なネットワークセキュリティを実現できます。
• NACL よりもさらにネットワーク保護を強化したい場合は、AWS Network Firewall を使用して、包括的な VPC 保護によるエンタープライズグレードの境界防御を実現できます。Network Firewall は、侵入防止システム、ドメインフィルタリング、ディープパケットインスペクション、地理的 IP コントロールを組み合わせるとともに、Amazon が収集したグローバルな脅威インテリジェンスを使用して、新たな脅威からクラウド環境を自動的に保護します。Network Firewall と AWS Transit Gateway を統合すると、一元管理によって、VPC やアベイラビリティーゾーン全体に一貫したセキュリティポリシーを適用できます。
• 組織全体でネットワークセキュリティを自動化してスケールさせるには、AWS Firewall Manager を使用して、Network Firewall のルールとセキュリティグループポリシーの両方を一元管理できます。Firewall Manager は、組織の成長に合わせて共通のセキュリティグループポリシーのデプロイを自動化し、未使用のグループをクリーンアップし、複数のアカウントや組織単位にわたって許可範囲が広すぎるルールを修正することで、セキュリティの維持に役立ちます。

意図しないネットワークへの露出を大規模に特定するには、Amazon Inspector の使用を検討してください。Amazon Inspector は、ソフトウェアの脆弱性や意図しないネットワークへの露出がないか AWS ワークロードを継続的にスキャンし、セキュリティの脆弱性が悪用される前に特定して修正できるようにします。

主な機能は次のとおりです。

• パッケージの脆弱性: パッケージの脆弱性の検出結果は、AWS 環境内で CVE (Common Vulnerabilities and Exposures) の影響を受けるソフトウェアパッケージを特定します。悪意のある攻撃者は、パッチが適用されていないこれらの脆弱性を悪用して、データの機密性、完全性、可用性を侵害したり、他のシステムにアクセスしたりする可能性があります。
• コードの脆弱性: コードの脆弱性の検出結果は、悪用される可能性のあるコード行を特定します。コードの脆弱性には、暗号化の欠如、データ漏えい、インジェクション、脆弱な暗号方式などがあります。Amazon Inspector は、Lambda 関数のスキャンと Code Security 機能によって検出結果を生成し、Amazon Q と共同で開発された内部ディテクターに基づいて、ポリシー違反や脆弱性を特定します。
• ネットワーク到達可能性: ネットワーク到達可能性の検出結果は、インターネットゲートウェイ (Application Load Balancer または Classic Load Balancer の背後にあるインスタンスを含む)、VPC ピアリング接続、または仮想ゲートウェイ経由の VPN を介して、インターネットからポートに到達できるかどうかを示します。これらの検出結果は、管理が不十分なセキュリティグループ、NACL、インターネットゲートウェイなど、許可範囲が広すぎる可能性のあるネットワーク設定や、悪意のあるアクセスを許す可能性のあるネットワーク設定を明らかにします。インスタンスのセキュリティグループで開いている SSH ポートも特定できます。

AWS WAF は、ネットワークセキュリティのコントロールと脆弱性管理を補完するサービスです。認証情報の露出につながる可能性のある悪意のあるウェブトラフィックをフィルタリングすることで、防御レイヤーを追加します。

AWS WAF には、不正アクセスや一般的な脆弱性から保護するための複数のマネージドルールグループが用意されています。

• AWS WAF Fraud Control Account Creation Fraud Prevention (ACFP) ルールグループ: ACFP は、リクエストトークンを使用して、クライアントブラウザに関する情報と、アカウント作成リクエストを生成する際の人間による操作の度合いに関する情報を収集します。このルールグループは、IP アドレスとクライアントセッションごとにリクエストを集計し、さらに住所や電話番号など、提供されたアカウント情報ごとにも集計して、大量のアカウント作成の試みを検出して管理します。また、侵害された認証情報を使用した新規アカウントの作成を検出してブロックするため、アプリケーションと新規ユーザーのセキュリティポスチャの保護に役立ちます。
• AWS WAF Fraud Control Account Takeover Prevention (ATP) ルールグループ: ATP は、異常なサインイン試行や、盗まれた認証情報を使用したサインイン試行を可視化して制御できるようにすることで、不正なアクティビティにつながる可能性のあるアカウントの乗っ取りの防止に役立ちます。Amazon CloudFront ディストリビューションの場合、ATP ルールグループは、受信したサインインリクエストの検査に加えて、サインイン試行に対するアプリケーションのレスポンスも検査し、成功率と失敗率を追跡します。ATP は、E メールアドレスとパスワードの組み合わせを、盗まれた認証情報のデータベースと照合します。このデータベースは定期的に更新され、ダークウェブで新たに見つかった、漏えいした認証情報が追加されます。

これらの保護レイヤーを補完し、セキュリティポスチャを継続的に維持するために、Secrets Manager による認証情報の自動管理を実装してください。これにより、環境全体でアクセスキーの適切なローテーションとライフサイクル管理を実現できます。自動化によって人為的ミスが減り、認証情報をタイムリーに更新しやすくなるほか、認証情報が侵害された場合の露出期間も短縮できます。

キーは少なくとも 90 日に 1 回ローテーションすることをお勧めします。Secrets Manager は、スケジュールに従ってシークレットをローテーションするプロセスを自動化し、手作業なしで認証情報が定期的に更新されるようにします。また、シークレットの保存場所を一元化するため、複数のユーザー間でアクセスキーが共有される可能性も低減できます。Secrets Manager では、Lambda 統合を使用して、キーの自動ローテーションを設定できます。

また、アクセスキーの自動ローテーションを大規模に実装するためにデプロイできる、既存のソリューションもあります。このパターンでは、AWS CloudFormation テンプレートを使用して、IAM アクセスキーを自動的にローテーションできます。テンプレートは、GitHub の IAM キーローテーションリポジトリで提供されています。

自動ローテーションを実装できず、ローテーションが必要なアクセスキーをすばやく特定したい場合は、AWS Trusted Advisor の IAM アクセスキーのローテーションに関するセキュリティチェックを使用できます。このセキュリティチェックでは、過去 90 日間にローテーションされていないアクティブな IAM アクセスキーを確認します。手動でローテーションを行う必要がある場合は、このセキュリティチェックを使用して、環境内のどのアクセスキーをローテーションすべきかを詳しく調べることができます。

最後に、IAM インフラストラクチャを保護するためのプロアクティブな対策は重要ですが、堅牢な検出とアラートの仕組みを整えておくことも同様に重要です。どれほど入念に対策を講じても、予期しない脅威や不正なアクティビティが発生する可能性は残ります。そのため、包括的な多層防御戦略には、IAM に関連する異常なイベントを迅速に特定して対応する機能を含める必要があります。Amazon GuardDuty は、機械学習と統合された脅威インテリジェンスを組み合わせて、AWS アカウント、ワークロード、データを脅威から保護するのに役立ちます。

GuardDuty 拡張脅威検出は、さまざまなデータソースにわたる複数のイベントを自動的に関連付けて、AWS 環境内の潜在的な脅威を特定します。拡張脅威検出は、疑わしい一連のアクティビティを検出すると、包括的な攻撃シーケンスの検出結果を生成します。このシステムは、個々の API アクティビティを弱いシグナルとして分析します。これらのシグナルは単独ではリスクを示さない場合もありますが、特定のパターンとして組み合わせて観測されると、潜在的なセキュリティ問題が明らかになることがあります。

この機能は、AWS アカウントで GuardDuty を有効にするとデフォルトで有効になるため、追加の設定なしで保護を受けられます。

侵害された認証情報に関連する攻撃シーケンスの検出結果は AttackSequence:IAM/CompromisedCredentials で、重要度は重大 (Critical) に分類されています。この検出結果は、AWS 認証情報を使用して実行された一連の疑わしいアクションを GuardDuty が検出し、そのアクションが環境内の 1 つ以上のリソースに影響を与えていることを示します。同じ認証情報による疑わしく異常な脅威行動が複数観測されているため、その認証情報が悪用されている可能性が高いと判断されます。

この記事で紹介したセキュリティのベストプラクティスは、長期的な認証情報に関連するリスクを軽減するための包括的な多層アプローチです。プロアクティブなコードスキャン、キーの自動ローテーション、ネットワークレベルのコントロール、データ境界による制限、脅威検出を実装することで、一時的な認証情報へ完全に移行できるようになるまでの間、アタックサーフェスを大幅に削減し、組織の AWS リソースをより確実に保護できます。

この記事の推奨事項は、組織のセキュリティポスチャを良好な状態に保つための十分なコントロールですが、各環境の具体的なニーズやリスクプロファイルによっては、追加のセキュリティ対策を講じることができる場合もあります。重要なのは、認証情報の管理と保護に対して、全体的かつ多層的なアプローチを採用することです。そうすることで、一時的な認証情報へ完全に移行できるようになるまでのギャップを埋めることができます。

これらのセキュリティ対策を実装するとリスクを軽減できますが、長期的な認証情報には本質的にセキュリティリスクが伴います。厳格なベストプラクティスと包括的なセキュリティコントロールを適用しても、認証情報が侵害される可能性を完全になくすことはできません。組織のセキュリティポスチャを評価し、可能な限り IAM ロールとフェデレーションによる一時的な認証情報を優先して使用することを検討してください。ご質問がある場合やサポートが必要な場合は、AWS がお手伝いします。