ANS-4.3ネットワークのデータと通信の機密性を実装し、保守する。

ヒントボタン

東京リージョンとオンプレをレイヤ2で直結しつつ20 Gbpsをまとめて扱い、自動フェイルオーバーまで求める場合、AWS Direct ConnectのDedicated Connectionを複数本束ねるLAGが王道です。LACPで二本の10 Gbps回線を論理集約すれば帯域も可用性も自動維持され、ポートチャネル全体をAWSコンソールやAPIで一元管理できます。個別接続＋BGPだけの冗長化では瞬断や運用負荷が残るため、「追加機器なし・高可用性」の条件と整合するかを意識しましょう。

FIPS 140-2準拠でワイヤ速度暗号化を実現する近道は、AWS Direct Connect物理ポートで利用できるIEEE 802.1AE(MACsec)をオンにすることです。MACsecはDedicated Connection限定の機能で、Partner Hosted ConnectionやTransit Gateway経由のSite-to-Site VPNはレイヤ3トンネル・最大1.25 Gbps程度の制約があるため20 Gbps用途には適しません。SDKやコンソールから年1回のCAK/CKNローテーションも行えるため、外部暗号装置を設置しなくても「追加機器不要」の要件を満たせます。

複数回線でMACsecを同時運用する際にシームレスなフェイルオーバーを実現する鍵は、各リンクに同一のCAK/CKNを設定して暗号セッションを共有することです。LAG配下で鍵が揃っていれば、フレームはどちらの10 Gbps回線経由でも即座に復号され切替遅延が発生しません。鍵を別々にするとフェイルオーバー時に再交渉が必要になり要件を損なう恐れがあるため、可用性・性能・暗号化の三要素を俯瞰した総合判断で最適な構成を選び取ってください。

ヒントボタン

Direct Connect の 10G/100G 回線ではロケーションによって IEEE 802.1AE-2018、つまり MACsec をネイティブで有効化できます。暗号処理はポート直結の ASIC が担当するため 100 Gbps でもスループットが落ちず、遅延はサブミリ秒で済みます。FIPS 140-2 検証アルゴリズムを実装しており、対向装置が対応していれば追加機器やトンネル設定なしでリンク全体を即時に暗号化できます。

IEEE 802.1AE には CKN／CAK を二組あらかじめ登録し、稼働中にアクティブ鍵を切り替える仕組みがあります。オンプレミスの Cisco NCS と Direct Connect 側でこのロールオーバーを設定すれば、90 日ごとに新しい鍵を投入してもセッション再確立が不要で通信は途切れません。BGP ピアも切れず、運用は「次の鍵を投入→指定日時にスワップ」のシンプルな手順で完了します。

要件は「100 Gbps の全トラフィック暗号化」「1 ms 未満の追加遅延」「無停止で 90 日ごとに鍵更新」「最小運用負荷」の四つです。Transit Gateway＋IPsec や ACM による TLS では帯域拡張やレイヤの不一致、遅延増大が懸念されます。ハードウェア暗号を備えた Direct Connect の MACsec オプションがこれら条件を同時に充足できるかを総合的に見極めると解答が導きやすくなります。

ヒントボタン

PCI DSS では鍵の平文保存が禁止されますので、AWS KMS の GenerateDataKeyWithoutPlaintext で 256 ビットの CAK/CKN を生成し、CiphertextBlob のみを Secrets Manager に格納すれば平文はメモリにも永続領域にも残りません。さらに Lambda ですぐに復号して Direct Connect の MACsec 設定へ流し込む流れにすることで一切のファイル出力を避けられ、要件①を自然に満たせます。

Secrets Manager のローテーションは 1～365 日の任意周期を指定できるため 90 日を設定し、ローテーション Lambda で Direct Connect の UpdateMacSecKey を呼び出して新旧 2 本を同時登録し 15 日の GracePeriod を確保、その後 DeleteMacSecKey で旧鍵を自動廃棄できます。API 呼び出しはサービスがトリガーするため EventBridge や手動スケジュールが不要となり、要件②を確実に実装できます。

CloudHSM や Parameter Store でも鍵生成や保存自体は可能ですが、GenerateDataKeyWithoutPlaintext＋Secrets Manager の自動更新、Direct Connect API 連携、IAM による権限制御、監査証跡、運用自動化によるヒューマンエラー削減という複数の観点を俯瞰すると、フルマネージドサービスを組み合わせた構成こそが三つの要件を同時に満たしつつ運用負荷を最小化できる最適解といえます。

ヒントボタン

新ガイドラインが求める「1 ms 以内の RTT を保ちつつ WAN 区間をレイヤー2で AES-256 で暗号化」という厳しい条件は、AWS Direct Connect の 10 Gbps / 100 Gbps Dedicated Connection がサポートする IEEE 802.1AE MACsec に合致します。MACsec を有効化する際は AWS サポートへ CKN/CAK を届け出るだけで、ヘッダー分のオーバーヘッドも DX 側が 9,206 bytes の MTU を確保しているため追加調整は不要で、機器も増やさず既存スイッチの設定変更のみで済むという点がポイントです。
一方、Transit Gateway や VGW 上に IPsec を重ねる案はレイヤー3暗号化となり要件の階層が異なるうえ、ESP カプセル化で 60〜74 bytes のフレーム増が発生し MTU を 1,400 bytes 近くまで下げる必要があります。問題文では MTU 変更や追加アプライアンスが禁止されているため、10 Gbps 超のスループットを維持しながら RTT を 1 ms 以内に抑えるのは難しく、運用も複雑化しやすい点に注意してください。
Hosted Connection は現時点で MACsec に未対応、PrivateLink や TLS 1.3 はトランスポート層であり WAN のイーサ網は暗号化されません。暗号方式の階層、レイテンシ、帯域、MTU、運用変更可否という複数観点を整理すると、既存 Dedicated Direct Connect を MACsec 対応回線へアップグレードする手法が最もシンプルかつガイドラインを網羅的に満たすと総合判断できます。

ヒントボタン

CloudFront で shop.example.com など独自ドメインを提供するには、ACM の公開証明書を us-east-1 に置くという制約があり、さらにワイルドカード *.example.com を選択すると Amazon Certificate Manager が無料で自動更新するため証明書サイクルの運用負荷が激減し、未来に sub1 や api などドメインが増えても再発行不要でコストと工数を最小化しながらブラウザ信頼チェーンを維持できます。
PCI-DSS で求められるエンドツーエンド暗号化を担保するには、CloudFront の Viewer Protocol Policy を HTTPS Only、Minimum TLS Version を 1.2 に設定したうえで Origin Protocol Policy も HTTPS に統一し、バックエンドには Fargate と親和性の高い Application Load Balancer を配置して東京リージョンの公開 ACM 証明書で終端すれば、ビューワー→エッジ→ALB の全経路が TLS 1.2 以上となりスループット 5 万 rps の負荷分散も吸収できます。
Classic Load Balancer で IAM インポート証明書や ACM Private CA を使う構成は手動更新や月額課金が発生し追加費用削減の方針と相反する一方、ALB とリージョナル公開 ACM の組み合わせは無料更新かつ Fargate に最適であり、us-east-1 のワイルドカード証明書を CloudFront に結び付ける案だけが①自動更新②TLS1.2 強制③サブドメイン拡張④追加コスト抑制という複数要件を同時に満たすことを俯瞰して確認できます。