Sdp 201902

https://www.cloudsecurityalliance.jp/Copyright © 2018 Cloud Security Alliance Japan Chapter
クラウド環境でのネットワークセ
キュリティとSDP（Software
Defined Perimeter）
一般社団法人日本クラウドセキュリティアライアンス
業務執行理事諸角昌宏
CCSP, CCSK, CSAリサーチフェロー 2019年2月22日

https://www.cloudsecurityalliance.jp/Copyright © 2018 Cloud Security Alliance Japan Chapter www.cloudsecurityalliance.orgCopyright © 2018 Cloud Security Alliance Japan Chapter
1. Cloud Security Allianceについて
2. 情報セキュリティとクラウドセキュリティ
3. クラウド環境でのネットワークアクセス
4. クラウド環境でのネットワーク境界防御
5. SDP
6. CSA本部およびCSAジャパンのSDPの取り組み
7. まとめ

https://www.cloudsecurityalliance.jp/Copyright © 2018 Cloud Security Alliance Japan ChapterCopyright © 2018 Cloud Security Alliance Japan Chapter https://cloudsecurityalliance.jp/
リクエスト/レスポンス型
リクエストを受け取るための口を
常に開けている
安全なリモートアクセスの問題
アクセスが許可されている人も許
可されていない人もアクセスが可
能
空いているポートの情報から脆弱性
を狙った攻撃が可能
DDoS攻撃が簡単に実現可能
4

NISTのクラウドの５つの特徴の
定義の１つ
幅広いネットワークアクセス
（Broad network access）
あらゆるデバイス
あらゆるネットワーク
場所、デバイスに基づくより粒
度の高いアクセス方法の設定が
必要
5

物理ネットワークを直接的に管理できない
一般的なネットワークセキュリティは、物理的な通信経路の制御とセキュ
リティアプライアンスの設置であるが、これが実施できない
クラウドでのネットワークアクセス制御
セキュリティグループ（クラウド型ファイアウォール）
SDN型
粒度の高い設定が可能
場所、デバイスに対する管理ができない。IPアドレス、ポートでの管理
6

ネットワーク型の防御
アイデンティティ型の防御
7

「あらゆるデータ侵害は『信頼
する』としたネットワークモデ
ルのほころびから生じている。
データ侵害をなくすには『ゼロ
トラスト（信頼しないこと）』
が必要」（引用：キンダーバグ氏
“https://enterprisezine.jp/article/detail/11575”）
データが置かれている場所を信
頼しないことを前提
アクセスする際に、毎回デバイ
スやアクセス認証を実施し、セ
キュリティを担保する
9

クラウド環境での情報漏洩はクラウドの問題？
2018年5月：「ホンダ」のインド法人Honda Cars India
ユーザーの個人情報5万人分以上がクラウドサービス上で公開
原因：データを保存するディレクトリの設定を「公開状態」にしていた
2018円2月： FedEX
クラウド上の11万9千件の顧客情報がアクセス可能
原因：「Amazon S3」ストレージサーバ上にパスワード無しの状態でホスティング
2016年1月：米Time Warner Cable
加入者情報32万人が流出した可能性。
原因: 外部からアクセス可能な状態
クラウドの問題以前に、利用者がクラウドを安全に使用しているかどうかが問題
10

ゼロトラスト下の3原則
1. 場所に関係なく、全てのリソースが安全にアクセスできることを保証する
2. 全てのトラフィックのログを調査する
3. 最小権限の原理を維持・強化する
ゼロトラストの対策
アクセスが許可される前は、全ての内部/外部（inside/outside perimeter）
の接続要求を信用しない
誰がアクセスしてきたが分かるまでは、ネットワークを閉じておく
認証されるまではIPアドレス、デバイスなどのアクセスを許可しない
11

安全なリモートアクセス
課題
クラウド利用者はリモートアクセスする
ネットワークを通した接続を用いて通信する
現在の解決策： VPN！
暗号化された通信として安全なリモートアクセス。
全てのユーザのトラフィックを企業のネットワークに集中した場合のレイテンシー、
単一障害点、バンド幅に伴うコストの問題
ユーザのデバイスから直接クラウドにアクセスした場合、設定、企業ネットワークと
の整合性等の問題
12

ユーザアクセスの管理と可視化
課題
セキュリティグループでの設定はIPアドレスでありユーザではない
ユーザアクセスの観点では設定が非常に複雑で手間がかかる
ユーザの場所の変化に対応できない。静的なリスト
13

