Software-Defined Perimeter

アーキテクチャガイド

SDP Working Group Software-Defined Perimeter Architecture Guide

11

ACKNOWLEDGMENTS
CSA thanks everyone who contributed and supported us
throughout the development of this guide.
LEAD AUTHORSCONTRIBUTORSJason Garbis
Juanita Koilpillai

Junaid Islam Nya
Murray Aaron
Palermo

CSA GLOBAL STAFF
Preeta Raman
Michael Roza

© Copyright 2019, Cloud Security Alliance. All rights reserved.

Shamun Mahmud

SDP Working Group Software-Defined Perimeter Architecture Guide

日本語版提供に際しての告知及び注意事項
本書「Software-Defined Perimeter アーキテクチャガイド」は、Cloud Security Alliance (CSA)が公開している「Software-Defined Perimeter ARCHITECTURE GUIDE」の日本語訳です。本書は、CSA ジャパンが、CSA の許可を得て翻訳し、公開するものです。原文と日本語版の内容に相違があった場合には、原文が優先されます。
翻訳に際しては、原文の意味および意図するところを、極力正確に日本語で表すことを心がけていますが、翻訳の正確性および原文への忠実性について、CSA ジャパンは何らの保証をするものではありません。
この翻訳版は予告なく変更される場合があります。以下の変更履歴（日付、バージョン、変更内容）をご確認く
ださい。

変更履歴
日付
2020 年 03 月 10 日バージョン
日本語版 1.0

変更内容
初版発行

本翻訳の著作権は CSA ジャパンに帰属します。引用に際しては、出典を明記してください。無断転載を禁止します。転載および商用利用に際しては、事前に CSA ジャパンにご相談ください。
本翻訳の原著作物の著作権は、CSA または執筆者に帰属します。CSA ジャパンはこれら権利者を代理しません。原著作物における著作権表示と、利用に関する許容・制限事項の日本語訳は、前ページに記したとおりです。なお、
本日本語訳は参考用であり、転載等の利用に際しては、原文の記載をご確認下さい。

CSAジャパン成果物の提供に際しての制限事項
日本クラウドセキュリティアライアンス（CSA ジャパン）は、本書の提供に際し、以下のことをお断りし、またお願いします。以下の内容に同意いただけない場合、本書の閲覧および利用をお断りします。
１． 責任の限定
CSA ジャパンおよび本書の執筆・作成・講義その他による提供に関わった主体は、本書に関して、以下のことに対する責任を負いません。また、以下のことに起因するいかなる直接・間接の損害に対しても、一切の対応、是正、支払、賠償の責めを負いません。
(1) 本書の内容の真正性、正確性、無誤謬性(2) 本書の内容が第三者の権利に抵触しもしくは権利を侵害していないこと(3) 本書の内容に基づいて行われた判断や行為がもたらす結果(4) 本書で引用、参照、紹介された第三者の文献等の適切性、真正性、正確性、無誤謬性および他者権利の侵害の可能性
２． 二次譲渡の制限
本書は、利用者がもっぱら自らの用のために利用するものとし、第三者へのいかなる方法による提供も、行わないものとします。他者との共有が可能な場所に本書やそのコピーを置くこと、利用者以外のものに送付・送信・提供を行うことは禁止されます。また本書を、営利・非営利を問わず、事業活動の材料または資料として、そのまま直接利用することはお断りします。
ただし、以下の場合は本項の例外とします。
(1) 本書の一部を、著作物の利用における「引用」の形で引用すること。この場合、出典を明記してください。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide(2) 本書を、企業、団体その他の組織が利用する場合は、その利用に必要な範囲内で、自組織内に限定して利用すること。
(3) CSA ジャパンの書面による許可を得て、事業活動に使用すること。この許可は、文書単位で得るものとします。
(4) 転載、再掲、複製の作成と配布等について、CSA ジャパンの書面による許可・承認を得た場合。この許可・承認は、原則として文書単位で得るものとします。
３． 本書の適切な管理(1) 本書を入手した者は、それを適切に管理し、第三者による不正アクセス、不正利用から保護するために必要かつ適切な措置を講じるものとします。
(2) 本書を入手し利用する企業、団体その他の組織は、本書の管理責任者を定め、この確認事項を順守させる
ものとします。また、当該責任者は、本書の電子ファイルを適切に管理し、その複製の散逸を防ぎ、指定された利用条件を遵守する（組織内の利用者に順守させることを含む）ようにしなければなりません。
(3) 本書をダウンロードした者は、CSA ジャパンからの文書（電子メールを含む）による要求があった場合には、そのダウンロードしまたは複製した本書のファイルのすべてを消去し、削除し、再生や復元ができない状態にするものとします。この要求は理由によりまたは理由なく行われることがあり、この要求を受けた者は、それを拒否できないものとします。
(4) 本書を印刷した者は、CSA ジャパンからの文書（電子メールを含む）による要求があった場合には、その印刷物のすべてについて、シュレッダーその他の方法により、再利用不可能な形で処分するものとします。
４． 原典がある場合の制限事項等
本書が Cloud Security Alliance, Inc.の著作物等の翻訳である場合には、原典に明記された制限事項、免責事
項は、英語その他の言語で表記されている場合も含め、すべてここに記載の制限事項に優先して適用されます。
５． その他
その他、本書の利用等について本書の他の場所に記載された条件、制限事項および免責事項は、すべてここに記載の制限事項と並行して順守されるべきものとします。本書およびこの制限事項に記載のないことで、本書の利用に関して疑義が生じた場合は、CSA ジャパンと利用者は誠意をもって話し合いの上、解決を図るものとします。
その他本件に関するお問合せは、info@cloudsecurityalliance.jp までお願いします。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

日本語版作成に際しての謝辞「Software-Defined Perimeter アーキテクチャガイド」の日本語訳は、CSA ジャパン会員の有志により行われました。
作業は全て、個人の無償の貢献としての私的労力提供により行われました。なお、企業会員からの参加者の貢献には、会員企業としての貢献も与っていることを付記いたします。
以下に、翻訳に参加された方々の氏名を記します。（氏名あいうえお順・敬称略）
石井
太田
小池
諸角
矢部

敏満
拓也
泰治
昌宏
沖比古

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

目次
はじめに ...............................................................................................................................................................................4
概要 ......................................................................................................................................................................................6
Software- Defined Perimeter (SDP)の概要................................................................................................................... 6
SDPのセキュリティ上の利点 ................................................................................................................................................. 6
SDPのビジネス上の利点 ........................................................................................................................................................... 7
SDPの主な機能 ......................................................................................................................................................................... 8
SDPの潜在的なユーザー ......................................................................................................................................................... 10
SDPアーキテクチャ ........................................................................................................................................................... 13
SDP接続セキュリティ ............................................................................................................................................................. 21
補完的なアーキテクチャ ................................................................................................................................................. 23
ゼロトラストとBeyondCorp ................................................................................................................................................. 23
結論 .................................................................................................................................................................................... 36
Appendix 1 ............................................................................................................................................................................... 37© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

4

はじめに
SDPは、技術コン
ポーネントとアー
キテクチャを組み合わせて、ネット
ワークベースのア
プリケーションとインフラストラク
チャを従来のセキュリティツールよりも効率的かつ効
果的に保護します。

今日のネットワークセキュリティアーキテクチャ、ツール、およびプラットフォームは、現在の脅威が示す課題を解決できていません。主なメディアの見出しを確認している、ネットワー
クの防衛に日々努めている、またはセキュリティベンダーとして活動しているかどうかにかかわらず、企業、政府組織、および重要インフラが、さまざまな攻撃者からの持続的な攻撃に対処できていないことは明らかです。
ネットワークスタックのすべてのレイヤを包含する最新の
ネ ッ ト ワ ー ク セ キ ュ リ テ ィ で あ る 、 Software-Defined
Perimeter（SDP）を採用する時が来ています。SDPは、実績のある技術コンポーネントとアーキテクチャを組み合わせて、ネッ
トワークベースのアプリケーションとインフラストラクチャを
従来のセキュリティツールよりも効率的かつ効果的に保護します。2014年4月に公開された SDPの仕様(1.0)では以下のように述べています:“SDPの背景にある原則は、新しいものではありません。
国防総省（DoD）およびインテリジェンスコミュニティ（IC）
内の複数の組織は、ネットワークアクセス前の認証と認可に基づいて類似のネットワークアーキテクチャを実装しています。通常、機密として扱われるものや高セキュリティ
ネットワーク（DoD定義による）におけるすべてのサーバー
は、リモートアクセスゲートウェイの背後に隠され、ユー
ザーのネットワークへのアクセスやサービスの利用に関する認可の前に、認証を受ける必要があります。SDPはそれぞれのネットワークで用いられる論理モデルを活用し、標準
ワークフローに組み込まれます。SDPでは、保護されているサーバーへのアクセスの前に、認証と認可を受ける必要があります。次に、接続元とアプリケーションインフラスト
ラクチャ間で暗号化通信がリアルタイムに行われます。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide目的5セキュリティ専門家、ソリューションプロバイダーのグループとして、私たちは情報セキュリティとサイバーセキュ
リティに情熱を傾けており、Software-Defined Perimeter(SDP)
は、私たち全員が直面するセキュリティの脅威に対抗するための重要な新しいソリューションであると考えています。
SDP Specification：1.0の発行以来、ソフトウェアベンダー、対象者

システムおよびセキュリティアーキテクト、および企業を含む
共同ワーキンググループとして、これらのガイドラインに従う

この文書に記載されている情報は、組織でSDPプロジェクトを多数のシステムを構築および配備してきました。一方で、SDPの検討している、または現在実装しているすべてのセキュリテ

実装について、特に元の仕様が欠けていた分野について多くのィチーム、アーキテクチャチーム、および技術ネットワーク

ことを学びました。

チームに役立ちます。

このガイドでは、企業や専門家がSDPに関する情報を取得す

この文書の主な対象者は、情報セキュリティに関わる専るのを支援します。これは、経済的および技術的利益を提供で門家、エンタープライズアーキテクト、セキュリティコンプ

きることを示すとともに、ユーザーが組織にSDPを正常に実装でライアンス担当者です。これらの方々は主に、SDPソリューシ

きるように支援します。以下の目標が達成できるように、このョンの評価、設計、配備、運用を担当します。

文書を利用していただきたいと考えています：

さらに、ソリューションプロバイダー、サービスプロバ•

市場の認知度、信頼性の向上、およびSDPの企業での採用

イダー、およびテクノロジーベンダーに従事する方々も、こ•さまざまな環境でSDPを使用する方法についての理解の向の文書を読むことでメリットを得ることが出来ます。

上•SDPを使用して企業の問題を解決するための動機付け•

SDPについて、内部関係者を教育するためにこの文書を使用•

企業が、この文書のアーキテクチャの推奨事項に基づいて、SDPソリューションの配備を成功させます。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

6

概要
Software Defined Perimeter(SDP)の概要
SDPは、データ暗号化など、実績のある標準ベースのコンポーネントを活用するように設計されています。それらは、リモート認証（ホストがリモートアクセスを認証する）; 双方向トラン
スポート層セキュリティ（TLS;クライアント情報を暗号化を用いて検証する方法）; 適切なアクセスを保護するために暗号化と デ ジ タ ル 署 名 を 利 用 し た Security Assertion Markup
Language（SAML）; 公開鍵を介したアクセスを検証したX.509証
明書などの様々な標準ベースのテクノロジーを組み込むことでSDPを組織の既存のセキュリティシステムと統合することができます。
クラウドセキュリティアライアンス（CSA）が、Software
Defined Perimeter（SDP）仕様を最初に公開して以来、CSAはSDPのセキュリティ上の利点

SDPイノベーションの可視性と企業での採用を飛躍的に高めています。従来のネットワークセキュリティ手法が、全ての産業の•SDPは、攻撃対象領域を減少させ、リスクを低減します。

•

SDPはアクセス制御とデータプレーンを分離してこれIT、セキュリティチームを圧倒してきたように、SDPテクノロジーの使用と関心の増加に関連する例として、以下のものがあります：•

を見えなくすることで、潜在的なネットワークベース
5つのSDPワークグループは、IaaS向けSDP、Anti-の攻撃を防ぎ、重要な資産やインフラストラクチャを

DDoS、および自動車の安全な通信、を含む重点分野

保護します。

において大きな進歩を遂げました。
•
•
•
•

•

SDPは、既存のNACやアンチマルウエアのような個々の複数の商用SDPが複数のベンダーおよび複数の企業で利用

セキュリティ製品では達成が難しい統合セキュリティ

されています。

アーキテクチャを提供します:»

ユーザーが認識しているアプリケーション»

クライアントが認識しているデバイス

Anti-DDoSのユースケースではオープンソースのリファレ
ンス実装が利用されています。
4つのSDPハッカソンにおいて、SDPテストインフラストラクチ
ャに対する攻撃は成功しませんでした。
業界アナリストの調査とプレゼンテーションのレポ»
ネットワークが認識しているファイアウォー
ル/ゲートウェイ•ートに、SDPの取り扱いが増えています。

SDPは、IPベースの代わりにコネクションベースのセキュリティアーキテクチャを提供します。これは、今日のIPの爆発的増加とクラウド環境での境界の喪失により、IPベースのセキュリティが弱くなることに対応します。

•

SDPはすべてのコネクションを制御できます。これは、接続できる人の事前審査、どのデバイスからか、どのサー
ビス、インフラストラクチャおよびその他のパラメータに対してか、に基づきます。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

7

