AWSセキュリティ設定ガイド【2026年版】必須チェック項目と設定ミスの防ぎ方

AWSはクラウドインフラの世界標準として広く普及しているが、その柔軟性の裏側には無数の設定項目が存在する。適切な知識なく運用を開始すると、気づかないうちに重大な脆弱性が生まれる。実際、国内外でAWSの設定ミスに起因する情報漏洩事故が毎年多数報告されており、2025〜2026年においても被害は続いている。

本記事では、AWSの設定ミスによる実際の事例を踏まえながら、よくある誤りのパターン・必須セキュリティ設定のチェックリスト・Security Hub/GuardDuty/Configの活用方法・マルチアカウント環境でのSCP運用まで体系的に解説する。

1. AWSの設定ミスによる情報漏洩事例（2025〜2026年）

1-1. S3バケットの公開設定ミスによる個人情報流出

2025年、国内の大手ECサイトが運営するAWS環境において、S3バケットのアクセス制御設定が誤って「パブリック」になっていたことが判明した。顧客の氏名・住所・メールアドレスを含む数十万件のデータが、認証なしで誰でもダウンロードできる状態だった。発覚のきっかけは外部のセキュリティ研究者による報告であり、内部での検知は一切なかった。

同様の事例は2026年に入ってからも複数確認されており、開発環境用に作成したバケットの設定が本番環境に誤って引き継がれるケースが目立つ。

1-2. IAM権限の設定過誤によるアカウント乗っ取り

2025年末、ある製造業のAWSアカウントで不正アクセスが発生した。原因を調査すると、CI/CDパイプライン用に作成したIAMユーザーに「AdministratorAccess」ポリシーが付与されており、そのアクセスキーがGitHubのパブリックリポジトリに誤ってコミットされていた。攻撃者はそのキーを使ってEC2インスタンスを大量起動し、仮想通貨マイニングに悪用した。被害額は数百万円に達した。

1-3. セキュリティグループの過剰な許可設定

2026年初頭、医療系スタートアップの開発環境でデータベース（RDS）が外部からアクセス可能な状態になっていた。セキュリティグループのインバウンドルールに「0.0.0.0/0」（全IPアドレス許可）が設定されており、認証情報のブルートフォース攻撃を受けた。患者に関連する情報が含まれていたため、個人情報保護委員会への報告対応が必要になった。

1-4. CloudTrailの無効化による証跡の消滅

インシデント発生後に調査を試みたものの、CloudTrailが有効化されていなかったため、攻撃者の行動ログが一切残っておらず、被害範囲の特定に数週間を要したケースが2025年に複数報告されている。ログがなければ何が起きたかを立証できず、原因究明も再発防止策の策定も困難になる。

2. よくある設定ミスTOP10

AWSの設定ミスには典型的なパターンがある。以下に頻度・影響度ともに高い10項目を整理する。

第1位：S3バケットのパブリックアクセス許可

バケット単位またはオブジェクト単位でパブリックアクセスが有効になっているケース。「Block Public Access」設定が未有効の場合、意図せずデータが公開される。アカウントレベルでブロック設定を有効にしていても、バケット個別の設定が上書きできる点に注意が必要だ。

第2位：IAMユーザーへの過剰権限付与

「AdministratorAccess」や「PowerUserAccess」を安易に付与するケース。最小権限の原則（Principle of Least Privilege）に従い、業務に必要な権限のみを付与する必要がある。ワイルドカード（"Action": "*"）の使用は原則として禁止とすべきだ。

第3位：IAMアクセスキーの長期運用

作成から数年が経過したアクセスキーが現役で使われているケース。キーが漏洩しても発覚が遅れる。90日以上未ローテーションのキーはリスク要因として扱い、定期的な棚卸しと無効化が必要だ。

第4位：ルートアカウントへのMFA未設定

AWSアカウントのルートユーザーにMFA（多要素認証）が設定されていないケース。ルートアカウントは全リソースへの無制限アクセス権を持つため、乗っ取られた場合の被害は甚大になる。

