HCCJP(ハイブリッドクラウド研究会) 第5回勉強会　発表資料 「クラウドサービス連携に有効なLayer 7のマルチクラウドコネクト技術」 ハイブリッド・マルチクラウドでシステムを動作させる事例が増えてきています。連携にはクラウド間接続が必要ですが、インターネットを挟む場合はVPNでもAPIゲートウェイでもなかなか大変です。また、インターネットに面することで余計な負担も増えてきます。 一方、Layer 7の技術・エコシステムの進化により、VPNなどを張らずともデータセンタを跨いだセキュアな通信を行うことが可能になってきました。また、セキュリティの考え方としてZero Trust Networkの考え方が重要になってきています。 今回のセッションでは、技術トレンドのご紹介と共に、弊社で開発中の新しいクラウド間接続サービスをご紹介します。 ⇒2020/2/12にTunaclo API Connectという名前で製品リリースをしました 　https://support.tunaclo.jp.fujitsu.com/ ⇒最後のスライドのMLは終息しているので、ご興味あれば下記までご連絡ください 　contact-tunaclo-biz@cs.jp.fujitsu.com

1. クラウドサービス連携に有効な
Layer 7のマルチクラウドコネクト技術
富士通株式会社
戦略企画本部) 古澤 慧, 津村 遼
Copyright 2019 FUJITSU LIMITED0
HCCJP 第5回勉強会
2019/7/4

2. 自己紹介
 名前 ：古澤 慧
 業務 ：最新のテクノロジーを活用した、製品・サービスの企画業務
 経歴 ：主にSDN関連製品の企画・開発
 名前 ：津村 遼
 業務 ：クラウドサービスの開発
 経歴 ：メインフレームのソフトウェア開発
Copyright 2019 FUJITSU LIMITED1

3. Multicloud is the New Normal
Copyright 2019 FUJITSU LIMITED
https://www.cisco.com/c/dam/global/en_uk/solutions/cloud/overview/cloud_business_cloud_advisor_infobrief_eng_FY18Q3.pdf
2

4. メルカリ
歴史的な経緯もありマルチクラウド構成（さくらでサービス開始、次第に他クラウド利用）
Copyright 2019 FUJITSU LIMITED
https://speakerdeck.com/kazeburo/microservices-on-multi-cloud
3

5. Sansan
AWSに構築したシステムで、名刺画像データのOCR処理だけGCPに移行
Copyright 2019 FUJITSU LIMITED
https://logmi.jp/tech/articles/320633
4

6. デジタル革新（DX）をスタート・加速させるためのポイント
クラウドを適材適所に使いこなし、競争上の優位性を確立することが重要に！
 事実、複数のクラウドを活用してビジネスの課題をスピーディに解決する、先進的なユーザ企業が増加。
（マルチクラウド、ハイブリッドクラウド、SaaSなどを柔軟に組み合わせ）
 更に今後はネットワークを介した企業間コラボレーションも増えてくることが予想される。
（APIを介したサービス連携）
Copyright 2019 FUJITSU LIMITED
基幹システム
Compute
Engine
BigQuery
複数クラウドで”いいとこ取り”
Fujitsu Cloud Service for OSS
サービスを組み合わせてサービスを提供する
5

7. もっと簡単につなげられないか
Copyright 2019 FUJITSU LIMITED
ではインターネット越しにサービスをどう繋ぐか？
6

8. サービスの本質
Copyright 2019 FUJITSU LIMITED
サービス利用者
アクセス
あらゆるサービスはアクセスされなければ機能しない
サービスは利用者からアクセスできるようにしなくてはいけない
この問題を “アクセシビリティ” と呼ぶ
7

9. 悪魔の双子：アクセシビリティとセキュリティ
Copyright 2019 FUJITSU LIMITED
アクセシビリティの 悪魔の双子
“セキュリティ”
より広く、より多様な方法で、より快適に
アクセシビリティを高めようとすると
セキュリティのコストが爆発的に上昇
 クラウド活用では、サービス間で必要十分・最低限のアクセシビリティ設定を
していくのが一つのポイントに
☞ 賢くアクセスさせて、賢く守る！
8

