AWSセキュリティ監査：よくある設定ミスと対策April 30, 2026 · 3 分
AWSセキュリティ監査：よくある設定ミスと対策
目次

はじめに：なぜAWSセキュリティ監査が重要なのか

クラウドサービスの普及に伴い、Amazon Web Services（AWS）を利用する企業は年々増加しています。Gartnerの調査によると、2025年時点でエンタープライズのクラウド支出の約65%がパブリッククラウドに向けられており、その中でもAWSは約32%のシェアを占める最大のプロバイダーとなっています。

しかし、クラウド環境の拡大とともに、セキュリティインシデントも増加の一途をたどっています。IBMの「Cost of a Data Breach Report 2025」によると、クラウド環境における設定ミスが原因のデータ漏洩は全体の約23%を占め、その平均被害額は1件あたり約480万ドル（約7.2億円）に達しています。

重要なのは、これらのインシデントの多くが**「設定ミス」という人為的なエラー**に起因しているという点です。AWSは「責任共有モデル」を採用しており、インフラストラクチャのセキュリティはAWSが担保する一方、クラウド上のリソース設定やデータ保護は利用者の責任となります。

本記事では、IT監査担当者やセキュリティ実務者が押さえておくべきAWSセキュリティ監査の要点として、実際の現場で頻繁に発見される設定ミスとその対策を詳しく解説します。

AWSセキュリティ監査の基本：責任共有モデルを理解する

責任共有モデルとは

AWSの責任共有モデル（Shared Responsibility Model）は、セキュリティとコンプライアンスの責任をAWSと利用者で分担する考え方です。

AWSの責任範囲（Security of the Cloud）：

利用者の責任範囲（Security in the Cloud）：

監査の際には、この責任範囲を明確に理解した上で、利用者責任の範囲に焦点を当ててチェックを行うことが重要です。

よくある設定ミスと対策：7つの重要ポイント

1. S3バケットのパブリックアクセス設定

問題の概要：

Amazon S3（Simple Storage Service）は、AWSで最も広く利用されているストレージサービスです。しかし、S3バケットのパブリックアクセス設定の誤りは、最も頻繁に発生するセキュリティインシデントの原因の一つです。

2017年の米国大手信用情報会社のデータ漏洩事件をはじめ、S3の設定ミスによる情報漏洩は後を絶ちません。2024年だけでも、世界中で200件以上のS3設定ミスに起因するデータ漏洩が報告されています。

具体的なチェックポイント：

□ バケットポリシーで「Principal: "*"」が設定されていないか
□ ACL（Access Control List）でパブリック読み取り/書き込みが許可されていないか
□ アカウントレベルのパブリックアクセスブロック設定が有効か
□ S3 Access Analyzerで外部アクセス可能なリソースが検出されていないか

対策：

  1. アカウントレベルでのパブリックアクセスブロック設定を有効化します。AWS Organizationsを使用している場合は、SCP（Service Control Policy）でこの設定を強制することも可能です。

  2. AWS Configを使用して、s3-bucket-public-read-prohibitedおよびs3-bucket-public-write-prohibitedルールを有効化し、継続的な監視を行います。

  3. S3 Access Analyzerを定期的に実行し、外部アクセス可能なリソースを特定します。

実務ポイント： 監査時には、単にパブリックアクセス設定を確認するだけでなく、意図的にパブリック公開が必要なバケット（静的ウェブサイトホスティングなど）が適切に文書化・承認されているかも確認しましょう。

2. IAMユーザー・ロールの過剰な権限付与

問題の概要：

IAM（Identity and Access Management）は、AWSリソースへのアクセスを制御する中核的なサービスです。多くの組織で見られる問題は、「最小権限の原則」に反した過剰な権限付与です。

特に以下のパターンが頻繁に発見されます：

具体的なチェックポイント：

□ AdministratorAccessまたはPowerUserAccessを持つユーザー/ロールの数
□ インラインポリシーで「Action: "*"」または「Resource: "*"」が設定されているか
□ IAM Access Analyzerで検出された問題の件数
□ 90日以上使用されていないIAMユーザー・アクセスキーの有無
□ MFA（多要素認証）が有効化されていないユーザーの有無