SDPのビジネス上の利点
SDPは、上記のセクションで触れた多くのビジネス上の利点（下記参照）を提供します。今後の成果において、これらの利点のより詳細な定性的および定量的な検討を提供するためにSDPコミュニティと協力することを期待しています。

ビジネスエリアSDPを実装した場合の利点
従来のネットワークセキュリティコンポーネントを置き換えることで、ライセンスとサポートのコストが削減されます。
SDPを使用してセキュリティポリシーを実装および実施することで、運用上の複雑さと従来のセキュリティツールへの依存を軽減します。

コストと省力化

IT運用のアジリティの向上

SDPはMPLSまたは専用回線の使用率を削減または置き換えてコストを削減することもできます。
これにより、組織はプライベートバックボーンネットワークの使用を削減または排除できます。

ITプロセスはビジネスプロセスの障害と見なされます。一方、SDPの実装は、ITまたはIAMのイ
ベントによって自動的に推進されます。これによりITが加速され、ビジネスとセキュリティの要求に対する応答性が向上します。

SDPは、従来の方法と比較してリスクを軽減します。SDPは脅威を抑制し、攻撃対象を減らし、ネットワークベースの攻撃やアプリケーションの脆弱性の悪用を防ぎます。
GRCの利点コンプライアンス範囲とコスト削減

SDPシステムは、システムおよびアプリケーションのコンプライアンス活動を合理化するために、（上記のSIEM統合シナリオと同様に）GRCシステムに取り込んだり対応したりすることができます。
SDPは、登録済みデバイスのユーザーから特定のアプリケーション/サービスへの接続の制御を一元管理するため、コンプライアンスデータの収集、報告、および監査プロセスを改善できます。
SDPは、オンラインビジネスのための追加の接続の追跡性を提供することによって全体的なコン
プライアンス活動を可能にします。
SDPが提供するネットワークのマイクロセグメンテーションは、コンプライアンスの範囲を縮小するために頻繁に使用されます。これは、コンプライアンス報告の取り組みに大きくプラスの影響を与える可能性があります。

セキュアクラウドコンピュ
ーティングの採用

SDPは、パブリッククラウド、プライベートクラウド、データセンター、または混在環境のアプリ
ケーションをサポートするために必要なセキュリティアーキテクチャのコストと複雑さを軽減することで、企業が迅速かつ自信を持って安全にクラウドアーキテクチャを採用できるようにします。
既存のオプションと比較して同等またはそれ以上のセキュリティ対策で新しいアプリケーショ
ンを迅速に配備できます。
SDPは、ビジネス上の優先事項を迅速かつ安全に実行できます。以下の例があります:• SDPは、 オンプレミスのコールセンターエージェントからホームベースのエージェントへの移行が避けられないビジネスを可能にします。

ビジネスのアジリティとイノベーションを実現• SDPは、非中核的な業務機能を専門の第三者にアウトソーシングすることを可能にします。
• SDPは、リモートのサードパーティパートナーネットワークおよび場所に、顧客向けのキオスクを配備することを可能にします。
• SDPは、顧客サイトへの会社資産の配備を可能にし、顧客とのより強力な統合を実現し、新しい収益を生み出します。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

8

SDPの主な機能
SDPは、少なくとも5つのセキュリティ層を含むように設計されています。（1）デバイスの認証と検証（2）ユーザーの認証と認可（3）
双方向暗号化通信の確保（4）コネクションを動的にプロビジョニング（5）サービスへの接続を見えない状態で維持しつつ管理する。
これらに加えて追加のコンポーネントもSDP実装に組み込まれています。

情報とインフラストラクチャの秘匿
SPDアーキテクチャのコンポーネント

サーバーは”黒塗り”（見えない化）

DoS攻撃を低減

不良パケット検出

セキュリティ脅威の低減、回避

全ての外部ネットワークからの攻撃
及びクロスドメイン攻撃が低減され
ます。

追加の利点
SDPコンポーネント（コントローラ、ゲートウェイ）は、クライアントがSingle-Packet Authorization（SPA）などのプロトコルを使用して認証及び認可されるまで、接続要求に応答しません。

帯域幅とサーバーのDoS攻撃（ただし、ISPによって提供されるアップストリームのAnti-DoSサービスと組み合わせる必要があることに注意してください。）

インターネットに面するサービスは、通常「denyall」SDPゲートウェイ（ネットワークファイアウォー
ルとして機能）の背後に配置されます。それにより、
DoS攻撃に対し耐性を持ちます。SDPゲートウェイ自体
は、SPAによりDoS攻撃から保護されています

全ての外部ネットワークおよびク
ロスドメイン攻撃は、すぐに検出されます。

受入れホスト（Accepting Host:AH）が他のホストから受け取る最初のパケットはSPAパケット（または同様のもの）です。AHがこれ以外のパケットを受信した場合、それは攻撃と見なされます。

双方向に暗号化された接続
SPDアーキテクチャのコンポーネント
ユーザーおよびデ
バイスの認証偽造された証明書の不許可

Man-in-the-middle
attacks（中間者攻撃）の防止

セキュリティ脅威の低減、回避

認証されていないまたは不正なデバイスからのコネクション

資格情報の盗難を目的とした攻撃

中間者攻撃

追加の利点

全てのホスト間の接続では、双方向認証を用いてユーザーとデバイスをSDPの承認されたメンバーとして検証する必要があります。

双方向認証スキームは、SDPによってルート管理（または信頼）されている既知の有効な証明書を固定します。

双方向ハンドシェイクは、サーバー証明書が取り消される前にOCSP応答を悪用する中間者攻撃を防止します。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

9“Need to Know”アクセスモデル
SPDアーキテクチャのコンポーネント

セキュリティ脅威の低減、回避追加の利点
全ての不良パケットを分析し、フォレンジック
アクティビティを追跡できます。.
アクセスポリシーに基づいて、許可されたユーザーとデバイ
スのみがサーバーに接続できます。

フォレンジックが容易

不良パケットとの不良接続。

きめ細やかなアクセス制御

未知のデバイスを用いた外部ユーザーかからのデータ盗難を低減します。

デバイスの検証

不正なデバイスからの脅威と、資格情報の盗難のリスクが低減します。

デバイスの検証により、接続を要求するデバイスが適切な鍵を保持していることが証明されます。

侵害されたデバイスからシステムを保護侵害されたデバイスからのラテラル
ムーブメントの脅威を低減します。

ユーザーは承認されたアプリケーションへのアクセスのみが許可されます。

動的なアクセスコントロール
SPDアーキテクチャのコンポーネント
動的なメンバーシップベ
ースのアクセス許可

セキュリティ脅威の低減、回避
追加の利点

ネットワークベースの攻撃

アクセスルールを動的に作成及び削除する事により、保護されたリソースへのアクセスを可能にします。（アウトバウンド、インバウンドの両方）

アプリケーションレイヤーのアクセス
SPDアーキテクチャのコンポーネント

セキュリティ脅威の低減、回避

広範なネットワークア
クセスを排除攻撃対象を最小化：マルウェアまたは
悪意あるユーザーによるポートスキャ
ン、脆弱性スキャンを排除します。

アプリケーションとサービスのアクセス制限

攻撃対象領域を制限し、マルウェ
アまたは悪意あるユーザーがリソースに接続出来ないよう防ぎます。

追加の利点
デバイスは、ポリシーで許可されている特定のホス
トとサービスのみにアクセス出来ます。ネットワー
クセグメントやサブネットへのアクセスは出来なくなります。

SDPシステムは、指定されたサービスへのアクセスを許可するデバイス、アプリケーションを制御出来ます。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

10

SDPの潜在的なユーザー
SDPはセキュリティアーキテクチャであるため、以下の表に示す様々なレベルで利点を提供しますが、古典的な「ユースケース」の狭い範囲にはうま
く収まりません。もちろん、SDPを適用できる他のシナリオもあり、以下のリストは包括的なものではありません。以下の図は、SDP実装によって保護できるコネクションのタイプの考えられる例を示しています。

ネットワー
クシナリオ

アイデンティティ主導のネットワークアクセス制御

ネットワークマイクロ
セグメンテーション

セキュアリモートアク
セス (VPN 代替)

サードパーティユーザー
のアクセス

既存の技術の限界

従来のネットワークソリューションは、粗い
ネットワークセグメンテーションのみを提供
し、IPアドレス中心となっています。
SDNのような新しいプラットフォームでも、企業はタイムリーにアイデンティティに焦点を合わせた正確なユーザーアクセス制御を実施するのは困難です。

従来のネットワークセキュリティツールでは、
マイクロセグメンテーションサービスによるネットワークセキュリティの強化は労働集約的になります。
VPNはユーザーに安全なリモートアクセスを提供しますが、範囲と機能が制限されます。
オンプレミスユーザーのセキュリティには一切対応しておらず、通常は粗いアクセス
コントロールのみを提供し、ネットワーク
セグメントまたはサブネット全体へのアクセスを許可します。これは多くの場合、セキュリティとコンプライアンスのリスクを表しており、最小権限の原則に違反しています。

セキュリティチームは通常、VPN、NAC及びVLANの組み合わせを活用してサードパーティアクセスを制御しようとします。これらのソリューションは一般的にサイロ化されており、環境全体でのきめ細やかなアクセ
ス制御、包括的なアクセス制御を提供できません。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDPに変更する利点
SDPを使用すると、ネットワークレベルで実施される組織に関連するアイデンティティ中心のアクセス制御を作成できます。例えば「財務管理システムへのWebアクセスには、企業が管理するデバイスを用いた財務ユーザーのみを許可する。ITユーザーにはSSHアクセスのみを許可する」というように。

SDPはユーザー定義のコントロールに基づいて、ネットワークのマイクロセグメンテーションを可能にします。サービスに対するきめ細やかな
ネットワークアクセス制御はSDPによって自動的に実行され、手動設定は不要です。
SDPはリモートユーザーとオンプレミスユーザ
ーの両方を保護します。
その結果、組織は全体的なソリューションとしてSDPを使用すると、VPNポイントソリューションを廃止できます。SDPソリューションはきめ
細かいアクセス制御用にも設計されています。
許可されていないリソースはユーザーからアクセスできず、最小権限の原則を満たしています。

安全なサードパーティアクセスにより、ビジネスの革新と適応を行う事ができます。例えば、
ユーザーを企業オフィスから自宅オフィスに移行してコストを削減できます。特定の機能はサードパーティの専門家に安全に外部委託できます。サードパーティユーザーのオンプレミスア
クセスを簡単に制御及び保護できます 。

SDP Working Group Software-Defined Perimeter Architecture Guide

11

ネットワー
クシナリオ

特権ユーザーアクセスの保護

高価値アプリケーションへのアクセス保護

管理対象サーバーへの
安全なアクセス

ネットワーク統合の簡素化

IaaSクラウド環境への安全な移行を可能にする

既存の技術の限界

特権ユーザー（通常は管理者）アクセスには、
高度なセキュリティ、監視、コンプライアン
ス監視が必要です。従来、特権アクセス管理（PAM）ソリューションは資格情報管理を通じてアクセスを管理しますが、ネットワーク
セキュリティ、リモートアクセス、または状況に応じたアクセス制御を提供しません。

現在、機密データを含む価値の高いアプリケーションに対するきめ細かい認可制御には、
いくつかの機能的なレイヤに変更が必要になる場合があります。（例えば、アプリケーシ
ョン、データ外部アクセス）

MSSPまたは大規模なIT環境では、管理者は管理対象サーバーへの定期的なネットワークアクセ
スを必要とし、そのIPアドレスレンジは重複する可能性があります。
これは、従来のネットワーク及びセキュリティ
ツールでは達成が難しく、面倒なコンプライア
ンスレポートが要求される可能性があります。
組織は、M&Aや災害復旧のシナリオなどで、以前は別だったネットワークを迅速に統合する必要がある場合があります。
IaaSの採用は劇的に増加していますが、多くの組織は依然としてセキュリティを懸念事項として挙げています。例えば、
IaaSアクセス制御は、企業から切断されクラウドプロバイダに限定されます。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDPに変更する利点
特権サービスへのアクセスは許可されたユーザーに制限され、ネットワークレベルで保護されます。
権限の無いユーザーから特権サービスは秘匿されるため、攻撃対象領域を制限する事が出来ます。
SDPシステムはビジネス条件で許可されている場合（例えば定義されたメンテナンスウィンドウ中）にのみアクセスが許可され、コンプライアンスレ
ポートのためにログに記録する事を保証できます。
もしくは特定デバイスからのアクセスの場合にのみ許可されます。

ユーザー/アイデンティティ認識、ネットワーク認識、およびデバイス認識を統合することにより、
またネットワーク全体を公開しないことにより、さらにアクセス制御をアプリケーションまたはア
プリケーションゲートウェイに依存することにより、アプリケーションへのアクセスを制限できます。SDPは、アプリケーションのアップグレード、
テスト、および展開を促進し、DevOps CI/CDに必要なセキュリティフレームワークを提供することもできます。

管理対象サーバーへのアクセスはビジネスプロセス（オープンサービスデスクチケットなど）で制御ができます。
SDPシステムは、複雑なネットワークレイヤをオーバーレイ
し、アクセスを簡素化及び合理化しながら、コンプライア
ンス要件を満たすためにユーザーアクティビティを記録できます。

SDPを使用すると、大規模な変更を必要とせず、ネッ
トワークを迅速かつ無停止で相互接続できます。
IaaSセキュリティの改善。アプリケーションをデ
フォルト拒否ファイアウォールの背後に隠すことに加え、全てのトラフィックが暗号化され、また、異機種混在の企業全体でユーザーアクセスポリシ
ーを一貫して定義できます。詳細については、CSAが2017年2月13日に公開した”SDP for IaaS”を参照してください。

