AWS監査のポイント：セキュリティ設定の確認方法

はじめに：なぜ今、AWS監査が重要なのか

クラウドサービスの普及に伴い、多くの企業がAWS（Amazon Web Services）を活用してビジネスを展開しています。2024年時点で、全世界のクラウドインフラ市場においてAWSは約31%のシェアを占めており、日本国内でも数多くの企業が本番環境をAWS上で稼働させています。

しかし、クラウド環境の急速な拡大は、セキュリティリスクの増大も意味します。実際、ガートナー社の調査によると、クラウドセキュリティインシデントの95%以上は、クラウドプロバイダー側ではなく、ユーザー企業側の設定ミスに起因するとされています。

このような背景から、AWS環境に対する適切な監査は、企業のセキュリティ体制を維持・向上させる上で不可欠なプロセスとなっています。本記事では、IT監査・セキュリティの実務担当者向けに、AWS監査における具体的な確認ポイントと実践的な手法を詳しく解説します。

AWS監査の基本概念と全体像

クラウド監査における責任共有モデルの理解

AWS環境を監査する際、まず押さえておくべきは「責任共有モデル（Shared Responsibility Model）」です。これは、AWSとユーザー企業がそれぞれ担当するセキュリティ責任範囲を明確にした概念です。

AWSが責任を持つ領域（クラウドのセキュリティ）：

• 物理的なデータセンターのセキュリティ
• ネットワークインフラストラクチャ
• ハイパーバイザーの管理
• AWSサービス自体のセキュリティ

ユーザー企業が責任を持つ領域（クラウド内のセキュリティ）：

• IAM（Identity and Access Management）の設定
• データの暗号化
• ネットワーク設定（セキュリティグループ、NACL等）
• OSやアプリケーションの設定・パッチ管理
• ログ管理・監視設定

AWS監査では、この責任共有モデルに基づき、ユーザー企業側の責任範囲を中心に確認を行います。

監査のフレームワークと準拠基準

AWS環境の監査を実施する際は、以下のようなフレームワークや基準を参照することが一般的です：

• CIS AWS Foundations Benchmark：Center for Internet Securityが提供するAWS向けのセキュリティベストプラクティス集。具体的な設定項目と推奨値が定義されている
• AWS Well-Architected Framework：AWS自身が提供するベストプラクティス集。セキュリティを含む5つの柱で構成
• NIST Cybersecurity Framework：米国国立標準技術研究所が策定したサイバーセキュリティフレームワーク
• ISO 27001/27017：情報セキュリティマネジメントシステムの国際規格

これらのフレームワークを参照しながら、自社の業種やリスク特性に応じた監査項目を設定することが重要です。

具体的な確認ポイント：8つの重要領域

1. IAM（Identity and Access Management）の設定確認

IAMは、AWS環境全体のアクセス制御を司る最も重要なサービスです。IAMの設定不備は、不正アクセスやデータ漏洩の直接的な原因となり得ます。

確認すべき主要項目：

ルートアカウントの管理

- ルートアカウントにMFA（多要素認証）が有効化されているか
- ルートアカウントのアクセスキーが存在しないか
- ルートアカウントの使用履歴（直近90日以内に使用されていないことが望ましい）

IAMユーザーの管理

- すべてのIAMユーザーにMFAが設定されているか
- 使用されていないIAMユーザー（90日以上未使用）が存在しないか
- パスワードポリシーが適切に設定されているか
  - 最小文字数：14文字以上推奨
  - 大文字、小文字、数字、記号の組み合わせ要求
  - パスワード履歴：24世代以上
  - パスワード有効期限：90日以内

IAMポリシーの確認

- 過度に広範な権限（"*"の使用）がないか
- 最小権限の原則が適用されているか
- 管理者権限を持つユーザー/ロールの数は適切か

実務でのチェック方法：

AWS CLIを使用した確認コマンド例：

# MFAが有効でないIAMユーザーの一覧
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 --decode

