[ANS-C01]復習
ブログにまとめられてなかった箇所をメモメモ
Transit Gateway
VPC や Direct Connect と接続できる中央ハブ的なサービス
実はリージョナルサービス
Transit Gateway はリージョナルサービスなので複数リージョンの VPC や Direct Connect を接続する場合ピアリングの作業が必要
このピアリングは IPv4, v6 が通過可能で別アカウントにも設置可能
※ルートテーブルはリージョン間で共有されないので、お互いに自分のリージョンに対するルートを登録する必要がある
ルートの伝播
- オンプレミスネットワーク間で伝播されたルート: VPN / Direct Connect に接続した際、BGPを使用して TGW - オンプレミス間で伝播される
- VPC 間で伝播されたルート: VPC 上で IP アドレス設定を変更すると自動的に反映される
※ CIDR が同一の VPC はアタッチできない
SD-WAN アプライアンスとの連携
AWS Transit Gateway Connect という機能でできる
GRE トンネルと BGP の動的ルーティングをサポート
Direct Connect との接続 (暗号化)
Direct Connect - Transit Gateway - VPC での通信の暗号化方法
- Transit Gateway がない場合(Direct Connect - VPC)は パブリック VIF にして Site-to-Site VPN にする
- Direct Connect がない場合(Site-to-Site VPN - Transit Gateway - VPC)は Site-to-Site VPN の接続先を Transit Gateway にする
結論これ
Transit VIF を使用した Transit Gateway への直接接続ではなく、パブリック VIF を使用し Site-to-Site VPN で接続、その VPN を Transit Gateway に対して接続する
MACsec (MAC Security)
データセンターから Direct Connect ロケーションまでのデータを暗号化する (レイヤ2トラフィック)
アカウント共有
Transit Gateway と同一リージョンで行う必要アリ
※ AWS Resource Access Manager (AWS RAM) もリージョナルサービス
- Transit Gateway を AWS RAM と共有する
※この時 Organizations ではリソース共有を有効化しておく - AWS RAM で Transit Gateway のリソース共有を承認する
- 共有しているアカウントで Transit Gateway アタッチメントを作成する
- Transit Gateway の所有者アカウントでアタッチメントの承諾をする
ロギング
Transit Gateway Flow Logs を使用することで Transit Gateway を通過する IP トラフィック情報をキャプチャできる (VPC Flow Logs の Transit Gateway 版)
出力先は以下3つ
- Amazon CloudWatch Logs
- Amazon S3
- Kinesis Data Firehose
AWS Global Accelerator
良さ
固定のシングルエンドポイントが提供できる (IPエニキャスト)
エンドポイントのヘルスチェックからのフェイルオーバーが可能
エンドポイントの AZ/リージョン間移動時 DNS 設定の変更は必要ない
CloudFront との使い分け
基本的には用途次第 ※以下ユースケースの場合は Global Accelerator を使用する
使われ方 (ユースケース)
HTTP 以外の通信
- オンラインゲーム
- リアルタイムビデオ
- VoIP
- IoT
- Websocket
固定 IP にメリット/制限がある場合
マルチリージョンでのフェイルオーバー
キャッシュが出来ない/いらない場合
差分
一般的なアクセス
直接あて先のサーバ(オリジン)に対してアクセスを行う（ローカルのキャッシュが切れるたび都度）
CloudFront / Route 53
AWS のエッジロケーション(近い場所)がユーザにレスポンスを行う(エッジロケーションではキャッシュを持つ)
※エッジロケーション - オリジン間は AWS 内部ネットワークなので高速
Global Accelerator
AWS のエッジロケーション(近い場所)がユーザにレスポンスを行う(エッジロケーションではキャッシュを持たない)
※エッジロケーション - オリジン間は AWS 内部ネットワークなので高速
トラフィックミラーリング
機能
- EC2インスタンスのENIを通過するトラフィックをENIもしくはNLBにミラーリング
- パケットはVirtual eXtensible Local Area Network(VXLAN)でカプセル化
- EC2インスタンスにログインしなくてもパケットパケットキャプチャが可能
- VPCフローログと異なりパケット内容を取得可能
ミラーリングターゲット
- ENI
- NLB *4789/UDP でのリスナー
- GWLB
メモ
今(2022/5~)は GWLB に対してもトラフィックの転送が可能になっている
メリットとしては以下が考えられました
- 複数 VPC で監視を行いたい際に展開/管理が簡単
- セキュリティアプライアンスを IDS のように使うことが出来る
Route 53 Resolver DNS Firewall
Route 53 Resolver に対する DNS クエリを検査/ブロックできる機能
※AWS Firewall Manager と統合可能
リージョナルサービスのため各リージョンで設定する必要アリ
イメージとしては DNS クエリに対して ホワイト/ブラック リストで設定できるファイアウォール (そのまま)
Route 53 DNSSEC
Route 53 で DNSSEC の設定を行うもの
DNSSEC って何
DNS キャッシュポイズニングに対策するための技術
ネームサーバからの応答が正しい権威ネームサーバからのものかどうかを検証する
キーワード
ZSK (ゾーン署名キー)
DNSSEC で使用するゾーンを署名する鍵
Route 53 では
Route 53 が管理を行う
KSK (キー署名キー)
ZSK を署名するために使用される
Route 53 では
ユーザ管理の KMS 内 非対称カスタマーマネージドキーで行う。ユーザ管理
※オプションでローテーションが出来る
以下注意点アリ
- us-east-1 リージョンに CMK を置く
- 非対称 CMK であること
- Route 53 に必要なアクセス権があること (KMS リソースへのアクセス権など)
信頼チェーン
DNSSECでは、子ゾーンの DS を親ゾーンに登録し、
親ゾーンはさらに上のゾーンに DS を登録することで信頼の連鎖を構築する。
→この信頼を確認することで攻撃により、あるゾーン情報が偽装され誤った KSK が送信されたとしても
親ゾーンに登録してある DS と比較すれば、偽装を検知できる
DS
Delegation Signer
レコードの署名に使用されたプライベートキーに対応するパブリックキー
DNSSEC で信頼チェーンを構築するために使用されるレコード
Discussion