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

クラウドサービスの利用が急速に拡大する中、AWS（Amazon Web Services）を導入する企業は年々増加しています。Gartner社の調査によると、2025年には企業のワークロードの85%以上がクラウド上で稼働すると予測されています。しかし、この利便性の裏側には、適切に管理されなければ深刻なセキュリティリスクが潜んでいます。

実際、2024年に発生したクラウド関連のセキュリティインシデントの約68%が「設定ミス」に起因していたというデータもあります。S3バケットの公開設定ミスによる情報漏洩、IAMポリシーの過剰な権限付与、セキュリティグループの不適切な設定など、人為的なミスがサイバー攻撃の糸口となるケースが後を絶ちません。

本記事では、IT監査担当者やセキュリティ実務者の方々に向けて、AWS環境を監査する際の具体的な確認ポイントと実践的な手法を解説します。内部監査、外部監査、あるいはセキュリティアセスメントの場面で活用できる内容となっていますので、ぜひ最後までお読みください。

AWS監査の基本概念と背景知識

クラウド監査と従来型監査の違い

オンプレミス環境の監査では、物理サーバーやネットワーク機器に直接アクセスして設定を確認することができました。一方、AWS監査では「責任共有モデル」を理解することが出発点となります。

責任共有モデルとは、AWSとユーザーがセキュリティ責任を分担する考え方です。具体的には以下のように分かれます：

  • AWSの責任（クラウド “の” セキュリティ）：物理インフラ、ハードウェア、ネットワーク、仮想化基盤など
  • ユーザーの責任（クラウド “内” のセキュリティ）：データ、アプリケーション、IAM設定、ネットワーク設定、暗号化など

監査担当者は、主にユーザー責任の領域を確認することになります。ただし、AWSが提供するコンプライアンスレポート（SOC 2レポートなど）を取得し、AWS側の統制も確認することが重要です。

AWS監査で活用できるフレームワーク

監査を実施する際は、以下のフレームワークや基準を参照すると体系的な確認が可能です：

  • CIS AWS Foundations Benchmark：最も広く使われるAWSセキュリティ基準（約50項目）
  • AWS Well-Architected Framework：セキュリティを含む5つの柱で構成
  • NIST Cybersecurity Framework：サイバーセキュリティの国際的なフレームワーク
  • ISO 27001/27017：クラウドセキュリティの国際規格

特に、CIS AWS Foundations Benchmarkは具体的なチェック項目が明示されているため、監査の基礎として活用しやすいでしょう。

具体的な監査ポイント：7つの重要領域

ここからは、AWS監査で必ず確認すべき7つの領域について、具体的な手順と確認ポイントを解説します。

1. IAM（Identity and Access Management）の監査

IAMは、AWS環境全体のセキュリティの根幹を成す最重要項目です。アクセス権限の管理が適切でなければ、他のすべての対策が無意味になりかねません。

確認すべきポイント

ルートアカウントの保護状況

ルートアカウントは、AWSアカウント内のすべてのリソースに無制限にアクセスできる最高権限を持ちます。以下を確認してください：

確認コマンド（AWS CLI）：
aws iam get-account-summary
  • ルートアカウントにMFA（多要素認証）が設定されているか
  • ルートアカウントのアクセスキーが発行されていないか（発行されている場合は削除を推奨）
  • ルートアカウントの最終使用日時が90日以上前であるか

IAMユーザーとポリシーの確認

確認コマンド（AWS CLI）：
aws iam list-users
aws iam list-attached-user-policies --user-name [ユーザー名]
  • 全IAMユーザーにMFAが設定されているか
  • 長期間使用されていないユーザー（90日以上）が存在しないか
  • 「PowerUser」や「AdministratorAccess」など広範な権限が不必要に付与されていないか
  • インラインポリシーではなく、マネージドポリシーを使用しているか

アクセスキーの管理状況

アクセスキーは漏洩リスクが高いため、以下を重点的に確認します：

  • アクセスキーのローテーション頻度（90日以内が推奨）
  • 使用されていないアクセスキーの有無
  • 複数のアクセスキーを持つユーザーの妥当性

実務上のポイント

監査時には、IAM Credential Reportを生成すると効率的です。このレポートはCSV形式で出力され、全IAMユーザーの認証情報の状態を一覧で確認できます。