対策：

  1. IAM Access Analyzerのポリシー検証機能を使用して、過剰な権限を特定します。

  2. AWS CloudTrailのログを分析し、実際に使用されている権限に基づいてポリシーを絞り込みます。IAM Access Analyzerの「ポリシー生成」機能を活用すると、CloudTrailのアクティビティに基づいて最小権限ポリシーを自動生成できます。

  3. 定期的な棚卸しとして、IAM Credential Reportを出力し、以下の項目を確認します：

    • パスワードの最終使用日
    • アクセスキーの最終使用日
    • MFAの有効化状況

実務ポイント： 監査では、権限の付与理由と承認プロセスの文書化も確認します。「なぜその権限が必要なのか」を説明できない権限は、削減の候補となります。

IAM権限レビューの目安：

権限レベル推奨レビュー頻度
管理者権限月次
開発者権限四半期
読み取り専用権限半期
サービスアカウント四半期

3. セキュリティグループの設定不備

問題の概要：

セキュリティグループは、EC2インスタンスやRDSインスタンスなどへのネットワークアクセスを制御するファイアウォールです。設定ミスにより、意図せずインターネットからのアクセスが許可されてしまうケースが多発しています。

代表的な問題パターン：

具体的なチェックポイント：

□ インバウンドルールで0.0.0.0/0または::/0が設定されているポート
□ 管理ポート（22, 3389）の開放範囲
□ データベースポートの開放状況
□ 未使用のセキュリティグループの存在
□ ルールの説明（Description）が記載されているか

対策：

  1. AWS Configを使用して、以下のマネージドルールを有効化します：

    • restricted-ssh：SSHポートの開放を検出
    • restricted-common-ports：一般的な危険ポートの開放を検出
    • vpc-sg-open-only-to-authorized-ports：許可されたポート以外の開放を検出

  2. AWS Systems Manager Session Managerを導入し、SSHを使用せずにEC2インスタンスへアクセスできる環境を構築します。これにより、22番ポートを完全に閉鎖できます。

  3. セキュリティグループの命名規則と説明文の標準化を行い、各ルールの目的を明確にします。

実務ポイント： 監査時には、開放されているポートについて「ビジネス上の必要性」と「代替手段の検討有無」を確認します。例えば、SSH直接アクセスが必要という説明に対しては、Session Managerや踏み台サーバー（Bastion Host）の利用を提案できます。

4. 暗号化設定の不備

問題の概要：

データの暗号化は、データ保護の基本的な対策です。AWSでは、保存データ（at rest）と通信データ（in transit）の両方を暗号化することが推奨されていますが、以下のような設定不備がよく見られます：

具体的なチェックポイント：

□ EBSボリュームの暗号化状況（デフォルト暗号化の有効化）
□ S3バケットのデフォルト暗号化設定
□ RDSインスタンスのストレージ暗号化とSSL接続の強制
□ KMSキーの管理状況とローテーション設定
□ ACM証明書の有効期限と自動更新設定

対策：

  1. アカウントレベルでEBSデフォルト暗号化を有効化します。これにより、新規作成されるEBSボリュームは自動的に暗号化されます。
aws ec2 enable-ebs-encryption-by-default --region ap-northeast-1
  1. S3バケットポリシーで、暗号化されていないオブジェクトのアップロードを拒否します：
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption": "true"
        }
      }
    }
  ]
}
  1. AWS Configで暗号化関連のルールを有効化します：
    • ec2-ebs-encryption-by-default
    • s3-bucket-server-side-encryption-enabled
    • rds-storage-encrypted

実務ポイント： 監査では、暗号化キーの管理体制も重要なチェックポイントです。AWS管理キー（aws/xxxxx）を使用している場合と、カスタマーマネージドキー（CMK）を使用している場合では、キー管理の責任範囲が異なります。機密性の高いデータを扱う場合は、CMKの使用と適切なキーポリシーの設定を推奨します。

5. ログ・監視設定の不備

問題の概要：

セキュリティインシデントの検出と調査には、適切なログ設定が不可欠です。しかし、以下のような設定不備により、インシデント発生時に十分な調査ができないケースがあります：

具体的なチェックポイント：

□ CloudTrailが全リージョンで有効化されているか
□ CloudTrailログの整合性検証（Log File Validation）が有効か
□ CloudTrailログの保存先S3バケットのアクセス設定
□ VPCフローログの有効化状況
□ GuardDutyの有効化状況
□ Security Hubの有効化と統合状況