SDP Working Group Software-Defined Perimeter Architecture Guide

12

ネットワー
クシナリオ

認証スキームの強化

エンタープライズコンプラ
イアンス管理とレポートの合理化

DDoS 防止既存の技術の限界

SDPに変更する利点

セキュリティまたはコンプライアンスの懸念により、既存の「レガシー」アプリケーションへ
2FAの追加が必要になる場合があります。これは、Web以外のアプリ、または簡単に変更できないア
プリでは実現が難しい場合があります。

SDPは、特定のアプリケーションへのアクセスを許可する前に、2FAを要求できます。
ユーザーエクスペリエンスを向上させるためにインプレースMFAシステムを使用でき、MFAを追加してレガシーアプリケーションのセキュリティを強化できます。

通常、コンプライアンスレポートは、セキュリ
ティチームとITチームにとって好ましくない負担です。

SDPは、コンプライアンスの範囲を（マイクロセグ
メンテーションを介して）縮小し、コンプライア
ンスレポートタスクを自動化します（ID中心のロ
グ記録とアクセスレポートを介して）。

従来のリモートアクセスソリューションは、
インターネット上のホストとポートを公開するため、DDoS攻撃の対象となります。従来のDDoSセキュリティ制御は、正常なパケットがドロップされるだけでなく、低帯域幅のDDoS
攻撃はバイパスされます。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDPはデフォルト拒否のファイアウォールを利用しており、権限の無いユーザーには見えない状態で配備されます。これにより、正常なパケットのみ許可します。

SDP Working Group Software-Defined Perimeter Architecture Guide

13

SDPアーキテクチャ
SDPアーキテクチャの主要コンポーネントには、クライアント/接続
SDP Architectureを開始するホスト（Initiating Hosts:IH）、サービス/接続を受け入れるホスト（Accepting Hosts:AH）、およびAHとIHの両方が接続するSDPコントローラが含まれます。 SDPホストは、接続を開始する（ホストを開始する、またはIH）か、接続を受け入れる（ホストを受け入れる、またはAH）ことができます。IHおよびAH接続は、安全な制御チャネルを介したSDPコントローラとの通信によって管理されます。この構造により、完全にスケーラブルなセキュリティシ

SDP
controller
3. Mutual TLS
to Controller

1. Controllers online
4. List of authorized
Accepting Hosts
determined
5. Accept
communication from
Initiating Host

6. Receive listof IPs ofAccepting
Hosts

accepting
SDP host

ステムを実現するために、コントロールプレーンをデータプレーンから分離したままにすることができます。さらに、すべてのコンポ

initiating
SDP host

ーネントは、拡張性または可用性の目的で冗長化できます。ここで概要を説明するワークフローに従うことにより、図1に概要を示した手法を使用して、これら3つのコンポーネント間の接続を保護でSDP client

7. mTLS
Tunnels

accepting
SDP host

2. Mutual TLS
to Controller

きます。
control channel
data channel

SDPの動作IH上のSDPクライアントソフトウェアは、SDPへの接続を開始します。
ラップトップ、タブレット、スマートフォンなどのIHデバ

図1: SDP Specification 1.0でCSAが公開したSDPアーキテクチャ,

イスはユーザー向けです。つまり、SDPソフトウェアはデバイス自体で実行されます。ネットワークは、SDPを運用している企業の管理外にある可能性があります。
AHデバイスはIHからの接続を受け入れ、SDPによって安全に保護された一連のサービスを提供します。AHは通常、企業の管理下（あるいは直接代表するもの）にあるネットワークに存在します。
SDPゲートウェイは、許可されたユーザーとデバイスに対して保護されたプロセスとサービスへのアクセスを提供します。
ゲートウェイは、これらの接続の監視、ロギング、およびレポートを実施することもできます。
IHおよびAHデバイスはSDPコントローラに接続します。SDP
コントローラは、ユーザーの認証と認可、デバイスの検証、安
全な通信の確立、ネットワーク上のユーザーと管理トラフィッ
クの分離を保証することにより、分離サービスへのアクセスを保護するアプライアンスまたはプロセスです 。
コントローラとAHはsingle-packet authorization（SPA）
で保護されており、許可されていないユーザーやデバイスからは見えず、アクセスもできません。SPAは、この文書全体および21ページで詳細に記述しています。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

14
SDPのセキュリティは、以下で示すステップバイステップのワークフローに
なります:
1.

5.

1つ以上のSDPコントローラがSDP内で追加およびアクテ

示し、暗号化された通信に必要なオプションのポリシーを開ィベートされ、AM、PKIサービス、デバイス認証、地理
位置情報、SAML、OpenID、OAuth、LDAP、Kerberos、多

始します。
6.

要素認証、IDフェデレーション、およびその他の同様の認証および認可サービスなどに接続されます。
2.

SDPコントローラは、IHにAHのリストと、暗号化された通信に必要なオプションのポリシーを提供します。

7.

IHは、許可された各AHに対してSPAを開始します。IHは、1つ以上のAHがSDP内で追加およびアクティベーション

それらのAHへの双方向暗号化接続（双方向TLS、またはされます。安全な方法でコントローラに接続して認証

mTLSなど）を作成します。

します。AHは他のホストからの通信を認識せず、あら3.

SDPコントローラは、IHからの通信を受け入れるようにAHに指8.

IHは、AHを介して相互に暗号化されたデータチャネル

かじめプロビジョニングされていない要求には応答しを通してターゲットシステムと通信します（注：前のません。

ページの図1にはステップ8は示されていません）。

各IHは、SDP内で追加およびアクティベーションされ、SDPコントローラに接続して認証されます。

4.

IHを認証した後、SDPコントローラは、IHが通信を認可されているAHのリストを決定します。

SDP配備モデル
CSAのSDP specification 1.0は、組織がSDPアーキテクチャを配備できる以下の潜在的な方法を紹介しました。:•

クライアント→ゲートウェイ•

クライアント→サーバー•

サーバー→サーバー••

クライアント→サーバー→クライアント

クライアント→ゲートウェイ→クライアン
ト•

ゲートウェイ→ゲートウェイ

クライアント→ゲートウェイ
1つまたは複数のサーバーをゲートウェイの背後で保護す
Client-to-Gateway Model

る必要がある場合、もとになるネットワークトポロジに関controller
environment

係なく、クライアント/IHとゲートウェイ間の接続が保護されます。ゲートウェイは同じ場所にある場合もあれば、世界中に分散している場合もあります。
クライアント/IHは、接続を終端するmTLSトンネルを介し

1.

2.

てゲートウェイに直接接続されます。サーバーへの接続を保護するには、追加の予防措置を講じる必要があります。

S1

clientenvironment

SDPコントローラは、コントローラとサーバーが同じSDPゲ

3.

ートウェイを使用するように、保護されたサーバーの近く
SDP clientに配置できます。
図2では、サーバー（1つ以上の環境）は、AHとして機能す
るSDPゲートウェイの背後で保護されています。ゲートウ
ェイを介したサーバーへの接続を保護するには、サーバー
環境はSDPを運用している組織によって制御される必要がserverenvironment

serverenvironment

S2

STEPS: 1. Registration // 2. Request // 3. Connection

図2：クライアント→ゲートウェイモデル：1つ以上のサーバーがゲートウェイの背後で保護されて
います

あります。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

S3

SDP Working Group Software-Defined Perimeter Architecture Guide

15
保護されたサーバーは、”Deny-All”ファイアウォールとして動作するSPAで保護されているため、適切にオンボードされClient-to-Server Model

たクライアント/IHを除いて到達不能であり、ゲートウェイとコ
ントローラは、攻撃者や不正ユーザーにはアクセスできません。

controller
environment

サーバーに変更を加えることなく、保護されたサーバーをSDPに含めることができます。それらが存在するネットワークは、保護されたサーバーへのインバウンド接続をゲートウェイから

1.

のみ許可するように構成する必要があります。これにより、許2.

可されていないクライアントは、ゲートウェイをバイパスでき

serverenvironment

ません。
このモデルは、SDPゲートウェイと保護されたサーバーの間

clientenvironment
3.

にそれらを展開することにより、組織がIDS/IPSなどの既存のネットワークセキュリティコンポーネントを使用することができます。トラフィックは、クライアントをゲートウェイに接続す
るmTLSトンネルから抽出された後に監視されます。
クライアント/IHは、デバイスでもサーバー自体でもかまいません。（16ページ「サーバー→サーバー」を参照）
クライアント→ゲートウェイモデルは、アプリケーション
をクラウドに移行した時のクラウド環境に適しています。 サー
バー環境の場所（クラウドまたはオンプレミス）に関係なく、組織はゲートウェイとアプリケーションの間でデータが保護されていることを保障できます。

SDP client

STEPS: 1. Registration // 2. Request // 3. Connection

図3：クライアント→サーバーモデル：サーバーはゲートウェイソフトウェアをローカルで実行します
サーバーはSDPゲートウェイ（AHとして機能）の背後で保護されます。ゲートウェイからサーバー（サーバー環境において）への安全な接続は、サーバー上のアプリケーション/サービスの所有者の制御下にあり、所有者がこれらの接続を完全に制御でまた、このモデルは、IHへの変更を必要としないため、オンプ
レミスのレガシーアプリケーションの保護に適しています。

きます。
保護されたサーバーは、”Deny-All”ファイアウォールとして動作するSPAで保護されているため、適切にオンボードされクライアント→サーバー

たクライアント/IHを除いては到達不能です。このことは、サーバーは内部/外部の攻撃者や不正ユーザーにはアクセスできず、組織がアプリケーションをIaaSプロバイダーに移行し、エンドインサイダーの脅威から最大限の保護を提供していることを意

ツーエンドで接続を保護する場合、このモデルはサーバーとゲ味します。

ートウェイを単一のホストに結合します。クライアント/IHは、このモデルでは、保護されたサーバーにゲートウェイを実サーバーと同じ場所に配置することも、分散させることもでき装する必要があります。サーバーが存在するネットワークは、ます。いずれの場合も、クライアント/IHとサーバー間の接続は保護されたサーバーへのインバウンド接続を許可するように構

エンドツーエンドで保護されます。

成する必要はありません。これらのサーバー上のゲートウェイ

このモデルは、サーバーとゲートウェイの組み合わせを必は、SPAを使用して、許可されていない接続を防ぎます。

要に応じて複数のIaaSプロバイダー間で移動できるため、組織

また、IDS/IPSやSIEMなどの既存のネットワークセキュリテに大きな柔軟性を提供します。このモデルは、アップグレードィコンポーネントを簡単に使用できます。トラフィックは、SDP

できないオンプレミスのレガシーアプリケーションの保護にもゲートウェイ/保護されたサーバーからのこれらのドロップされ適しています。

たパケットを分析することによって監視でき、クライアント/IH

このモデルでは、クライアント/IHは、接続を終端するmTLSとサーバー間のmTLS接続を保持します。(クライアント/IHは、トンネルを介してサーバーに直接接続されます。SDPコントロー

ユーザーデバイスとして表されますが、それ自体がサーバーでラは、（コントローラとサーバーが同じSDPゲートウェイを使用ある場合があります。このモデルについては、以下のサーバーするように）サーバーあるいはクラウドに配置できます。

→サーバーモデルを参照)
クライアント→サーバーモデルは、アプリケーションをクラウドに移行する組織に適しています。サーバー環境の場所（クラウドまたはオンプレミス）に関係なく、組織はクラウド内のアプリケーションへの接続を完全に制御できます。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

16
SDPコントローラは、コントローラとサーバーが同じSDPゲート

サーバー→サーバー

ウェイを使用するようにサーバーに配置できます。SDPコントロ
このモデルはIoTおよびVM環境に最適で、基盤となるネットワー

ーラはクラウドに存在する場合もあります。

クまたはIPインフラストラクチャに関係なくサーバー間のすべ

サーバーは、AHとして機能するSDPゲートウェイの背後で保護されての接続が暗号化されます。サーバー→サーバーモデルは、すています。ゲートウェイはサーバー環境内にあり、ゲートウェイからのべての通信がSDPホワイトリストポリシーによって明示的に許可

安全な接続は、サーバー上のアプリケーション/サービスの所有者の制されます。信頼できないネットワークを介したサーバー間の安御下にあり、所有者がこれらの接続を完全に制御できる場合があります。

全な通信を可能にし、軽量のSPAプロトコルを使用してサーバー保護されたサーバーは、”Deny-All”ファイアウォールとして動作するSPAで保護されているため、適切にホワイトリスト

をすべての不正接続から隠します。
このモデルは、前ページのクライアント→サーバーモデルに似ていますが、IH自体がサーバーであり、SDP AHとしても機能できるという違いがあります。クライアント→サーバーモデ
ルと同様に、サーバー→サーバーモデルは、各サーバーにSDPゲートウェイあるいは同様の軽量の技術をインストールする必要があり、すべてのサーバー→サーバートラフィックを、セキュ
リティエコシステムおよび攻撃者の他の要素から見えなくします。ネットワークベースのIDS/IPSは、SDP外部のパケット検査の代わりに、SDPゲートウェイからドロップされたパケットを取得する必要があります。さらに、組織はホストベースのIDS/IPSに登録された他のサーバーを除き到達不能です。攻撃者や不正ユーザー（内部、外部の両方）にはアクセスできず、インサイダーの脅威から最大限の保護を提供します。
このモデルでは、保護されたサーバーにゲートウェイまたは軽量SPAプロトコルメカニズムを実装する必要があります。保護されたサーバーへのインバウンド接続を許可するように、サーバーが存在するネットワークを構成する必要はありません。
これらのサーバーのゲートウェイは、SPAを使用して、内部および外部の不正接続を防止します。
また、IDS/IPSやSIEMなどの既存のネットワークセキュリティコンポーネントを簡単に使用できます。トラフィックは、SDP

