オンプレとGoogle Cloudを安全に繋ぐための、セキュア通信の勘所

本資料は、2月28日に開催されたSRE Kaigi 2026 延長戦 ~ ゆるSRE勉強会もあるよ！ ~で発表した内容になります
https://sre-connect.connpass.com/event/381108/

Transcript

1. © MBK Digital co., Ltd. All Rights Reserved. 1 オンプレとGoogle Cloudを安全に繋ぐため の、セキュア通信の勘所 OZAKI Yuta
2. © MBK Digital co., Ltd. All Rights Reserved. 2 自己紹介 ざき(おざき　ゆうた) 株式会社MBKデジタル 役割：リードデータエンジニア/PRディレクター コミュニティ活動 　DATA Saber(since 2025/06) 　Master of DATA Saber(since 2026/02) 　データパイプライン講座の運営 所属組織 X:@waichang111
3. © MBK Digital co., Ltd. All Rights Reserved. 3 一生懸命設計したけどお蔵入りしたケースって多いですよね 　　 本日はその中の一つを供養させていただきます 概要
4. © MBK Digital co., Ltd. All Rights Reserved. 4 障害起点の話ではなく 障害を起こさないための設計レビューの話です 前提
5. © MBK Digital co., Ltd. All Rights Reserved. 5 © MBK Digital co., LTD. All Rights Reserved. 5 導入 接続の「成功」を再定義する Chapter 1
6. © MBK Digital co., Ltd. All Rights Reserved. 6 オンプレとCloudを繋ぐ時に置きがちなゴール ・IPsec張った ・VPN上がった ・FW開けた
7. © MBK Digital co., Ltd. All Rights Reserved. 7 画像引用元：接続テストの概要 だいたいこの子達
8. © MBK Digital co., Ltd. All Rights Reserved. 8 しかしこれはネットワークレイヤの成功でしかなく 実際には上のレイヤで止まることがしばしば多い
9. © MBK Digital co., Ltd. All Rights Reserved. 9 接続に成功しているのに止まる例 レイヤ 起きる現象 なぜ止まるか データ 欠損 再取得不能 アプリ 部分成功 リトライ未設計 認証 途中で403 トークン期限 経路 大容量だけ失敗 MTU/再送 TCP 長時間処理で切断 セッションタイムアウト
10. © MBK Digital co., Ltd. All Rights Reserved. 10 レイアを跨ぐと・・・ 考慮事項がとっても増える
11. © MBK Digital co., Ltd. All Rights Reserved. 11 接続成功は、運用成功ではない 接続 = 完了ではなく接続 = スタート 本日のおはなし
12. © MBK Digital co., Ltd. All Rights Reserved. 12 © MBK Digital co., LTD. All Rights Reserved. 12 原因の考察 「4種類の失敗」の提示 Chapter 2
13. © MBK Digital co., Ltd. All Rights Reserved. 13 ネットワークは生きているのに サービスが転けている・・・・
14. © MBK Digital co., Ltd. All Rights Reserved. 14 セキュア通信とは暗号ではない4種類の失敗を潰すことである 種類 失敗の典型 何を設計する？（勘所） 成功条件 到達(reachability) ルート/FW/NATで届かな い 到達性を「通信経路」で保証 （経路設計・責務境界） 到達できること 認証(Identity) 403、鍵/トークン期限、過 剰権限 主体を信頼単位にする （SA/IAM、最小権限） 「誰が」通ってよいか 継続(Sustainability) 長時間で切れる、MTU、 セッション切れ 失敗を正常系にする （retry/backoff、再接続、タ イムアウト設計） 継続できること 整合(Integrity) 部分成功、欠損、二重取り込 み 業務成功を定義 （冪等、件数/ハッシュ、再実行） データが正しいこと
15. © MBK Digital co., Ltd. All Rights Reserved. 15 トラフィックとパフォーマンスあるある きっと見つかる！ 分類 質問項目 確認内容 設計・方式へ与える影響 トラフィック データ転送量 月間 / 日次の総データ量 VPNで足りるか / 専用線必要か / コスト見積 ピーク帯域 最大 Mbps / Gbps 帯域設計・輻輳・転送時間 許容遅延 リアルタイム or バッチ 同期 / 非同期・CDC可否 信頼性 SLA 許容停止時間 HA構成・リージョン冗長 冗長化 自動フェイルオーバー必要か HA VPN / マルチトンネル バックアップ回線 代替経路の有無 Interconnect + VPN構成 セキュリティ 閉域要件 インターネット経由可否 VPN or 専用線 暗号化 IPsecのみ or TLS必須 L7暗号化・証明書管理 接続制限 接続先サービス制限 VPC SC / Private Service Connect 運用 オンプレ機器 BGP/IPsec対応可否 動的/静的ルーティング IPアドレス 重複の有無 CIDR再設計・NAT必要性 管理責任 回線保守主体 障害対応フロー・運用SLA
16. © MBK Digital co., Ltd. All Rights Reserved. 16 © MBK Digital co., LTD. All Rights Reserved. 16 設計の勘所 Chapter 3
17. © MBK Digital co., Ltd. All Rights Reserved. 17 静的ルートの限界とBGP（動的ルーティング）の優位性を比較 到達 認証 継続 整合 ファイアウォールの「優先度」設計 基本は全部ブロックし、必要なIPだけ通す 監視すべきメトリクス BGPの接続が切れていないか監視 BGP（動的ルーティング）による経路広報 ※静的ルートを使わず、BGPで双方向の 経路を自動共有する ※🚨オンプレからCloudへ行けても、Cloudからオンプレへのルートが Google Cloud の VPC ルーティングテーブルに正しく広報されていないと、通信は成立しない
18. © MBK Digital co., Ltd. All Rights Reserved. 18 BGP広報（BGP Advertisement）とは？ 参考リンク：BGP セッションを確立する 画像引用元：How to do network traffic analysis with VPC Flow Logs on Google Cloud ネットワーク機器同士が「自分はこのIPアドレス宛の通信を受け取れるよ」という情報を互いに教え合うこと Google Cloudでは、Cloud Router というサービスがこの役割を担い、オンプレミスや他社クラウドとの接続（Cloud VPN や Cloud Interconnect）において動的に経路情報を交換するために不可欠な仕組み 到達 認証 継続 整合
19. © MBK Digital co., Ltd. All Rights Reserved. 19 認証の強化と継続的な監視によるセキュリティ対策 到達 認証 継続 整合 IAM 条件 (IAM Conditions) IAM条件で「時間」と「経路」を制限し、 侵入後の操作を防ぐ 監視すべきメトリクス IAMの拒否ログが急増していないか監視 Workload Identity 連携 鍵を置かず、一時トークンで認証する
20. © MBK Digital co., Ltd. All Rights Reserved. 20 Workload Identityとは？ 到達 認証 継続 整合 一言でいうと、「Google Cloud専用の『通行証』を発行せずに、外部の身分証（AWSのIDや GitHubのIDなど）をそのまま使ってアクセスできるようにする仕組み」 オンプレミス側に鍵をおかなくても一時的なトークンで自社サーバー からGoogle Cloud APIをセキュアに呼び出せる 参考リンク：Workload Identity 連携 画像引用元：キーなしの API 認証 - サービス アカウント キーを必要としない Workload Identity 連携によるクラウド セキュリティの向上
21. © MBK Digital co., Ltd. All Rights Reserved. 21 物理的に繋がっていても、大きなデータを流した瞬間に通信が止まる 到達 認証 継続 整合 タイムアウトと再試行の設計 Cloud Load Balancing や Cloud VPN の背後にあるアプリのキープアライブをクラ ウドのタイムアウトより短くする 監視すべきメトリクス パケットドロップが増えていないか監視 MTU（最大パケットサイズ）の不整合を潰す MTU差を吸収するため、MSSを 1300〜1400に調整する ※Google Cloud の標準 MTU は 1460 地味だけど重要な設定
22. © MBK Digital co., Ltd. All Rights Reserved. 22 MTU最大バケットサイズの不整合とは？ 参考リンク：MTUに関する考慮事項 到達 認証 継続 整合 Google Cloud とオンプレミス間における MTU の不整合とは、一度に送信できるパケットの最大サイズ（MTU）が、双方 のネットワークや機器で一致していない状態 ※バケットサイズは、Cloud Storage のバケット ではなく、パケットを運ぶ「器」としてのサイズ（MTU長）のこと わかりやすくいうと、トンネルの高さ制限（MTU）」と「トラックの荷物の高さ（パケット）」が合っていない状態
23. © MBK Digital co., Ltd. All Rights Reserved. 23 MTU最大バケットサイズの不整合の原因は？ 参考リンク：トラブルシューティング 到達 認証 継続 整合 主な原因は、デフォルト設定の違いとトンネルによるオーバーヘッド • 標準的なネットワーク: MTU は 1,500 バイト • Google Cloud VPC: デフォルト MTU は 1,460 バイト（内部のカプセル化のため） • Cloud VPN: 通信を暗号化するため、サイズが削られ、推奨値は 1,440 バイト以下になることが多い 不整合が起きるとどうなる？ 1. 通信が成立しなくなる：Google Cloud 側でサイズ超過と判断されたパケットが破棄される 2. パフォーマンス低下: パケットを小さく分割する「フラグメンテーション」が発生し、再構成の負荷で通信速度 が極端に落ちる 3. 特定のアプリのハング: SSH は通るのに、データ量の多い HTTP 通信だけがタイムアウトするといった、 不可解な挙動の原因に
24. © MBK Digital co., Ltd. All Rights Reserved. 24 MTU最大バケットサイズの不整合の対策は？ 参考リンク：トラブルシューティング 到達 認証 継続 整合 MTU を合わせる: VPC ネットワーク、VLAN アタッチメント、およびオンプレミス側ルーターの MTU 値を同一 （例：1,440 や 1,500）に統一する(特にオンプレ側が要注意！！) MSS クランピング: ルーター側で、TCP 接続確立時に「パケットサイズをこれ以下にして」と強制的に通知する設定 ▷Cloud VPNなどを使用の場合はデフォルトでONになっているが、手動カスタマイズも可能 🚨上記はあくまでTCPの話。UDPは救えない UDP 通信（音声、ビデオ、一部の監視プロトコルなど）には MSS という概念がない・・・ 🫠大きなパケット（1,460 ギリギリ）を送ると、クランプが効かずにドロップすることも・・・ ▷重要な UDP 通信がある場合は、オンプレミス側のアプリケーションや NIC で MTU 自体 を低めに設定しておくのが良い
25. © MBK Digital co., Ltd. All Rights Reserved. 25 到達 認証 継続 整合 Pub/Sub の重複削除 リトライ時の重複送信をクラウド側で排除 監視すべきメトリクス チェックサムエラーが発生していないか監視 Cloud Storage のハッシュ検証 ※ハッシュで破損データを受け付けない 冪等性確保とマネージドサービスの活用 ※🚨アップロード時にローカルで算出した MD5 または CRC32C ハッシュを付与し、 Google Cloud 側で不一致を検知すると自動でエラーを返す
26. © MBK Digital co., Ltd. All Rights Reserved. 26 © MBK Digital co., LTD. All Rights Reserved. 26 実践例 Chapter 4
27. © MBK Digital co., Ltd. All Rights Reserved. 27 問題 対象システム：Oracle DB → BigQuery データ量：500GB / 日（夜間バッチ） 対象システム 制約 外部公開IPは禁止 SLA99.9% 転送制限6時間以内
28. © MBK Digital co., Ltd. All Rights Reserved. 28 HA VPN + BGP 採用構成 失敗の４分類の解決策 PSC(Private Service Connect) Workload Identity PSCでインターネットを完全回避 BGPで経路を自動収束 キーレスな Workload Identity でなりすま しを防止 万が一の瞬断・再送時も、データの壊れ・重 複を許さない 障害時もBGPで自動切替 止まらない通信路 到達 継続 認証 アプリ実装(ハッシュ・冪等性) 整合
29. © MBK Digital co., Ltd. All Rights Reserved. 29 PSCに関して：Cloud DNS連携で解決済み想定 6時間の壁：VPNの帯域（通常1トンネル3Gbps程度）であれば理論上余裕があること（計算上は約 185Mbps以上あればOK)
30. © MBK Digital co., Ltd. All Rights Reserved. 30 到達テスト: Connectivity Testsを実行し、PSC経由でBigQueryへのルートが「Virtual Pass」 になるか？ 認証テスト: 許可されていないセグメントや時間帯からのアクセスが403で拒否されるか？ 継続テスト: 片系のVPNトンネルを意図的にダウンさせ、数秒以内にBGPが切り替わるか？ 整合テスト: 意図的に破損させたデータを送り、ハッシュエラーで正しく検知・停止するか？ 耐えられるだろうか？運用に・・・
31. © MBK Digital co., Ltd. All Rights Reserved. 31 接続トラブルの半分は障害ではなく「責任分解の不明確さ」 気をつけたいところ 観点 対象ポイント 何を定義するか 観測方法 防げる失敗 責任分界 オンプレルータ 疎通・遅延の基準 Ping / Interface統計 到達 キャリア網 / ISP パケット損失率 回線監視 / SLA 継続 GCP接続エッジ(VPN/Interconnect) トンネル状態 Tunnel状態 / BGP 到達・継続 VPCリソース アクセス可否 FWログ 認証 観測 通信拒否 不正アクセス Flow Logs / Audit Logs 到達・認証 スループット低下 輻輳/断片化 Monitoringメトリクス 継続 再送増加 MTU不整合 Retransmit監視 継続 業務エラー データ不整合 アプリログ 整合 変化対応 構成変更 手動差分 Terraform 到達・認証 証明書更新 期限切れ 自動更新 認証 IP帯拡張 ルート漏れ CI検証 到達 到達 認証 継続 整合
32. © MBK Digital co., Ltd. All Rights Reserved. 32 種類 テストシナリオ テスト内容 確認ポイント 成功条件 到達 設定した全経路でパケットが「到達可 能」と表示されること Connectivity Tests FW/ルートでドロップされないか Virtual Passになる BGP経路変更 ネクストホップ切替 Cloud Routerが自動収束 認証 IAM条件（IP/時間）に反するアクセス が全て拒否されること 権限外アクセス IAM制御 403で拒否される トークン期限切れ 自動再認証 処理が継続する 継続 切り替え時の瞬断がSLA範囲内（数 秒）に収まること VPN片系停止 フェイルオーバー 数秒以内に復旧 大容量連続転送 再送/帯域低下 スループット維持 整合 破損データが検知され、後続の業務 処理に流れないこと ハッシュ不一致 破損検知 Bad Requestで拒否 二重実行 冪等性 データ重複しない 「4種類の失敗」を検証するテストシナリオ まだ、やるかい？？ 到達 認証 継続 整合
33. © MBK Digital co., Ltd. All Rights Reserved. 33 低コストで繋ぐか、低リスクで繋ぐかは「運」用スケール次第 読み切れるだろうか・・？ 規模 想定用途 推奨接続方式 コスト感 主に守るもの セキュア通信の設計ポイント 小規模数GB〜数十 GB/月 開発環境検証小規模バック アップ Cloud VPN (HA VPN) 低 到達・主体 ・外部IPを持たない構成・IAP併 用で利用者識別・短時間で構築可 能 中規模数百GB〜数 TB/月 本番運用DB同期日常ファイ ル連携 Cloud VPN また は Partner Interconnect 中 継続・運用性 ・帯域安定化（必要に応じ専用線 へ移行）・VPC Flow Logs によ る通信監査・BGPで経路自動反 映 大規模数十TB以上/ 月 DWH連携DR拠点マルチク ラウド Dedicated Interconnect 高 可用性・分離 ・物理専用線による閉域 ・MACsec検討（L2暗号化）・拠 点冗長接続必須
34. © MBK Digital co., Ltd. All Rights Reserved. 34 大事なのは事前に判断があったのかどうか 解像度が高いに越したことはない よねというお話し
35. © MBK Digital co., Ltd. All Rights Reserved. 35 専門外の設計がきてしまったら とりあえず「失敗の４分類」から整理を
36. © MBK Digital co., Ltd. All Rights Reserved. 36 セキュア通信とは暗号ではない4種類の失敗を潰すことである 種類 失敗の典型 何を設計する？（勘所） 成功条件 到達(reachability) ルート/FW/NATで届かな い 到達性を「通信経路」で保証 （経路設計・責務境界） 到達できること 認証(Identity) 403、鍵/トークン期限、過 剰権限 主体を信頼単位にする （SA/IAM、最小権限） 「誰が」通ってよいか 継続(Sustainability) 長時間で切れる、MTU、 セッション切れ 失敗を正常系にする （retry/backoff、再接続、タ イムアウト設計） 継続できること 整合(Integrity) 部分成功、欠損、二重取り込 み 業務成功を定義 （冪等、件数/ハッシュ、再実行） データが正しいこと
37. © MBK Digital co., Ltd. All Rights Reserved. 37 まとめ 今回は接続成功は運用成功ではないとして、オンプレをGoogle Cloud連携する 事例紹介を交えつつ勘所をお伝えしました フルサイクルは辛いが、染み出そう。 📚持ち帰って欲しいこと ・セキュア通信は暗号ではない ・4種類の失敗（到達/認証/継続/整合）を潰す設計が重要 ・接続=ゴールではなくスタート ✅ポイント
38. © MBK Digital co., Ltd. All Rights Reserved. 38 データとAIの力で志をカタチに Empowering Will with Data & AI.