ストーリー
田
田中VPoE
ID管理の次はネットワークセキュリティだ。マルチクラウドではクラウド間の通信経路が新しい攻撃面になる
あなた
VPCの設計は各クラウドで経験がありますが、クラウド間の接続は初めてです
あ
田
田中VPoE
単一クラウドではVPC内の通信が主だったが、マルチクラウドではクラウド間をまたぐ通信が発生する。この経路をどう保護するか、どう制御するかが重要だ
あなた
インターネットを経由するか、専用線を使うかの判断もありますね
あ
田
田中VPoE
その通り。セキュリティ要件とコストのバランスで決める。ゼロトラストの考え方も重要になる
マルチクラウドネットワーク設計
全体アーキテクチャ
マルチクラウドネットワーク構成:
┌─────────────────────────────────────────┐
│ Transit Hub │
│ (専用線接続 / Cloud Interconnect) │
└────┬──────────────┬──────────────┬───────┘
│ │ │
┌──────┴──────┐ ┌─────┴──────┐ ┌─────┴──────┐
│ AWS VPC │ │ GCP VPC │ │ Azure VNet │
│ 10.1.0.0/16│ │ 10.2.0.0/16│ │ 10.3.0.0/16│
├─────────────┤ ├────────────┤ ├────────────┤
│ Public Sub │ │ Public Sub │ │ Public Sub │
│ Private Sub │ │ Private Sub│ │ Private Sub│
│ Isolated Sub│ │ Isolated │ │ Isolated │
└─────────────┘ └────────────┘ └────────────┘IPアドレス設計
| クラウド | CIDRレンジ | 用途 |
|---|---|---|
| AWS | 10.1.0.0/16 | メインクラウド |
| GCP | 10.2.0.0/16 | データ分析基盤 |
| Azure | 10.3.0.0/16 | Enterprise・EU |
| 共通 | 10.0.0.0/16 | 将来の拡張用（予約） |
IPアドレスの重複は絶対に避ける。クラウド間のルーティングが破綻する。設計段階で全クラウドのCIDRを統合管理すること。
クラウド間接続の選択肢
接続方式の比較
| 方式 | セキュリティ | 帯域幅 | コスト | 用途 |
|---|---|---|---|---|
| VPN | 暗号化通信（IPsec） | 〜数Gbps | 低 | 中小規模のセキュアな接続 |
| 専用線 | 物理的に隔離 | 10-100Gbps | 高 | 大規模、高帯域要件 |
| サードパーティ | 仮想的な専用接続 | 柔軟 | 中 | マルチクラウド間接続 |
| インターネット | TLS/mTLSで暗号化 | 制限なし | 低 | 低頻度、小データ |
接続方式別のサービス対応
| 方式 | AWS | GCP | Azure |
|---|---|---|---|
| VPN | Site-to-Site VPN | Cloud VPN | VPN Gateway |
| 専用線 | Direct Connect | Cloud Interconnect | ExpressRoute |
| ピアリング | Transit Gateway | Cloud Router | Virtual WAN |
ゼロトラストアーキテクチャ
マルチクラウドでのゼロトラスト原則
| 原則 | 説明 | 実装 |
|---|---|---|
| 信頼しない | ネットワーク境界内外を問わず信頼しない | すべての通信を認証・認可 |
| 常に検証 | すべてのアクセスリクエストを毎回検証 | リクエストごとのトークン検証 |
| 最小権限 | 必要最小限のアクセスのみ許可 | マイクロセグメンテーション |
| 暗号化 | すべての通信を暗号化 | mTLS（mutual TLS） |
| 監視 | すべての通信を可視化・記録 | ネットワークフローログ |
Service Mesh によるゼロトラスト
Service Mesh（Istio）によるマルチクラウドのゼロトラスト:
EKS (AWS) GKE (GCP)
┌────────────────┐ ┌────────────────┐
│ App A │ mTLS │ Analytics │
│ ┌───┐ ┌───┐ │←────────→│ ┌───┐ ┌───┐ │
│ │Pod│←│Envoy│ │ │ │Pod│←│Envoy│ │
│ └───┘ └───┘ │ │ └───┘ └───┘ │
│ │ │ │
│ Istio Control │ │ Istio Control │
│ Plane │ │ Plane │
└────────────────┘ └────────────────┘
↑ ↑
└───── 統合ポリシー管理 ──────┘ファイアウォールとセキュリティグループ
統一ファイアウォールポリシー
| ルール | 許可/拒否 | 送信元 | 送信先 | ポート |
|---|---|---|---|---|
| クラウド間管理通信 | 許可 | 管理ネットワーク | 全クラウド管理IP | 22, 443 |
| アプリ間通信 | 許可 | アプリサブネット | アプリサブネット | 443, gRPC |
| DB通信 | 許可 | アプリサブネット | DBサブネット | 5432, 3306 |
| インターネット受信 | 許可 | 0.0.0.0/0 | LB/CDN | 80, 443 |
| インターネット送信 | 制限 | プライベートサブネット | 許可リストのみ | 443 |
| その他 | 拒否 | すべて | すべて | すべて |
まとめ
| ポイント | 内容 |
|---|---|
| ネットワーク設計 | IPアドレスの統合管理と重複回避 |
| 接続方式 | VPN/専用線/サードパーティ/インターネットから要件に応じて選択 |
| ゼロトラスト | ネットワーク境界を信頼せず、すべての通信を認証・暗号化 |
| ファイアウォール | クラウド横断の統一ポリシーを定義し、各クラウドで実装 |
チェックリスト
- マルチクラウドのIPアドレス設計ができる
- クラウド間接続方式の選択基準を理解した
- ゼロトラストアーキテクチャの原則を理解した
- 統一ファイアウォールポリシーの設計ができる
次のステップへ
次は「マルチクラウドコンプライアンス」を学びます。複数クラウドにまたがるコンプライアンス要件の管理方法を身につけましょう。
推定読了時間: 30分