システムに依存する場合があります。

ゲートウェイ/保護されたサーバーからのこれらのドロップされたパケットを分析することによって監視でき、クライアント/IH
Server-to-Server Modelとサーバー間のmTLS接続を保持します。
このモデルは、組織がIoTまたはVM環境をクラウドに移行した時のすべてのクラウド環境に適しています。サーバー環境のcontroller
environment

場所（クラウドまたはオンプレミス）に関係なく、組織はクラウド内の環境への接続を完全に制御できます。
1.

1.
2.

2.

serverenvironment

serverenvironment3.

図4：サーバー→サーバーモデル：API呼び出しやシス
テムサービスを含むすべての通信。
STEPS: 1. Registration // 2. Request // 3. Connection© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

17
クライアント→サーバー→クライアント

このモデルにより、IDS/IPSやSIEMなどのネットワークセキュリティコンポーネントを簡単に使用できます。SDPゲートウェ

場合によっては、ピアツーピアの関係になり、トラフィックが中間サ

イ/保護対象サーバーからドロップされたすべてのパケットを分

ーバーを通過する必要があるIP電話、チャット、ビデオ会議などのアプ

析して、クライアントと保護対象サーバー間のmTLS接続を保護

リケーションに使用できます。このような場合、SDPは接続クライアン

することで、トラフィックを監視できます。

トのIPアドレスを難読化し、コンポーネント間のネットワーク接続を暗このモデルは、組織がすべての環境のピアツーピアアプリ

号化し、サーバー/AHをSPAによる不正なネットワーク接続から保護しま

ケーションをクラウドに移行する場合に非常に適しています。

す。

サーバー環境がどこにあるか（クラウドまたはオンプレミス）にかかわらず、組織はクライアントへの接続を完全に制御できClient-to-Server-to-Client Modelます。

クライアント→ゲートウェイ→クライアント

controller
environment2.

2.

このモデルは上記のモデルの変化形です。このモデルには、SDP

clientenvironment

clientenvironmentのアクセスポリシーを適用しながら、クライアントが互いに直接接続することが必要となるピアツーピア・ネットワークプロ
トコルをサポートする利点があります。

1.

SDP client

SDP client
serverenvironment
3.

Client-to-Gateway-to-Client Model3.

controller
environment

図5：クライアント→サーバー→クライアントモデル：IP
電話やチャットなどのピアツーピアスタイルのサービスに使用されます。

2.

2.

STEPS: 1. Registration // 2. Request // 3. Connection

clientenvironment

clientenvironment

1.

SDPコントローラは、（コントローラとサーバーが同じSDP

SDP client

ゲートウェイを使用する）サーバー上あるいはクラウドに配置

SDP client

3.

3.

することができます。SDPコントローラはクラウドに常駐することもできます。上記のように、サーバーはAHとして機能するSDP
ゲートウェイの背後で保護されています。ゲートウェイを経由

STEPS: 1. Registration // 2. Request // 3. Connection

するサーバーへの安全な接続は、デフォルトではサーバー上のアプリケーション/サービスの所有者の管理下にあります。
保護されたサーバーは、他の適切なオンボードクライアン

図6：クライアント→ゲートウェイ→クライアントモデ
ル：クライアントからクライアントへの通信を保護するために使用されます。.

ト以外から到達不能で、ゲートウェイとコントローラが”DenyAll”ファイアウォールとしてのSPAで保護されています。従ってサーバーは到達不能なため、攻撃者や不正ユーザー（内部と外部の両方）にはアクセスできず、インサイダーの脅威からの保護が強化されます。
このモデルでは、保護されたサーバーにゲートウェイまたは軽量SPAプロトコルメカニズムを装備する必要があります。サーバーが存在するネットワークは、保護対象サーバーへのイン
バウンド接続に制限するように構成する必要はありません。サーバー上のゲートウェイ（実施ポイント）はSPA を利用して、これにより、クライアント間で論理的な接続が確立されます（それぞれがアプリケーションプロトコルに応じてIH、AH、
またはその両方として機能します）。アプリケーションプロト
コルによって、クライアント同士の接続方法が決まることに注意してください。SDPゲートウェイは、それらの間で一般的なファイアウォールの役割を担います。
このモデルの詳細については、今後の出版物で追加される予定です。

内部および外部の両方の無許可接続を防止します。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

18
ゲートウェイ→ゲートウェイ
ゲートウェイ→ゲートウェイモデルは、SDP Specification 1.0の最初の公開には含まれていませんでした。このモデルは、特定のIoT環境に適しています。このシナリオでは、1つ以上のサーバーがAHの背後にあり、AHがクライアントとサーバー間のゲートウェイとして機能します。同時に、IHがゲートウェイとしても機能するように、1つ以上のクライアントがIHの背後にあります。

Gateway-to-Gateway Modelcontroller
environment

1.

1.
2.

2.

client/server IH
environmentsclient/server AH
environments
3.

STEPS: 1. Registration // 2. Request // 3. Connection

図7：ゲートウェイ→ゲートウェイモデル：1つ以上のサーバ
ーまたはクライアントがゲートウェイの背後で保護されています
このモデルでは、クライアントデバイスはSDPクライアントソフト
ウェアを実行しません。実際に、プリンタ、スキャナ、センサー、IoT
デバイスなどでは、SDPクライアントをインストールすることが望まし
くないか不可能なデバイスタイプである可能性があります。このモデルでは、ゲートウェイはファイアウォールとして機能し、実装によってはルーターまたはプロキシーとして機能する可能性もあります。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

19
SDP配備モデルと関連するシナリオ
以下の表は、どの配備モデルがどのSDPシナリオを利用できるかを示しています。配備の種類ごとに、異なる接続を保護する必要があります。

ネットワークシナリオ

クライアン
ト →ゲー
トウェイ

クライア
ント→サ
ーバー

サーバー
→ サーバ
ー

クライアン
ト → サー
バー → クライアント

クライアン
ト → ゲー
トウェイ
→ クライ
アント

アイデンティティ主導のネットワークアクセス制御

Y

Y*

Y

Y

Y

ゲートウェ
イ →ゲートウェイ

Y**

すべてのSDPモデルは、アイデンティティ主導のネットワークアクセス制御をサポートしています。
* このモデルは、ネットワークおよびサービスへの安全な接続を提供します。
**SDPがデバイスをどこまで識別できるかは、デバイスの識別と検証を実行する方法に依存します。 たとえば、MACアドレスは802.1xに基づく実装よりも弱いID検証を提供します。
ネットワークマイクロセグメンテーション

Y*

Y **

Y ***

Y

Y

Y

すべてのSDPモデルは、個々の接続を保護することにより、ネットワークのマイクロセグメンテーションを提供します。
* このモデルは、クライアントとゲートウェイ間の接続を保護することでマイクロセグメンテーションを提供しますが、ゲートウェ
イの背後にあるサーバーへのマイクロセグメント接続は行いません。
**このモデルは、サーバーへのすべての接続を安全にすることによってネットワークマイクロセグメンテーションを提供します。
さらに、ゲートウェイをホストするサーバーを隠します。
***このモデルは、サーバーへのすべての接続を安全にすることによってネットワークマイクロセグメンテーションを提供します。さらに、ゲートウェイをホストするサーバーを隠します。
Y
Y
Y
Y
Y
Y
セキュアリモートアクセス（VPN代替）SDPモデルは、従来のVPNに代わるものです。すべての場合において、コントローラとゲートウェイ/AHは、リモートデバイスからアクセス可能である必要があり、SPAを使用して接続を開始できます。
サードパーティユーザーアクセス

Y

Y

Y*

Y

Y

Y

SDPは、保護が必要な接続に応じて、すべてのシナリオでサードパーティアクセスをサポートします。 サードパーティは、リモートまたはオンプレミスである可能性があり、また、認証を受ける別のIDプロバイダーを持っている場合があります。
* SDPは、これらのモデルの内部アプリケーションにアクセスするすべてのサードパーティアプリケーションからの接続を保護し、サード
パーティアプリケーションはクライアントとして機能します。
特権ユーザーアクセス保護

Y

Y

N

Y

Y

N

SDPは、クライアントからの接続に対する特権ユーザーアクセスを保護します。通常、特権ユーザーアクセスはサーバーにアクセスするクライアントを対象としています。しかし、アプリケーションによっては他のモデルも適用可能です。
価値の高いアプリケーションのアクセス保護

Y

Y

Y

Y

Y

N

ゲートウェイ→ゲートウェイモデルを除くすべてのモデルは、その特定のモデルによって保護された価値の高いアプリケーションに関連するすべての接続を保護します。.
マネージドサーバーへのセキュ
アアクセス

Y

Y*

Y

Y

N

Y

このシナリオは、マネージドサーバーへのサービスプロバイダーアクセス用です。 サーバーは、ゲートウェイによって非表示にできます。
* このモデルでは、SDPゲートウェイソフトウェアがサーバーに配備されます。サーバーが非表示になり、MSSP /マネージドサービスへのサービス接続の検出および制御を許可します。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

20

ネットワーク統合の単
純化

Y

Y*

Y*

Y

Y

Y

Y

Y

Y

Y

Y

Y

必要なセキュア接続のタイプに応じて、すべてのSDP配備モデルがこのシナリオをサポートします。
* これらのモデルの利点は、サーバー上のサービスをゲートウェイで非表示にできることです。
IaaSクラウド環境へのセキ
ュアな移行

Y

Y

Y

このシナリオには、オンプレミスからIaaS環境へのサービスの移行を含みます。
認証スキームの強化

Y

Y

Y*

すべてのSDPモデルは、多くの場合ユーザーの多要素/ステップアップ認証を介して、認証を強化する機能を提供します。
*ユーザーのいないこのモデルは、ワンタイムパスワードの入力を要求できませんが、PKIやサーバーベースのHSMの使用など、多要素認証をサポートできます。 アイデンティティ管理シ
ステムは、人だけでなく、システムやデバイスにも使用すべきです。
企業のコンプライアンスコ
ントロールとレポートの合
理化

Y

Y

Y

Y

Y

Y

すべてのSDPモデルは、コントロールを統合することにより、企業がコンプライアンスを合理化するのに役立ちます.
DDoS攻撃対策

Y

Y

Y

Y

Y

Y

すべてのSDPモデルはゲートウェイ内でSPAを利用するため、DDoS攻撃への対応力が向上します。“Deny-All”なゲートウェイを構成してない場合、インターネットに直接接続されたサービスは、内部でホストされているサービスと比較して、DDoSの影響を受けやすくな
ります。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

21

SDP接続セキュリティ
アーキテクチャとして、SDPはネットワークスタックのすべてのレイヤで安全に接続するためのプロトコルを提供します。図8は、各SDPの配備モデルによって保護されている接続について示しています。重要な場所にゲートウェイとコントローラを配置することで、実装者は最も重要な接続の保護に集中し、ネットワー
クベースおよびクロスドメイン攻撃から保護することができます。

Single-Packet Authorization (SPA)
SDP モ デ ル の 最 も 重 要 な 要 素 の 1 つ は 、 「 接 続 前 認 証（authenticate-before connect）」モデルを必要としている（実施している）ことです。これは、TCP / IPの根本的にオー
プンな（そして安全でない）性質を補うものです。 SDPは、
Single Packet Authorization（SPA）を通してこれを実現しています。SPAは、デバイスまたはユーザの身元を検証し、追加のアクセス制御を実施する関連するシステムコンポーネント（コントローラまたはゲートウェイ）へのネットワークアクセスを許可するだけの軽量プロトコルです。
要求者のIPアドレスを含むこのリクエストに関する情報は、単一のネットワークメッセージの中で暗号化および認証が行われます。SPAの目的は、デフォルトドロップのファイアウォールを通してサービスを見えなくすることができることです。そしてそのサービスへのアク
セスは、認証（そして暗黙の認可）が起こったときに一度だけ許可されます。SPA はSDP仕様の中核部分であり、クライアントからコントロ
ーラ、ゲートウェイからコントローラ、クライアントからゲートウェ
イのすべてで通信を開始するために使用されます。

図8：各展開モデルで保護された接続

SPAの実装方法は多少異なる場合がありますが、以下の共通の原則を共有する必要があります。:

SDPアーキテクチャを使用するアプリケーションは、SDPゲート

1.

SPAパケットは、暗号化されなければならないし、認証されなければならない。

2.

SPAパケットは、必要な情報をすべて1パケットの中に含めなければならない。パケットヘッダーは信頼できると考えてはいけません。

ウェイ/AHの背後に隠されているため、許可されたユーザーのみ
がアクセスできます。さらに、SDPコンポーネント自体（コントローラーとゲートウェイ）は、SPAによって保護されています。
これにより、インターネットに面した状況で安全に配備でき、

3.

SPAパケットは、生成および送信するために管理者またはルー
トレベルのアクセスに依存してはいけません。パケットそのものの操作はありません。

正当なユーザーが生産的で信頼性の高いアクセスを確保し、許4.

サーバーは、SPAパケットをできるだけ静かに受信して処理しなければならない。応答も検証も送信されません。

ファイアウォールのスタンスは、ポートスキャンおよび関連すスを見えなくするという重要な利点を提供します。”Deny-All”
る偵察技術を軽減します。このタイプのファイアウォールは、
SPAコンポーネントを許可されていないユーザーに見えなくし、SPAの利点

