本ページは、Linux Web サーバを Public Subnet に、Windows DB／アプリ サーバを Private Subnet に分離した 2 層 VPC 構成を対象とし、AWS が提供する各種セキュリティサービスを「設計・実装・運用」の 3 視点で解説する。製品カタログ的な羅列ではなく、要件定義→設計判断→ベストプラクティス→運用手順までを一気通貫で示すことを目的とする。
(1)ロール設計
コンポーネント単位 (例: WebRole, AppRole) で作成し、ポリシーはアクション×リソース最小化。SCP で明示的 Deny を設け「脱線」を防止。
(*1)アクション×リソース最小化 とは例えば面倒だからと言って片方を"すべてのS3"とかしてはダメということです。
(*2)SCP(Service Control Policy)とは
「SCP＝AWSアカウント全体の“やってはいけないリスト”」
→ IAMで権限を付けても、SCPで禁止されていたら絶対に実行できないのが最大の特徴！
例:
「全アカウントで、東京リージョン以外の操作を禁止」
「ルートユーザーによる削除操作を禁止」
→ これらはIAMでは防げないが、SCPなら強制可能です。
(2)MFA と認証強度
すべての IAM ユーザを原則 SSO 経由にし、やむを得ず静的 IAM ユーザを使う場合は MFA 必須。パスワードは 15 文字以上、履歴 5 世代保持。
(*1)SSOで利用可能なサービスの例は以下の通り。
AWS SSOは SAML 2.0 や SCIM に対応しており、以下のような外部サービスと連携できます。
・Microsoft 365（Azure AD連携）
・Google Workspace（Google Cloud Identity連携）
・Slack（SAMLベースのSSO）
・Zoom（SAML SSO）
・Atlassian（Jira, Confluence）
・Salesforce
・ServiceNow
・Box / Dropbox
・DevOps・クラウドツール
・GitHub Enterprise
・GitLab
・Terraform Cloud
・Datadog
・Splunk
・New Relic
・Okta（カスタムSAMLアプリとして連携可能）
・CyberArk（特権アクセス管理）
・SAP Cloud Platform
(*2)MFA デバイスとしては以下のようなものが利用可能
(a) 仮想 MFA デバイス（ソフトウェアトークン）
特徴：スマホやPCのアプリで利用可能。設定が簡単でコスト不要（現状では無料）。ただしインターネット接続が必須。
Google Authenticator（iOS/Android）
Microsoft Authenticator（iOS/Android）
Authy（マルチデバイス同期可能）
AWS IAM Identity Center の MFA 機能（組み込み）
(b) ハードウェア MFA デバイス（物理トークン）
特徴：オフラインで利用可能。セキュリティ強度が高いが、デバイス購入が必要。
YubiKey（Yubico 製、FIDO/U2F 対応）
Gemalto SafeNet（旧称：Gemalto Token）
Feitian（ePass など）
ただしフィッシングサイト攻撃に弱い。
(c) FIDO2 / U2F セキュリティキー
特徴：USB/NFC 対応の物理キー。パスワードレス認証も可能。秘密鍵が埋め込まれている。
偽のサイト(偽のURL)では反応しないため、フィッシング攻撃に強い。
物理デバイスのボタン押下が必要ですが、正規サイトでないと押せません。
YubiKey 5 シリーズ（USB-A/USB-C/NFC）
Google Titan Security Key
SoloKey（オープンソースのセキュリティキー）
ゼロトラストセキュリティを実現したい組織。フィッシング対策が必要な環境。
(d) SMS（テキストメッセージ）ベースの MFA
特徴：携帯電話番号に SMS でコードを送信。設定が簡単だが、SIM ジャッキングのリスクあり。
AWS ルートアカウントでは利用可能だが、IAM ユーザーでは非推奨（セキュリティ上の理由）。
国際 SMS 料金が発生する場合あり。
AWSはSMSに限らず脆弱性があるので推奨されない。
(e) AWS MFA を統合した ID プロバイダー（企業向け）
特徴：既存の企業認証システム（Azure AD, Okta など）と連携。
Microsoft Azure AD MFA（電話、アプリ通知、OTP）
Okta Verify（プッシュ通知、OTP）
RSA SecurID（トークン/クラウド版）
エンタープライズ環境で既存の MFA を流用したい場合に利用。
(3)キー管理
アクセスキーは自動ローテーション (Lambda＋EventBridge)。90日経過で失効し削除を徹底。
(*1)ただしアクセスキーの利用はセキュリティの観点上推奨されない
以下の代替案が推奨されます。
(a)IAMロール（AWSサービス間アクセス）
EC2インスタンスやLambdaなどAWSリソースからのアクセスには、IAMロールを割り当てることで、アクセスキーを直接配置する必要がなくなる。
これはとても簡単な方法です。
例：
・EC2インスタンスにS3読み取りロールをアタッチ。(とても危険なため、決してEC2内にアクセスキーを書き込むようなことをしないこと)
・Lambda関数にDynamoDBアクセスロールを設定。
(b)AWS IAM Identity Center（旧SSO）
組織内のユーザーには、AWS IAM Identity Center（AWS SSO）を利用し、フェデレーテッドアクセス（SAML/OIDC連携）や短期クレデンシャルを発行する。
例:
・Active Directoryと連携し、ADユーザーに一時的なAWSアクセス権限を付与。
(c)一時クレデンシャル（STS: Security Token Service）
AssumeRoleやGetSessionTokenを利用し、有効期限付きの一時的なアクセスキーを発行します。この方法が推奨される。
例:
・CLIで aws sts assume-role を実行し、一時的なキーを取得。
(d)AWS CloudShell
AWSマネジメントコンソールから直接利用できるCloudShellでは、自動的に一時的な認証情報が割り当てられる。
(4)可視化
IAM Access Analyzer で「パブリック／クロスアカウント公開」を検知し、Security Hub へ送信。
(*1)IAM Access Analyzerで以下のようなセキュリティホールが発生していないかチェック
・パブリック公開: インターネット上の認証されていないすべてのユーザーがアクセスできる状態。
・クロスアカウント公開: 特定の AWS アカウント以外の AWS アカウントがアクセスできる状態。
(*2)AWS Security Hub は、AWS 環境全体のセキュリティ状況を一元的に把握し、管理するためのサービス。
IAM Identity Center を利用し、ユーザのパスワード管理の負担(特にAWSサービス以外の複数パスワード管理)やセキュリティ向上をアップする。
IdP 連携: Azure AD や Okta と SAML/OIDC 連携し、属性 (department, projectId 等) をタグとして伝搬させ ABAC を実装。Identity Center 側の権限セットに Permission Boundary を設定し過剰特権を防止。
ローテーション不要の一時クレデンシャル: Fed ユーザは IAM ロールを “AssumeRole” し、最長 12 時間の一時トークンのみを使用。
監査: sso.amazonaws.com アクティビティを CloudTrail Lake に長期保管。
メリット：
(a)シンプルなアクセス管理
複数のAWSアカウント・クラウドアプリに1回のログインでアクセス可能（SSO）。
(b)一元化された権限制御
組織全体のユーザー/グループを一箇所で管理でき、権限の割り当て・監査が容易。
(c)セキュリティ強化
MFA（多要素認証）の強制、きめ細かいアクセスポリシー、外部ID連携（Azure AD等）で安全性向上。
(d)運用効率化
AWS CLI/SDKとの連携で開発者体験が向上。手動のIAMユーザー管理から解放される。
(e)コスト削減
無料で利用可能（一部連携サービスを除く）。
→ 複数AWSアカウントや外部アプリを使う企業ほど効果的
AWS Managed Microsoft AD を 2 AZ 構成でデプロイ。Windows Server は LDAPS 経由で認証。
グループポリシー (GPO) でローカル管理者アカウントを無効化し、SSM Session Manager のみ許可。
Web アプリの外部ユーザ用 ID 基盤。MFA、OTP メール／SMS、外部 IdP (Google, Apple) を統合し、クライアントにトークン (ID/Access/Refresh) を払い出す。トークンは API Gateway の Lambda Authorizer で検証。
(*1)IAMとCognitoは、管理する対象と目的が根本的に異なる。
IAM は、AWSのインフラストラクチャ自体のセキュリティとアクセス制御に焦点を当てている。AWSリソースを誰が、何ができるかを管理するためのもの。
Cognito は、アプリケーションのユーザーというより抽象度の高いレイヤーに焦点を当てている。アプリケーションの利用者を認証し、そのユーザーに関連する情報を管理し、必要に応じてAWSリソースへのアクセス権限を付与するために設計されている。
簡単に言うとIAMは組織のユーザ、Congnitoは顧客ということ。もちろん組織内のIAMへのアクセスを持たないユーザはCongnito認証ということもある。
ポリシーストア: マルチテナント SaaS ではテナントごとにストアを分割。2025 年 5 月のアップデートで リソースタグによるアクセス制御
が可能となり、管理効率が向上。
Cedar 言語でオブジェクトレベルの許可を宣言的に記述し、アプリ側から IsAuthorized API を呼び出して権限判定。
(設計のサンプル)
高可用性: 各サブネットを 3 AZ に展開。
Endpoint: SSM, Logs, KMS など必要な Interface Endpoint を Private-Subnet 側に配置し、アウトバウンド NAT を不要化。
・ポイント
AWS 環境のネットワーク設計におけるセキュリティと効率性を向上させるための重要なプラクティスです。それぞれのキーワードを分解して、その意味を詳しく解説します。
(a) Private Subnet (プライベートサブネット)
VPC (Virtual Private Cloud) 内のサブネットの一種で、インターネットゲートウェイへの直接的なルートを持たないため、インターネットからの直接的なインバウンドアクセスはできません。
通常、EC2 インスタンスなどのワークロードは、セキュリティ上の理由からプライベートサブネットに配置されます。
プライベートサブネット内のインスタンスがインターネット上のリソースにアクセスするには、一般的に NAT (Network Address Translation) ゲートウェイを経由する必要があります。
(b)アウトバウンド NAT (Outbound Network Address Translation)
プライベートサブネット内のインスタンスがインターネット上のサービスやリソースにアクセスする際に、そのプライベート IP アドレスを、NAT ゲートウェイが持つパブリック IP アドレスに変換する仕組みです。
これにより、プライベート IP アドレスを公開することなくインターネットへのアクセスが可能になりますが、NAT ゲートウェイの運用と管理、およびわずかながらコストが発生します。また、インターネットを経由するため、セキュリティ上の懸念も僅かに存在します。
(c). Interface Endpoint (インターフェースエンドポイント)
AWS PrivateLink という技術を利用して、VPC 内から AWS の各種サービス（例：S3、DynamoDB、EC2 Image Builder、ECR、CloudWatch Logs、SSM、KMS など）にプライベートに接続するための仮想ネットワークインターフェースです。
インターフェースエンドポイントは、指定したプライベートサブネット内に作成され、プライベート IP アドレスを持ちます。
VPC 内のインスタンスは、インターネットを経由することなく、このプライベート IP アドレスを介して AWS のサービスに安全かつ低遅延でアクセスできます。
(d). SSM, Logs, KMS など必要な Interface Endpoint
SSM (AWS Systems Manager): EC2 インスタンスなどのハイブリッド環境のリソースを一元的に管理するためのサービスです。セッションマネージャー機能を利用すると、踏み台サーバーなしで安全にインスタンスにアクセスできます。
Logs (Amazon CloudWatch Logs): アプリケーションやサービスのログデータを収集、監視、分析するためのサービスです。
KMS (AWS Key Management Service): 暗号化キーの作成と管理を行うためのサービスです。
これらのサービスは、プライベートサブネット内のインスタンスから頻繁にアクセスされる可能性が高いため、インターフェースエンドポイントを配置するメリットが大きいです。
「Endpoint: SSM, Logs, KMS など必要な Interface Endpoint を Private-Subnet 側に配置し、アウトバウンド NAT を不要化。」の意味
この設計は、プライベートサブネット内の EC2 インスタンスなどが、インターネットを経由せずに以下の AWS サービスにプライベートにアクセスできるようにすることを意味します。
AWS Systems Manager (SSM)
Amazon CloudWatch Logs
AWS Key Management Service (KMS)
その他、必要に応じて S3 (Interface Endpoint 経由)、ECR など
この設計のメリット
セキュリティの向上: インスタンスと AWS サービス間の通信がパブリックインターネットを経由しないため、セキュリティリスクを低減できます。データは AWS のセキュアなネットワーク内のみを流れます。
ネットワーク構成の簡素化: アウトバウンド NAT ゲートウェイが不要になるため、ネットワーク構成がよりシンプルになり、管理 overhead を削減できます。
コスト削減: NAT ゲートウェイの運用コストや、データ転送料金の一部を削減できる可能性があります。
レイテンシーの低減: プライベートな接続は、インターネットを経由するよりも低遅延で安定した通信を提供できる場合があります。
設計のポイント
プライベートサブネットごとに、必要なサービスのインターフェースエンドポイントを作成します。
VPC のルートテーブルを適切に設定し、対象の AWS サービスへのトラフィックがインターフェースエンドポイントに向かうようにします。
インターフェースエンドポイントにはセキュリティグループを設定し、適切なインバウンド/アウトバウンドルールを定義して、アクセスを制御します。
KMS エンドポイントを使用する場合は、IAM ポリシーで KMS キーへのアクセス許可を適切に設定する必要があります。
Stateful Suricata IPS ルール: 公式および自社カスタムシグネチャで C2 通信をブロック。
(a)Stateful Suricata IPS ルール (ステートフル Suricata 侵入防御システムルール)
Suricata: オープンソースの高性能なネットワーク侵入検知システム (IDS) および侵入防御システム (IPS) です。ネットワークトラフィックを監視し、悪意のある活動や既知の脅威パターンを検出・防御するために使用されます。
IPS (Intrusion Prevention System): ネットワーク上の悪意のある活動を検知するだけでなく、それをブロックしたり、隔離したりする機能を持つセキュリティシステムです。単に「検知」する IDS とは異なります。
Stateful (ステートフル): Suricata は、ネットワーク接続の状態を追跡します。つまり、個々のパケットだけでなく、TCP/IP などのコネクション全体の流れを分析し、文脈を理解した上で悪意のある活動を特定できます。これにより、フラグメント化された攻撃や、複数パケットにまたがる複雑な攻撃をより効果的に検出できます。
ルール: Suricata がネットワークトラフィックを検査し、悪意のあるパターンと照合するための定義です。ルールには、どのようなトラフィックを検知またはブロックするかの条件が記述されています。
(b)公式および自社カスタムシグネチャ
公式シグネチャ: Suricata の開発コミュニティやセキュリティベンダーなどが提供する、既知のマルウェア、エクスプロイト、攻撃手法などのパターンを定義したルールセットです。これらは定期的に更新され、最新の脅威に対応します。
自社カスタムシグネチャ: 組織や企業の特定のセキュリティ要件や環境に合わせて独自に作成したルールです。例えば、特定のマルウェアファミリーの亜種や、自社のインフラストラクチャに対する特有の攻撃パターンなどを検知・ブロックするために作成されます。
(c)C2 通信 (Command and Control Communication) をブロック
C2 通信: マルウェアに感染したシステム（ボット）が、攻撃者の制御サーバー（C2 サーバー）と通信を行うことです。攻撃者は C2 サーバーを通じて、感染したシステムに命令を送ったり、機密情報を窃取したりします。
ブロック: Suricata IPS ルールによって、この C2 サーバーとの通信を検出し、ネットワークレベルで遮断することを意味します。これにより、感染したシステムが攻撃者の制御下に入るのを防ぎ、さらなる悪意のある活動を阻止できます。
全体的な意味
この記述は、Suricata IPS を活用し、公式に提供されている最新の脅威情報に基づいたルールだけでなく、自社の環境や脅威に対応するために独自に作成したルールを適用することで、マルウェアに感染したシステムが攻撃者の C2 サーバーと通信するのを防ぐという、高度なセキュリティ対策を示しています。
C2 通信の遮断は、サイバー攻撃の被害を最小限に抑えるために非常に重要です。マルウェアが C2 サーバーと通信できなくなると、攻撃者は感染したシステムを制御できなくなり、データの窃取やさらなる攻撃の実行が困難になります。
まとめると、この記述は以下のことを示唆しています。
組織は Suricata IPS を導入し、ネットワークセキュリティを強化している。
最新の脅威情報に対応するために、公式の Suricata ルールセットを適用している。
自社の環境や特定の脅威に対処するために、カスタムの Suricata ルールを作成・運用している。
これらのルールを活用して、マルウェア感染システムが攻撃者の C2 サーバーと通信するのをネットワークレベルで阻止し、被害の拡大を防いでいる。
予備検査 (TLS 取込): TLS 1.3 に備え、ALB で復号→Firewall→再暗号化構成を採用。
この構成は、Web アプリケーションへのアクセスにおいて、以下のセキュリティ対策を実現することを意味します。
TLS 1.3 への対応: 最新の暗号化プロトコルを前提とした設計。
可視性の確保: ALB で TLS を復号することで、ファイアウォールが HTTP レベルのトラフィックを検査し、悪意のある攻撃を検出・防御できる。
エンドツーエンドの暗号化: クライアントから ALB、そして ALB からアプリケーションサーバーまでの全経路で通信が暗号化され、機密性が保たれる。
この構成のメリット
セキュリティの向上: Web アプリケーションに対する多層防御を実現し、様々な脅威から保護します。
パフォーマンスの最適化: ALB は TLS 処理に特化しているため、アプリケーションサーバーの負荷を軽減できます。
集中管理: TLS 証明書の管理などを ALB で一元的に行うことができます。
まとめると、この設計は、最新の暗号化技術である TLS 1.3 を考慮しつつ、ロードバランサー（ALB）を活用してトラフィックを復号し、ファイアウォールで詳細なセキュリティ検査を行った後、バックエンドとの通信を再度暗号化することで、安全かつ効率的な Web アプリケーションの提供を目指すものです。
スケーリング: CloudWatch Alarm で ProcessedBytes を監視し、フローレート上限 (100 Gbps) を超える前に AZ 追加。
(*)ProcessedBytes (処理済みバイト数)とは ネットワークインターフェースやロードバランサーなどが処理したデータ量の合計を示すメトリクスです。ここでは、ネットワークトラフィックの量を監視していることを意味します。
要するに、ネットワークのトラフィック量を CloudWatch Alarm を用いて継続的に監視し、その量がネットワークの処理能力の上限である
100 Gbps に達する前に、自動的に追加のアベイラビリティゾーンにリソースを投入することで、ネットワーク全体の処理能力をスケールアウト（水平方向のスケーリング）させるという設計戦略を示しています。
この戦略のメリット：
高可用性の維持: 複数の AZ にリソースを分散させることで、単一の AZ の障害による影響を最小限に抑え、サービスの継続性を高めます。
パフォーマンスの維持: ネットワークの負荷が高まっても、事前にリソースを追加することで、フローレートが上限を超過し、パフォーマンスが低下するのを防ぎます。
自動化による迅速な対応: CloudWatch Alarm によって自動的にスケーリングが行われるため、手動での対応が不要となり、迅速かつ効率的に負荷に対応できます。
キャパシティプランニングの容易化: ネットワークの利用状況を監視し、閾値を適切に設定することで、事前に必要なキャパシティを予測しやすくなります。
まとめると、この設計は、ネットワークの処理能力を常に監視し、上限に近づく前に複数のアベイラビリティゾーンにリソースを自動的に追加することで、高可用性と安定したネットワークパフォーマンスを維持するための、堅牢なスケーリング戦略を示しています。
マネージドルール: AWSManagedRulesKnownBadInputsRuleSet で SQLi/XSS を即時ブロック。
マネージドルールセットを適用することで、Web アプリケーションに対する代表的な脆弱性攻撃である SQLインジェクション (SQLi) とクロスサイトスクリプティング
(XSS) を、特別な設定やカスタムルールの作成なしに、迅速かつ効果的に防御できることを示しています。
この戦略のメリット
容易な導入: 数クリックでマネージドルールセットを適用できるため、セキュリティ対策を迅速に開始できます。
専門知識の不要: SQLi や XSS などの攻撃手法に関する深い知識がなくても、効果的な防御が可能です。
自動更新: AWS によってルールセットが常に最新の状態に保たれるため、新たな脆弱性や攻撃パターンにも自動的に対応できます。
運用負荷の軽減: カスタムルールを管理する手間が省け、セキュリティ運用にかかる負担を軽減できます。
セキュリティレベルの向上: 一般的な既知の悪意のある入力パターンを幅広くカバーするため、Web アプリケーションのセキュリティレベルを大幅に向上させることができます。
Rate-based: /login など 5 分 100 回超の POST を遮断。
Webアプリケーションの特定の重要なエンドポイント（例：ログインページ）に対して、短時間（5分間）に異常なほど大量のPOSTリクエスト（100回超）があった場合に、それをDoS攻撃やブルートフォースアタックの試みとみなし、その後のリクエストを自動的に遮断することで、Webアプリケーションを保護する仕組みを表しています。
この対策のメリット
DoS攻撃の緩和: 短時間に大量のリクエストを送信してサーバーをダウンさせようとする攻撃を防ぎます。
ブルートフォースアタックの防御: 短時間に何度もログインを試みる不正なアクセスを遮断し、アカウントの乗っ取りを防ぎます。
リソース保護: 異常なトラフィックによるサーバーリソースの過剰な消費を防ぎ、正常なユーザーの利用を妨げないようにします。
自動化された防御: 設定されたルールに基づいて自動的に遮断が行われるため、手動での対応は不要です。
まとめると、このレートベースの制御は、Webアプリケーションの可用性とセキュリティを向上させるための重要な対策であり、特にログイン試行のような悪用されやすいアクションに対して、時間あたりのリクエスト数を制限することで、不正なアクセスを効果的に防御するものです。
Shield Advanced: 大規模 L7 攻撃対策として、DDoSResponseTeam (DRT) アクセスを許可。
Shield Advancedとは：
AWS (Amazon Web Services) が提供する、より高度なDDoS（分散型サービス妨害）攻撃対策サービスです。
Standardプランよりも強力な防御機能や、攻撃発生時の専門家によるサポートが含まれています。
DDoSResponseTeam (DRT) は、AWSの専門家チームで、DDoS攻撃が発生した際に、Shield Advancedの顧客をサポートします。
「DRTアクセスを許可」するということは、大規模なL7攻撃が発生した場合に、AWSのDRTがあなたのAWS環境（具体的にはShield Advancedで保護されているリソース）にアクセスし、攻撃の分析、緩和策の適用、および復旧支援を行うことを許可することを意味します。
PrivateLink 管理者 UI (例: Jenkins) を Interface Endpoint 経由でオンプレまたは他 VPC からアクセスさせ、パブリック露出をゼロ化。
PrivateLinkとは
AWSのサービスの一つで、VPC（Virtual Private Cloud）とAWSのサービス、他のAWSアカウントのVPC、またはサポートされているオンプレミスネットワークとの間に、プライベートな接続を確立します。
パブリックIPアドレスを使用せず、インターネットゲートウェイ、NAT（Network Address Translation）デバイス、VPN接続、またはAWS Direct Connect接続を必要としません。
トラフィックはすべてAWSネットワーク内を流れ、セキュリティとパフォーマンスが向上します。
通常、Webアプリケーションに外部からアクセスできるようにするためには、パブリックIPアドレスを割り当てたり、インターネットゲートウェイを経由したりする必要があります。これにより、アプリケーションはインターネット上に公開され、セキュリティ上のリスクが増加します。
PrivateLinkのInterface Endpointを使用すると、アプリケーションにパブリックIPアドレスを割り当てる必要がなくなり、インターネットゲートウェイを経由することもありません。
その結果、管理者UIはパブリックインターネットから完全に隔離され、攻撃のリスクを大幅に低減できます。許可されたネットワーク（オンプレミスや特定のVPC）からのプライベートな接続のみを受け付けるようになります。
まとめると、この記述は以下のことを意味します。
AWS PrivateLinkのInterface Endpointという機能を利用することで、Jenkinsのような管理者UIを持つアプリケーションを、パブリックインターネットに公開することなく、オンプレミス環境や他のVPCからプライベートなネットワーク接続を通じて安全にアクセスできるようにする。これにより、セキュリティを向上させ、外部からの不正アクセスリスクを排除することができる。
・キー種別：KMS CMK (Customer Managed Key) をサービスごとに分離し、prod/web/cmkey, prod/db/cmkey
など命名。
・ローテーション： 1 年自動ローテーション。EBS/S3 スナップショットも継承。
・外部鍵 (XKS)：金融などデータ主権要件が厳しい場合、オンプレ HSM と連携する External Key Store を利用し鍵を AWS
外で保持。
自動ローテーション：Lambda: SQL Server パスワードを 30 日周期で生成し、RDS & SSM Parameter Store
に連携。
VPC エンドポイント：com.amazonaws.ap-northeast-1.secretsmanager を Private-App Subnet
に配置し、機密情報がインターネット経由しない構成。
4.3 ACM/TLS
証明書発行：apex ドメインは Route 53 DNS 検証、ワイルドカード *.example.com を ALB/CloudFront
にアタッチ。
運用：有効期限アラームを EventBridge + SNS で 30 日前に送信。
S3：Block Public Access を全バケットに強制。SSE-KMS、有効化済みバージョニング、Object Lock (Compliance
Mode) でランサム耐性を確保。
EBS：EncryptedByDefault を ON。スナップショットは CopyTags=true で機密度を継承し、外部共有を禁止。
RDS：Transparent Data Encryption は KMS CMK。ログ (error, slow query) は CloudWatch
へ転送し改ざん防止。
組織トレイルを有効化し、S3 + CloudTrail Lake に 7 年保管。
不審操作アラート: DeleteTrail, PutBucketAcl などを EventBridge → SNS/Slack。
EKS Runtime Monitoring： コンテナレイヤでの暗号通貨マイニングや権限昇格を検知。
Malware Protection： EBS Snapshot スキャンでランサムウェアを早期検出。
EC2 + Lambda + ECR 全スキャン。ECR は push イベントで即時、pull 後は再スキャン期間を要件に応じて調整。
重大 CVE を Security Hub 標準ルールで自動チケット化 (Jira)。
CIS AWS Foundations Benchmark v1.5 を自動評価し、スコアを KPI 化。
Inspector / GuardDuty / Macie を統合し、優先度付きワークフローを生成。
PCI‐DSS, ISO 27001, ISMAP テンプレートで証跡を自動収集し、取引先監査に備えたレポートを生成。
GuardDuty イベントから IAM ロール横断の攻撃パスをグラフ表示。インシデント対処チームが原因解析を迅速化。
AWS Artifact で SOC 2, ISO 27017, 27018 レポートをダウンロードし、第三者監査に提供。
Control Tower + Organizations を導入し、SCP・ログアーカイブ・共有アカウントで多アカウント統制。
AWS Config で「必須タグ欠落」「Public S3 バケット」などをリアルタイム評価し、修復 Lambda をトリガ。
パッチ管理：Patch Manager で Windows Update カタログを毎月第 2 火曜 22:00 に適用。 Systemsanager
脆弱性修正：Inspector High のみ SSM Runbook CVE-Fix を自動適用、運用時間外は保留。 Inspector +
SSM
インシデント対応：GuardDuty Critical → SNS → Incident Manager。自動で isolation Lambda
(SG 0.0.0.0/0→Deny) を実行。 GuardDuty, Incidentanager
IaC ガードレール：Terraform Cloud で tflint + terraform-compliance、プッシュ前に CI で強制。
CodePipeline
本書では、多層防御 (Defense in Depth) と ゼロトラスト を軸に、IAM → ネットワーク → データ → 監査の各階層を横断した詳細設計を示した。実装時は、
・Infrastructure as Code による再現性、
・継続的な セキュリティ評価の自動化、
・監査証跡の 長期保管と可視化
を徹底することで、変化の速いクラウド環境でも 継続的コンプライアンス を維持できる。
本ドキュメントを基盤に、組織固有のリスクアセスメント結果と規制要件を加味し、さらに詳細な運用手順書・Runbook を構築していただきたい。
【重要事項】
本ページは個人で作成しております。他のいかなる団体、組織と全く関係ありません。本サイトに記載されている内容に関しては、いかなる団体、組織にも問い合わせしないでください。あくまでも、メモとしてお楽しみください。内容は一切保証しません。
免責事項：このページは著作者が独自に調査した事項をメモ書きしたものです。何人も正当性を保証するものではありません。当然誤りも含まれます。また時間の経過により内容が劣化する可能性もあります。このページを参考にして発生したいかなる損失も何人も保証しません。自己責任で参考程度で閲覧してください。
本ページはアンオフィシャルです。Amazon とは一切関係ありません。