第5位：セキュリティグループの0.0.0.0/0許可

22番ポート（SSH）・3389番ポート（RDP）・3306番ポート（MySQL）などを全IPアドレスから許可しているケース。インターネット経由での不正アクセスを招く。踏み台サーバーやVPN経由のアクセスに限定すべきだ。

第6位：CloudTrailの無効化または部分的な有効化

一部のリージョンでのみCloudTrailを有効にしているケース。攻撃者が意図的に未設定リージョンでリソースを作成する事例もある。全リージョンでの有効化が必須だ。

第7位：暗号化の未設定

S3・RDS・EBS・SQS・SNSなどのデータが平文で保存されているケース。保存時の暗号化（Encryption at Rest）はAWSのマネージドキー（SSE-S3やSSE-KMS）を使用して有効化できる。

第8位：VPCフローログの未収集

ネットワークトラフィックの記録であるVPCフローログを収集していないケース。不正通信の検知や侵入後の横断移動の追跡が困難になる。

第9位：AWS Configの未有効化

リソース設定変更の記録ツールであるAWS Configを有効化していないケース。「いつ・誰が・何を変更したか」を追跡できなくなり、設定ドリフトの検出も不可能になる。

第10位：タグポリシーの未適用

リソースへのタグ付けがなく、所有者・環境（本番/開発）・用途が不明なリソースが乱立するケース。不要リソースの放置につながり、攻撃対象の拡大を招く。

3. 必須セキュリティ設定チェックリスト（カテゴリ別）

以下のチェックリストをAWS環境の定期レビュー時に活用されたい。

IAM（Identity and Access Management）

• [ ] ルートアカウントのMFAが有効になっている
• [ ] ルートアカウントのアクセスキーが存在しない（削除済み）
• [ ] IAMユーザーのMFAが全員に適用されている
• [ ] コンソールアクセスが不要なIAMユーザーにはアクセスキーのみを発行している
• [ ] アクセスキーのローテーションポリシーが90日以内に設定されている
• [ ] 未使用のIAMユーザー・ロール・ポリシーが定期的に削除されている
• [ ] IAMポリシーに"Action": ""や"Resource": ""の組み合わせが存在しない
• [ ] IAMロールに信頼ポリシーが適切に設定されており、不要な外部アカウントを信頼していない
• [ ] パスワードポリシーで最低12文字・複雑性要件・有効期限（90日）が設定されている
• [ ] IAM Access Analyzerが全リージョンで有効になっている

S3（Simple Storage Service）

• [ ] アカウントレベルの「Block Public Access」が有効になっている
• [ ] 全バケットのバケットレベル「Block Public Access」が有効になっている
• [ ] パブリックアクセスが必要なバケットのみ例外設定し、用途をタグで明記している
• [ ] バケットポリシーに意図しないワイルドカードアクセスが含まれていない
• [ ] 重要データを含むバケットでサーバーサイド暗号化（SSE-KMS推奨）が有効になっている
• [ ] バケットのバージョニングが有効になっている（削除・上書きからの復旧用）
• [ ] アクセスログが別バケットに収集されている
• [ ] MFAデリートが有効になっている（重要データのバケット）
• [ ] S3 Object Lockが必要に応じて設定されている（コンプライアンス用途）

EC2 / VPC / セキュリティグループ

• [ ] セキュリティグループのインバウンドに0.0.0.0/0でSSH（22）・RDP（3389）を許可していない
• [ ] データベースポート（3306・5432・1433等）がインターネットから直接到達できない
• [ ] VPCフローログが全VPCで有効になっている
• [ ] 不要なパブリックIPが付与されたインスタンスが存在しない
• [ ] EC2インスタンスのメタデータアクセスがIMDSv2のみに制限されている
• [ ] EBSボリュームの暗号化がデフォルトで有効になっている
• [ ] 踏み台サーバーへのアクセスはSSM Session Manager経由に限定されている
• [ ] NACLが不要なトラフィックをブロックするように設定されている