SDP全体の攻撃対象領域を大幅に削減します。SPAは、多くの実SPAはSDPで大きな役割を果たします。SDPの目標の1つは、TCP/IPの基
本的にオープンで安全でない特性を克服することです。これは、「接続してから認証する」モデルです。今日のサイバーセキュリティの脅威の状況を考えると、悪意のある攻撃者が企業のシステムをスキャンして接続することを許可することは受け入れられません。SPAとSDPの組み合わ
せは、2つの方法でこの脆弱性に対処します。

可されていないユーザーには見えなくなります。SPAは、サービ装でポートが開いているなどの既知の脆弱性があるVPNよりも多くのセキュリティを提供します。
別の利点は、ゼロデイからの保護です。認証されたユーザーのみが目的のサービスにアクセスできるので、新たに発見された脆弱性はそれほど問題ではありません。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

22

SDPとアクセス制御

もう1つの利点はDDoSからの保護です。もし、HTTPSサービスが攻

新しいアーキテクチャとしてのSDPの価値は、情報資産とネットワ

撃可能なパブリック・インターネットに公開されている場合、比較的少ークサービスを保護するために、ユーザーアクセス管理、ネットワ

量のトラフィックでHTTPSサービスをオフラインにすることができます。

ークアクセス制御、システム認証制御を実装するための標準を設定

SPAは、認証されたユーザーのみにそのサービスを見えるようにしていするアクセス制御管理を強化することです。SDPには、許可されてるので、DDoS攻撃は、保護されているサービス自体ではなく、デフォル

いないユーザーからのネットワークレベルのアクセス、あるい

トドロップのファイアウォールによって処理されます。

は、未検証のデバイスの使用を防止するアクセス制御を実施す
る機能があります。 SDPは”deny-all”ゲートウェイを配備するため、ネッ

SPAの制限トワークパケットがIHとAHの間を流れるのをブロックまたは許可または防止しま

SPAはSDPの一部にすぎず、それだけでは完全ではありません。SPAの実装

す。SDPを使用すると、組織は、少なくとも、どのアイデンティティがはリプレイ攻撃に対してレジリエントであるように設計されるべきです

ネットワークサービスおよびどの検証済みデバイスからのアクセスを許が、SPAは中間者攻撃（MITM）を受ける可能性があります。具体的には、可するかを決定するアクセスポリシーを定義および制御できます。

MITMの攻撃者がSPAパケットをキャプチャまたは変更できる場合、攻撃者

SDPは、既存のアイデンティティとアクセス管理のソリューショ
ンを置き換えようとしません。しかし、SDPはユーザー認証のみのアクセス制御を拡張します。SDPはユーザーの認証と認可を他のセキュリティコンポーネントと統合することで、攻撃対象領域
を大幅に縮小します（ページ8「中心となるSDP コンセプト」を参照）。例として、私たちのお気に入りのユーザーJaneは、会社の稼働中の財務管理サーバーにサインインするための資格情報を持っていないとします。もしそれがネットワーク上のJaneのデバイスから見える場合、それはリスクになります。Janeの会社がSDPアーキテ
クチャを実装している場合、財務管理サーバーはJaneのデバイスから隠されています。そのため、攻撃者がJaneのマシンに足場を築いたとしても、SDPはJaneのデバイスからJaneが資格情報を持たない財務管理サー
バーへの接続を拒否します。Janeが財務管理サーバーへのアクセスを許可する資格情報を持っていたとしても、SDPクライアントをデバイスにインストールすると、さらに保護が提供されます。攻撃者は多要素ユーザー認証と強力なデバイス検証を有効にして接続を確立するのは困難です。

は認可されたクライアントに代わってコントローラ/AHへのTCP接続を確立できる可能性があります。しかしながら、この攻撃者はクライアントの証明書を持っていないため、mTLS接続を行うことができません。そのため、コントローラ/ AHは、この接続の試行を拒否し、TCP接続を閉じます。
MITMシナリオにのみ適用されるこの制限を考慮しても、SPAは標準のTCPよりはるかに安全です。SPAの実装は、ベンダーによって若干異なる場合があります。オープンソースのSPA参照の実装は、Fwknopプロジェクト、あるいはは「FireWall KNock OPerator」で利用できます。SPAの詳細な技術情報については、38ページの「Appendix 2」を参照してください。その他の
優 れ た 参 考 資 料 は 、 Evan Gilman と Doug Barth に よ る Zero Trust
Networksの「Trusting the Traffic」の章です（O'Reilly Media、
Inc.、2017） 。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

23

補完的なアーキテクチャ
ゼロトラストとBeyondCorp
Software-Defined Perimeterに加えて、今日のセキュリティ環
境には2つの新しいアプローチがあります。最初は業界アナリス
ト会社Forresterによって推進された「ゼロトラスト」コンセプ
トと、Google社内の「BeyondCorp」イニシアチブです。

Forresterゼロトラストモデル
Forresterのゼロトラストモデルは、過去数年間で範囲が拡大し、主に次の3つの原則に基づいています:•

すべてのリソースが場所に関係なく安全にアクセスされるようにする•

すべてのトラフィックを記録して検査する•

最小特権の原則を実施する

GoogleのBeyondCorpモデル
BeyondCorpは、従業員が内部リソースにアクセスできるように設計されたGoogleの内部ネットワークおよびアクセスセキュリ

これらの原則は、SDPが提供するものと明確に整合が取れています。実際、
SDPアーキテクチャは、ゼロトラストの原則を実装する理想的な方法であると考えています。SDPはユーザーとデバイスを強力に認証し、ネットワ
ーク接続を暗号化するため、ユーザーの場所に関係なく、すべてのリソー
スに安全にアクセスできます。また、SDPは通常、既存のネットワーク全体にオーバーレイとして配備されるため、リソースの場所（オンプレミス、
クラウド、またはその他）に関係なく、すべてのリソースに安全にアクセスできることも保証します。ネットワーク接続はSDPによって制御される
ため、どのID（人間またはマシン）がどのリソースにアクセスしているかを記録するための効果的かつ一元化された場所を提供します。ディープパ
ケットインスペクションが必要な場合、SDPはネットワークトラフィックのインスペクションシステムと簡単に統合できます。最後に、おそらく最も重要なこととして、SDPは本質的かつ強力に最小権限の原則を実施します。SDPはデフォルトですべての通信を拒否するゲートウェイから始まり、
アクセスはホワイトリストアクセスモデルに厳密に従うため、IDはSDPコントロールによって明示的に許可されている場合にのみネットワークアプ
リケーション（およびSDPシステム自体）にアクセスできます。これが最小権限の原則の本質です。

ティプラットフォームであり、企業発行のChromebookを管理するためのデバイス検証に重点を置いています。Googleチームによって文書化されており、すべてのアカウントで過去5年間にわたってGoogleで成功した内部プロジェクトとなっています。
BeyondCorpは、いくつかの点でSDPアーキテクチャと異なります。BeyondCorpは、http、https、およびsshプロトコルをサポートするWebプロキシベースのソリューションですが、SDPは通常、より多くの（一部の実装ではすべての）IPプロトコルをサポートします。SDPは、BeyondCorpよりもきめの細かいアクセ
ス制御もサポートしています。BeyondCorpは、アプリケーショ
ンが割り当てられる少数の「信頼層」を持っています。SDPは、
ユーザーおよびデバイスのコンテキストにより、よりきめ細か
く個別化されたアクセス制御をサポートします。
GoogleのBeyondCorpは市販されていませんが、BeyondCorpプラッ
トフォームの一部の要素をマイクロサービスを保護するためのistio プ ラ ッ ト フ ォ ー ム に 含 め て い ま す 。 ま た 、 Google は 、
Google Cloud Platform（GCP）ベースのリソースへのアクセスを制御するためのIdentity-Aware Proxy（IAP）と呼ばれる無料のコンポーネントを開始しました。IAPはSDPではありません（完全なBeyondCorpでもありません）が、Googleが述べているように、「クラウドIAPはBeyondCorpの構成要素です」。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

24
ゼロトラストを検討する場合の結論として、アーキテクチャとしてSDPを評価する必要があります。BeyondCorpアプローチが望ましい場
合でも、SDPを評価する必要があります。SDPは同様のメリットをもたらし、すべての環境でアクセスを保護する複数の市販ソリューションがあるためです。
要約すると、アーキテクチャとしてのSDPは、ゼロトラストの原則の実装を確実に成功させることができます。BeyondCorpの実装においては、自社のBYOD戦略にSDPアーキテクチャを組み込み、推進してく必要があります。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

25

SDPとエンタープライズセキュリティアーキテクチャ
エンタープライズ情報セキュリティアーキテクチャは、組織全体に多数の利の重要な概念を備えているため、エンタープライズセキュリティアーキテク

SDPは、APIの統合を含む、アプリケーションのリリース/
DevOpsプロセスおよびツールセットにどのように影響しますか？

チャの基盤になります:

多くの組織がDevOpsやCI / CDなどの高速アプリケーションリリ

害関係者がいるため、複雑になる可能性があります。SDPは、基盤となるIP
インフラストラクチャに関係なく、安全な接続を保証します。SDPは、以下1.

接続を許可する前にユーザーを認証し、デバイスを検証する

ースプロセスを採用しています最小権限。これらのプロセス、

2.

双方向暗号化通信

ティシステムとの慎重な統合を必要とし、SDPも例外ではありま3.

deny-allファイウォールに基づいた動的制御およびサーバー隠蔽

せん。SDPは、DevOpsの中で非常に効果的に使用され、認可され4.

アプリケーションコンテキストときめ細かいアクセス制御の統合たユーザーが開発環境への接続を安全に行うことができます。

およびそれをサポートする自動化フレームワークは、セキュリ

SDPは、正当なユーザーから保護されたサーバーやアプリケーシ
このセクションでは、アーキテクトが企業にSDPを配備する計画を立て

ョンへの接続を保護するために運用中にも使用できます。

る際に考慮すべき多くの質問を示します。質問は、アーキテクトが利用

セキュリティアーキテクトは選択したSDP配備モデルを理解

数、ネットワーク、サーバー環境、セキュリティおよびコンプライアン

し、組織のDevOpsメカニズムがSDPと相互連携し統合する方法をス要件など、セキュリティのさまざまな側面を検討するのに役立ちます。

理解しなければなりません。API統合はDevOpsのツールセットとの統合が必要となることが多いため、セキュリティチームは、

SDPの配備は、既存のネットワークテクノロジにどのように適合しますか?

SDPの実装においてサポートされる一連のAPIを検討する必要があります。

アーキテクトは、どのSDP配備モデルを使用するかを決定する必ェイが追加のインラインネットワークコンポーネントになる可SDPは、ユーザー、特にビジネスユーザーにどのような影響を与えますか？

能性があることを理解してください。これは、保護されたサーセキュリティチームは、通常、ソリューションをユーザーに対バーを見えないようにし、SDPゲートウェイ経由でのみアクセス

してできるだけ透過的に機能させるように努めています。SDPは可能にするために、ファイアウォールやルーティングの変更を

これをサポートします。もし、最小権限の原則が達成されると、必要とするなど、ネットワークに影響を与える可能性がありま

ユーザーは必要なものすべてにフルアクセスできるようになり、す。

不要なアクセスが取り除かれたことに気付くことはありません。

要があります。また、いくつかのモデルにおいては、ゲートウ

SDP配備モデルに応じて、ユーザーは自分のデバイスでSDPクラ

SDPは、監視およびロギングシステムにどのように影響しますか？

イアントソフトウェアを実行します。セキュリティアーキテク

SDPはIHとAHの間でmTLSを使用するため、このネットワークトラ

トソフトウェアの配布、デバイスのオンボードプロセスのモデ

フィックは、セキュリティ、パフォーマンス、信頼性を監視す

ル化と計画を立てる必要があります。

トは、ITと協力して、ユーザーエクスペリエンス、クライアンる目的で配置されている可能性がある中間サービスに対して不透明になります。アーキテクトは、どのシステムが稼働してい
るのか、またネットワークトラフィックの変更がそれらにどのように影響するのかを理解する必要があります。反対に、SDPシ
ステムは通常、より豊富なアイデンティティ中心のユーザーア
クセスのログ記録を提供するため、既存の監視システムを強化するために使用されることがよくあります。さらに、SDPゲート
ウェイおよびコントローラでドロップされたパケットはすべて、より深く分析するためにSIEM に記録できます。誰が、いつ、何を、どこからという、すべての接続の情報を、SDPを用意することで簡単に収集できるようになります。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

26

エンタープライズ情報セキュ
リティ アーキテクチャ要素
下の図9は、エンタープライズセキュリティアーキテクチャの主な要素を示しています。この図は、ハイブリッドエンタープライズを単純化したもので、プロトタイプのセキュリティインフラストラク
チャの主要要素と要素間の論理的な関係を表しています。

Enterprise Security Architecture

VPN
client

VPN
Gateway

Bastion Firewall
Host

NGFW

IDS/IPS
SIEM
IAM
GRC
PKI

SaaS
& PaaS

WAF

Load
Balancers

CASB
NAC
DirectConnection

IaaS
Security GroupDMZ

図9：エンタープライズセキュリティアーキテクチャの主な要素
このエンタープライズセキュリティアーキテクチャの例では、オン
プレミスおよびクラウドベースのリソース（IaaSおよびSaaS/PaaS）
で構成され、セキュリティ、IT、コンプライアンスコンポーネントの標準セットを備えています。これらの標準コンポーネントとSDPの統合方法については、次のページ以降で詳しく説明します。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

EMM/MDM

SDP Working Group Software-Defined Perimeter Architecture Guide