対策：

  1. AWS CloudTrailを組織全体で有効化します。AWS Organizationsを使用している場合は、組織証跡（Organization Trail）を作成することで、全メンバーアカウントのAPIアクティビティを一元的に記録できます。

  2. Amazon GuardDutyを有効化します。GuardDutyは機械学習を活用した脅威検出サービスで、以下のような異常を自動検出します：

    • 不審なAPIコール
    • 暗号通貨マイニング
    • マルウェアによる通信
    • 特権昇格の試み

  3. AWS Security Hubを有効化し、セキュリティチェックを自動化します。Security Hubは以下のセキュリティ基準に基づいて自動チェックを実行します：

    • AWS Foundational Security Best Practices
    • CIS AWS Foundations Benchmark
    • PCI DSS

必須の CloudWatch アラーム設定例：

監視項目検出する異常
ルートアカウントの使用管理者の不正アクセス
IAMポリシーの変更権限の不正変更
セキュリティグループの変更ネットワーク設定の改ざん
CloudTrailの無効化証跡隠滅の試み
認証失敗の増加ブルートフォース攻撃

実務ポイント： 監査では、ログの保存期間についても確認します。法規制やコンプライアンス要件により、ログの保存期間が定められている場合があります（例：PCI DSSでは1年間、SOXでは7年間）。S3ライフサイクルポリシーとGlacierへのアーカイブ設定を組み合わせて、コスト効率よく長期保存を実現しましょう。

6. ネットワーク設計の脆弱性

問題の概要：

VPC（Virtual Private Cloud）のネットワーク設計の不備は、セキュリティ侵害の影響範囲を拡大させる要因となります。以下のような問題がよく見られます：

具体的なチェックポイント：

□ パブリックサブネットに配置されているリソースの適切性
□ プライベートサブネットの設計とNATゲートウェイの配置
□ ネットワークACLのルール設定
□ VPCピアリング・Transit Gatewayの接続設計
□ VPCエンドポイントの活用状況

対策：

  1. 多層防御（Defense in Depth）アーキテクチャを採用します：

    • パブリックサブネット：ALB/NLB、Bastion Hostのみ
    • プライベートサブネット（アプリケーション層）：EC2インスタンス、ECS/EKS
    • プライベートサブネット（データ層）：RDS、ElastiCache

  2. VPCエンドポイントを活用し、AWSサービスへのアクセスをVPC内に閉じます：

    • ゲートウェイ型：S3、DynamoDB（無料）
    • インターフェース型：その他のAWSサービス（時間課金）

  3. AWS Network Firewallまたはサードパーティファイアウォールの導入を検討し、高度なトラフィック検査を実施します。

推奨ネットワーク構成例：

インターネット
    │
Internet Gateway
    │
├── パブリックサブネット
│   └── ALB (HTTPSのみ)
│
├── プライベートサブネット (アプリ層)
│   ├── EC2/ECS
│   └── NAT Gateway経由でインターネット接続
│
└── プライベートサブネット (データ層)
    ├── RDS
    └── インターネット接続なし

実務ポイント： 監査では、ネットワーク図と実際の設定の整合性を確認します。AWS Config のvpc-flow-logs-enabledルールでVPCフローログの有効化を確認し、実際のトラフィックパターンを分析することで、設計と実態の乖離を発見できます。

7. 自動化・IaC（Infrastructure as Code）セキュリティ

問題の概要：

近年、CloudFormationやTerraformなどのIaCツールによるインフラ構築が一般化しています。しかし、IaCテンプレート自体にセキュリティ上の問題が含まれていると、同じ設定ミスが大量に複製されてしまいます。

よく見られる問題：

具体的なチェックポイント：

□ IaCテンプレートの静的解析（SAST）ツールの導入
□ シークレット（認証情報）の管理方法
□ CI/CDパイプラインでのセキュリティゲートの設定
□ 本番環境へのデプロイ承認フロー
□ IaCテンプレートのバージョン管理と変更履歴

対策：

  1. IaCセキュリティスキャンツールをCI/CDパイプラインに組み込みます：

    • cfn-nag：CloudFormationテンプレートの静的解析
    • tfsec：Terraformコードのセキュリティスキャン
    • Checkov：マルチクラウド対応のIaCスキャナー

  2. AWS Secrets ManagerまたはAWS Systems Manager Parameter Storeを使用して、認証情報を安全に管理します。IaCテンプレートからは参照のみを行い、実際の値をハードコードしません。

  3. AWS Service Catalogを活用し、事前承認されたセキュアなテンプレートを提供します。