ログ・監査（CloudTrail / CloudWatch）

• [ ] CloudTrailが全リージョンで有効になっている
• [ ] CloudTrailのマルチリージョントレイルが設定されている
• [ ] CloudTrailのログファイル検証が有効になっている（改ざん検知）
• [ ] CloudTrailのS3バケットへのアクセスが制限されている
• [ ] CloudWatchアラームがルートアカウントログイン・MFAなしコンソールログイン・IAMポリシー変更等に設定されている
• [ ] ログの保存期間がコンプライアンス要件を満たしている（最低1年推奨）

暗号化・鍵管理（KMS）

• [ ] 重要なサービス（RDS・S3・EBS・Secrets Manager等）でKMSカスタマーマネージドキー（CMK）を使用している
• [ ] KMSキーのローテーションが有効になっている（年1回自動ローテーション）
• [ ] KMSキーポリシーで不要なアカウント・プリンシパルへのアクセスが拒否されている
• [ ] Secrets ManagerまたはParameter Store（SecureString）でシークレットを管理し、ハードコーディングを排除している

4. AWS Security Hubを使ったセキュリティスコア管理

AWS Security Hubは、複数のAWSセキュリティサービスと外部ツールの検出結果を一元管理するサービスだ。有効化することで、AWSセキュリティのベストプラクティスへの準拠状況を「セキュリティスコア」として可視化できる。

Security Hubの主要機能

統合ダッシュボード GuardDuty・Amazon Inspector・IAM Access Analyzer・AWS Configなどの検出結果が集約される。個別サービスを行き来せずに全体のリスク状況を把握できる。

セキュリティ標準への準拠チェック 以下の標準への準拠状況を自動評価する。

• AWS基礎セキュリティのベストプラクティス（FSBP）
• CIS AWS Foundations Benchmark v1.4 / v3.0
• PCI DSS v3.2.1
• NIST SP 800-53 Rev. 5

各コントロールにPass/Fail/Warningのステータスが付与され、どの設定が基準を満たしていないかを一覧で確認できる。

自動化されたレスポンス Security Hubの検出結果をトリガーにEventBridgeルールを設定し、Lambda関数で自動修復アクションを実行できる。例えば「S3バケットのパブリックアクセスブロックが外れた」という検出結果に対し、自動的にブロックを再有効化する仕組みを構築できる。

セキュリティスコアの見方と目標値

Security HubのFSBP（AWS Foundational Security Best Practices）スコアは0〜100%で表示される。

新規でAWS環境を構築した場合、何も設定しない状態では50〜60%台になることが多い。まず90%以上を目標として設定ミスを解消していくことが現実的な指針となる。

Security Hubの有効化手順

1. AWSマネジメントコンソールでSecurity Hubを開く
2. 「Security Hubを有効にする」をクリック
3. 適用するセキュリティ標準を選択（FSBPとCIS Benchmarkを推奨）
4. 全リージョンで有効化するためにAWS Organizationsとの統合を設定
5. 管理アカウントで集約リージョンを設定し、メンバーアカウントの検出結果を一元集約

5. GuardDuty・Config・CloudTrailの活用

AWS GuardDuty：脅威の自動検出

GuardDutyはCloudTrailイベント・VPCフローログ・DNSログを継続的に分析し、機械学習と脅威インテリジェンスを用いて悪意ある活動を検出するサービスだ。

GuardDutyが検出できる脅威の例

• EC2インスタンスからの仮想通貨マイニング通信
• 既知の悪意あるIPアドレスとの通信
• IAMユーザーによる異常なAPIコール（通常と異なる地域からのアクセス等）
• S3バケットへの異常なアクセスパターン
• ECSコンテナからの不審なコマンド実行
• RDSへのブルートフォースアタック

GuardDuty導入時の推奨設定