27
Security Information and Event Management (SIEM)
SIEMシステムは、アプリケーションやネットワークコンポーネントから生成されたログ情報およびセキュリティ警告の分析を行います。SIEMは、ログの保存と解釈を一元化し、ほぼリアル
タイムの分析を可能にし、セキュリティ担当者がより迅速に防御措置を取ることを可能にします。SIEMシステムは、また、コ
ンプライアンス（規制、監査）に通常必要とされる自動化され一元化された報告を提供します。
SIEMシステムは、オンプレミスにでもクラウドにでもおかれ、ITおよびセキュリティ管理システムの主要な部分として設置されます。市販のSDPソリューションは、通常、内部でロギン
グ機能を提供していますが、SDPログが複数のソースからの情報を集約するエンタープライズSIEMシステムに送信されると、その価値はさらに高まります。企業システムは、分散されたSDPコンポーネントから直接フィードを受けたり、複数の収集エージ
ェントを階層的に配置したりすることがあります。SIEMは、SDP
用に事前定義およびカスタマイズされたイベントを集中管理コ
ンソールに転送するか、電子メールを介して指定された個人にアラートを送信することによって、検査を実行し、異常に対してフラグを立てます。

ーション監視ツールよりもはるかに豊富な情報をSIEMに提供します。
SDPは、リアルタイムに、誰が、何を、どこからという、あらゆる接続に関する情報を提供することができ、それによってSIEMシステムの有効性と価値を高めることができます。SIEMは現在ロギングに使用されており、アナリストは複数のログから情報をまとめる必要があり、許可されていないユーザーはもちろん、許可されていないデバイスがどこへ接続しようとしているかも識別します。SDPは、特定のユーザーが特定のデバイスから特定のサービスに接続した接続情報について、SIEMに明確な情報を提供します。SDPクライアントがユーザーのデバイス上にある場合は、そのデバイスからより具体的な情報も収集できます。SDPゲートウェイからは、ドロップされたすべてのパケットを分析のために保存します。これは、潜在的なハッキングだけでなく攻撃者による偵察などの分析になります。
このレベルの記録は、従来のファイアウォールによって生成されたIPアドレスとポートのリストよりも優れています。
これは、（たとえば）従来のファイアウォールによって生成されたIPアドレスとポートのリストよりもはるかに優れた情報です。SDPは、複数のデバイスで発生するユーザーアクティビティを簡単に関連付ける
SIEMの機能も強化します。SDPなしでは、特にBYODやモバイル機器の出現
により、これを達成することは困難であるかエラーが発生しやすくなります。
SIEMをSDPの配備と統合すると、セキュリティ操作を事後対応型から予防型に移行するという目標を達成することができます。リスクを制御するには、SDPログ情報を含めることに加えて、既存のSIEMも重要な情報

SIEM and SDP
Traditional security and IT
systems feed log data into
SIEM

SIEM

A

B

C

SDP controller orgateway

SDP systems can interact
with SIEM in multiple ways:
A. Feed enriched log data
into SIEM
B. Make calls into SIEM toobtain security or user
content
C. Receive calls from SIEM
to adjust security or user
content源と見なす必要があります。SIEMは、ユーザーの接続を切ったり、未検証のデバイスまたは特定のホストからの接続を拒否したり、疑わしい接続をドロップすることにより、リスクを制御するのに役立ちます。たとえば、SIEMが不正なユーザーアクティビティを示す通常よりも高いリス
クレベルを示した場合、SDPは、追加の分析を実行できるようになるまで、ユーザーからのすべての接続をドロップします。SDPは、接続のアドレ
ス指定と制御を数秒で行うことにより、SIEMを補完します。
ログ情報を生成するすべてのシステムと同様に、SDPログは企業にとってデータプライバシーの潜在的な懸念事項になります。ネットワーク接続（およびそのメタデータ）はログ内の特定のユーザーに関連付けられる可能性があるため、組織はこの問題に対処するた
めにSDPの配備中に予防策を講じる必要があります。
SDPは、さまざまな種類の攻撃を防止、検出、対応するためのSIEMシス
テムの機能を強化および向上させます。次のページに、軽減できる攻撃の種類の例をいくつか示します。（SDPとSIEMを統合することで防止さ

図10：SDPを用いたSIEM

れる攻撃の網羅的なリストは、将来のCSAの出版物で予定されていSDPはアイデンティティとデバイスを検証することで接続の観点か
らアクセスを制御するため、通常のネットワークまたはアプリケます）。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

28
攻撃の

軽減

SDPのSIEMへの統合の仕方

ポートスキャン/ネッ
トワーク偵察ブロックと通知

SDPは不正なネットワークアクティビティをすべてブロックし、SIEM内で使用するためにすべての接続要求をログに記録できます。

DoS攻撃

ブロックと通知SDPシステムはSPAによって保護されているため、DoS攻撃はほとんど効果がありません。SPAは、不良パケットをドロップします。これはSIEMに記録できます。

検出と対応

認可されたリソースへの認可されたユーザーのアクセスは、
SDPによって許可されますが、SIEMは異常な行動についてユーザーのアクティビティを分析できます。また、SDPは更なる分析が行われるまでこの許可されたユーザーによるアクセスを許可しません。

ブロックと通知

通常、SDPは、デバイスの検証やオンボーディング（訳注： 新規デバイ
スが有線/無線のネットワークに初めてアクセスできるようにするプロセスのこと）など、接続前に複数の要素が必要です。これにより、盗まれたパスワードは攻撃者がアクセスするのに不十分になります。

種類認可されたリソースの悪用

盗まれたクレデンシャルの使用

従来のファイアウォール
従来のファイアウォールは、一連の規則に従ってネットワーク

ファイアウォールを利用する（あるいは同等のネットワークトラフ

トラフィックを監視および制御します。これらは、OSI（Openィック実施機能を実装する）SDPは、今日の企業のファイアウォールの使

Systems Interconnection）モデルのレイヤ2から4（データリン

用方法を大幅に改善します（そしてある意味では誤用を招きます）。SDP

クレイヤ、ネットワークレイヤ、トランスポートレイヤ）の情は、今日組織がファイアウォールを使用しようとしているネットワークア

報を使用してネットワークパケットデータをフィルタリングしクセス制御の実施の大部分を引き受けるでしょう。SDPを使用すると、企ます。従来のファイアウォールは、5タプルで表現された単純な業はファイアウォールのルールセットを大幅に減らすことができます。5

ルールモデルをサポートしています。ファイアウォールは、ネット

タプルの制約内でアイデンティティ中心のアクセス制御をモデル化するこ

ワークアドレス変換（NAT）やポートアドレス変換（PAT）などの機能もとを試みる代わりに、SDPはそれらをSDPアクセス制御としてはるかに正確サポートする場合がありますが、ここでは直接関係ありません。

に表現し実施することを可能にします。これにより、複雑な環境でのファファイアウォールは何十年もの間、エンタープライズネットワー

イアウォールルールの作成、テスト、デバッグ、配備に必要な作業が軽減

クセキュリティの主力でしたが、5タプルの限られた世界の中でのみ動されるだけでなく、はるかに正確で豊富なアクセス制御メカニズムも可能

作しているため、多くの制限があります。特に、アイデンティティ情報になります。

に基づいてルールを表現する（または実施する）ことができず、通常は静的なルールセットを表現することができるだけです。したがって、セキュリティインフラストラクチャの一部にすぎません。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

29

Traditional Firewall Setup

Application A
FirewallDatabase
Server B

Ofﬁce LAN
192.168.0.0/18

Hypervisor

Data Center
10.1.0.0/16

図11：従来のファイアウォール設定
上の図11は, ユーザーサブネット（192.168.100.0/24）からローカ

SDPのクライアント→ゲートウェイモデルの簡略版を示す以下の図と比ルデータセンターサブネットへのアクセスを制御するために、単一較してください（わかりやすくするためにコントローラを省略していまのファイアウォールを使用する従来のオフィスLAN環境を示していす）。従来のファイアウォール設定と、下の図12を比較してくださます。この図は単純ですが、静的なファイアウォールルールを使用

い。図12は、SDPのクライアント→ゲートウェイモデルの簡略バー

してこのアクセスを保護しようとすることの難しさを示しています。

ジョンを示しています（わかりやすくするためにコントローラを省

ファイアウォールはオフィスネットワーク上のユーザーを区別できま

略しています）。他のSDP配備モデルにも同様に適用されることにせん。IPアドレスのみ表示されるからです。さらに、多くのユーザーが、定期的に接続および切断するラップトップを使用しているため、ユーザーのIP

注意してください。
この例では、ネットワークファイアウォールは、ファイアウォー
ル機能を実行するSDPゲートウェイに置き換えられています。SDPはアイ

アドレスは頻繁に変更します。
一般的なデータセンターネットワークには、テストシステムと本番シ

デンティティと使用しているデバイスに基づいてアクセスを制御するた

ステムの両方を含むさまざまなワークロードがあります。アプリケーション

め、組織はデータセンターに対してきめ細かいアクセス制御を適用できの中には長寿命で静的IPアドレスを持つものもありますが、別のアプリケーます。大規模な攻撃対象となるオープンでフラットなネットワークは最ションでは定期的に作成および破棄される（したがって予測不可能なIPアド

小限に抑えられています。データセンター内のサーバーの近くまたは上レスを持つ）仮想マシン上に構築されます。個々のユーザーがデータセンタにSDPゲートウェイを追加することで、特定のサービスへのよりきめ細ー内のすべてのサーバー（およびそれらのサーバー上のすべてのポート）に

かいアクセスを実現できます。（上記のクライアント→サーバーモデ

アクセスする必要はありませんが、この環境では、実質的にファイアウォー

ルを参照）

ルにオフィスLANのすべてのIPアドレスからデータセンターネットワーク内のすべてのIPアドレスへのアクセスを許可するルールセットを設定します。

Improved Security via SDP Client-to-Gateway ModelC

Application A

CG

Ofﬁce LAN
192.168.0.0/18

Database
Server B

Hypervisor

Data Center
10.1.0.0/16

図12:SDPクライアント→ゲートウェイモデルを使用して改善されたセキュリティ© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide30
侵入検知/防止システム (IDS/IPS)

仮想プライベートネットワーク（VPN）

侵入検知および侵入防止システム（IDS/IPS） - ここでは同義

VPNは、信頼できないネットワーク間で安全なプライベートネッ

的に扱います - 悪意のある活動やポリシー違反についてネット

トワーク接続を確立するために使用されます。VPNは、安全なリワークやシステムを監視するセキュリティコンポーネントです。

モートアクセス（従業員から企業サイトへ）、安全なサイト間

これらは、ネットワーク型（トラフィックの検査）あるいはホ通信（サイト間）、または異なる企業間（サイト間エクストラ

スト型（アクティビティおよび潜在的にネットワークトラフィネット）でさえも一般的に使用されています。VPNは一般にTLS

ックの検査）があります。SDPはIDS/IPSシステムの導入にプラ

またはIPSecを使用しますが、他の種類も存在します。

スの影響を与える可能性がありますが、コスト削減のために

VPNはネットワークトラフィックのカプセル化と暗号化を提供

IDS/IPSの必要性を排除しても、ネットワーク型のIDSの変更やしますが、SDPによって解決されるいくつかの制限もあります。SDP

小規模な運用（つまり単一ネットワークのリモートオフィス）の展開にはIDSシステムの変更が必要になる場合がありますが、許には必要です。

可されていないネットワークトラフィックをすべてブロックするこ

さらに、SDPはクライアントとゲートウェイ間で双方向TLSとにより、システムのノイズを削減するという利点をもたらします。

（mutual TLS）暗号化を使用するため、ネットワークトラフィ

この移行により、IDSとそれを運用しているチームは、許可された

ックはTLSインスペクションに基づくネットワークベースのIDS

アプリケーションへのネットワークトラフィックに集中し、内部のでは見えなくなります。IDSは通常、証明書をインポートして脅威の検出にリソースを移行できます。第一に、VPNは一般に広く、TLSトラフィックのプロキシーになります。（これは攻撃対象を過度に寛容なネットワークアクセスを提供します。VPNは通常、基本的増大させる副作用があります）/これは双方向TLSに基づいておなアクセス制御制限のみを提供します（たとえば、サブネット範囲に基り（通常は一時証明書を使用）、したがってIDSが果たすMITMのづく）。これは多くの組織におけるセキュリティとコンプライアンスの役割に耐性があるため、一般にSDPでは不可能です。

リスクを表します。第二に、分散環境では、VPNは企業のデータセンタ

これらの論理接続のmTLSセグメント（紫色で表示）は、外部のシステーを介してユーザートラフィックの不要なバックホールを必要とし、待ムには不透明です。これらはSDPの資格情報を使用して暗号化されているたち時間と帯域幅のコストを追加する可能性があります。第三に、VPNサ

め、このトラフィックを分析しようとするシステムにはアクセスできません。

ーバー自体は、定義上、インターネット上のサービスとして公開されてある意味では、この変更はTLS 1.2から1.3への移行と同様に、中間のセキュいます。VPNサーバーにはセキュリティの脆弱性が存在することがあり

リティやネットワーク監視システムに影響を与えることになります。ペーます。これは攻撃者によって悪用される可能性があります。

ジ 21、SDP接続セキュリティを参照.)

さらに、VPNはユーザーにかなりの負担をかけ、弱いユーザ

SDPの展開にはIDSシステムの変更が必要になる場合があり

ーエクスペリエンスをもたらします。ユーザーは、どのアプリ

ますが、許可されていないネットワークトラフィックをすべてケーションがVPNの使用を必要としているか（およびどのアプリ