レポート生成コマンド：
aws iam generate-credential-report
aws iam get-credential-report --output text --query Content | base64 -d > credential_report.csv

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

Amazon S3（Simple Storage Service）は、AWSで最も広く使われるストレージサービスですが、設定ミスによる情報漏洩事例が最も多いサービスでもあります。

確認すべきポイント

パブリックアクセスの設定

確認コマンド：
aws s3api get-public-access-block --bucket [バケット名]

2019年以降、AWSはデフォルトでパブリックアクセスをブロックする設定を導入しました。以下の4つの設定がすべて「true」になっていることを確認します：

  • BlockPublicAcls
  • IgnorePublicAcls
  • BlockPublicPolicy
  • RestrictPublicBuckets

バケットポリシーの確認

確認コマンド：
aws s3api get-bucket-policy --bucket [バケット名]

ポリシーに「Principal: *」が含まれている場合、全世界からアクセス可能な状態を意味します。業務上の正当な理由がない限り、これは重大な設定ミスです。

暗号化設定

確認コマンド：
aws s3api get-bucket-encryption --bucket [バケット名]
  • サーバーサイド暗号化（SSE-S3、SSE-KMS、SSE-C）が有効になっているか
  • 機密データを含むバケットではSSE-KMSを使用しているか

アクセスログの有効化

バケットへのアクセスログが取得されていることを確認します。インシデント発生時の調査に必須です。

実務上のポイント

AWS Config Rulesを活用すると、S3バケットのセキュリティ設定を継続的に監視できます。「s3-bucket-public-read-prohibited」や「s3-bucket-server-side-encryption-enabled」などのマネージドルールが用意されています。

3. ネットワークセキュリティの監査

VPC（Virtual Private Cloud）、セキュリティグループ、ネットワークACLの設定は、外部からの不正アクセスを防ぐ重要な防衛線です。

セキュリティグループの確認

セキュリティグループは、EC2インスタンスなどのリソースに対するファイアウォールとして機能します。

確認コマンド：
aws ec2 describe-security-groups --query 'SecurityGroups[*].[GroupId,GroupName,IpPermissions]'

重点確認項目

  • インバウンドルールで「0.0.0.0/0」からのSSH（22番ポート）やRDP（3389番ポート）を許可していないか
  • インバウンドルールで不必要に広い範囲のポートを許可していないか
  • 未使用のセキュリティグループが存在しないか
  • 各ルールに説明（Description）が記載されているか

特に危険な設定例

リスクレベル設定内容
高0.0.0.0/0 から 22/tcp (SSH) を許可
高0.0.0.0/0 から 3389/tcp (RDP) を許可
高0.0.0.0/0 から全ポート(0-65535) を許可
中0.0.0.0/0 から 3306/tcp (MySQL) を許可
中0.0.0.0/0 から 5432/tcp (PostgreSQL) を許可

VPCフローログの確認

VPCフローログは、VPC内のネットワークトラフィックをキャプチャする機能です。

確認コマンド：
aws ec2 describe-flow-logs
  • 主要なVPCでフローログが有効になっているか
  • ログの保存先（S3またはCloudWatch Logs）が適切に設定されているか
  • ログの保持期間は十分か

4. CloudTrailとログ管理の監査

AWS CloudTrailは、AWSアカウント内のすべてのAPI呼び出しを記録するサービスです。いわばAWS環境の「監査ログ」であり、インシデント対応や法的な証跡として不可欠です。

確認すべきポイント

CloudTrailの有効化状況

確認コマンド：
aws cloudtrail describe-trails
aws cloudtrail get-trail-status --name [証跡名]
  • すべてのリージョンでCloudTrailが有効になっているか
  • マネジメントイベントとデータイベントの両方を記録しているか
  • ログファイルの整合性検証（ダイジェストファイル）が有効になっているか

ログの保護

  • CloudTrailログを保存するS3バケットのアクセス制御が適切か
  • ログファイルの暗号化（SSE-KMS推奨）が有効になっているか
  • S3バケットのバージョニングが有効になっているか（改ざん防止）
  • オブジェクトロックまたはMFA削除が設定されているか

ログの保持期間