CI/CDパイプラインでの推奨セキュリティチェック：

ステージ1: コミット時
  └── git-secrets（ハードコードされた認証情報の検出）

ステージ2: ビルド時
  ├── cfn-nag / tfsec（IaCスキャン）
  └── 依存関係の脆弱性スキャン

ステージ3: デプロイ前
  ├── CloudFormation Change Set確認
  └── セキュリティチームによるレビュー（本番環境）

ステージ4: デプロイ後
  └── AWS Config / Security Hubによる継続的監視

実務ポイント： 監査では、「誰が」「いつ」「どのような変更を」「なぜ」行ったかを追跡できる体制が整っているかを確認します。GitリポジトリのブランチプロテクションルールやPull Requestのレビュープロセスも監査対象となります。

よくある質問（FAQ）

Q1: AWS環境のセキュリティ監査はどのくらいの頻度で実施すべきですか？

A1: 監査の種類によって推奨頻度は異なります。

継続的監査（リアルタイム）：

定期監査（四半期）：

年次監査：

また、システム変更時（新サービスの導入、大規模なアーキテクチャ変更など）には、変更に伴うセキュリティ影響を評価する臨時監査を実施することを推奨します。

Q2: 監査で発見された問題の優先順位はどのように決めればよいですか？

A2: 以下のリスク評価マトリクスを参考に、優先順位を決定します。

優先度の決定要素：

要素高リスク中リスク低リスク
影響範囲全システム・顧客データ特定システム開発環境のみ
発生可能性すでに悪用事例あり技術的に可能理論上の脆弱性
検出難易度自動スキャンで検出手動確認が必要特殊な条件下のみ

即時対応が必要な問題（Critical）：

1週間以内に対応すべき問題（High）：

1ヶ月以内に対応すべき問題（Medium）：

計画的に対応する問題（Low）：

Q3: 小規模な組織でも本格的なセキュリティ監査は必要ですか？最小限のコストで実施するには？

A3: 組織の規模に関わらず、クラウド環境のセキュリティ監査は必要です。特に、顧客データや個人情報を扱う場合は、法的責任を問われる可能性もあります。

小規模組織向けの最小限セキュリティ監査セット：

無料で実施できる対策：

  1. IAM Access Analyzer：外部アクセス可能なリソースの特定（無料）
  2. AWS Trusted Advisor：基本的なセキュリティチェック（無料プランでも一部利用可能）
  3. S3パブリックアクセスブロック：アカウントレベルでの設定（無料）
  4. CloudTrail：最初の証跡は無料（S3保存コストは発生）

低コストで大きな効果がある対策：

  1. AWS Security Hub：約$0.001/チェック（月額数ドル程度から）
  2. Amazon GuardDuty：$4/100万イベント程度（小規模環境では月額数ドル）
  3. AWS Config：$0.003/評価（必要なルールのみ有効化）

推奨アプローチ： まず、Security Hubの「AWS Foundational Security Best Practices」スタンダードを有効化し、自動チェックを開始します。これにより、最も重要なセキュリティ設定の問題を自動検出できます。検出された問題を優先度順に対処していくことで、効率的にセキュリティレベルを向上させることができます。

まとめ：効果的なAWSセキュリティ監査のために

本記事では、AWSセキュリティ監査において頻繁に発見される設定ミスと、その対策について解説しました。

重要なポイントの振り返り：

  1. 責任共有モデルの理解：AWSと利用者の責任範囲を明確に理解し、利用者責任の範囲に焦点を当てた監査を実施する

  2. S3バケットのアクセス設定：パブリックアクセスブロックの有効化とAccess Analyzerによる継続的監視

  3. IAM権限の最小化：最小権限の原則に基づいた権限設計と定期的な棚卸し

  4. セキュリティグループの適切な設定：管理ポートの保護とSession Managerの活用

  5. 暗号化の徹底：保存データと通信データの両方を暗号化

  6. ログ・監視の充実：CloudTrail、GuardDuty、Security Hubによる多層的な監視体制

  7. IaCセキュリティ：インフラコードの静的解析とCI/CDパイプラインでのセキュリティ

IT監査 セキュリティ