ブロックすることにより、システムのノイズを削減するというケーションがそうしていないか）を覚えており、手動で接続お利点をもたらします。この移行により、IDSとそれを運用していよび切断する必要があります。複数の遠隔地にアクセスする必るチームは、許可されたアプリケーションへのネットワークト

要があるユーザーの場合、VPNでは、両方の場所に同時に接続でラフィックに集中し、内部の脅威の検出にリソースを移行でききないため、環境間での切り替えが必要になります。クラウドのます。

移行が行われるたびに、VPN管理は複雑になり、IT管理者は複数の場所にまさらに、SDPは「ハニーポット」システムの作成と有効性を単純たがってVPNおよびファイアウォールポリシーを設定および同期することに化し、強化することができます。保護されたシステムは攻撃者にはなります。これにより、不当なアクセスを排除することがさらに困難になり見えないため、悪意のある行為者がハニーポットを見つけて攻撃すます。

る可能性が高くなります。これは、承認されたユーザーまたは承認

VPNは明らかにSDPによる置き換えの主なターゲットです。VPNと同様に、されていないユーザーにとって目に見えるシステムの割合が高いた

SDPもユーザーのデバイスにクライアントをインストールする必要がありまめです。これにより、ネットワーク上の悪意のあるアクティビティ

す。VPNの代わりにSDPを使用することで、組織は、リモートユーザーとオンをより迅速に検出できます。

プレミスユーザーの両方、およびモバイルデバイスユーザーにとって一貫性のある単一のアクセス制御プラットフォームを持つことができます。そして、
特にインターネットにさらされている環境においてSDPはSPAとダイナミック
なファイアウォールを使用してゼロ可視性を提供し、一般的なVPNサーバー
よりも攻撃にかなり弾力性があります。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

31

次世代ファイアウォール (NGFW)
一般に、次世代ファイアウォールは上記の伝統的なファイアウ
ォールの特性と利点を持ち、追加の機能が含まれています（それが「次世代」なるものです）。特に、事前定義された規則に

SDPは配備されたNGFWを自然に補完するものです - 企業はセキュアなユーザーアクセスポリシーのためにSDPを使用することができますが、コアのファイアウォール機能、IDS/IPSおよび
トラフィック検査にNGFWを使用することができます。SDPをNGFWと統合することの利点は、可視性をゼロにし、それらをより動従ってアクセスを監視し、ネットワークパケットを検査し、OSI的にすることです（このセクションの後半で説明します）。ユ（ Open Systems Interconnection model ） の 第 2 層 か ら 第 4 層

ーザーアクセスポリシーは、NGFWをIAMまたはADと統合すること（データリンク層、ネットワーク層、トランスポート層）の情によって実現できます。しかし、真の安全な接続とそれらの制報を使用してデータをフィルタリングします。さらに、第5層か御を得るためには、SDPを使用してください。

ら第7層（セッション層、プレゼンテーション層、およびアプリ
ケーション層）の情報を使用して追加機能を実行します。
ベンダーに応じて、以下の機能の一部または全部を提供する可能ある意味で、NGFWアーキテクチャはSDPと競合し（そしてオーバーラップします）、これがここで議論するポイントです。
過去10年ほどで、NGFWベンダーは市場で大成功を収めており、SDPと同じ問題のいくつかを革新し、解決しようとしてきました。

性があります:具体的には、NGFWとVPN機能とユーザーおよびアプリケーション•

アプリケーション認識 - アプリケーションを認識して、どの攻撃を探すべきかを判断します。

•

侵入検知システム（IDS） - ネットワークのセキュリ
ティステータスを監視します。

•

侵入防止システム（IPS）：セキュリティ問題を防ぐためにトラフィックを拒否します。

許可された接続の制御が容易です。NGFWは、限られたアイデン•

アイデンティティ認識（ユーザおよびグループ制御）- ユーザーがアクセスできるリソースを制御します。

ます。それらのアクセスポリシーモデルは通常粗粒度であり、•Virtual Private Network（VPN;バーチャルプライベー
トネットワーク） - NGFWは、信頼できないネットワー
クを介したリモートユーザアクセスに対してこの機能を提供することがあります。

に提供します。それらはSDP よりもはるかに動的ではない傾向

NGFWは、従来のファイアウォールや、個別のセキュリティデバイの認識を組み合わせることで、企業はある程度までSDPの目標の多くを達成できます。ただし、ここで説明する一般的なアーキ
テクチャ上の違いがいくつかあります。 NGFWシステムはIPベースであるのに対し、SDPはコネクションごとの制御であるため、ティティとアプリケーション中心の機能を提供する傾向があり厳密に必要なものよりも広いネットワークアクセスをユーザーがあります。SDPは多くの場合、外部システムをアクセス決定に含める機能をサポートしています。たとえば、承認された変更
管理ウィンドウ中にのみ開発者がステージングサーバーにアクセスすることを許可します。SDPシステムは、ステップアップ認ス/アプライアンスの調整に比べて大幅に改善されていますが、まだ制証を実施することもできます。これは通常、NGFWではサポート

限があります:されていません。

•

他のIDS / IPSと同様に、特にファイル検査を実行している場合は、ネットワークトラフィックにレイテンシが増加します。

••

NGFWは依然としてファイアウォールであり、ロケーション
間のサイト間接続を伴う従来の境界中心のネットワークアーキ
テクチャを義務付けていることがよくあります。SDP配備は通常、より分散された柔軟なネットワークをサポートし、それによっスケーラビリティの問題 - 規模を拡大するためにはて柔軟なネットワークセグメンテーション機能を可能にします。

かなり充実したハードウェアが必要になる場合があり

SDPは基本的に「知る必要性」（ホワイトリスト）セキュリティモデル

ます。

に基づいています。これは、設計上、すべての不正なサービスをユーザ

ルールの複雑さ - 一部のNGFWベンダーは、ユーザー

ーから隠し、SPA と動的ファイアウォールを利用してSDPで保護されたやグループの属性など、IDに関する機能を備えていま

接続を隠します。NGFWは単純にこのように設計されていないため、通常すが、逸話的にこれらは実装が複雑になる傾向があり

はSDPよりも目に見える（したがってリスクが高い）環境になります。

ます。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

32
アイデンティティとアクセス管理(IAM)

IAMはSDP内でユーザーを認証し、SDPが承認の決定を下すために使用する情報を提供し、登録済みデバイスからユーザーに付与さアイデンティティおよびアクセス管理（IAM）システムは、（認れたすべてのアクセスに対して強化された監査ログを有効にするた証を介して）自分のアイデンティティを検証し、それらのアイ

めに使用されます。（ネットワークアクセスではなく）アプリケー

デンティティに関する管理された属性とグループメンバーシッ

ションアクセスを（IPアドレスではなく）ユーザーに結び付けると、プを保存するためのメカニズムをユーザーとデバイスに提供しログ記録に役立つ接続情報が得られ、セキュリティ上またはコンプます。SDP アーキテクチャは、ユーザー認証およびユーザー属

ライアンス上の理由から過去のアクセスを監査する際のITオーバー

性の取得のために、LDAP、Active Directory、SAMLなどの既存のエンタープライズIAMプロバイダーと統合するように設計されています。

ヘッドが大幅に削減されます。
IAMツールは通常、IDライフサイクルを維持するビジネスプロセスに重点を置き、リソースへのアクセスを制御するためにID情報を使用する方法を標準化します。たとえば、アクセスのためのユーザーの「プロSDPは、通常、接続を確立するために使用されているデバイスの属性とビジョニング」のメカニズム。通常は手動プロセスと自動プロセスを組

ともに、IAM属性やグループメンバーシップなどの要素に基づいてアクみ合わせたものです。SDPはIAMによって管理されるID属性とグルセスを制御します。ユーザーとデバイスの承認基準を組み合わせることープメンバーシップに依存するため、SDPはこれらのIAMプロセ

で、アクセスを許可または制限するためのきめ細かいアクセス規則を作

スをサポートします。ユーザー属性またはグループメンバーシ

成し、登録済みデバイス上のユーザーからの承認されたアクセスのみをップが変わると、SDPはこれを自動的に検出し、IAMプロセスを許可されたアプリケーションに認めます。

変更せずにユーザーアクセスを変更します。

SDPとIAMの統合は、初期ユーザー認証に使用されるだけでなく、OTPから機密システムへのアクセスを要求するなどのステップアップ認証や、特定の状況下（リモートアクセスとオンプレミスなど）にも使用されます。 IAMシステムは、アカウントの無効化、グループメンバーシップの変更、ユーザーからの接続の切断、ユーザーロールの変更などのIDライフサイクルアクションに応答して、API呼び出しを介してSDPと通信することもできます。

SDPはSAMLと統合します。SDP配備の中では、SAMLプロバイ
ダーはユーザー属性のためのアイデンティティプロバイダーとして、そして/または認証プロバイダーとして（例えばMFAのために）機能するかもしれません。
SAML に 加 え て 、 OAuth 、 OpenID Connect 、 W3C Web 認 証（WebAuthn）などの多くのオープン認証プロトコルがあります。
また、FIDOアライアンスのClient-to-Authenticatorプロトコル（CTAP）は、今後のSDP関連の研究で検討される予定です。しかしながら、これらの調査はこの研究文書の範囲には含まれていません。

ネットワークアクセス制御（NAC）ソリューションネットワークアクセス制御（NAC）は通常、どのデバイスがネッ
トワークに接続できるかを制御し、どのネットワークサブジェ
クトにアクセスできるかを管理します。これらのソリューショ
ンは、ネットワークへのアクセスを許可する前に、標準的なハードウェア（802.1X）とソフトウェアを使用してデバイスを検証するのが最も一般的で、OSI モデルのレイヤ2で動作します。
デバイスが最初にネットワークに表示されたときに、NACはデバイ
ス検証を実行してから、デバイスをネットワークセグメント（VLAN）に割り当てます。実際には、NACは少数のネットワークにデバイスを非常に大まかに割り当てるために使用されます。ほとんどの組織には、Guest、Employee、Productionなどの少数のネットワークしかありません。NACはネットワークのレイヤ2で動作するため、特定のネットワーク
機器を必要とし、クラウド環境では動作せず、リモートユーザーが使用することはできません。
© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

33
SDPは、デバイスアクセスと組み合わせてユーザーを統合するための

通常、IDS / IPSのようにユーザーとアプリケーションの間

NACに対する最新のソリューションです。ただし、NACの使用に意味がある環でネットワーク内でインラインで動作しています。一般に、こ境には、プリンタ/コピー機、ハードフォン、防犯カメラなどのハードウェ

れらは悪意のあるコンテンツを検出してブロックするためにアデバイスがあります。これらのデバイスには802.1Xサポートが組み込まれHTTP（S）プロトコルトラフィックを調べるためだけに設計されていることが多く、通常はSDPクライアントのインストールをサポートしてています。WAFはSDPを補完するものです。たとえば、クライアいません。これらのデバイスを保護し、それらへのユーザーアクセスを制御

ント→ゲートウェイモデルでは、WAFはSDPゲートウェイの背後するためのゲートウェイ間モデルは、より優れた選択肢であり、今後のSDPに配備され、SDP mTLSトンネルから抽出された後、ネイティブ調査のトピックとなります。

Webアプリケーショントラフィックを処理します。クライアント→サーバーモデルまたはサーバー→サーバーモデルでは、HTTP（S）

エンドポイント管理 (EMM/MDM/UEM)

トラフィック検査をより分散的に制御するために、WAFがサーバ
ー上のSDPゲートウェイと統合されています。このトピックに関多くの企業では、エンタープライズモビリティ管理（EMM）、モする今後の研究が計画されています。

バイルデバイス管理（MDM）、または統合エンドポイント管理(UEM)として分類されることが多いエンドポイント管理システム

ロードバランサを利用しています。これらはエンタープライズITとセキュリテ
ィの重要な要素であり、それらの価値と重要性はSDPの配備によロードバランサは、多くの企業のネットワークおよびアプリケって強化されます。

ーションアーキテクチャの一部であるため、SDP配備において検まず、これらの管理システムを使用して、ユーザーデバイス間でのSDPクライアントの配布とインストールを自動化できます。
これらのシステムはSDPと同じIAMシステムを使用することが多
いため、これらの配備はユーザーエクスペリエンスを簡素化するために密接に調整することができます。そして第二に、これ討する必要があります。DNSやネットワークベースのソリューシ
ョンを含むさまざまな種類のロードバランサがあり、設計者は、組織がそれらをどのように利用しているか、およびSDP配備が及ぼす可能性のある影響について明確に理解する必要があります。
例えば、ネットワークベースのロードバランサは通常、クらの管理システムはしばしばデバイスの内観とプロファイル評

ライアントとサーバーの間のネットワーク上にインラインで配価に関して機能的に豊富な機能を提供します。SDPは、特定のユ備され、上述のWAFの説明と同様に、SDPコンポーネント間のーザーデバイスに関する情報を取得するためにデバイス管理プ

mTLS接続を検査できない場合があります。SDP配備とロードバラ

ラットフォームにAPI呼び出しを行い、この情報に基づいて動的

ンサのアプローチの詳細は、最大限の利益を得るためにSDPを配なアクセス決定を行うことができます。一般に、SDPはエンドポ

備できることを保証するために慎重な分析を必要とします。こイント管理システムの価値と到達範囲を高めることができます。

のトピックに関する将来のSDP研究が計画されています。

あるいは、エンドポイント管理システムを持たない組織は、
SDPによって提供されるデバイスの管理と制御を利用できます。