法令や社内規程に基づき、適切な保持期間が設定されているか確認します。多くの規制では最低1年間、金融機関などでは7年間の保持が求められることがあります。

実務上のポイント

CloudTrailログをAmazon CloudWatch Logsに連携し、特定のイベント（ルートアカウントの使用、セキュリティグループの変更、IAMポリシーの変更など）に対してアラートを設定することを推奨します。

5. 暗号化とキー管理の監査

保存データ（Data at Rest）と転送中データ（Data in Transit）の暗号化は、データ保護の基本です。

AWS KMS（Key Management Service）の確認

確認コマンド：
aws kms list-keys
aws kms describe-key --key-id [キーID]
aws kms get-key-policy --key-id [キーID] --policy-name default

確認ポイント

  • カスタマーマネージドキー（CMK）の使用状況
  • キーローテーションが有効になっているか（年1回が推奨）
  • キーポリシーが最小権限の原則に基づいているか
  • 削除予定のキーがないか

各サービスの暗号化設定

サービス確認項目
EC2（EBS）ボリュームが暗号化されているか、デフォルト暗号化が有効か
RDSストレージ暗号化が有効か、SSL/TLS接続が強制されているか
S3サーバーサイド暗号化が有効か、バケットポリシーで暗号化を強制しているか
Lambda環境変数が暗号化されているか
EFS保存時の暗号化が有効か

6. EC2およびコンピューティングリソースの監査

EC2インスタンスは、多くのワークロードの基盤となるサービスです。

確認すべきポイント

IMDSv2（Instance Metadata Service Version 2）の強制

IMDSv1には、SSRF（Server-Side Request Forgery）攻撃に対する脆弱性がありました。IMDSv2では、セッショントークンが必須となり、セキュリティが向上しています。

確認コマンド：
aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,MetadataOptions]'
  • HttpTokensが「required」に設定されているか

パブリックIPアドレスの付与状況

確認コマンド：
aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,PublicIpAddress,State.Name]'
  • 不必要にパブリックIPアドレスが付与されているインスタンスがないか
  • インターネットに公開する必要がある場合は、ロードバランサー経由でのアクセスが推奨

AMI（Amazon Machine Image）の管理

  • 使用しているAMIが最新のパッチが適用されたものか
  • 古いAMIや不要なAMIが残っていないか
  • AMIのパブリック共有が設定されていないか

Systems Managerの活用状況

SSHキーを使った直接アクセスではなく、AWS Systems Manager Session Managerを使用することで、より安全なアクセス管理が可能です。

7. 監視・検出機能の監査

セキュリティインシデントの早期発見と対応には、適切な監視体制が不可欠です。

AWS Security Hubの確認

Security Hubは、AWSのセキュリティ状態を一元的に可視化するサービスです。

確認コマンド：
aws securityhub describe-hub
aws securityhub get-findings --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}'
  • Security Hubが有効化されているか
  • CIS AWS Foundations Benchmarkの自動チェックが有効か
  • 重要度「CRITICAL」「HIGH」の検出結果が未対応のまま放置されていないか

Amazon GuardDutyの確認

GuardDutyは、機械学習を活用した脅威検出サービスです。

確認コマンド：
aws guardduty list-detectors
aws guardduty get-findings --detector-id [ディテクターID]
  • GuardDutyが有効化されているか
  • S3保護、EKS保護、マルウェア保護などの追加機能が有効か
  • 検出された脅威への対応フローが整備されているか

AWS Configの確認

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

確認コマンド：
aws configservice describe-configuration-recorders
aws configservice describe-config-rules
aws configservice describe-compliance-by-config-rule
  • Configが有効化されているか
  • 適切なConfigルールが設定されているか
  • 非準拠リソースの対応状況

監査を効率化するツールとサービス

AWSネイティブツール

  1. AWS Trusted Advisor：コスト最適化、パフォーマンス、セキュリティ、耐障害性、サービス制限の5つの観点からベストプラクティスを自動チェック

  2. AWS Audit Manager：監査準備を自動化し、継続的なエビデンス収集が可能

  3. IAM Access Analyzer：外部からアクセス可能なリソースを自動的に検出

サードパーティツール

  1. Prowler：オープンソースのAWSセキュリティ監査ツール。CIS Benchmark、GDPR、HIPAAなど複数のフレームワークに対応

  2. ScoutSuite：マルチクラウド対応のセキュリティ監査ツール

  3. CloudSploit：リアルタイムでクラウドセキュリティをスキャン