10.  既存技術は２パターンに大別
1. ネットワークで統合する … VPN, 専用線
2. サービス（API）をインターネットに公開する … API Gateway
Internet
ネットワーク越しにどうサービスをつなげるか？
Copyright 2019 FUJITSU LIMITED
Data Center #A Data Center #B
IPsec-VPN
サービス（API）
Internet
Data Center #A Data Center #B
サービス（API）
VPN GatewayVPN Gateway
API Gateway
クライアント
クライアント
9

11. もっと簡単につなげられないか
Copyright 2019 FUJITSU LIMITED
本題に入る前に世の中の動向について
10

12. 近年のセキュリティ動向について
 “Zero Trust Network” のキーワードが飛び交うように
 これは、2010年にForrester Research社のJohn
Kindervag氏が提唱したセキュリティの概念モデル
 大規模なセキュリティ事故もあり注目されてきている
• 2013年に米小売りのTargetで4000万件のカード情報と7000万
件の個人情報が流出、当時のCEOは引責辞任に追い込まれる
• 2012年から2015年にかけて、米連邦政府人事管理局(OPM)で、
2150万人の政府職員の個人情報が流出
※ OPMは流出後、監督する委員会からゼロトラストを導入すべきと提言される
Copyright 2019 FUJITSU LIMITED
ゼロトラスト提唱
OPM情報漏洩
Target情報漏洩
ここ１~２年の
注目度の伸び大
11

13. Zero Trust Network とは
 従来の ”Firewallの内側は安全” と主張する境界型セキュリティモデルに
対するアンチテーゼ
 一度でも侵入を許してしまえば特権的なアクセスができてしまうリスクに対処
 技術的ポイント
 境界の内・外といった区別を設けない
 厳密にアクセス制御（認証・認可）する
 全てのトラフィックのログを取る
Copyright 2019 FUJITSU LIMITED
従来の境界型セキュリティモデル
Data Center #BData Center #A
Internet
VPN
VPN Gateway VPN Gateway
Firewall
安全
危険
境界の内側であっても信用しない！（性悪説）
12

14. Zero Trust Network 実施例（Google BeyondCorp）
 Googleは2014年に社内ネットワークを ”BeyondCorp” と呼ばれるZero
Trustベースのアーキテクチャに刷新することを発表
Copyright 2019 FUJITSU LIMITED
https://www.secure-sketch.com/blog/zero-trust-security-model
 社内システムを全てInternet経由のアクセス
に変更、VPNも廃止
 実際、社内システムへのFQDNはDNSで公開され
ているらしい
 アクセスにはHTTP（L7）のみに限定、
L2/3といったプリミティブなアクセスを許容しない
 中央のアクセスプロキシが “Context” に応じて
ユーザからのアクセスを認証・認可
 下記要素をContext として複合的に判断
• Device（Security Updateは最新？）
• User（HR Staff？Engineering Staff？）
• Location（社内？自宅？Starbucks？）
 ただし、Googleでも移行に6年かかっている
全アクセスを
コントロールし
ログも取る
13

15. 新しいサービス事例（Akamai EAA, Zscaler ZPA)
Copyright 2019 FUJITSU LIMITED
Akamai EAA（Enterprise Application Access） Zscaler ZPA (Zscaler Private Access)
 Zero Trustの考え方を取り込み、様々なベンダーがリモートアクセスVPNの
リプレースを狙った、次世代型リモートアクセスソリューションを提供
 サブスクリプションベースのSaaS、基本的にユーザID数の課金体系
 HTTPでアクセス可能なシステムであれば、社外からアクセス可能に
 導入はConnectorをユーザNW内に配置するだけ（FW等の設定変更が要らない）
14

16.  社内に配置した ConnectorがOut通信 でEAA Edgeとコネクションを確立し、
そのコネクションを使ってユーザはリモートから社内サービスにアクセス
☞ FW等の設定変更（穴あけ）が不要となる
 HTTP/2を含めた双方向通信（WebSocket, WebRTC）技術の進化が貢献
社内ネットワーク
技術的にはどうなっているの？
Copyright 2019 FUJITSU LIMITED
InternetInternet
Enterprise
Connector
サービスEAA Edge
HTTPS
Out通信でHTTPSコネクションを確立
Firewall
（参考）https://qiita.com/namusyaka/items/71cf27fd3242adbf348c
Man-In-The-Middle型
Proxyの役割
Akamai EAA の仕組み
リモートアクセス
ユーザ
15