GuardDutyの検出結果をEventBridgeでキャプチャし、SlackやTeamsへの通知・Security Hubへの集約・Jira/ServiceNowへのチケット起票を自動化することで、対応漏れを防ぐことができる。

また、GuardDuty Malware Protectionを有効化すると、EC2インスタンスとコンテナのマルウェアスキャンが可能になる（2024年以降の機能拡張）。

AWS Config：設定変更の継続的な追跡

AWS Configは、AWSリソースの設定変更を継続的に記録・評価するサービスだ。「コンフォーミティパック」や「Configルール」を使用することで、セキュリティポリシーへの準拠を自動チェックできる。

主要なConfigルール（マネージドルール）

Configルールが「Non-compliant（非準拠）」と判定したリソースに対し、Systems Manager Automation（SSM）を使った自動修復を設定することも可能だ。

CloudTrail：操作ログの収集と分析

CloudTrailはAWSアカウントでのすべてのAPI操作を記録する。セキュリティインシデント発生時の「誰が・いつ・何をしたか」を追跡するための根拠となる。

CloudTrail設定の必須ポイント

• マルチリージョントレイル：1つのトレイルで全リージョンのイベントを収集
• ログファイルの整合性検証：ログの改ざんを検知する機能。インシデント調査時に証跡の信頼性を担保する
• S3バケットの保護：CloudTrailのログを保存するS3バケットに対し、MFAデリート有効化・バケットポリシーで書き込みを制限
• CloudWatch Logsへの連携：CloudTrailのログをCloudWatch Logsに送信し、メトリクスフィルターとアラームで重要イベントをリアルタイム検知

CloudTrail Insightsの活用

CloudTrail Insightsを有効化すると、APIコール数の異常な増減をML（機械学習）で検出できる。大量のDeleteObject呼び出しや異常なEC2RunInstances呼び出しなど、攻撃の兆候を早期に把握できる。

6. マルチアカウント環境でのSCP活用

企業規模が拡大するにつれ、AWS Organizations配下に複数のAWSアカウントを持つマルチアカウント構成が一般的になる。この環境ではSCP（Service Control Policy）を活用することで、組織全体のセキュリティポリシーを一元的に強制できる。

SCPとは

SCPはAWS Organizationsの機能の一つで、組織単位（OU）またはアカウントに対してIAMポリシーと同様の構文で適用するポリシーだ。SCPは「許可の上限（ガードレール）」として機能し、SCPで拒否された操作はたとえアカウント内のIAMで許可されていても実行できない。

推奨SCPの例

1. ルートアカウントのアクション制限

`json { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyRootUser", "Effect": "Deny", "Action": "", "Resource": "", "Condition": { "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" } } } ] } `

2. 特定リージョン以外でのリソース作成禁止

国内向けサービスを東京リージョンのみで運用する場合、他リージョンでのリソース作成を禁止できる。意図しないリージョンでのリソース作成による管理漏れを防ぐ。

3. GuardDuty・Security Hub・CloudTrailの無効化禁止

セキュリティサービスの無効化を組織レベルで禁止するSCPを適用することで、個別アカウントの担当者が誤って（あるいは意図的に）監視機能を停止できなくなる。

`json { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyDisableSecurityServices", "Effect": "Deny", "Action": [ "guardduty:DeleteDetector", "guardduty:DisassociateFromMasterAccount", "securityhub:DisableSecurityHub", "cloudtrail:DeleteTrail", "cloudtrail:StopLogging", "config:DeleteConfigurationRecorder", "config:StopConfigurationRecorder" ], "Resource": "*" } ] } `

4. 承認済みサービス以外の利用禁止

コンプライアンス要件によっては、使用可能なAWSサービスを限定するSCPが有効だ。例えば「承認済み以外のAIサービス（Bedrock等）は使用禁止」というポリシーをデータ保護の観点から適用できる。

マルチアカウント環境のベストプラクティス

7. AEVUSのAWSセキュリティ診断

