Upgrade to Pro — share decks privately, control downloads, hide ads and more …

クラウドサービス連携に有効なLayer 7のマルチクラウドコネクト技術

クラウドサービス連携に有効なLayer 7のマルチクラウドコネクト技術

ハイブリッドクラウド研究会 第5回勉強会での発表スライドです。
https://news.mynavi.jp/itsearch/article/cloud/4540?memberflag=1

近年注目されている Zero Trust Network についての解説と、マルチクラウド間通信向けの新たな技術をご紹介しています。

Avatar for Furusawa Kei

Furusawa Kei

July 04, 2019

Other Decks in Technology

Transcript

  1. 自己紹介 ◼ 名前 :古澤 慧 ◼ 業務 :最新のテクノロジーを活用した、製品・サービスの企画業務 ◼ 経歴

    :主にSDN関連製品の企画・開発 ◼ 名前 :津村 遼 ◼ 業務 :クラウドサービスの開発 ◼ 経歴 :メインフレームのソフトウェア開発 Copyright 2019 FUJITSU LIMITED 1
  2. 悪魔の双子:アクセシビリティとセキュリティ Copyright 2019 FUJITSU LIMITED アクセシビリティの 悪魔の双子 “セキュリティ” より広く、より多様な方法で、より快適に アクセシビリティを高めようとすると

    セキュリティのコストが爆発的に上昇 ◼ クラウド活用では、サービス間で必要十分・最低限のアクセシビリティ設定を していくのが一つのポイントに ☞ 賢くアクセスさせて、賢く守る! 8
  3. ◼ 既存技術は2パターンに大別 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 Gateway VPN Gateway API Gateway クライアント クライアント 9
  4. 近年のセキュリティ動向について ◼ “Zero Trust Network” のキーワードが飛び交うように ◼ これは、2010年にForrester Research社のJohn Kindervag氏が提唱したセキュリティの概念モデル

    ◼ 大規模なセキュリティ事故もあり注目されてきている • 2013年に米小売りのTargetで4000万件のカード情報と7000万 件の個人情報が流出、当時のCEOは引責辞任に追い込まれる • 2012年から2015年にかけて、米連邦政府人事管理局(OPM)で、 2150万人の政府職員の個人情報が流出 ※ OPMは流出後、監督する委員会からゼロトラストを導入すべきと提言される Copyright 2019 FUJITSU LIMITED ゼロトラスト提唱 OPM情報漏洩 Target情報漏洩 ここ1~2年の 注目度の伸び大 11
  5. Zero Trust Network とは ◼ 従来の ”Firewallの内側は安全” と主張する境界型セキュリティモデルに 対するアンチテーゼ ◼

    一度でも侵入を許してしまえば特権的なアクセスができてしまうリスクに対処 ◼ 技術的ポイント ◼ 境界の内・外といった区別を設けない ◼ 厳密にアクセス制御(認証・認可)する ◼ 全てのトラフィックのログを取る Copyright 2019 FUJITSU LIMITED 従来の境界型セキュリティモデル Data Center #B Data Center #A Internet VPN VPN Gateway VPN Gateway Firewall 安全 危険 境界の内側であっても信用しない!(性悪説) 12
  6. 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
  7. 新しいサービス事例(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
  8. ◼ 社内に配置した ConnectorがOut通信 でEAA Edgeとコネクションを確立し、 そのコネクションを使ってユーザはリモートから社内サービスにアクセス ☞ FW等の設定変更(穴あけ)が不要となる ◼ HTTP/2を含めた双方向通信(WebSocket,

    WebRTC)技術の進化が貢献 社内ネットワーク 技術的にはどうなっているの? Copyright 2019 FUJITSU LIMITED Internet Internet Enterprise Connector サービス EAA Edge HTTPS Out通信でHTTPSコネクションを確立 Firewall (参考)https://qiita.com/namusyaka/items/71cf27fd3242adbf348c Man-In-The-Middle型 Proxyの役割 Akamai EAA の仕組み リモートアクセス ユーザ 15
  9. ◼ 既存技術は2パターンに大別 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 Gateway VPN Gateway API Gateway クライアント クライアント 18
  10. 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 Gateway VPN Gateway クライアント DNS Router Security Group DNS Router Security Group 19
  11. ◼ 既存技術は2パターンに大別 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) Router Router API Gateway クライアント クライアント 20
  12. ◼ リモートにある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
  13. マルチクラウドサービスコネクタ技術 Copyright 2019 FUJITSU LIMITED マルチクラウド サービスコネクタ技術 コンセプト ◼ 特定拠点から特定API(HTTP)へのアクセスを個別に許可(ホワイトリスト方式)

    ◼ 複雑化するクラウドまたぎの通信を一元管理(Single Point of Management) ◼ お客様のネットワーク設定変更や、追加の機器購入なしに柔軟にアクセス クラウドプロバイダ #A クラウドプロバイダ #B オンプレミス 複雑化するクラウドまたぎの 通信を一元的に管理 登録されたエンドポイント間 通信を個別に許可 お客様のNWに対する 設定変更は一切不要 富士通 先進技術 23
  14. 既存技術との比較 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
  15. ◼ 海外を含む複数拠点の間でお互いにAPIにアクセスさせたい ◼ 従来 … VPNを張るか、API Gatewayを個別に設置(拠点によってはオーバースペック) ◼ 新技術の利用後 …

    コスト的に接続が難しかった拠点にも、調整無しにすぐに導入できる! 国内拠点 Firewall 【Case #1】 複数拠点にまたがったデータセンタ間での利用 Copyright 2019 FUJITSU LIMITED 共有データ 拠点 (海外 A) Firewall 多地点接続を 低コストで実現 拠点 (海外 B) ・ ・ ・ 国内拠点 共有データ 拠点 (海外 A) 拠点 (海外 B) ・ ・ ・ VPN GW VPN GW VPNだとコスト的 に割りに合わない 国内のセキュリティ担当 海外のセキュリティ担当 調整 マルチクラウド サービスコネクタ技術 26
  16. ◼ オンプレ環境にある実データと連携して、新しいクラウドサービスのPoCを実施したい ◼ 従来 … 費用と期間が限られているが、VPN 設置にリソースを割いている ◼ 新技術の利用後 …

    ネットワークの調整も不要で、ソフトインストールすればすぐに使える! クラウドプロバイダ オンプレミス 【Case #2】 オンプレデータを使ったPoC環境の構築 Copyright 2019 FUJITSU LIMITED 実データ VPN Gateway VPN Gateway 新クラウドサービス VPN接続に 向けたNW管理者 との調整 構築費用が 損益を圧迫 クラウドプロバイダ オンプレミス 実データ 新クラウドサービス Firewall コストを抑えて すぐに使える VPN マルチクラウド サービスコネクタ技術 27
  17. 【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