Hybrid cloud fj-20190704_final

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

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

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

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

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

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

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

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

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

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

本題に入る前に世の中の動向について
10

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

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

Zero Trust Network 実施例（Google BeyondCorp）
 Googleは2014年に社内ネットワークを ”BeyondCorp” と呼ばれるZero
Trustベースのアーキテクチャに刷新することを発表
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

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

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

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

ここから本題
17

Internet
（再掲）ネットワーク越しにどうAPIをつなげるか？
IPsec-VPN
Internet
API Gateway
クライアント
クライアント
18

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

Internet
（再掲）ネットワーク越しにどうAPIをつなげるか？
IPsec-VPN
Internet
RouterRouter
API Gateway
クライアント
クライアント
20

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

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

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

既存技術との比較
 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

具体的にはどこに使えるの？
25

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

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

Demonstration
28

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

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

Hybrid cloud fj-20190704_final

Hybrid cloud fj-20190704_final

More Related Content

What's hot

Similar to Hybrid cloud fj-20190704_final

Hybrid cloud fj-20190704_final