c3.1 セキュアなアーキテクチャを設計する
セキュアなアーキテクチャを設計するとは、セキュリティを設計の意図的な一部にすることです。AWS Well-Architected のセキュリティ設計原則を適用し、AWS Security Reference Architecture を参照の設計図として使うことで、設計そのものが攻撃対象領域を減らし、あらゆる侵害の影響範囲を抑えます。
実装ガイダンス
セキュリティは設計上の決定であり、後付けではない
アーキテクチャ自体がセキュリティ統制です。優れた設計は攻撃対象領域と侵害の影響範囲を縮小します。「セキュアなアーキテクチャを設計する」とは、後から統制を付け足すのではなく、2 つの具体的なこと——設計原則に従い、リファレンスアーキテクチャの上に構築すること——を意味します。
Well-Architected のセキュリティ設計原則を適用する
設計を AWS Well-Architected フレームワークのセキュリティの柱の 7 つの設計原則に基づかせます。
- 強固なアイデンティティ基盤: 最小権限、職務分掌、一元化された ID、長期の静的認証情報の排除。
- トレーサビリティの維持: アクションと変更をリアルタイムで監視・アラート・監査する。
- すべての層でセキュリティを適用: エッジ、VPC、ロードバランサー、インスタンス、OS、アプリ、コードにわたる多層防御。
- セキュリティのベストプラクティスを自動化: バージョン管理されたテンプレートでコードとして定義・管理される統制。
- 転送時・保存時のデータ保護: データを分類し、暗号化・トークン化・アクセス制御を適用する。
- 人をデータから遠ざける: データへの直接・手動アクセスを減らし、人的ミスを抑える。
- セキュリティイベントに備える: インシデント管理プロセス、演習、検知・復旧の自動化。
実際にはこう現れます。公開された SSH/RDP をなくす（Session/Fleet Manager を使う）、最小権限のネットワーク経路と、開いた CIDR ではなく相互参照するセキュリティグループ、そしてレジリエンスのための複数のアベイラビリティーゾーン。
リファレンスアーキテクチャの上に構築する
AWS Security Reference Architecture（SRA）を、マルチアカウント組織全体で AWS のセキュリティサービスがどう組み合わさるかを示す規範的な設計図として使います。リファレンスアーキテクチャに照らして設計すると、プロジェクトごとに作り直すのではなく、自分の設計を測るための「既知の良い」目標が得られます。
実際に動いているものを把握する
設計は現実と一致して初めて安全です。Workload Discovery on AWS は稼働中のインフラからアーキテクチャ図を生成し、設計のレビュー、シャドーリソースの発見、draw.io などへのエクスポートを支援します。
How to validate
- 新しいアーキテクチャは、構築前に AWS Well-Architected のセキュリティの柱の設計原則に照らしてレビューされていますか（たとえば Well-Architected レビューで）？
- 設計はマルチアカウントのサービス配置について AWS Security Reference Architecture（SRA）に従っていますか？
- 設計は、最小権限のネットワーク経路、公開された管理ポートがないこと、マルチ AZ のレジリエンスを強制していますか？
- セキュリティ統制は、手作業ではなくバージョン管理されたテンプレートでコードとして定義されていますか？
- 実際にデプロイされているもの（シャドーリソースを含む）の正確で最新のビューを維持していますか？
Threats addressed
- 広いネットワーク到達性と公開された管理ポートを持つ設計は、攻撃者に容易な初期アクセスと横方向移動の余地を与え、単一の足がかりを広範な侵害に変えます。
- 設計が固まった後に付け足すセキュリティは、後で修正するのが高くつくギャップを残しがちです。一方、原則とリファレンスアーキテクチャに基づく設計は、それらを最初から防ぎます。