FW: クラウドアクセスにおけるネットワーク・アクセス制御の問題
企業のオンプレからのアクセスは固定IPアドレス。
誰がアクセスできるかという細かい設定ができない。
インスタンスの認証にゆだねている => 認証されていない攻撃者が脆弱
性を突いてくる可能性。
コンプライアンス上も問題。誰がアクセスしたかのレポートが求められる
場所の属性ができない
SDP: アイデンティティに基づくアクセス制御
14

従来のクライアントからのサーバーへの接続
接続後にIDとパスワードでシステムにログイン
クライアントの信用性が確認される前に接続ーサーバーは外向きに公開されている
攻撃者は、最初の接続でネットワークに入り込み、様々な悪意のある活動が可能
SDPによる接続
サーバーとは別のところで、認証およびデバイスの検証を行い、信頼されたデバイスおよ
び信頼できるユーザーのみがサーバーに接続
サーバーの悪用、クレデンシャル情報の盗難、接続ハイジャックを防止可能
15

SDPワークフロー
1. SDP コントローラがオンラインとなる
2. Accepting hostは、SDP ControllerとセキュアなVPN接続を確立
3. Initiating hostは、SDP ControllerとセキュアなVPN接続を確立
4. SDP Controllerは、Initiating hostから送られてきたデバイスと本人情報に基づいて認証。接続依頼先にAccepting host
が存在するかを確認
5. 接続依頼が正しい場合、SDP Controllerは、Accepting hostに対して、Initiating hostからの接続要求を送信
6. SDP Controllerは、Initiating hostに対して、アクセスが可能なAccepting hostのネットワーク情報を送信
7. Initiating hostは、アクセスが許可されたAccepting hostに対して双方向暗号の通信を開始
2つのコンポーネント
SDP Hosts
SDP Controller
SDP Hostsは、Initiaiting Hosts(IH) と Accepting Hosts(AH)で
構成され、SDP Controllerによって管理される。
17
出典「クラウド時代に求められる最新
の認証方式」

1. 情報/インフラの見えない化
• クライアントが認証・認可されるまで、いかなる接続も行われない
• インターネットにフェースしているサービスは“deny-all”
• SPA(Single Packet Authorization)パケット以外は攻撃とみなしてドロップ＊詳細は後述
2. 双方向の暗号化された接続（Mutual TLS）
• 双方向認証を持いたユーザ、デバイスの確認
• 双方向認証により、証明書の偽装を防止
• 双方向ハンドシェイクによる中間者攻撃の防止
3. “Need to know”の原則に基づいたアクセスモデル
• 正しくないパケットは削除、および、追跡・解析
• 承認されたユーザおよびデバイスのみが接続できる
• ユーザは承認されているアプリケーションのみアクセスできるため、マルウエアに感染し
たデバイスからの接続を抑止
18

4. ダイナミックなアクセス制御
• 保護されているリソースに対して、ダイナミックにアクセスルールの作成・削除が可能。
ネットワークベースの攻撃を最小化。
5. アプリケーションレイヤー・アクセス
• ポートスキャンや脆弱性スキャンを削除。攻撃面を最小化可能。
• アプリケーション、サービスへのアクセス権を設定可能。リソースへのアクセスを制限
できる
19

SPA: Controller等への安全な接続を実現（ RFC 4226 ベース）
SPAのベースとなる考え方はPort-Knocking
通常はファイアウォールによって閉じられているポートを外部から密かに開く方法
予め決めておいた順番で閉じているポートを叩き、正しい順番のポートの"ノック" (接続試行)
を受け取ったとき、ファイアウォールは特定のポートを開いて接続を許可
（参照：
https://wiki.archlinux.jp/index.php/%E3%83%9D%E3%83%BC%E3%83%88%E3%83%8E%E3%83%83%E3%82%AD%E3%83%B3%
E3%82%B0）
Port-Knockingのメリット
パケットはデフォルト・ドロップ
サービスの非可視化。サービスの保護
ポートスキャンしても空きポートを見つけることができない
攻撃が非常に困難
DDoS攻撃も最小化できる
20
引用：
https://www.linuxjournal.com/article/9565

Port-Knockingの主な３つの課題
1. リプレイ攻撃に弱い
 クライアントからのパケット・シーケンスをそのまま送ることで接続可能
2. 悪意のある第三者によるノック・シーケンスの破壊
 正しいクライアントに変わってノック・シーケンスの一部を送ることでシーケンス
を破壊可能
3. IDSあるいはポートスキャンによるノック・シーケンスの探索
 ノック・シーケンスは一連のパケットの流れになるので探索が可能
