セキュアなアーキテクチャの設計 #1
伝播されたルートに狭い静的ルートを重ねる経路の振り分け
オンプレミス宛の通信のうち一部だけを別の経路へ振り分ける問題は、次の 3 点で判断します。
・最長プレフィックス一致 — ルートテーブルは宛先の範囲が狭い経路を優先します。オンプレミスのデータセンター全体を含む伝播されたルートと 10.1.8.0/22 の静的ルートが並べば、10.1.8.0/22 宛は後者に一致します。デフォルトルート 0.0.0.0/0 が使われるのは、ほかのどの経路にも一致しない宛先だけです。
・経路を置く場所 — ルートテーブルが振り分けるのは、関連付けられたサブネットから出る通信です。アプライアンス側のルートテーブルに経路を足しても、アプリケーションからの通信が送られるターゲットは変わりません。
・静的ルートの役割 — 仮想プライベートゲートウェイ (VPC にアタッチして Direct Connect の接続を受けるゲートウェイ) から伝播されたルートのターゲットは仮想プライベートゲートウェイで、アプライアンスには向けられません。広い範囲は伝播に任せ、アプライアンスへ向ける狭い範囲だけを静的ルートで重ねます。伝播を止めて静的ルートに置き換える必要はありません。
「一部だけ検査したい」「運用上のオーバーヘッドを最小限に」と並んだら、伝播を残したまま送信側へ狭い静的ルートを 1 本足す構成を選びます。
外向き通信の送信元を固定する NAT ゲートウェイの Elastic IP
「外部の相手が送信元 IP を許可リストで制限している」「台数が変動する」と読んだら、送信元を 1 か所に集約して固定する設計を考えます。使うのはパブリック NAT ゲートウェイと Elastic IP の組み合わせです。
・NAT ゲートウェイ — 送信元を NAT ゲートウェイのアドレスに置き換え、インターネットゲートウェイがそれを関連付けた Elastic IP に変換します。台数が増減しても外から見える送信元は同じです。
・インスタンスごとの Elastic IP — 入れ替えのたびに関連付けと相手側への登録が要り、アドレスの数も台数分になります。
・受信側の仕組みと混同しない — Network Load Balancer や AWS Global Accelerator の固定 IP アドレスはクライアントから受ける側の入口で、外へ出ていく通信の送信元には関与しません。
KMS キーのリージョン境界とスナップショットのキーを差し替えられる唯一の機会
暗号化されたスナップショットとキーの関係は、リージョン境界と差し替えの機会の 2 点で覚えると迷いません。
・AWS KMS のキーはリージョン固有です。暗号化スナップショットを別リージョンへコピーするときは、コピー先リージョンの KMS キーを指定します。ソース側のキー ARN はコピー先から参照できません。
・既存のボリューム・スナップショットに関連付けられた KMS キーは変更できません。スナップショットを別のキーで暗号化し直せるのはコピーを作るときで、スナップショットからボリュームを作成するときにも別のキーを指定できます。
・コピー先で使うキーは、コピーの操作で明示的に指定します。指定を省くと、コピー先リージョンの EBS 暗号化のデフォルトキー (aws/ebs、またはデフォルトに設定してあるキー) が使われます。
「別リージョンへスナップショットを複製」と出たら、まずコピー先リージョンのキーを用意したかを確認します。
複数フォレストの ID ソースは信頼関係で束ねた AWS Managed Microsoft AD
IAM Identity Center の ID ソースに Active Directory を使う問題は、認証元のドメインやフォレストの数から考えます。
・ドメインが 1 つ — AD Connector でも足ります。AD Connector はドメインと 1 対 1 で対応して推移的な信頼をサポートせず、同じフォレストでも子ドメインごとに要ります。IAM Identity Center に接続できるディレクトリは一度に 1 つです。
・複数のドメインやフォレスト — AWS Managed Microsoft AD を作り、各フォレストと双方向の信頼関係を結んで束ねます。IAM Identity Center は信頼先のドメインのユーザーとグループも読み取って同期するため、一方向の信頼では動作しません。
・作り直さない — 信頼関係があれば認証は元のフォレストで行われるため、AWS 側でアカウントを作り直す案は外します。
・置き場所 — ディレクトリは管理アカウントか委任管理者アカウントに置き、IAM Identity Center は同じリージョンで有効にします。
「2 つのフォレスト」「普段の認証情報で」と並んだら、信頼関係で束ねた AWS Managed Microsoft AD を選びます。
Shield Standard と Advanced を分けるのはコスト保護（サービスクレジット）
DDoS の設問は、まずどの層の攻撃かで道具が分かれます。ネットワーク層・トランスポート層は AWS Shield、アプリケーション層は AWS WAF のウェブ ACL が担当します。
Shield の Standard はすべての AWS アカウントで追加費用なく自動的に働きます。Advanced をサブスクライブすると、主に次の機能が加わります。
・請求の急増に対するコスト保護（サービスクレジット。攻撃前に保護対象へ追加し、CloudFront と ALB ではブロックするレートベースルールを置き、DDoS 攻撃中のコストを抑えるベストプラクティスに沿って構成しておくことが前提）
・アプリケーション層の自動の DDoS 緩和
・詳細な攻撃の可視化
・Shield Response Team による支援（Business Support または Enterprise Support への加入も必要）
「攻撃で増えた利用料」「クレジット」とあれば、Shield Advanced のコスト保護が決め手です。AWS WAF のルールや CloudWatch の監視、CloudFront のキャッシュは、いずれもコスト保護を持ちません。