AWSはデフォルト設定のまま運用すると、多くのセキュリティ上の問題を抱える状態になる。本記事で紹介した設定項目を一つひとつ確認することは重要だが、実際の現場では「何が設定されているか」より「何が見落とされているか」を客観的に把握することが難しい。

AEVUSのAWSセキュリティ診断では、現状のAWS環境を体系的に評価し、リスクの高い設定ミスを優先度付きで報告する。

診断の対象範囲

• IAM設定（ユーザー・ロール・ポリシー・アクセスキー管理）
• ネットワーク設定（VPC・セキュリティグループ・NACL・パブリックサブネット構成）
• ストレージ設定（S3・EBS・RDS・Secrets Manager）
• ログ・監査設定（CloudTrail・Config・VPCフローログ・CloudWatch）
• セキュリティサービス設定（GuardDuty・Security Hub・Inspector・IAM Access Analyzer）
• マルチアカウント環境（SCP・Organizationsポリシー・Control Tower設定）
• コンプライアンス対応（ISMS・SOC2・PCI DSSなどの要件への準拠状況）

診断で明らかになること

• セキュリティスコアの現状と業界平均との比較
• 重大・高・中・低の4段階リスク別の未対応項目一覧
• 各設定ミスの悪用シナリオと潜在的な被害シミュレーション
• 優先度順の修正手順と推奨設定値
• AWS Security Hubへの自動化対応を含む改善ロードマップ

現在のAWS環境の安全性に不安がある場合や、Security Hubのスコアが低い場合は、AEVUSへ診断の依頼を検討されたい。

まとめ

AWSのセキュリティは「構築して終わり」ではなく、継続的な監視と改善が不可欠だ。本記事のポイントを以下に整理する。

• S3パブリックアクセスブロック・IAM最小権限・MFA設定は最優先で対処すべき項目
• CloudTrail（全リージョン）・VPCフローログ・AWS Configを必ず有効化し、ログを保護する
• Security Hubでセキュリティスコアを継続的に計測し、90%以上を維持目標とする
• GuardDutyで脅威を自動検出し、EventBridgeで通知・対応を自動化する
• マルチアカウント環境ではSCPでセキュリティサービスの無効化を組織レベルで禁止する
• 定期的な第三者診断でチェックリストだけでは発見しにくい設定ミスを洗い出す

AWSのセキュリティ設定は複雑で広範にわたるが、体系的なアプローチで取り組むことで、設定ミスによる情報漏洩リスクを大幅に低減できる。

【サムネイル生成プロンプト】

` Generate a professional blog thumbnail image for a Japanese cybersecurity company called AEVUS.

Theme: AWS Security Settings Guide 2026 - Essential Checklist and Preventing Configuration Mistakes

Visual concept:

• Dark background with deep navy or dark charcoal tones
• AWS cloud architecture diagram with shield/lock overlay representing security
• Visual representation of security checklist items with checkmarks
• Warning indicators on common misconfiguration points (S3 bucket, IAM user icons)
• Abstract data flow lines connecting security services (GuardDuty, Security Hub, CloudTrail)

Color scheme:

• Primary: AWS Orange (#FF9900) as accent color
• Secondary: Deep navy blue (#1A2332) background
• Alert red (#E53935) for misconfiguration warnings
• Green (#43A047) for properly configured elements
• White (#FFFFFF) for text and icons

Text overlay:

• "AWS Security 2026" in bold English
• Small Japanese subtitle: "設定ガイド"
• "AEVUS" logo area in bottom right

Style: Modern tech illustration, flat design with subtle depth, no photorealistic elements, clean and professional cybersecurity aesthetic

Aspect ratio: 16:9 (1200x630px for blog OGP) `

関連記事

• 多要素認証（MFA）の導入ガイド【2026年版】種類・設定・運用のポイント
• Microsoft 365のセキュリティ設定ガイド【2026年版】必須チェック15項目
• ASM（攻撃表面管理）とは？ツール比較・導入費用・効果【2026年版】