# 管理者権限を持つユーザーの確認
aws iam list-attached-user-policies --user-name [ユーザー名]

2. S3バケットのセキュリティ設定

S3（Simple Storage Service）は、AWSで最も広く使われるストレージサービスですが、設定ミスによるデータ漏洩事故も頻繁に報告されています。2023年には、S3バケットの設定不備により、数十万件の個人情報が流出する事故が複数発生しています。

確認すべき主要項目：

パブリックアクセス設定

- S3パブリックアクセスブロックが有効化されているか
  - BlockPublicAcls
  - IgnorePublicAcls
  - BlockPublicPolicy
  - RestrictPublicBuckets
- 意図しないパブリックバケットが存在しないか

暗号化設定

- サーバーサイド暗号化が有効化されているか
  - SSE-S3（AES-256）
  - SSE-KMS（AWS KMSによる暗号化）
  - SSE-C（顧客提供キー）
- デフォルト暗号化が設定されているか

アクセスログとバージョニング

- S3アクセスログが有効化されているか
- バージョニングが有効化されているか（重要データの場合）
- ライフサイクルポリシーは適切か

バケットポリシーの確認ポイント：

// 危険なバケットポリシーの例（避けるべき設定）
{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-bucket/*"
}

上記のように、Principalが「*」（誰でもアクセス可能）となっている設定は、業務上の正当な理由がない限り是正が必要です。

3. VPCとネットワークセキュリティ

VPC（Virtual Private Cloud）は、AWS上の仮想ネットワーク環境です。ネットワーク設計の不備は、不正アクセスの経路となり得ます。

確認すべき主要項目：

セキュリティグループの設定

- インバウンドルールで0.0.0.0/0からのアクセスが許可されているか
  - 特にSSH（22番ポート）、RDP（3389番ポート）への全開放は高リスク
- 使用されていないセキュリティグループが存在しないか
- デフォルトセキュリティグループのルールが最小限か

ネットワークACL（NACL）の確認

- デフォルトNACLが適切に設定されているか
- カスタムNACLのルールは最小権限の原則に従っているか

VPCフローログ

- VPCフローログが有効化されているか
- ログの保持期間は監査要件を満たしているか
- 適切なログ送信先（CloudWatch Logs/S3）が設定されているか

リスクの高いセキュリティグループ設定の例：

4. CloudTrailによる操作ログの監査

CloudTrailは、AWS環境内で行われたAPIコールを記録するサービスです。インシデント発生時の調査や、不正操作の検知に不可欠なサービスです。

確認すべき主要項目：

基本設定

- CloudTrailが有効化されているか
- すべてのリージョンでトレイルが作成されているか
- マルチリージョントレイルの使用が推奨
- グローバルサービスイベント（IAM等）の記録が有効か

ログの保護

- ログファイルの検証（ログファイル整合性検証）が有効化されているか
- CloudTrailログのS3バケットに対するパブリックアクセスが禁止されているか
- S3バケットのMFA Delete機能は有効か
- ログファイルの暗号化（SSE-KMS）が設定されているか

アラート設定

- CloudWatch Logsとの連携は設定されているか
- 重要なイベントに対するアラートは設定されているか
  - ルートアカウントの使用
  - IAMポリシーの変更
  - セキュリティグループの変更
  - CloudTrailの無効化

5. 暗号化とキー管理（KMS）

データ保護において、暗号化は最も基本的かつ重要な対策です。AWS KMS（Key Management Service）を使用した適切なキー管理が求められます。

確認すべき主要項目：

KMSキーの管理

- 顧客管理キー（CMK）のローテーションが有効化されているか
  - 推奨：1年ごとの自動ローテーション
- キーポリシーは最小権限の原則に従っているか
- 使用されていないキーは無効化・削除されているか

暗号化の適用状況

- EBSボリュームの暗号化がデフォルトで有効化されているか
- RDSインスタンスが暗号化されているか
- Secrets Managerでシークレット情報が管理されているか

暗号化チェックのためのCLIコマンド例：

# EBSボリュームの暗号化状態確認
aws ec2 describe-volumes --query 'Volumes[?Encrypted==`false`].VolumeId'

# RDSインスタンスの暗号化状態確認
aws rds describe-db-instances --query 'DBInstances[?StorageEncrypted==`false`].DBInstanceIdentifier'

6. 監視とアラート設定（CloudWatch/GuardDuty）

継続的なセキュリティ監視は、インシデントの早期発見と対応に不可欠です。

CloudWatchの確認項目：

- 重要なメトリクスに対するアラームが設定されているか
  - 不審なAPIコール
  - 失敗したログイン試行
  - セキュリティグループの変更
- ログの保持期間は適切か（コンプライアンス要件に準拠）
- ダッシュボードでセキュリティ状況が可視化されているか

GuardDutyの確認項目：

- GuardDutyが有効化されているか
- すべてのリージョンで有効化されているか
- 検出結果の通知設定は適切か
- 重要度の高い検出結果への対応プロセスは定義されているか

設定すべきCloudWatchアラームの例：

7. コンプライアンス設定（AWS Config）

AWS Configは、AWSリソースの設定変更を追跡し、コンプライアンス状態を評価するサービスです。

確認すべき主要項目：

基本設定

- AWS Configが有効化されているか
- 監視対象のリソースタイプは適切に設定されているか
- 設定履歴の保持期間は要件を満たしているか

コンプライアンスルール

- AWS Configルールが設定されているか
- マネージドルールの活用状況
  - ec2-instance-no-public-ip
  - s3-bucket-public-read-prohibited
  - encrypted-volumes
  - iam-password-policy
  - mfa-enabled-for-iam-console-access
- 違反検出時の自動修復設定は適切か

推奨するConfigルールの例：

8. 脆弱性管理と自動評価（Security Hub/Inspector）

継続的な脆弱性評価は、セキュアな環境を維持するために重要です。

Security Hubの確認項目：

- Security Hubが有効化されているか
- セキュリティ標準が有効化されているか
  - AWS Foundational Security Best Practices
  - CIS AWS Foundations Benchmark
  - PCI DSS（該当する場合）
- 検出結果の集約と対応プロセスは定義されているか
- 他のAWSセキュリティサービスとの統合は適切か

Amazon Inspectorの確認項目：

- Inspectorが有効化されているか
- EC2インスタンスとコンテナイメージの評価対象は適切か
- 脆弱性検出時のアラート設定は適切か
- 発見された脆弱性への対応期限は定義されているか

AWS監査の実施アプローチ

手動監査とツール活用のバランス

AWS監査を効率的に行うためには、手動での確認と自動化ツールの活用を組み合わせることが重要です。

手動監査が適している領域：

• ポリシーや設計の妥当性評価
• ビジネス要件との整合性確認
• 例外承認の適切性確認

自動化ツールが適している領域：

• 設定項目の網羅的な確認
• 継続的なコンプライアンス監視
• ドリフト検出（意図しない設定変更の検知）

推奨される監査ツール

AWS純正ツール：

• AWS Config：設定管理とコンプライアンス評価
• Security Hub：セキュリティ状況の一元管理
• Trusted Advisor：ベストプラクティスチェック
• IAM Access Analyzer：アクセス許可の分析

サードパーティツール：

• Prowler：オープンソースのAWSセキュリティ評価ツール
• ScoutSuite：マルチクラウド対応のセキュリティ監査ツール
• CloudSploit：クラウドセキュリティ設定チェックツール

Prowlerを使用した監査実行例：

# Prowlerのインストール
pip install prowler

# 基本的な監査実行
prowler aws

# CIS Benchmark準拠チェック
prowler aws --compliance cis_2.0_aws

# 特定のサービスのみチェック
prowler aws --services iam s3 cloudtrail

監査証跡の保全

監査結果は、適切に保全・管理する必要があります。

証跡保全のポイント：

- 監査実施日時、実施者、対象範囲の記録
- スクリーンショットやCLI出力の保存
- 検出事項のリスク評価と優先順位付け
- 改善計画と対応状況の追跡

よくある質問（FAQ）

Q1: AWS監査の頻度はどのくらいが適切ですか？

A: 監査の頻度は、組織のリスク特性や規制要件によって異なりますが、一般的には以下のような頻度が推奨されます。

• 継続的な監視（リアルタイム）：AWS Config、Security Hub、GuardDutyによる自動監視を常時稼働させる
• 月次レビュー：Security Hubの検出結果、IAMアクセスレビュー、コスト異常の確認
• 四半期監査：IAMユーザー・ロールの棚卸し、不要リソースの特定、セキュリティグループの見直し
• 年次監査：全体的なセキュリティ体制の評価、外部監査対応、ポリシー・手順の見直し

金融機関や医療機関など、規制の厳しい業界では、より頻繁な監査が求められる場合があります。また、重大なセキュリティインシデントが発生した場合や、大規模なシステム変更後には、臨時の監査を実施することをお勧めします。

Q2: 監査で発見された問題への優先順位付けはどのように行えばよいですか？

A: 発見された問題（検出事項）は、以下の観点から優先順位を付けることをお勧めします。

リスク評価の観点：

また、CIS BenchmarkやSecurity Hubでは、各項目に重要度が付与されているため、それを参考にすることも有効です。ただし、自社のビジネス要件やデータの機密性を考慮して、優先順位を調整することが重要です。

Q3: マルチアカウント環境での監査を効率的に行う方法はありますか？

A: 複数のAWSアカウントを運用している場合、個別に監査を行うのは非効率です。以下のアプローチを検討してください。

AWS Organizationsの活用：

- 組織レベルでのポリシー適用（SCP：Service Control Policies）
- 集中管理アカウントからの監査実施
- 組織全体のCloudTrailログの集約

委任管理者の設定：

- Security Hubの委任管理者を設定し、全アカウントの検出結果を一元管理
- AWS Configのアグリゲータを使用して、複数アカウントの設定を統合
- GuardDutyの管理者アカウントで脅威検出を集約

自動化の推進：

- StackSetsを使用したセキュリティ設定の一括展開
- Organizations統合のConfigルールの適用
- 監査スクリプトのクロスアカウント実行

マルチアカウント環境では、Landing Zone やControl Towerを活用することで、セキュリティのベースラインを確立し、監査の効率化を図ることができます。

まとめ：効果的なAWS監査のために

本記事では、AWS環境におけるセキュリティ監査の主要なポイントを解説しました。最後に、効果的な監査を実施するための要点を整理します。

監査成功のための5つのポイント

1. 責任共有モデルの理解：AWS環境における自社の責任範囲を正確に把握し、監査対象を明確にする

2. フレームワークの活用：CIS Benchmark等の標準的なフレームワークを基準とし、網羅的かつ一貫性のある監査を実施する

3. 自動化ツールの活用：AWS純正サービス（Config、Security Hub等）やサードパーティツールを活用し、継続的な監視と定期監査を効率化する

4. リスクベースアプローチ：すべての項目を同じ重みで扱うのではなく、自社のリスク特性に応じて優先順位を付ける

5. 継続的改善：監査結果をPDCAサイクルに組み込み、セキュリティ体制の継続的な向上を図る

最後に

クラウド環境のセキュリティは、一度設定すれば終わりというものではありません。AWSサービスは日々進化し、新たなセキュリティ機能が追加される一方で、新たな脅威も出現し続けています。

定期的な監査を通じて現状を把握し、ベストプラクティスに沿った設定を維持することで、セキュアなAWS環境を実現してください。また、監査で発見された課題は、単に是正するだけでなく、なぜその問題が発生したかの根本原因を分析し、再発防止策を講じることが重要です。

本記事が、皆様のAWS監査業務の一助となれば幸いです。

参考リンク：

• CIS AWS Foundations Benchmark
• AWS Well-Architected Framework - Security Pillar
• AWS Security Best Practices