17. これら近年の動向から言えることは？
Copyright 2019 FUJITSU LIMITED
Zero Trust の考え方は取り入れ始めるべき
双方向通信でインタラクティブになったHTTP(S)をうまく使う
VPN 以外の選択肢も増えてきている
16

18. もっと簡単につなげられないか
Copyright 2019 FUJITSU LIMITED
ここから本題
17

19.  既存技術は２パターンに大別
1. ネットワークで統合する … VPN, 専用線
2. サービス（API）をインターネットに公開する … API Gateway
Internet
（再掲）ネットワーク越しにどうAPIをつなげるか？
Copyright 2019 FUJITSU LIMITED
Data Center #A Data Center #B
IPsec-VPN
サービス（API）
Internet
Data Center #A Data Center #B
サービス（API）
VPN GatewayVPN Gateway
API Gateway
クライアント
クライアント
18

20. VPNを使った接続を考える
 リモートにあるAPIを呼び出したいだけなのに考慮することは沢山ある
① ルーティング ：ルーティングやIPサブネットの設計が必要（サブネット重複はNG）
② VPN Gateway ：ハードであれば調達リードタイム有、場合によってFW穴あけや固定IPも必要
③ 名前解決（DNS） ：クラウドだとVPN先からPrivate DNSが引けないことも多い
* この問題にフォーカスしたソリューションもある（HashiCorp Consul Connect）
④ アクセス制御 ：低レイヤ（L2/3）の接続であり、不要なアクセスはSecurity Groupでブロックすべき
Copyright 2019 FUJITSU LIMITED
インフラの判るエンジニアが必要不可欠！
Internet
Data Center #A Data Center #B
IPsec-VPN
サービス（API）
VPN GatewayVPN Gateway
クライアント
DNS RouterSecurity Group DNSRouter Security Group
19

21.  既存技術は２パターンに大別
1. ネットワークで統合する … VPN, 専用線
2. サービス（API）をインターネットに公開する … API Gateway
Internet
（再掲）ネットワーク越しにどうAPIをつなげるか？
Copyright 2019 FUJITSU LIMITED
Data Center #A Data Center #B
IPsec-VPN
サービス（API）
Internet
Data Center #A Data Center #B
サービス（API）
RouterRouter
API Gateway
クライアント
クライアント
20

22.  リモートにあるAPIを呼び出したいだけなのに考慮することは沢山ある
① DMZ構築 ：セキュリティの専門家を交えて構築する必要、インターネットからの攻撃対策
* DoS attack, SQL injection, XSS, Brute force attack …
② セキュリティ監査 ：セキュリティ的に問題が無いことを証明する必要があり、時間もかかる
③ 証明書管理 ：Internet経由となるためHTTPS化したいが、サーバ証明書の取得・維持管理が伴う
④ 認証・認可 ：場合によっては個人情報の管理ポリシーも必要
Data Center #A Data Center #B
API Gatewayを使った接続を考える
Copyright 2019 FUJITSU LIMITED
Internet
サービス（API）
API
Gatewayクライアント
セキュリティの判るエンジニアが必要不可欠！
Firewall
DMZ
SSL
Certificate
21

23. もっと簡単につなげられないか
Copyright 2019 FUJITSU LIMITED
… もっと簡単につなげられないか？
アクセシビリティを
“特定拠点” からの ”特定API” アクセスにまで
狭めてみると・・・
22

24. マルチクラウドサービスコネクタ技術
Copyright 2019 FUJITSU LIMITED
マルチクラウド
サービスコネクタ技術
コンセプト
 特定拠点から特定API(HTTP)へのアクセスを個別に許可（ホワイトリスト方式)
 複雑化するクラウドまたぎの通信を一元管理（Single Point of Management）
 お客様のネットワーク設定変更や、追加の機器購入なしに柔軟にアクセス
クラウドプロバイダ #A
クラウドプロバイダ #B
オンプレミス
複雑化するクラウドまたぎの
通信を一元的に管理
登録されたエンドポイント間
通信を個別に許可
お客様のNWに対する
設定変更は一切不要
富士通
先進技術
23