Webアプリケーションファイアウォール (WAF)
Webアプリケーションファイアウォール（WAF）は、Webアプリケーションとの間のWeb（HTTP（S））トラフィックをフィルタリ
ング、監視、およびブロックするように設計されています。WAF
は、SQL インジェクション、クロスサイトスクリプティング

Cloud Access Security Brokers (CASB)
CASBはクラウドサービスユーザーとクラウドアプリケーションの間に位置し、セキュリティポリシーの実施を含むすべてのア
クティビティを監視します。CASBは、ユーザーの行動の監視、潜在的に危険な行動に関する管理者への警告、セキュリティポ
リシーの遵守の実施、マルウェアの自動防止など、さまざまなサービスを提供できます。CASBは、ユーザーとクラウドサービ
スの間にインラインで配備するか、ベンダーによる実装とSaaS（XSS）、ファイルインクルード、セキュリティの誤設定など、

プラットフォーム内のAPIサポートのレベルに応じて、SaaS API

Webアプリケーションのセキュリティ上の欠陥による攻撃を防ぐを利用してSaaSシステムの「内部」に配備することができます。

ために、アプリケーションプロトコルトラフィックを分析しま

CASBの機能は通常SDPの機能と重複しませんが、SDPを使用することで、す。WAFはネットワークアクセス制御やネットワーク

データ保護やユーザーの行動分析のためにアプリケーショントラフィックを

セキュリティソリューションではありません。

内観するレイヤ7（アプリケーション層）で動作するため、操作が簡単になります。CASBは、一般的にネットワークセキュリティやアクセス制御機能を提供していないので、SDPを含めることでそれらの製品を強化することができます。詳細についてはSDPとSaaSに関する次のセクションを参照してくだ
さい。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

34
Infrastructure as a Service (IaaS)

Platform as a Service (PaaS)

IaaSのセキュリティは、責任共有モデルに基づいて構築されます。
そこでは、クラウドプロバイダは一定の責任（クラウドのセキュリティ）を持ち、利用者はアプリケーションのセキュリティ（クラウド内のセキュリティ）に対して責任があります。IaaSの利用
者は、ネットワークセキュリティグループを利用して、クラウド
リソースへのアクセスを制御します。これらのネットワークセキュリティグループは、基本的なファイアウォールを構成し動作します。このように、ネットワークセキュリティグループはSDPによって効果的に利用することができます。
追加情報については、”SDP for IaaS research document”を参照してください。

Platform-as-a-Serviceによって、企業は標準的なハードウェア
やIaaSベースのシステムよりも少ないオーバーヘッドで、カス
タムアプリケーションを構築および配備できます。IaaSおよびSaaS（どちらも上記）とは異なり、PaaSシステムへのネットワ
ークアクセス制御（したがってSDPの関連する度合）は、提供される機能の種類、およびPaaSプロバイダが外部アクセス制御を有効にした方法によって異なります。
ただし、主要なPaaSプロバイダーは、IaaSと同じネットワークセキュリティモデルをPaaSプラットフォームに対してもサポートしています。たとえば、Microsoft Azure PaaSセキュリ

Software as a Service (SaaS)

ティモデル、Google Cloud Platform App EngineやAWS Elastic
Beanstalkと同様に、Azureネットワークセキュリティグループ

Salesforce.comやOffice 365などのSaaSアプリケーションは、によるソースIPアドレスの制限をサポートしています。PaaSア

マルチテナントであり、インターネット上で一般公開されていプリケーションがどのようなものであり、どの接続を保護するます。したがって、権限のないユーザーによるネットワークレのが最善かに応じて、さまざまなSDPモデルを配備できます。

ベルのアクセスを防止することは、現時点では難しいです。代わりに、組織は以下の理由でSaaSアプリケーションでSDPを使用することができます：•

許可されたデバイス上の許可されたユーザーのみが、その特定の組織のテナントがSaaSにアクセスできるよ
うにします。

•••

ガバナンス、リスク、およびコンプ
ライアンス（GRC）
ガバナンス、リスク、コンプライアンスの原理は、企業全体の企業セキュリティフレームワークの一部 であることが多く 36「組織が確実に目的を達成し、不確実性に対処し、誠実に行動

管理対象の企業IAM認証情報が、SaaSアプリケーショ

することを保証するのに役立ちます」。GRCシステムは、ITを含ンへの認証に使用されるようにします。

む多くの組織システムの周りで統制を定義し実施するのを助け、SaaSアプリケーションにアクセスするための多要素認証を実施し通常は標準やガイドライン（例：SOX、PCIなど）の順守を確実

ます。

にします。

SaaSアプリケーションへのすべてのユーザーアクセス
がログに記録され追跡されるようにします。

SDPは、GRCに必要なアクセス制御を実施および文書化することによって、GRCシステムと対話してGRCシステムをサポートできます。たとえば、GRCシステムでは、本番システムを非本番システムから分離し、稼働システムへのすべてのユーザーアク

増え続けるSaaSプロバイダーは、自社の利用者がこれらの利点

セスをログに記録することが必要になる場合があります。SDPはを望んでいることを認識しており、これをサポートするための「ソこのネットワークセグメンテーションを実施し、GRCシステムにースIPアドレスとデバイス制限」機能を追加しています。

監査ログを提供してこの制御が適切に機能していることを検証

この機能は、SDPまたは従来のVPNのどちらでも同じように機能し、SaaSの利用者が自分のドメイン（テナント）に対するユーザーできます。このトピックに関するさらなる研究が計画されています。

アクセス（ログインと使用）を制限できるため、その利用者のテナントに対するすべてのアクセスは特定のIPアドレスから開始されます。SDPでは、そのソースIPは、ユーザートラフィックがルーティングされ、不正な接続が拒否されるシステム（SDPゲートウェイなど）の要素になります。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide35
この場合、これらのやり取りは公開されるように設計されているため、Public Key Infrastructure (PKI)

SDPモデルは適用されません。

公開鍵基盤（PKI）は、デジタル証明書を作成、管理、配布、使ただし、他のサービス（または他のクラウドプロバイダ）は、用、保存、失効させ、暗号化、復号化、ハッシュ、署名に使用

各利用者が“as a service”機能用の独自の専用アクセスポイ

される秘密鍵と公開鍵を管理するために必要なロール、ポリシントを持つという異なるセキュリティモデルを選択する場合がー、手順のセットです。SDPは、TLS証明書の生成と安全な接続のたあります。このモデルでは、SDPはこれらの接続を制御するため

めにPKIを使うこともできます。PKIインフラストラクチャが存在しないに使用されるSDPゲートウェイによって保護されたプライベート

場合、SDPは安全な接続に使用するためのTLS証明書を提供できます。

アクセスポイントに適用できます。

既存のPKIは、SDP証明書の生成およびオプションでユーザー認証に使用できるため、SDPに自然に統合が可能です。

Software-Defined Networking (SDN)
SDNは、ITネットワークインフラストラクチャのAPI駆動型オーケストレーションであり、ITネットワーク内のネットワークル

アーキテクチャ上の考慮事項
ネットワークアクセスシナリオを十分広くカバーしていますが、SDPはすべてのセキュリティ問題を解決することを意図していません。一部の除外領域として以下があります:•

パブリックネットワークサービス（認証を必要としないーティングのオーケストレーションを可能にするために使用さウエブサイトなど）へのアクセスを保護または制御 –れます。ネットワーク管理を容易にし、ネットワークのパフォ

SDPはメンバーシップを基本としたサービスに、より適ーマンスと監視を改善するためにプログラム的で効率的なネッしています

トワーク構成を可能にします。SDNはネットワークトラフィックの効率的なフローに焦点を当てており、現在は、認証または認可を含む接続のセキュリティには対応していません。適切に運•

エンドポイントプロテクション•

サーバレスコンピューティングのような特定のコンピュー
ティングモデル

用されているSDNシステムは、信頼性が高く効率的で適応性のあるネットワーク帯域幅の提供を企業に提供します。
SDPは、基盤となるネットワークインフラストラクチャに関係なく、ネットワーク上のオブジェクト間の接続のオーケストレーションを提供•

SDP配備モデルに応じた、ピアツーピアなどの特定のネットワーク接続トポロジ (ページ19、SDP配備モデルと関連シナリオを参照)

します。SDPは、SDNの配備による恩恵を受けるように統合できますが、必須ではありません。たとえば、SDPとSDNコントローラの統合や、SDNが不透明で暗号化されたmTLS接続にネットワークQoSを提供する機能など、いくつかの興味深い統合ポイントがあります。この分野におけるさらなる研究が計画されています。

サーバーレスコンピューティングモデル
コンピューティングモデルが進化するにつれて、セキュリティ
ツールとアーキテクチャもそれらと共に進化する必要があります。そのような進化の1つは、いわゆる「サーバーレス」コンピューティングモデルです41。ここでは、クラウドプロバイダは、カスタムコード（“function as a service”モデル）、または事前に構築されたコードセット（「サーバーレスデータベース」など）のいずれかを実行する機能を提供します。
“function as a service”モデルは、インターネット全体に共通のパブリックエンドポイントを公開し、認証と認可を制御するためにAPIキーを使用することがあります。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

36

結論
情報セキュリティは今日の企業や政府機関にとって重大な課題
であり、組織のデータ資産を保護するためにより効果的なアプ
ロ ー チ を 採 用 す る 必 要 が あ り ま す 。 Software Defined
Perimeterアプローチは、堅牢な開発、運用、セキュリティのために、組織が強力で適応性があり管理しやすい基盤を提供する
方法を根本的に最新にすることができます。この文書は、セキ
ュリティの専門家に、SDPアーキテクチャがどのように機能するのか、またどのように組織に効果的に配備できるのかについてのより深い理解を提供します。
しかしながら、私たちの仕事はまだ終わっていません。
今後の調査で取り上げるトピックは、SDP配備モデルやここに掲載されている統合ごとの詳細な論文、SDPのビジネス上の利点、SDP配備に基づくコンプライアンスコントロールマッピングなど、
いろいろあります。最も重要なこととして、私たちはすべての答えを持っているわけではありません！私たちはあなたが私た
ちのワーキンググループに参加し、会話に参加し、そして貢献していただくことを勧めます。
最も重要なことは、私たちはすべての答えを持っていないことを認識していることです！SDPワーキンググループに参加して、会話に参加し、貢献してください。安全でオープンで利用可能なインターネットをサポートするセキュリティ専門家として、また倫理的に動機付けられた人間として、私たちはより良
い未来を確保するために懸命に働いています。活動に。ご参加いただけることを期待します。詳細については、
https://cloudsecurityalliance.org/working-groups/softwaredefined-perimeter/.

を参照してください。

© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

37

Appendix 1

補足資料“Software-Defined Perimeter Working Group: SDP Specification 1.0,” by Brent Bilger, Alan Boehme, Bob Flores, Zvi Guterman,
Mark Hoover, Michaela Iorga, Junaid Islam, Marc Kolenko, Juanita Koilpilla, Gabor Lengyel, Gram Ludlow, Ted Schroeder, and Jeff
Schweitzer (CSA, April 2014).
SDP v1.0 Spec“Software-Defined Perimeter for Infrastructure as a Service,” by Jason Garbis and Puneet Thapliyal (CSA, 2016).
SDP for IaaS
“Software-Defined Perimeter Working Group Glossary,” Cloud Security Alliance (CSA, 2018).
SDP Glossary“Zero Trust Networks: Building Secure Systems in Untrusted Networks,” by Evan Gilman and Doug Barth (June 2017).
http://shop.oreilly.com/product/0636920052265.do“fwknop: Single Packet Authorization > Port Knocking,” by Michael Rash (CipherDyne).
http://www.cipherdyne.org/fwknop/“Open Source Software-Defined Perimeter,” Waverley Labs.
http://www.waverleylabs.com/open-source-sdp/© Copyright 2019, Cloud Security Alliance. All rights reserved.

SDP Working Group Software-Defined Perimeter Architecture Guide

38

Appendix 2

SPAの詳細SDP 1.0仕様で定義されているSPAパケットのフォーマットは次のとおりです。

Nonce

Prevents servicing outdated SPA packets

Timestamp

Most common: Service Access Request

Message Type

Possibly deprecated: access request, NAT access request,
gateway command message

Message String

Source IP address to allow, service ID(s) to open

Optional Fields

NOTE: Gateway knows which port to open as well as
whether and where to forward the connection.

Digest

NOTE: Might be used to request tunneling of service traffic.

HMAC

Before encryption, this SHA256 hash is calculated overthe ciphertext portion of the message and then used by
the server to verify message integrity after a successful
message decrypt.

CIPHERTEXT

CLEARTEXT

上記に対する改善案として、平文のクライアントIDを追加することが考えられます。これにより、着信パケットをより効率的に処理できます。RFC文書と同様にバイナリSPAフォーマットを設計するための取り組みが始められました。
SPAは、単一のUDPパケットとして送信された場合に最も効果的です。一部の使用例では、ネットワーク環境が一部またはすべての発信UDPパケットをブロックする可能性があるため、実用的ではありません。このような場合、SPAパケットはTCP接続を介して送信できます。これは技術的にSPAの「シングルパケッ
ト」の性質に反しますが、実際的な考慮事項として必要な場合があります。
SPAパケットは接続しているマシンから送信できますが、別のシナリオではパケットが別のデバイスから送信されます。この使用例は、デスクトップコンピュータの代わりにモバイルデバイスを使用してSPAパケットを送信する場合です。他のシナリオでは、UDPパケットをブロックする環境のための合理的な回避策になります。

© Copyright 2019, Cloud Security Alliance. All rights reserved.