⚡ 結論ファースト ─ 実装に必要な4つのステップ
既存のDirect Connect LAG環境にMACsecを導入するには、以下の4ステップを順番に実行します。
MACsecの設定はLAGレベルで行い、個々の接続レベルでは行いません。
1
CKN/CAK
キーペアを生成
キーペアを生成
OpenSSL等で作成
2
CKN/CAKを
LAGに関連付け
LAGに関連付け
AssociateMacSecKey API
3
LAGの暗号化
モードを設定
モードを設定
UpdateLag API
4
オンプレミス
ルーターを設定
ルーターを設定
同一CKN/CAKを投入
🚛
たとえ話で理解 ─ 「現金輸送の護送隊」にセキュリティ装甲を追加する
銀行（本店）
＝ オンプレミス
🚛
🚛
🚛
🛡️ 防弾装甲＝MACsec暗号化
📦 護送隊＝LAG
金庫（支店）
＝ AWS リージョン
| 🚛 たとえ話 | ☁️ AWSの実際 | 📝 補足 |
|---|---|---|
| 🏦銀行（出発地） | オンプレミスデータセンター | MACsec対応ルーターが必要 |
| 🚛護送隊（まとめて管理） | LAG（リンク集約グループ） | 複数の回線を1つの論理接続として管理 |
| 🛡️防弾装甲（通信の暗号化） | MACsec（IEEE 802.1AE） | L2のポイントツーポイント暗号化 |
| 🗝️装甲の合鍵 | CKN/CAK キーペア | 両端（銀行と金庫）で同じ鍵が必要 |
| 📋セキュリティポリシー | 暗号化モード（should / must） | 装甲なしの車を走行禁止にするかどうか |
| 🛤️専用道路（高速道路ではない） | Direct Connect 専用回線 | 物理的に隔離された接続。暗号化は別途必要 |
🔄
Before / After ─ MACsec導入前後の変化
BEFORE ─ MACsec未導入
🔓 専用道路だが中身は丸見え
🏢
オンプレ
オンプレ
⚠️ 暗号化なし
🏬
DX拠点
DX拠点
AWS内部
☁️
AWS
AWS
✓ 専用回線で物理的に隔離
✓ LAGで帯域集約・冗長化
✗ イーサネットフレームは平文
✗ 中間者攻撃の可能性が残る
AFTER ─ MACsec導入後
🔐 専用道路 + 装甲で二重防御
🏢
オンプレ
オンプレ
🔐 MACsec暗号化
🏬
DX拠点
DX拠点
AWS物理層暗号化
☁️
AWS
AWS
✓ 専用回線で物理的に隔離
✓ LAGで帯域集約・冗長化
✓ L2暗号化でデータ機密性を確保
✓ データ整合性・改ざん防止・リプレイ防御
📡
MACsecの暗号化範囲とレイヤー構造
🔐 MACsecはポイントツーポイントのL2暗号化 ─ オンプレミスルーターとDXエンドポイント間のみ暗号化。AWSはDX拠点〜リージョン間も物理層で暗号化（多層防御）
📦
LAG内部でのMACsec構成
⚠️ 重要：MACsec設定はLAGレベルで行う ─ 個々の接続レベルでは設定しない。LAGに接続を追加すると、既存の接続のMACsecキーはdisassociateされLAGのキーが適用される
🤝
鍵のハンドシェイクプロセス
🔧
CKN/CAK生成
OpenSSL等で
64桁hex × 2
64桁hex × 2
🗄️
Secrets Manager
保管
保管
AWSが自動で
シークレット作成
シークレット作成
📡
MKA
ネゴシエーション
ネゴシエーション
両端のCKN/CAKで
相互認証を実行
相互認証を実行
🔑
SAK
自動導出
自動導出
セッション鍵を
暗号的に生成
暗号的に生成
🔐
暗号化
通信開始
通信開始
Encryption Up
ステータスに遷移
ステータスに遷移
SAK（Secure Association Key）はCKN/CAKペアから暗号的に自動導出されます。管理者が直接SAKを設定する必要はありません。CKN/CAKさえ両端で一致していれば、MKAプロトコルがSAKの生成・交換を自動的に行います。
🛠️
実装ステップ ─ 詳細手順
1
CKN/CAKキーペアを生成する ─ 🗝️ 合鍵を作る
MACsec暗号化に使用する事前共有鍵（CKN/CAK）を生成します。たとえ話では「護送隊の装甲を解除するための合鍵」です。両端で同じ鍵を持っていないと暗号化通信は成立しません。
🔑 CKN/CAKの役割
CKN（Connectivity Association Key Name）
MACsec接続を「識別」するための名前。合鍵にラベルを貼るようなもの。64桁の16進数（32オクテット）。
CAK（Connectivity Association Key）
実際の暗号化に使う「秘密鍵」本体。ここからセッション鍵（SAK）が自動導出される。64桁の16進数。
# OpenSSLを使ったCKN/CAK生成例
openssl rand -hex 32 # → CKN（64桁の16進数文字列）
openssl rand -hex 32 # → CAK（64桁の16進数文字列）
# 出力例：
# CKN: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
# CAK: f6e5d4c3b2a1f0e9d8c7b6a5f4e3d2c1f6e5d4c3b2a1f0e9d8c7b6a5f4e3d2c1
AWSは静的CAKモードのみサポート（動的CAKモード非対応）。256ビット鍵のみ使用可能です。
2
CKN/CAKをLAGに関連付ける ─ 🔗 合鍵をセットする
生成したCKN/CAKペアをLAGに関連付けます。LAGレベルで設定すると、全メンバー接続に同じ鍵が自動適用されます。たとえ話では「護送隊のすべての車に同じ装甲と合鍵をセットする」ステップです。
# 方法1：CKN/CAKを直接指定
aws directconnect associate-mac-sec-key \
--connection-id dxlag-abcd1234 \
--ckn a1b2c3d4...（64桁） \
--cak f6e5d4c3...（64桁）
# 方法2：Secrets Managerに保存済みのARNを参照
aws directconnect associate-mac-sec-key \
--connection-id dxlag-abcd1234 \
--secret-arn arn:aws:secretsmanager:ap-northeast-1:...
CKN/CAKを直接指定した場合、AWSが自動的にSecrets Managerにシークレットを作成して保管します。
関連付け後のMACsecキーは変更不可です。変更するには、一度disassociateしてから新しい鍵をassociateし直す必要があります。
3
LAGの暗号化モードを設定する ─ ⚙️ セキュリティルールを決める
LAGの暗号化モードを要件に応じて変更します。たとえ話では「装甲なしの車は走行禁止にするかどうかのルール」を決めるステップです。
# LAGの暗号化モードを更新
aws directconnect update-lag \
--lag-id dxlag-abcd1234 \
--encryption-mode should_encrypt
# 動作確認後、厳格モードに変更
aws directconnect update-lag \
--lag-id dxlag-abcd1234 \
--encryption-mode must_encrypt
must_encrypt を設定すると、暗号化が確立できない場合に接続がダウンします。必ず先に should_encrypt で動作確認してから切り替えてください。
4
オンプレミスルーターを設定する ─ 🏢 自社側にも合鍵を配備
オンプレミス側のルーターにAWSと同一のCKN/CAKおよびMACsec設定を投入します。両端の設定が一致して初めてMKAセッションが確立されます。
⚙️ オンプレミス側で必要な設定項目
CKN/CAK
AWS側と完全に一致させる（1文字でも違うとNG）
SCI（Secure Channel Identifier）
必ずONにする（AWS必須要件）
暗号スイート
10G: GCM-AES-256 / XPN-256
100G/400G: GCM-AES-XPN-256のみ
Key-Server Priority
0以外に設定（AWS側がキーサーバー）
Cisco Catalyst（IOS XE 17.x.x）の場合は ssci-based-on-sci オプションを有効化。設定完了後はインターフェースのshutdown → no shutdownでバウンスが必要です。
⚙️
3つの暗号化モードと選択フロー
暗号化なし
no_encrypt
MACsec暗号化を行わない。通常のDirect Connect接続と同じ動作
初期設定
可能なら暗号化
should_encrypt
MACsecが確立できれば暗号化。確立できなくても接続はダウンしない
推奨（初期導入時）
暗号化必須
must_encrypt
暗号化が必須。確立できない場合、接続がダウンする
厳格セキュリティ要件向け
🧭 暗号化モードの選択フローチャート
✅
前提条件チェックリスト
専用接続（Dedicated）であること
MACsecは10G / 100G / 400Gbps専用接続のみ対応。ホスト接続や1Gbpsでは使用不可
LAGの全接続がMACsec対応
LAG内のすべてのメンバー接続がMACsecをサポートし、同一帯域幅であること
オンプレミス機器がMACsec対応
自社側のルーター/スイッチがMACsec対応で、SCI有効化が可能であること
256ビットキーのみ
CKN: 64桁hex（32オクテット）、CAK: 64桁hex（32オクテット）
対応PoPロケーション
MACsecは選択されたDXポイント・オブ・プレゼンスでのみ利用可能。事前確認が必要
L2透過性の確保
ラストマイル回線がL2トラフィックに対して透過的であること。プロバイダに確認
⚖️
MACsec vs IPsec 比較表
| 比較項目 | 🔐 MACsec | 🔒 IPsec VPN |
|---|---|---|
| レイヤー | レイヤー2 データリンク層 | レイヤー3 ネットワーク層 |
| 暗号化範囲 | ポイントツーポイント（ホップ単位） | エンドツーエンド |
| パフォーマンス | ほぼ回線速度 ハードウェア処理（ASIC/PHY） | オーバーヘッドあり（暗号エンジン依存） |
| 対応帯域幅 | 10Gbps / 100Gbps / 400Gbps | 通常 1〜数Gbps程度 |
| 必要な接続タイプ | 専用接続のみ | 専用 / ホスト接続どちらもOK |
| セットアップ | 比較的シンプル（CKN/CAKの交換のみ） | トンネル設定、IKE等の設定が必要 |
| 追加コスト | なし | VPNゲートウェイ料金等 |
| 上位プロトコル影響 | なし（L2で透過的に動作） | ルーティング/アプリ設定への影響あり |
💣
よくある落とし穴
🚫 個々の接続にMACsecを設定する
LAG環境ではMACsec設定はLAGレベルで行う。接続レベルで設定するとLAG追加時にdisassociateされる。
🚫 いきなりmust_encryptにする
MKAセッション確立前にmust_encryptにすると、接続が即座にダウンし通信断が発生する。
⚠️ CKN/CAKの不一致
AWS側とオンプレミス側でCKN/CAKが1文字でも違うとMKAセッション確立不可。
⚠️ SCIをOFFのまま放置
AWSはSCIの有効化を必須要件としている。オンプレミス側で有効化忘れはネゴシエーション失敗の原因。
⚠️ Key-Server Priorityを0に設定
AWS側がキーサーバーとなるため、オンプレミス側のpriority値は0以外に設定する必要がある。
⚠️ 100GbpsでXPN非対応スイートを使用
100G/400G接続はGCM-AES-XPN-256のみ対応。XPN非対応だとネゴシエーション失敗。
🔍
トラブルシューティングフロー
📝
試験で狙われるポイント
🎯 SAP / Advanced Networking 出題パターン
❓ LAGでのMACsec設定レベル
✗ 誤：個々の接続にCKN/CAKを設定する
✓ 正：LAGレベルでCKN/CAKを関連付ける
❓ 暗号化モードの初期値
✗ 誤：should_encrypt がデフォルト
✓ 正：no_encrypt がデフォルト（明示的な変更が必要）
❓ MACsec対応の接続タイプ
✗ 誤：ホスト接続でもMACsecが使える
✓ 正：専用接続（10G/100G/400G）のみ対応
❓ MACsecの暗号化範囲
✗ 誤：MACsecでエンドツーエンド暗号化される
✓ 正：ポイントツーポイント（オンプレ〜DXロケーション間のみ）
❓
よくある質問
Q
既存のLAGをMACsec対応に変更できますか？
▼
既存LAG内のすべての接続がMACsec対応（10G/100G/400Gbps専用接続で、MACsec対応PoP）であれば可能です。ただし、接続がMACsec非対応の場合は、MACsec対応の新しい接続を作成し、VIFの移行が必要になります。
Q
MACsecの追加料金はかかりますか？
▼
MACsec自体に追加料金はかかりません。ただし、専用接続のポート料金とデータ転送料金は通常通り発生します。
Q
鍵のローテーションはどのように行いますか？
▼
新しいCKN/CAKペアをLAGに関連付け → オンプレミス側にも新鍵を設定 → MKAセッション確立を確認 → 古い鍵をdisassociate。LAGでは同時に1つのアクティブキーのみ利用され、複数キー対応は鍵ローテーション専用です。
Q
100Gbps接続で使える暗号スイートは？
▼
100G/400Gbps接続では GCM-AES-XPN-256 のみサポート。XPN（Extended Packet Numbering）は64ビットのパケット番号空間を使用し、高速接続での頻繁な鍵ローテーションを不要にします。10Gbps接続では GCM-AES-256 と GCM-AES-XPN-256 の両方が利用可能です。
Q
MACsecだけで十分なセキュリティですか？
▼
MACsecはL2のポイントツーポイント暗号化であり、特定の暗号化技術を置き換えるものではありません。AWSは多層防御（Defense in Depth）の考え方で、MACsecに加えてTLS/IPsec等の既存暗号化も併用し続けることを推奨しています。
Q
Secrets Managerのシークレットを削除するとどうなりますか？
▼
Secrets Managerでシークレットの削除をスケジュール（7〜30日）すると、CKNが読み取り不能になりネットワーク接続に影響する可能性があります。接続がavailable状態の場合、AWSが所有者にメールで通知し、30日以内に対応がなければCKNがdisassociateされます。最後のCKNがdisassociateされると、must_encryptモードは自動的にshould_encryptに変更され、突然のパケットロスを防止します。