25. 既存技術との比較
Copyright 2019 FUJITSU LIMITED
 Pros
 イントラネットと同じように使え、HTTP以外のプロトコルも通る
 Cons
 L2/L3レイヤで統合するため、サービスの統合にはネットワーク
インフラの統合も必要
• ネットワークまで統合が必要であり、統合先のネットワークを全面的に信
用しないといけない (e.g. ルーティング、名前解決(DNS))
• 守るべきネットワーク境界面が増え、水平方向に脅威が拡大
• インフラの判るエンジニアが必要
ネットワークレイヤで統合する：VPNや専用線
 Pros
 API単位でアクセスをコントロールでき、複雑な制御も可能
 Cons
 インターネットに露出させるためセキュリティの作り込みが必要
• API公開に際し、セキュリティ設定の変更が必要
(DMZ設計、DoS対策、SQL injection等々)
• 限定的な内部通信であっても、インターネットからの脅威を考慮要
• クライアントを制限するため、認証・認可の設計が必要
• セキュリティの判るエンジニアが必要
インターネットに公開する：API Gateway
アプリ間を直接つなぐ：マルチクラウドサービスコネクタ技術
 Pros
 ネットワークレイヤで統合しないため、インフラの専門スキル
無しに簡単に導入できる
 インターネットにAPIを公開しないため、特別なセキュリティ
の作り込みが要らない
 Cons
 通信可能なプロトコルがHTTPに限定される
 複雑なAPI制御はできない
24

26. もっと簡単につなげられないか
Copyright 2019 FUJITSU LIMITED
具体的にはどこに使えるの？
25

27.  海外を含む複数拠点の間でお互いにAPIにアクセスさせたい
 従来 … VPNを張るか、API Gatewayを個別に設置（拠点によってはオーバースペック）
 新技術の利用後 … コスト的に接続が難しかった拠点にも、調整無しにすぐに導入できる！
国内拠点
Firewall
【Case #1】 複数拠点にまたがったデータセンタ間での利用
Copyright 2019 FUJITSU LIMITED
共有データ
拠点
（海外 A）
Firewall
多地点接続を
低コストで実現
拠点
（海外 B）
・
・
・
国内拠点
共有データ
拠点
（海外 A）
拠点
（海外 B）
・
・
・
VPN GW
VPN GW
VPNだとコスト的
に割りに合わない
国内のセキュリティ担当海外のセキュリティ担当
調整
マルチクラウド
サービスコネクタ技術
26

28.  オンプレ環境にある実データと連携して、新しいクラウドサービスのPoCを実施したい
 従来 … 費用と期間が限られているが、VPN 設置にリソースを割いている
 新技術の利用後 … ネットワークの調整も不要で、ソフトインストールすればすぐに使える！
クラウドプロバイダオンプレミス
【Case #2】 オンプレデータを使ったPoC環境の構築
Copyright 2019 FUJITSU LIMITED
実データ
VPN GatewayVPN Gateway
新クラウドサービス
VPN接続に
向けたNW管理者
との調整
構築費用が
損益を圧迫
クラウドプロバイダオンプレミス
実データ 新クラウドサービスFirewall コストを抑えて
すぐに使える
VPN
マルチクラウド
サービスコネクタ技術
27

29. Copyright 2019 FUJITSU LIMITED
Demonstration
28

30. 【Demo】 リモート環境のPrivateなサービス（API）を呼び出す
 Azure環境に構築したサービス（API）に、発表中端末からアクセスする
 リモートのサービスはPublicには公開されていない（固定IPアドレスを持たない）
 Azure側のFirewall では、HTTPのOut通信（Port 443）のみ許可
Copyright 2019 FUJITSU LIMITED
サービス（API）
IP address：10.0.1.4
HTTPS
マルチクラウド
サービスコネクタ技術
発表中端末
HTTPS
Security Group設定
 送信規則
✔ 許可：プロトコル（HTTP）
✘ 拒否：その他の全通信
 受信規則
✘ 拒否：全通信
curlでリモートの
APIを呼び出し
Firewall
29

31. Q&A、ディスカッション
Copyright 2019 FUJITSU LIMITED
ご紹介した “マルチクラウドサービスコネクタ技術” について
詳細について聞いてみたい方は、下記までご連絡ください
✉ fj-pf-mcc-contact@jp.fujitsu.com
30