AWSセキュリティ問題は見出しを飾り続けており、パターンは驚くほど一貫しています：クラウドプラットフォーム自体が根本原因になることは稀です。Intruderの2026 Cloud Security Indexによると、設定ミスはプロバイダー間でクラウドアカウントの80%から98%に影響を及ぼし、AWSは6つの設定ミスカテゴリーのうち5つでリードしています。最も一般的なAWSセキュリティ問題 — 公開S3バケット、過度に許容的なIAM、MFA欠如、公開サービス — はAWSプラットフォームの欠陥ではなく、顧客側の設定問題です。
このガイドでは、AWSセキュリティ問題の主要な問題点とその対策をカバーし、2025-2026年の侵害レポートとCIS AWS Foundations Benchmark監査で最も頻繁に現れる問題をマッピングし、なぜそれぞれが持続するかを説明し、侵害になる前にそれぞれを防ぐ方法を示します。AWS共有責任モデルから始まります。その境界がほとんどのAWSセキュリティリスクが実際に始まる場所だからです。
AWS共有責任モデルの理解
AWSセキュリティ問題を議論する際の基礎概念はAWS共有責任モデルです。このモデルはAWSエコシステムで誰が何をセキュアにするかを定義し、驚くべき数のAWSセキュリティ問題がプラットフォームの脆弱性ではなく、この境界の誤解または誤用から生じます。
AWS共有責任モデルとは
AWS共有責任モデルは、AWSがセキュアにする環境の側面と顧客の制御下にある側面を明確に概説します：
- AWSはクラウド「の」セキュリティを担当 — グローバルクラウドインフラストラクチャ、物理データセンター、ネットワークハードウェア、ハイパーバイザー、基盤サービス層。
- お客様はクラウド「内」のセキュリティを担当 — アプリケーション、データ、IAMポリシー、設定、アクセス制御、暗号化、デプロイまたは管理するすべてのパッチ適用。
モデルは簡単に見えますが、多くのAWSセキュリティ問題はAWSの責任が終わり顧客の責任が始まる場所についての誤った仮定から生じます。
AWSの責任：クラウド「の」セキュリティ
AWSはすべてのサービスをサポートするコアインフラストラクチャをセキュアにします：
- データセンターの物理セキュリティ
- 冗長電源、ネットワーク、HVACシステム
- ネットワークセグメンテーションとDDoS軽減
- ハイパーバイザーと基盤サービス層
AWSはこのインフラストラクチャを継続的に監視、テスト、監査して、ISO 27001、SOC 1/2/3、PCI DSSなどのコンプライアンス認証を維持しています。ただし、この強固な基盤があっても、顧客の層が適切にセキュアでない場合、セキュリティギャップは依然として発生します。
顧客の責任：クラウド「内」のセキュリティ
顧客はクラウドアプリケーション、データ、設定のセキュリティに責任があります：
- S3、EC2、RDSなどのサービスの適切な設定
- Identity and Access Management（IAM）ポリシーとロール
- 入力検証や安全なコーディングなどのアプリケーションレベルのセキュリティ（AWSハードニングを補完するアプリケーション層の制御については、Node.jsセキュリティベストプラクティスと本番環境Node.jsセキュリティ深掘りを参照）
- オペレーティングシステムとソフトウェアスタックのパッチ適用と維持
- 保存時および転送時の暗号化による機密データの保護
AWSで作成、管理、または設定できる場合、おそらくそのセキュリティに責任があります。これがAWSセキュリティ問題の大部分が発生する場所です。公開読み取りまたは書き込みアクセスを許可する誤設定されたS3バケットはAWSのせいではなく、顧客側の設定ミスです。
リスクにつながる誤解
AWSセキュリティ問題の大部分は、洗練された攻撃やゼロデイエクスプロイトではなく、人為的ミスと責任モデルの誤解によって引き起こされます。多くの組織はAWSが「すべてを処理する」という誤った信念で運営していますが、これは真実ではありません。
一般的な例には以下が含まれます：
- S3バケットリーク — 制御なしで公開アクセスが有効になり、機密データが露出。
- IAMロール悪用 —
"Action": "*"、"Resource": "*"のような過度に許容的なポリシーが権限昇格の扉を開きます。 - 未パッチEC2インスタンス — 攻撃者が発見から数分以内に悪用する既知のCVEを持つ古いオペレーティングシステム。
AWSがすべてのレベルでセキュリティを処理すると仮定することは危険な考え方であり、予防可能なセキュリティ障害への直接的な道です。
現実世界のアナロジー
AWSを安全なアパートメントビルと考えてください。AWSは正面玄関のロックが機能し、火災報知器が作動し、ビルに24時間セキュリティがあることを保証します。アパートメント（クラウドアカウントまたはリソース）を借りたら、窓のロック、ブラインドを閉める、金庫の設置はあなたの仕事です。これらの責任を無視すると、正面玄関を開けたままにするのと同じように侵害につながります。
なぜ教育が重要か
クラウド環境は急速に動き、デプロイメントサイクルは短いです。AWS責任に関する適切なトレーニングがなければ、善意のエンジニアでもサービスを公開したり不適切に設定したりして、深刻なAWSセキュリティリスクを導入する可能性があります。AWSは定期的に新しいサービスと機能を導入し、適応に失敗すると古いプラクティスにつながることが多い — クラウドセキュリティ課題の別の源です。
2025-2026年の主要なAWSセキュリティ問題
AWSは最も安全なクラウドプラットフォームの1つであるにもかかわらず、AWSセキュリティリスクは依然として頻繁に発生しています — プラットフォームの欠陥ではなく、ユーザーがクラウド環境を設定および管理する方法が原因です。以下は、現実世界の影響と予防戦略を含む、最も緊急かつ一般的に遭遇する問題です。
1. S3バケットの設定ミス
最も悪名高いAWSセキュリティリスクはAmazon S3バケットの設定ミスです。これらのストレージリソースは強力ですが、適切にセキュアでないと危険です。
多くの侵害で、S3バケットは意図せず公開アクセスを許可するように設定されており、URLを持つ人なら誰でもデータを読み取り、時には書き込むことができます。VerizonとAccentureはこの問題で注目されるデータリークを経験しました。
重要な更新： 2023年4月5日以降、AWSは新しいバケットでS3 Block Public Accessを有効にし、ACLをデフォルトで無効にします。ただし、このデフォルトは遡及しません。その日より前に作成されたバケットは、Block Public Accessを明示的に有効にしない限り、元の公開アクセス設定を保持します。2023年以前のバケットは依然としてS3データリークの一般的な原因です。
VerizonのケースとAccentureのケースをご覧ください。
なぜ起こるか
- 2023年以前のバケットでのデフォルトまたは継承された権限
- 公開アクセス設定の可視性欠如
- AWSアクセスポリシー警告の見落とし
防ぐ方法
- アカウントレベルでS3 Block Public Accessを有効化 — これは2023年以前のバケットを含むすべてのバケットをカバーします
- AWS Configを使用してオープンバケットを監視
- 最小特権原則に従うバケットポリシーを適用
- S3バケットのデフォルト暗号化を有効化
2. 過度に許容的なIAMポリシー
AWSセキュリティ問題の別の一般的なベクトルは、広範または許容的なIAMポリシーの使用です。多くのチームは"Effect": "Allow"、"Action": "*"、"Resource": "*"でポリシーを割り当てます — これは事実上無制限のアクセスを付与します。
この設定はセキュリティ時限爆弾を作り、内部または外部の行為者が権限を昇格したり意図しないリソースにアクセスしたりすることを許可します。2026 Cloud Security Indexによると、IAM Policy Allows Privilege EscalationはAWSアカウントの83%に影響し、IAM Access Key Not Rotatedは71%に影響します。
結果には以下が含まれます
- 完全なアカウント乗っ取り
- 不正なデータアクセス
- サービス間の横方向の移動
ベストプラクティス
- 最小特権アクセスを実装 — 権限なしで開始し、必要なものだけを追加
- IAM Access AnalyzerでIAMロールとポリシーを定期的に監査
- AWS Identity Center（旧SSO）を使用した集中型人的アクセス
- ポリシーをユーザーに直接添付せず、ロールを使用
3. ルートおよびIAMユーザーでのMFA欠如
多要素認証（MFA）はAWSで最もシンプルで効果的な制御の1つですが、十分に強制されていません。2026 Cloud Security Indexは、Root Access Not Centrally ManagedがAWSアカウントの72%に影響することを発見しました。
AWSルートアカウントはアカウント内のすべてのリソースへの完全で無制限のアクセスを持っています。攻撃者がMFAなしでルート認証情報を侵害した場合、アカウントは事実上失われます。同じことが管理者権限を持つIAMユーザーにも当てはまります。
防ぐ方法
- ルートアカウントでMFAを有効化し、回復コードを安全に保管
- 管理者または書き込みアクセスを持つすべてのIAMユーザーにMFAを強制
- AWS Identity Centerを使用して組織全体でMFAを集中強制
- ルートユーザーのIAMアクセスキーを無効化または削除 — ルートはコンソール + MFAのみ使用すべき
4. 暗号化の欠如
暗号化を見落とすことは深刻なAWSセキュリティ問題です。保存時または転送時のデータを暗号化しないと、傍受、改ざん、露出への扉が開きます。AWSはKMS（Key Management Service）や転送時TLSなどのサービスを提供しますが、暗号化は常にデフォルトで強制されるわけではありません。
暗号化がよくスキップされる場所
- EBSボリューム
- RDSスナップショット
- Lambda環境変数
- 2023年以前のバケット内のS3オブジェクト
軽減のヒント
- アカウントまたはサービスレベルでS3、EBS、RDSのデフォルト暗号化を有効化
- キーローテーションとアクセスのより厳格な制御のためにカスタマーマネージドキー（CMK）を使用
- KMS経由で暗号化キーを定期的にローテーション
- すべてのAPI呼び出しとデータベース接続で転送時TLSを強制
5. 安全でないAPIと公開エンドポイント
組織がマイクロサービスとサーバーレスアーキテクチャを採用するにつれて、AWSセキュリティリスクの攻撃面は増加します。API GatewayとLambdaエンドポイントはこの表面が成長する主な方法です。
保護されていないまたは弱く認証されたAPIは、自動スキャンツールを使用する攻撃者によって発見および悪用される可能性があります。発見されると、データ抽出、ブルートフォース攻撃、またはサービス中断に使用される可能性があります。2026 Cloud Security Indexは、76%のAWSアカウントが少なくとも1つの公開サービスを持っていることを発見しました。
寄与要因
- 認証なしまたは弱いAPIキー使用
- レート制限またはスロットリングの欠如
- 過度に公開されたCORSポリシー
APIをセキュアにする
- Amazon CognitoまたはIAMベースの認証を有効化
- WAF（Web Application Firewall）ルールを実装
- AWS CloudWatchとGuardDutyで監視
- API Gatewayレベルでレート制限とリクエストスロットリングを適用
6. 未パッチEC2インスタンスとAMI
AWSが物理インフラストラクチャを処理しても、EC2インスタンスは依然として顧客の責任です。これらは不適切なパッチ管理によるAWSセキュリティリスクの最も一般的な源の1つを表します。
インスタンスが古いオペレーティングシステムまたは脆弱なソフトウェアを実行している場合、攻撃者は既知のCVE（Common Vulnerabilities and Exposures）を悪用できます。これらの脆弱性は発見から数分以内に標的にされることがよくあります。
典型的な原因
- 更新なしの古いAMIを使用
- パッチ適用の自動化の欠如
- ベンダーセキュリティブリテンの無視
修正方法
- AWS Systems Manager Patch Managerを使用してパッチ適用を自動化
- AMIを定期的に更新およびローテーション
- 可能な場合は自動セキュリティ更新を適用
- AWS Security Bulletinsに登録
7. 最小特権原則の無視
あまりにも多くの場合、組織はユーザーとサービスに必要以上のアクセスを付与します。意図的か悪意かにかかわらず、これは悪用の可能性を高めます。これはAWSセキュリティリスクの静かだが重要な寄与者です。
結果には以下が含まれます
- 脅威行為者による権限昇格
- 過度に範囲が広いロールからのデータリーク
- 侵害時のblast radiusの増加
解決するには
- IAM Access AnalyzerでIAM権限を定期的にレビュー
- 権限境界と**属性ベースのアクセス制御（ABAC）**を使用
- 最小特権強制をCI/CDパイプラインに統合
- deny-by-defaultの姿勢を採用し、正当化される場合のみ権限を追加
8. セキュリティグループとネットワークACLの設定ミス
より微妙で危険なAWSセキュリティリスクの1つは、Amazon VPC内の不適切に設定されたセキュリティグループとネットワークアクセス制御リスト（ACL）を含みます。
多くの組織はポートを広く開放したままにしており、特にSSH（ポート22）、RDP（ポート3389）、または0.0.0.0/0のようなCIDRブロック全体です。2026 Cloud Security Indexは、Permissive Ingress to Sensitive PortsがAWSアカウントの84%に影響し、VPC Subnet Auto-Assigns Public IPが72%に影響することを発見しました。
よくある間違い
- 「すべてを許可」ルールの過度の使用
- アウトバウンドトラフィックの制限を忘れる
- 内部サービスの適切なセグメンテーションなし
- プライベートであるべきサブネットへの公開IPの自動割り当て
主要な安全策
- default denyアプローチを適用し、既知のCIDRからの必要なポートのみを許可
- VPCフローログを使用してトラフィックパターンを監査
- 機密サービスにNetwork FirewallとPrivateLinkを実装
- プライベートサブネットでの公開IP自動割り当てを無効化
AWSセキュリティベストプラクティス
AWSセキュリティリスクを防ぐことは車輪の再発明を必要としません。一貫性、可視性、実証済みのベストプラクティスへの順守を必要とします。以下の戦略を積極的に実装することで、組織はAWSでの設定ミスとコンプライアンス障害の可能性を劇的に減らすことができます。
最小特権原則を強制
AWSセキュリティリスクの繰り返しの根本原因は過度のアクセスです。常に最小特権原則に従ってください：ユーザーとサービスは絶対に必要な権限のみを取得すべきです。IAMロール、権限境界、および細粒度のアクセス制御を使用して、各エンティティができることを制限します。
ヒント： IAM Access Analyzerを使用して意図しないアクセスを検出および修正します。
ロギングと継続的な監視を有効化
多くの組織は適切な可視性がないため侵害検出が遅延します。AWS CloudTrail、Amazon GuardDuty、AWS Configを有効にすると、環境全体でアクティビティを追跡し、異常を検出し、内部ポリシーと外部規制の両方へのコンプライアンスを維持できます。
主な利点： エスカレートする前に潜在的なAWSセキュリティリスクについてリアルタイムアラートを受け取ります。
セキュリティチェックを自動化
手動レビューはクラウド環境ではスケーラブルではありません。AWS Config Rules、Inspector、Security Hubを使用すると、ベースラインセキュリティ設定を自動的に強制できます。これらのツールはオープンポート、暗号化欠如、公開アクセス可能なリソースなどのセキュリティ設定ミスを検出します。
ボーナス： 開発中の早期検出のためにこれらのチェックをCI/CDパイプラインに統合します。
すべてを暗号化 — 常に
暗号化は最もシンプルで効果的な防御形態の1つです。すべてのデータを**AWS Key Management Service（KMS）**またはカスタマーマネージドキーを使用して保存時および転送時に暗号化してください。S3、RDS、EBSボリュームなどのサービスでデフォルト暗号化を有効にします。
リマインダー： 暗号化の欠如は注目されるAWSセキュリティインシデントの繰り返しのテーマです。
認証情報を定期的に監査およびローテーション
古い認証情報とローテーションされていないキーは侵害のリスクを高めます。2026 Cloud Security Indexは、IAM Access Key Not RotatedがAWSアカウントの71%に影響することを発見しました。IAMユーザーを定期的に監査し、未使用のアカウントを無効にし、AWS Secrets Managerを使用してシークレットをローテーションします。
これらのプラクティスを運用化する方法のより広範なプログラムレベルのビューについては、クラウドセキュリティマネージドサービスのガイドをご覧ください。AWSでAIワークロードも構築している場合、エージェンティックAIのLLMセキュリティガイドは、AIゲートウェイとエージェントがもたらす追加リスクをカバーしています。
AWSセキュリティを強化するツールとリソース
AWSセキュリティリスクを最小限に抑えるには、適切なツールがすべての違いを生みます。AWSは、要件に最も適したサービスを選択できる堅牢なネイティブサービスのエコシステムを提供します。
AWS Security Hub
AWS Security Hubは、GuardDuty、Inspector、サードパーティツールなどの複数のサービスからの発見を単一のダッシュボードに集約します。CIS AWS Foundations Benchmarkなどの業界標準を使用して環境を評価し、重要なAWSセキュリティリスクを特定します。
主な利点
- AWSアカウント間での統一された可視性
- 自動コンプライアンスチェック
- チケットシステムとSOARツールとの統合
Amazon GuardDuty
この脅威検出サービスは、ポートスキャン、認証情報侵害試行、悪意のあるIPアドレスからのアクセスなどの異常なアクティビティを特定するために機械学習を使用します。AWSでのリアルタイム脅威に対する最初の防衛線の1つです。
使用理由
- パフォーマンスへの影響なし
- アカウント侵害、EC2悪用などを検出
- EventBridge経由で実行可能なアラートを送信
AWS ConfigとConfig Rules
セキュリティ設定ミスはAWS Configで早期に検出できます。このツールはAWSリソースへの変更を追跡し、事前定義またはカスタムルールに対して評価します。公開S3バケットや暗号化されていないボリュームなどのセキュリティ問題をほぼリアルタイムで特定できます。
ユースケース
- ベースライン設定からのドリフトの検出
- Lambda関数を使用した自動修復
- ガバナンスのための監査証跡
IAM Access Analyzer
最も一般的なAWSセキュリティリスクの1つは過度に許容的なアクセスです。IAM Access Analyzerは、外部と共有されたリソースや過度に広範な権限を持つリソースを発見するのに役立ちます。
主要な機能
- IAMロール、ポリシー、リソース共有をスキャン
- 過度の権限をフラグ
- AWS Organizationsと統合
CloudTrailとCloudWatch
フォレンジック分析とアクティビティ追跡のために、CloudTrailはAWS環境で行われたすべてのAPI呼び出しをログに記録します。CloudWatchは監視とアラート機能を提供します。
組み合わせることで可能になること
- 不正アクセス試行の検出
- セキュリティ関連のアクションに対するアラームの設定
- 監査とコンプライアンス要件の満たす
AWS Trusted Advisor
AWS Trusted Advisorは、公開ポート、ルートアカウントでのMFA、IAM使用などのセキュリティ設定チェックを含むAWSベストプラクティスに基づくインサイトを提供します。
その関連性
- AWS BusinessおよびEnterprise Supportプランに組み込み
- セキュリティ、コスト、フォールトトレランス、パフォーマンスをカバー
- 修復タスクの優先順位付けを支援
AWSセキュリティ問題の現実世界の例
理論を理解することは一つのことです；現実世界での結果を見ることはレッスンをはるかに具体的にします。これらのインシデントはすべて、より良いプラクティスで避けられたAWSセキュリティリスクに起因しました。
Capital Oneデータ侵害（2019）：IAM設定ミスとSSRF
歴史上最悪名高いAWSセキュリティ問題の1つはCapital Oneを含み、元AWS従業員が脆弱性を悪用して1億件以上の顧客レコードにアクセスしました。
何が間違ったか
- EC2インスタンスに過度に許容的なIAMロールがあり、機密S3バケットへのアクセスを許可しました。
- 攻撃者は**サーバーサイドリクエストフォージェリ（SSRF）**を使用してインスタンスに認証情報を発行させました。
- ロギングが完全に集中化されていなかったため、検出が遅延しました。
教訓： 常にIAMロールをレビューし、最小特権原則を適用し、異常なリクエストパターンを監視してください。
AccentureのS3露出（2017）：公開バケットが機密データを露出
グローバルITコンサルタントAccentureは、複数のS3バケットを公開アクセス可能にし、内部アクセスキー、APIデータ、顧客認証情報を含んでいました。これらの設定ミスはバケットレベルのアクセスポリシーと監視の欠如に起因しました。
修復： 厳格なアクセス制御を持つS3バケットポリシーを使用し、AWS Configを活用してリアルタイムで公開露出を検出します。
Booz Allen Hamiltonリーク（2017）：政府データを含むオープンS3バケット
別の主要なコンサルタント会社、Booz Allen Hamiltonは、オープンS3バケットにより分類軍事ファイルと認証情報を不注意に漏洩させました。侵害は内部監視ツールではなく、セキュリティ研究者によって発見されました。
学んだ教訓： 慎重で監査された決定なしに、インターネットにリソースを露出させるべきではありません。Default-denyポリシーと自動修復ツールは類似のAWSセキュリティリスクを防ぐことができます。
サプライチェーン認証情報リーク（2026）：AIゲートウェイがAWS認証情報を露出
2026年、脅威インテリジェンス企業CloudSEKは、人気のAIゲートウェイライブラリを通じたサプライチェーン攻撃を追跡し、2,500以上の組織と約434,000のCI/CDパイプラインでクラウド認証情報、SSHキー、Kubernetesトークンを露出させました。AWSプラットフォームの欠陥ではありませんが、このインシデントはAWS認証情報がサードパーティツールを通じて漏洩する可能性があることを示しています — AWSコンソールを超えてシークレット管理と認証情報衛生が重要であることを思い出させます。
学んだ教訓： AWS認証情報をシークレットマネージャーに保管し、リポジトリにコミットされた環境ファイルに保管せず、キーを定期的にローテーションします。クラウド認証情報へのアクセスを持つサードパーティライブラリを攻撃面の一部として扱います。
AWSセキュリティチェックリスト
このチェックリストを使用して、AWS環境を最も一般的なAWSセキュリティリスクに対して監査してください：
- アカウントレベルでS3 Block Public Accessを有効化（2023年以前のバケットもカバー）
- ルートアカウントでMFAを強制し、書き込みアクセスを持つすべてのIAMユーザー
- 最小特権IAMを適用 —
"Action": "*", "Resource": "*"ポリシーなし - デフォルト暗号化をS3、EBS、RDSで有効化
- セキュリティグループを制限 — SSH、RDP、またはデータベースポートで
0.0.0.0/0なし - 公開IP自動割り当てをプライベートサブネットで無効化
- CloudTrailをすべてのリージョンで有効化してAPI呼び出しログ記録
- GuardDutyを脅威検出のために有効化
- AWS ConfigをCIS AWS Foundations Benchmarkルールで有効化
- Security Hubを実行してアカウント間で発見を集約
- IAMアクセスキーを少なくとも90日ごとにローテーション
- アプリケーションシークレットにAWS Secrets Managerを使用、repoの
.envファイルではなく - Systems Manager Patch ManagerでEC2インスタンスをパッチ適用
- AWS Security Bulletinsに登録し、重要なCVEに対応
よくある質問
最も一般的なAWSセキュリティ問題は何ですか？
最も一般的なAWSセキュリティ問題は、S3バケットの設定ミス、過度に許容的なIAMポリシー、ルートおよびIAMユーザーでのMFA欠如、保存時および転送時のデータ暗号化欠如、公開APIおよびエンドポイント、未パッチのEC2インスタンス、およびセキュリティグループとネットワークACLの設定ミスです。これらのほとんどはAWSプラットフォームの欠陥ではなく、顧客側の設定ミスに起因します。
AWS共有責任モデルとは何ですか？
AWS共有責任モデルは、AWSが何をセキュアにし、顧客が何をセキュアにするかを定義します：AWSはクラウド「の」セキュリティ（物理データセンター、ネットワークハードウェア、ハイパーバイザー、基盤サービス）を担当し、顧客はクラウド「内」のセキュリティ（アプリケーション、データ、IAM、設定、暗号化、パッチ適用）を担当します。ほとんどのAWSセキュリティ問題は、この境界の誤解から生じます。
AWSセキュリティ問題をどう防ぎますか？
AWSセキュリティ問題を防ぐには、最小特権IAMを強制し、すべてのユーザーでMFAを有効にし、アカウントレベルでS3 Block Public Accessを有効にし、保存時および転送時のデータを暗号化し、CloudTrailとGuardDutyで継続的に監視し、AWS ConfigとSecurity Hubでセキュリティチェックを自動化し、IAMアクセスキーとシークレットを定期的にローテーションします。
AWSはデフォルトで安全ですか？
AWSはデフォルトで安全ではありませんが、完全に安全でもありません。AWSは基盤インフラをセキュアにしますが、多くのサービス — 2023年4月より前に作成されたS3バケット、IAMポリシー、セキュリティグループ、暗号化設定 — は顧客が安全な設定を適用する必要があります。デフォルト設定は改善されましたが、顧客側の設定ミスが依然としてAWS侵害の主な原因です。
Capital One AWS侵害とは何ですか？
2019年のCapital One侵害は1億件以上の顧客レコードを露出させました。攻撃者は過度に許容的なIAMロールを持つEC2インスタンスのサーバーサイドリクエストフォージェリ（SSRF）脆弱性を悪用し、インスタンスの認証情報を使用して機密S3データを読み取りました。根本的な原因はSSRF、過度のIAM権限、および遅延した検出の組み合わせ — すべて顧客側のAWSセキュリティ問題でした。
AWS Block Public AccessはデフォルトでS3リークを防ぎますか？
2023年4月5日以降、AWSは新しいバケットでS3 Block Public Accessを有効にし、ACLをデフォルトで無効にします。ただし、このデフォルトは遡及しません — その日より前に作成されたバケットは、アカウントまたはバケットレベルでBlock Public Accessを明示的に有効にしない限り、元の公開アクセス設定を保持します。2023年以前のバケットは依然としてS3データリークの一般的な原因です。
結論
AWS環境をセキュアにすることは、AWSの組み込み保護に依存する以上のことを必要とします。このガイドが示すように、2025-2026年の最も一般的なAWSセキュリティ問題 — S3設定ミス、過度に許容的なIAM、MFA欠如、公開サービス、未パッチインスタンス、弱いネットワーク制御 — は顧客側の問題であり、顧客側の規律で防ぐことができます。AWS共有責任モデルから始め、最小特権を強制し、すべてを暗号化し、セキュリティチェックを自動化し、認証情報を攻撃面の一部として扱います。上記のチェックリストは実践的な出発点です；今日アカウントに対して実行してください。
AWS環境のハードニングや安全なクラウドワークロードの構築に支援が必要な場合、HDWEBSOFTはAWS開発サービスとサイバーセキュリティサービスを提供しています。