Prowlerの実行例

# Prowlerのインストールと実行
pip install prowler
prowler aws -M csv,json-ocsf -o ./output

# 特定のチェックのみ実行
prowler aws -c s3_bucket_public_access -o ./output

よくある質問（FAQ）

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

A1. 理想的には、継続的な監視と定期的な監査を組み合わせることを推奨します。

  • 継続的監視：AWS Config、Security Hub、GuardDutyなどのサービスを活用し、リアルタイムでセキュリティ状態を監視
  • 定期監査：四半期に1回の頻度で網羅的な監査を実施。重要な変更（新サービス導入、組織再編など）があった場合は、追加で監査を行う
  • 年次監査：外部監査法人による年1回の独立した監査

特に金融機関や医療機関など、規制が厳しい業界では、月次での確認が求められる場合もあります。

Q2. マルチアカウント環境での監査をどう効率化できますか？

A2. AWS Organizationsを活用した集中管理アプローチが効果的です。

具体的な方法

  1. 専用の監査アカウントを作成し、すべてのアカウントのCloudTrailログ、Configデータを集約
  2. AWS Control Towerを導入し、ガードレール（予防的・検出的統制）を一括適用
  3. Security Hubの組織統合で、全アカウントのセキュリティ状態を一元管理
  4. **IAM Identity Center（旧AWS SSO）**で監査担当者のアクセスを一元管理

また、CloudFormation StackSetsやTerraformを使用して、監査用の設定を全アカウントに一括展開することも効率化につながります。

100以上のアカウントを持つ大規模環境では、上記の自動化なしに監査を行うことは現実的ではありません。

Q3. 監査で発見した問題への対応優先度はどう決めるべきですか？

A3. リスクベースのアプローチで優先度を決定することを推奨します。

優先度の判断基準

優先度条件対応目標
最高（P1）インターネットに公開されている脆弱性、認証情報の漏洩即時対応（24時間以内）
高（P2）特権アカウントの設定不備、暗号化未実施1週間以内
中（P3）ベストプラクティスからの逸脱、ログ設定の不備1ヶ月以内
低（P4）推奨設定との差異、ドキュメント不備四半期以内

実務上のポイント

  • 発見事項をリスクマトリクス（影響度×発生可能性）でマッピングする
  • 攻撃者の視点で「悪用可能性」を評価する
  • 規制要件に直接関わる項目は優先度を上げる
  • 対応コストと効果のバランスも考慮する

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

本記事では、AWS環境のセキュリティ監査における7つの重要領域と具体的な確認方法について解説しました。

重要ポイントの振り返り

  1. IAM監査：ルートアカウントの保護、MFA設定、最小権限の原則の徹底
  2. S3監査：パブリックアクセスのブロック、暗号化、アクセスログの有効化
  3. ネットワーク監査：セキュリティグループのルール精査、VPCフローログの確認
  4. CloudTrail監査：全リージョンでの有効化、ログの保護と保持
  5. 暗号化監査：保存データと転送中データの暗号化、KMSキーの管理
  6. EC2監査：IMDSv2の強制、パブリックIPの最小化
  7. 監視機能監査：Security Hub、GuardDuty、Configの有効活用

監査を成功させるための3つの原則

1. 自動化を積極的に活用する

手動での確認には限界があります。AWS Config、Security Hub、サードパーティツールを組み合わせて、継続的な監視体制を構築しましょう。

2. リスクベースのアプローチを採用する

すべてを完璧にすることは不可能です。重要度の高いリソース、公開されているサービス、機密データを扱うシステムから優先的に対応しましょう。

3. 組織全体でセキュリティ文化を醸成する

監査は「指摘すること」が目的ではありません。発見事項を建設的にフィードバックし、開発・運用チームと協力してセキュリティを向上させることが真の目的です。

AWS環境は日々進化しており、新サービスや新機能が次々とリリースされています。本記事で紹介した内容を基盤としつつ、常に最新のベストプラクティスをキャッチアップし、継続的な改善を心がけてください。

効果的なAWS監査が、皆さまの組織のセキュリティ向上に貢献することを願っています。