目次
はじめに:なぜAWS監査が重要なのか#
クラウドサービスの利用が当たり前となった今、AWS(Amazon Web Services)を採用している企業は急増しています。しかし、「クラウドだから安全」という認識は大きな誤りです。実際、Gartner社の調査によると、2025年までにクラウドセキュリティインシデントの99%は顧客側の設定ミスが原因になると予測されています。
AWS環境の監査は、単なるコンプライアンス対応ではありません。ビジネスを守り、顧客からの信頼を維持するための必須プロセスです。本記事では、IT監査・セキュリティの実務担当者がすぐに活用できるAWS監査チェックリストを、8つの重要カテゴリに分けて詳しく解説します。
監査対象となる主な規格・フレームワークとしては、以下が挙げられます:
- SOC 2 Type II:サービス組織の内部統制
- ISO 27001:情報セキュリティマネジメントシステム
- PCI DSS:クレジットカード業界のセキュリティ基準
- HIPAA:医療情報のプライバシー保護(米国)
- FISC安全対策基準:金融機関向けセキュリティガイドライン
それでは、現場で実際に使える監査チェックリストを見ていきましょう。
1. IAM(Identity and Access Management)の監査#
1-1. IAMポリシーの原則確認#
IAMはAWSセキュリティの要です。監査では最小権限の原則が守られているかを重点的に確認します。
チェックポイント:
| 項目 | 確認内容 | 推奨基準 |
|---|---|---|
| ルートアカウント使用 | 直近90日間の使用履歴 | 使用なし |
| MFA設定 | ルートアカウントのMFA有効化 | 必須 |
| パスワードポリシー | 最小文字数、複雑性要件 | 14文字以上、記号必須 |
| アクセスキーのローテーション | 最終ローテーション日 | 90日以内 |
| 未使用の認証情報 | 90日以上未使用のユーザー/キー | 削除または無効化 |
実務ポイント: AWS CLIで以下のコマンドを実行し、認証情報レポートを取得できます。
aws iam generate-credential-report
aws iam get-credential-report --output text --query Content | base64 -d
このレポートには、各ユーザーのパスワード最終使用日、アクセスキーの状態、MFA設定状況が含まれます。監査証跡として保存しておきましょう。
1-2. IAMロールとポリシーの精査#
具体的な確認事項:
管理者権限(AdministratorAccess)の付与状況
- 付与されているユーザー/ロールの一覧を作成
- ビジネス上の正当性を文書化
インラインポリシーの使用状況
- 管理ポリシーへの移行を推奨
- インラインポリシーは例外的なケースのみに限定
クロスアカウントアクセス
- 信頼関係(Trust Relationship)の設定確認
- 外部アカウントIDの妥当性検証
数値目標の例:
- 管理者権限を持つユーザー:全ユーザーの5%以下
- MFA有効化率:100%
- 90日以上未使用のアクセスキー:0件
2. ネットワークセキュリティの監査#
2-1. VPC設定の確認#
VPC(Virtual Private Cloud)は、AWS上の仮想ネットワークです。適切なセグメンテーションがセキュリティの基本となります。
チェックリスト:
- パブリックサブネットとプライベートサブネットの分離
- NATゲートウェイの冗長構成(本番環境)
- VPCフローログの有効化と保存期間設定
- デフォルトVPCの使用状況(本番環境では非推奨)
2-2. セキュリティグループの監査#
セキュリティグループは、インスタンスレベルのファイアウォールです。最も設定ミスが多い箇所であり、重点的な監査が必要です。
危険な設定パターン:
# 絶対に避けるべき設定例
インバウンド: 0.0.0.0/0 → ポート22(SSH)
インバウンド: 0.0.0.0/0 → ポート3389(RDP)
インバウンド: 0.0.0.0/0 → ポート3306(MySQL)
監査時の確認コマンド:
# 全リージョンのセキュリティグループで0.0.0.0/0が許可されているルールを抽出
aws ec2 describe-security-groups \
--query 'SecurityGroups[*].{ID:GroupId,Name:GroupName,Rules:IpPermissions[?contains(IpRanges[].CidrIp, `0.0.0.0/0`)]}' \
--output table
推奨事項:
- SSHアクセスは踏み台サーバー(Bastion Host)経由、またはSession Manager使用
- データベースポートはアプリケーションサーバーからのみ許可
- 定期的な未使用セキュリティグループの棚卸し
2-3. ネットワークACLの確認#
ネットワークACL(NACL)は、サブネットレベルのファイアウォールです。セキュリティグループとの二重防御を構成します。
チェックポイント:
- デフォルトNACLの使用可否
- 明示的な拒否ルールの設定
- ルール番号の整合性(100, 200, 300などの規則的な番号付け)
3. データ保護と暗号化の監査#
3-1. 保管時の暗号化(Encryption at Rest)#
サービス別の暗号化確認:
| サービス | 暗号化方式 | 確認ポイント |
|---|---|---|
| S3 | SSE-S3, SSE-KMS, SSE-C | バケットポリシーでの強制 |
| EBS | AES-256 | デフォルト暗号化の有効化 |
| RDS | TDE, KMS | インスタンス作成時に設定 |
| DynamoDB | AWS所有キー, CMK | テーブル設定の確認 |
S3バケットの暗号化強制ポリシー例:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyUnencryptedUploads",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::your-bucket-name/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
}
]
}
3-2. 転送時の暗号化(Encryption in Transit)#
確認事項:
- ELB/ALBでのTLS 1.2以上の強制
- CloudFrontでのHTTPS強制リダイレクト
- RDSへの接続でSSL/TLS使用
- 内部通信のVPCエンドポイント活用
実務ポイント: AWS Certificate Manager(ACM)で発行した証明書の有効期限を監視リストに追加してください。自動更新が設定されていても、DNS検証の失敗などで更新に失敗するケースがあります。
3-3. KMS(Key Management Service)の監査#
重要な確認項目:
キーポリシーの確認
- キー管理者とキー使用者の分離
- 外部アカウントへのアクセス許可の有無
キーローテーション設定
- カスタマーマネージドキー:年1回の自動ローテーション推奨
- ローテーション履歴の確認
削除保留中のキー
- 7〜30日の待機期間が設定されているか
- 影響を受けるリソースの特定
4. ログ記録と監視の監査#
4-1. CloudTrail設定の確認#
CloudTrailは、AWS APIコールの履歴を記録するサービスです。監査の生命線と言っても過言ではありません。
必須設定チェックリスト:
- 全リージョンでの有効化
- マルチリージョン証跡の作成
- S3バケットへの保存(90日以上、推奨:1年以上)
- ログファイルの整合性検証の有効化
- CloudWatch Logsへの連携
- S3バケットのパブリックアクセスブロック
CloudTrailログの整合性確認コマンド:
aws cloudtrail validate-logs \
--trail-arn arn:aws:cloudtrail:ap-northeast-1:123456789012:trail/your-trail \
--start-time 2026-04-01T00:00:00Z \
--end-time 2026-04-30T23:59:59Z
4-2. CloudWatch設定の確認#
推奨するアラーム設定:
| イベント | 重要度 | 対応SLA例 |
|---|---|---|
| ルートアカウントログイン | 重大 | 即時対応 |
| IAMポリシー変更 | 高 | 1時間以内 |
| セキュリティグループ変更 | 高 | 1時間以内 |
| CloudTrail無効化 | 重大 | 即時対応 |
| 不正なAPIコール(AccessDenied多発) | 中 | 24時間以内 |
CloudWatch Alarmの設定例(ルートログイン検知):
{
"FilterPattern": "{ ($.userIdentity.type = \"Root\") && ($.userIdentity.invokedBy NOT EXISTS) && ($.eventType != \"AwsServiceEvent\") }",
"MetricTransformations": [
{
"MetricName": "RootAccountUsage",
"MetricNamespace": "CloudTrailMetrics",
"MetricValue": "1"
}
]
}
4-3. AWS Configの活用#
AWS Configは、リソースの設定変更履歴を記録し、コンプライアンス評価を自動化するサービスです。
推奨するマネージドルール:
s3-bucket-public-read-prohibited:S3バケットのパブリック読み取り禁止encrypted-volumes:EBSボリュームの暗号化確認iam-password-policy:IAMパスワードポリシーの確認root-account-mfa-enabled:ルートアカウントMFA確認vpc-flow-logs-enabled:VPCフローログ有効化確認
実務ポイント: AWS Config Rulesの評価結果を定期的にエクスポートし、監査報告書の根拠資料として活用できます。AWS Config Aggregatorを使用すると、複数アカウント・リージョンの状況を一元管理できます。
5. S3バケットセキュリティの監査#
5-1. パブリックアクセス設定の確認#
S3バケットの設定ミスによるデータ漏洩事故は後を絶ちません。2019年には、Capital One社で1億人以上の顧客情報が流出し、設定ミスが原因でした。
重点確認項目:
# 全バケットのパブリックアクセス設定を確認
aws s3api list-buckets --query 'Buckets[].Name' --output text | \
xargs -I {} aws s3api get-public-access-block --bucket {}
推奨設定:
| 設定項目 | 推奨値 | 説明 |
|---|---|---|
| BlockPublicAcls | true | 新規パブリックACLをブロック |
| IgnorePublicAcls | true | 既存パブリックACLを無視 |
| BlockPublicPolicy | true | パブリックポリシーをブロック |
| RestrictPublicBuckets | true | パブリックバケットへのアクセス制限 |
5-2. バケットポリシーの監査#
危険なポリシーパターン:
// 危険な例:誰でも読み取り可能
{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket-name/*"
}
監査時の確認ポイント:
Principal": "*"またはPrincipal": {"AWS": "*"}の使用有無- Conditionによる適切な制限の有無
- HTTPSの強制(
aws:SecureTransport) - VPCエンドポイントからのアクセス制限
5-3. オブジェクトレベルのログ記録#
S3サーバーアクセスログの設定確認:
- ログ出力先バケットの指定
- ログバケット自体のアクセス制限
- CloudTrailデータイベントとの使い分け
6. コンピューティングリソースの監査#
6-1. EC2インスタンスの監査#
チェックリスト:
- IMDSv2(Instance Metadata Service v2)の強制
- パブリックIPアドレスの割り当て状況
- セキュリティグループの関連付け確認
- Systems Manager(SSM)エージェントのインストール状況
- インスタンスプロファイル(IAMロール)の適切な設定
IMDSv2強制の確認コマンド:
aws ec2 describe-instances \
--query 'Reservations[*].Instances[*].[InstanceId,MetadataOptions.HttpTokens]' \
--output table
HttpTokensがrequiredになっていれば、IMDSv2が強制されています。
6-2. Lambda関数の監査#
重要な確認項目:
実行ロールの権限
- 最小権限の原則に従っているか
- リソースベースポリシーの確認
環境変数のセキュリティ
- 機密情報の直接保存禁止
- Secrets ManagerまたはParameter Store(SecureString)の使用
VPC設定
- 必要なLambdaのみVPC内で実行
- セキュリティグループの適切な設定
6-3. コンテナサービスの監査#
ECS/EKSを使用している場合の追加チェック項目:
- コンテナイメージの脆弱性スキャン(ECRイメージスキャン)
- Fargateタスクの場合、タスクロールの権限確認
- EKSの場合、Kubernetes RBACの設定確認
- コンテナへのシークレット注入方法(Secrets Manager統合)
7. データベースセキュリティの監査#
7-1. RDS/Aurora監査#
セキュリティ設定チェックリスト:
| 項目 | 確認内容 | 推奨設定 |
|---|---|---|
| パブリックアクセス | Publicly Accessible設定 | No |
| 暗号化 | Storage Encryption | 有効 |
| SSL接続 | rds.force_ssl パラメータ | 1(有効) |
| 自動バックアップ | Backup Retention Period | 7日以上 |
| マイナーバージョン自動更新 | Auto Minor Version Upgrade | 有効(推奨) |
| 削除保護 | Deletion Protection | 有効 |
監査ログの設定確認:
# RDSインスタンスのログ設定確認
aws rds describe-db-instances \
--query 'DBInstances[*].[DBInstanceIdentifier,EnabledCloudwatchLogsExports]' \
--output table
7-2. DynamoDBの監査#
確認項目:
- 暗号化設定(AWS所有キーまたはCMK)
- VPCエンドポイント経由のアクセス制限
- オンデマンドバックアップの設定
- Point-in-Time Recovery(PITR)の有効化
- IAMポリシーによるテーブルレベルのアクセス制御
8. コンプライアンスとガバナンスの監査#
8-1. AWS Organizations設定#
マルチアカウント環境での監査ポイント:
Service Control Policies(SCP)の確認例:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyLeaveOrganization",
"Effect": "Deny",
"Action": "organizations:LeaveOrganization",
"Resource": "*"
},
{
"Sid": "DenyDisableCloudTrail",
"Effect": "Deny",
"Action": [
"cloudtrail:DeleteTrail",
"cloudtrail:StopLogging"
],
"Resource": "*"
}
]
}
8-2. AWS Security Hubの活用#
Security Hubは、複数のセキュリティサービスの検出結果を一元管理するサービスです。
有効にすべきセキュリティ基準:
- AWS Foundational Security Best Practices v1.0.0
- CIS AWS Foundations Benchmark v1.4.0
- PCI DSS v3.2.1(該当する場合)
監査での活用方法: Security Hubのスコアと検出結果を定期的にエクスポートし、改善状況をトラッキングします。90%以上のスコアを維持することを目標値として設定するのが一般的です。
8-3. タグ戦略の確認#
適切なタグ付けは、コスト管理とセキュリティガバナンスの両面で重要です。
必須タグの例:
| タグキー | 説明 | 例 |
|---|---|---|
| Environment | 環境識別 | Production, Staging, Development |
| Owner | 責任者 | [email protected] |
| CostCenter | コストセンター | CC-1234 |
| Compliance | 適用規制 | PCI-DSS, HIPAA |
| DataClassification | データ分類 | Confidential, Internal, Public |
タグコンプライアンスの確認: AWS Config RulesまたはAWS Resource Groupsを使用して、タグ付けポリシーの準拠状況を自動的に監視できます。
よくある質問(FAQ)#
Q1. AWS監査の頻度はどのくらいが適切ですか?#
A1. 監査の種類によって推奨頻度が異なります。
| 監査タイプ | 推奨頻度 | 備考 |
|---|---|---|
| 自動化されたセキュリティチェック | リアルタイム〜日次 | Security Hub, Config Rules |
| 内部監査 | 四半期ごと | 重点項目のローテーション |
| 外部監査 | 年1回以上 | SOC 2, ISO 27001等 |
| 設定変更後のスポット監査 | 都度 | 重大な変更時 |
特に、重大なインフラ変更やセキュリティインシデント発生後は、臨時の監査を実施することを推奨します。
Q2. 監査で問題が見つかった場合の優先順位はどうつけますか?#
A2. 以下のリスクマトリクスに基づいて優先順位を決定します。
重大(即時対応):
- ルートアカウントのMFA未設定
- S3バケットのパブリックアクセス(機密データ含む)
- CloudTrailの無効化
- 管理者権限を持つアクセスキーの漏洩疑い
高(1週間以内):
- セキュリティグループの過度に緩い設定
- 暗号化されていないデータストレージ
- 90日以上未使用の認証情報
中(1ヶ月以内):
- パスワードポリシーの不備
- ログ保存期間の不足
- タグ付けの不備
低(次回監査まで):
- ドキュメントの更新
- 非本番環境の設定改善
Q3. 小規模チームでもAWS監査を効率的に行う方法はありますか?#
A3. 以下のアプローチで、少人数でも効果的な監査が可能です。
自動化ツールの最大活用
- AWS Security Hub:無料枠で基本的なセキュリティチェック
- AWS Config:設定変更の継続的モニタリング
- Trusted Advisor:ベストプラクティスチェック(Business/Enterpriseサポート)
Infrastructure as Code(IaC)の導入
- CloudFormationやTerraformでインフラをコード化
- コードレビューでセキュリティ設定をチェック
- ドリフト検出で意図しない変更を発見
チェックリストの優先順位付け
- まずは「重大」カテゴリの項目に集中
- リスクベースアプローチで対応範囲を絞る
外部サービスの活用
- Prowler(オープンソースのセキュリティ評価ツール)
- ScoutSuite(マルチクラウド対応のセキュリティ監査ツール)
Prowlerの実行例:
# 全チェックを実行(約45分)
prowler aws
# 特定のチェックグループのみ実行
prowler aws --checks-group iam
まとめ:AWS監査を成功させるための5つのポイント#
AWS環境の監査は、一度きりのイベントではなく継続的なプロセスです。本記事で解説したチェックリストを活用しつつ、以下のポイントを意識してください。
1. 自動化を最大限活用する#
手動チェックには限界があります。Security Hub、Config Rules、CloudWatch Alarmsを組み合わせて、継続的なモニタリング体制を構築しましょう。
2. 文書化を怠らない#
監査結果、対応状況、例外承認などを確実に文書化してください。これは外部監査対応だけでなく、組織内での知識共有にも役立ちます。
3. リスクベースでアプローチする#
すべてを完璧にすることは現実的ではありません。ビジネスへの影響度と発生可能性を考慮し、優先順位をつけて対応しましょう。
4. 最新情報をキャッチアップする#
AWSは頻繁に新サービスや機能をリリースします。AWS Security Blog、re:Invent、AWS Summitなどを通じて、最新のベストプラクティスを把握してください。
5. チーム全体でセキュリティ意識を共有する#
監査担当者だけでなく、開発者、運用担当者も含めたセキュリティ文化の醸成が重要です。定期的な勉強会やナレッジ共有の場を設けましょう。
参考リソース:
- AWS Well-Architected Framework - セキュリティの柱
- CIS Amazon Web Services Foundations Benchmark
- AWS Security Best Practices
本記事のチェックリストが、皆様のAWS環境のセキュリティ向上と監査業務の効率化に貢献できれば幸いです。
IT監査 セキュリティ