Port-Knockingの主な３つの課題に対するSPAによる解決
1. パケット内に16バイトのランダム・データを挿入。同じパケットが来たらドロップする。
2. シングル・パケットにすることでスプーフィングだけでは攻撃できない。
3. シングル・パケットにすることで解析は不可。
21
引用：
https://www.linuxjournal.com/article/9565

1. Client-Gateway
• プロキシを使用し、クライアントとサーバを接続
2. Client-Server
• ゲートウェイを使わずにクライアントとサーバを直接接続
3. Server-Server
• アプリに対するサービスを提供するサーバを使用（主にREST API）
4. Client-Server-Client
• クライアント間のpeer-to-peer接続をサーバが仲介（chatなど）
5. その他
22

IoT通信プラットフォーム
SORACOM: SIMカード提供に基づくモバイル通信
SigFox: LPWAネットワークによる無線通信（SORACOMも利
用）
SDP: インターネットベースの通信
CSA IoTWGでもフォーカス
「SDP(Software Defined Perimeter)とIoTを結び付ける研究は、
IoTへの攻撃に対する防御として、階層的セキュリティとネット
ワーク防御を実現する上で、大きな利益をもたらすだろう。」
（引用：「IoT早期導入者のためのセキュリティガイダンス」）
23

今までの活動
SDPワーキンググループ立ち上げ： 2013年12月
SDP White Paper公開： 2013年12月
SDPの概要、構成等の紹介
CSAとしての取り組み： SDPプロトコルの定義とベンダー間の相
互運用性
SDP Specification V1.0公開： 2014年4月
第1回ハッカソン： 2014年4月
その後以下のドキュメントの公開
SDP for IaaS: 2017年3月
Software Defined Perimeter Glossary: 2018年6月

外部との連携（Open Source SDP）
https://www.waverleylabs.com/open-source-sdp/
WAVERLEY LABS
SDPのオープンソースの公開、SDP Centerを提供
背景
ほとんどのSDPの実装が、利用する組織の要求に応じて非常にカス
タマイズ、個別の設計が行われている。
様々な組織で利用できるように、より一般的なアプローチとして提
供。

ハッカソン
過去4回実施。一度も破られていない
第1回（2014年2月）
目的：内部脅威
概要：攻撃者にSDPのすべてのコンポーネントの情報を提供。正規のユーザのター
ゲットサーバへのアクセスのフルキャプチャを提供
第2回（2014年10月）
目的： DDoS攻撃
概要：攻撃者にSDP GatewayのIPアドレスを提供。
第3回（2015年4月）
目的：資格情報の盗難（Credential Theft）
概要：攻撃者にSDP Clientの資格情報とアプリケーションサーバの情報を提供。
第4回（2016年3月）
目的：パブリッククラウドを使用した高可用性
概要：攻撃者にSDPのすべてのコンポーネントの情報を提供。正規のユーザのター
ゲットサーバへのアクセスのフルキャプチャを提供。
引用 SDP Hackathon Whitepaper

今後の活動
SDP Architecture Guide V2.0 の公開：SDPの実践に向けたガイドライン。
現在 Peer Review中
内容
企業、対象者向けSDPの概要
SDPを採用したビジネス的、技術的なユースケース
SDPの利点
SDPの実装におけるアーキテクチャ上利点

SDPワーキンググループの活動状況
2015年9月：スタート
2016年5月：「クラウド時代に求められる最新の認証方式ソフトウエア・デファイン
ド・ペリメタ(Software Defined Perimeter：SDP) の活用」を公開
今までの活動における問題点、SDPの普及に対する問題点
SDPが個別商談になっている。大型の案件への導入のみになっている。
SDPが浸透しない理由として、エンドユーザの事情が分からない。
SDPの標準化に走りすぎていて、販売に力が入っていない。
日本にラボを作り自由に使っていただけることを計画したが、PoCとかが無いと難しい。
ユースケースがない。
今後の予定
SDPのユースケース・シナリオ集の作成・公開
SDP Architecture Guide V2.0 の日本語版公開

1. クラウドの利用を前提とした上でのセキュリティ対策
2. クラウドの境界防御の原則はアイデンティティ型
3. ゼロトラストに基づく資産の保護が重要
4. SDP：ゼロトラスト環境でのネットワーク、アクセス保
護
5. CSAのSDPへのコミットメント
31

ありがとうございました
https://cloudsecurityalliance.jp
info@cloudsecurityalliance.jp
CSAの活動 == 「場」の提供！
様々なワーキンググループ活動の「場」
自由な情報発信の「場」

Sdp 201902

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Sdp 201902

Semelhante a Sdp 201902 (20)

Último

Último (10)

Sdp 201902

Notas do Editor