タグ別アーカイブ: SDP

ゼロトラスト関連用語を整理する ~ ZT・ZTA・ZTNA・SDP の違い

2026年4月12日
CSAジャパン　ゼロトラストWG
CCZT(Certificate of Competence in Zero Trust)
諸角昌宏

はじめに

「ゼロトラスト」という言葉が広く使われるようになった一方で、ZT・ZTA・ZTNA・SDPという関連用語が混在して使われ、混乱を招くケースが増えている。これらは互いに密接に関連しているが、指し示す概念の範囲や性格はそれぞれ異なる。本ブログでは、各用語の定義・関係性・違いを整理し、正確な理解の助けとなることを目指す。

全体像：4つの用語の関係

4つの用語は以下のような階層関係にある。ZTが最も広い概念であり、ZTA・ZTNA・SDPはそれを具体化・実装化していく階層に位置する。

すなわち、ZTという概念をシステム設計として具現化したものがZTAであり、ZTAを実現する技術カテゴリの一つがZTNA、そしてZTNAの具体的な実装アプローチがSDPである。

ZT（Zero Trust：ゼロトラスト）

定義

ZTとは「すべてのアクセスを検証する（Never Trust, Always Verify）」というセキュリティの概念・原則である。ネットワークの内側・外側を問わず、いかなるユーザー・デバイス・アプリケーションも、明示的に認証・認可されるまでは信頼しないという考え方に基づく動的・継続的な信頼評価モデルである。2010年にForrester ResearchのアナリストJohn Kindervagが提唱したことが起源とされている。

主な原則（NIST SP 800-207より）

すべてのデータソースとコンピューティングサービスをリソースとみなす
ネットワークの場所に関係なく、すべての通信を保護する
企業リソースへのアクセスは、セッション単位で付与する
リソースへのアクセスは、ダイナミックなポリシーやその他の行動・環境属性によって決定する
すべての資産の完全性とセキュリティ動作を監視し、測定する
すべてのリソースの認証と認可を動的に行い、アクセスが許可される前に厳格に実施する
資産、ネットワークインフラストラクチャ、通信の現状について可能な限り多くの情報を収集し、セキュリティポスチャの改善に利用する

重要なポイント

ZTは製品でも技術でもなく、考え方である。「ゼロトラスト製品を導入した＝ゼロトラストを実現した」とはならない。ZTはあくまで組織のセキュリティ戦略の指針であり、その実現手段がZTAである。

ZTA（Zero Trust Architecture：ゼロトラストアーキテクチャ）

定義

ZTAとは、ZTの原則を組織のシステム・インフラ・ワークフローに適用するためのシステム設計・アーキテクチャである。NIST SP 800-207が最も権威ある技術ガイドラインとして広く参照されている。

主なコンポーネント

NIST SP 800-207はZTAの論理的なコンポーネントとして以下の3つを定義している。

コンポーネント	略称	役割
ポリシーエンジン	PE	アクセスの許可・拒否を最終決定する
ポリシーアドミニストレータ	PA	PEの決定をPEPに伝達・実行させる
ポリシー実施ポイント	PEP	実際にアクセス制御を執行するゲートキーパー

PEはトラストアルゴリズムを用いて、アイデンティティ・デバイス状態・脅威インテリジェンス・行動履歴などを総合的に評価し、動的にアクセス判断を行う。

ZTとZTAの違い

	ZT	ZTA
特徴	概念・原則	設計・構造
目的	「何を目指すか」	「どう設計するか」
具体性	抽象的	具体的（コンポーネント・データフローを定義）

ZTNA（Zero Trust Network Access：ゼロトラストネットワークアクセス）

定義

ZTNAはゼロトラスト原則に基づくアクセス制御のカテゴリであり、VPNの代替となるケースも多いが、すべてのユースケースを置き換えるものではない。現在はZTAを構成する重要な要素として、より広い役割を担うものと位置づけられている。

VPNとZTNAの比較

観点	VPN	ZTNA
アクセスの粒度	ネットワーク全体への接続	アプリケーション単位での接続
信頼モデル	ネットワーク内を信頼	常に検証（Never Trust）
可視性	限定的	継続的なモニタリング
リスク	侵害時にラテラルムーブメントが容易	最小権限によりラテラルムーブメントを制限
スケーラビリティ	アーキテクチャ変更が困難	クラウドネイティブで拡張が容易

ZTAとZTNAの違い

ZTAはゼロトラスト全体のアーキテクチャ設計であるのに対し、ZTNAはその中のネットワークアクセス制御に特化した市場カテゴリである。ZTNAはZTAを実現するための要素の一つであり、ZTAにはZTNA以外にも、アイデンティティ管理・エンドポイント管理・データセキュリティなど多くの要素が含まれる。

	ZTA	ZTNA
特徴	アーキテクチャ設計	技術カテゴリ
範囲	ゼロトラスト全体	ネットワークアクセス制御に特化
目的	どう設計するか	どうアクセスを制御するか

SDP（Software Defined Perimeter）

定義

SDPとは、ネットワークの境界をソフトウェアによって動的に定義するアーキテクチャアプローチである。SDPはZTNAを実現する一つのアーキテクチャであるが、ZTNAはプロキシ型など複数の実装方式を含む。

仕組みの特徴

SDPの核心は「接続前に認証する（Authenticate Before Connect）」という原則である。従来のファイアウォールが「まず接続を許可し、その後にフィルタリングする」のに対し、SDPはネットワーク接続そのものを確立する前にアイデンティティとデバイスの正当性を確認する。CSAが定義し、Google BeyondCorpと思想的に類似している。

主な構成要素は以下のとおりである。

構成要素	役割
SDPコントローラ	アクセスポリシーの管理・認証の決定
SDPクライアント	ユーザー側のエージェント。接続要求を送信
SDPゲートウェイ	リソース側のゲートキーパー。許可された接続のみを通過させる

単一パケット認証（SPA：Single Packet Authorization）という技術を用いて、正当なクライアントからのパケット以外にはゲートウェイの存在すら見えないよう設計されている。

ZTNAとSDPの違い

	ZTNA	SDP
特徴	技術カテゴリ・機能の定義	実装アーキテクチャ・設計アプローチ
策定主体	Gartner（市場定義）	CSA（技術仕様）
目的	何を実現するか（What）	どう実現するか（How）
関係	より広い概念	ZTNAを実現する手段の一つ

多くの場合、SDPはZTNAの選択形態の一つとして採用されており、両者は実質的に重なる部分が大きいが、概念の性格は異なる。

4つの用語の総合比較

観点	ZT	ZTA	ZTNA	SDP
特徴	概念・原則	アーキテクチャ設計	技術カテゴリ	実装アプローチ
範囲	最も広い	広い	ネットワークアクセス制御に特化	ZTNAの実現手段の１つ
策定主体	Kindervag/Forrester	NIST	Gartner	CSA
主な規格	—	NIST SP 800-207	Gartnerレポート	CSA SDP仕様書
考え方	何を目指すか	どう設計するか	どうアクセスを制御するか	どう境界を実装するか

真のゼロトラストを実現するには

ゼロトラストは製品を導入すれば完成するものではない。ZT・ZTA・ZTNA・SDPの各概念を正しく理解した上で、組織全体として段階的に取り組む必要がある。以下に、真のゼロトラスト実現に向けてやるべきこと・考慮すべき点を整理する。

ZTAの全体設計から始める
最初にやるべきことは製品の選定ではなく、ZTAの全体設計である。「何を守るか（プロテクトサーフェスの定義）」「誰が何にアクセスするか（トランザクションフローの把握）」を明確にした上で、必要な技術要素を選択する順序が重要である。ZTNAやSDPはその後に来る手段であり、目的ではない。
アイデンティティを中核に置く
ゼロトラストの根幹はアイデンティティの継続的な検証にある。ユーザーIDだけでなく、デバイス・アプリケーション・サービスアカウント（非人間アイデンティティ）を含むすべての主体を対象に、多要素認証（MFA）・最小権限の原則・継続的な認証・認可の仕組みを整備することが不可欠である。
5つの柱を横断的に整備する
CISAゼロトラスト成熟度モデルが示すとおり、ゼロトラストはアイデンティティ・デバイス・ネットワーク・アプリケーション／ワークロード・データという5つの柱を総合的に整備して初めて機能する。ZTNAによるネットワークアクセス制御だけを強化しても、デバイス管理やデータ保護が脆弱であれば、ゼロトラストの実効性は限定的となる。
段階的・反復的なアプローチをとる
すべてを一度に変えようとすることは現実的でなく、リスクも高い。NSTACモデルが示す5ステップを参照しつつ、まず取り組みやすいプロテクトサーフェスを1つ選んでパイロット的に実施し、そこで得た知見・経験を活かしながら段階的に最も重要な資産（プロテクトサーフェス）へと対象を広げていく反復アプローチが有効である。例えば、既存のISMSを基盤として活用することで移行コストを抑えつつゼロトラストを段階的に展開することも考えられる（参考：CSAジャパンゼロトラストWG「ISMSを基盤としたゼロトラストの展開」、2026年2月 [6]）。
継続的な監視とポリシーの更新
ゼロトラストは一度構築すれば終わりではなく、継続的な監視・評価・改善のサイクルが本質である。SIEM・UEBAなどのツールを活用してアクセスログを常時分析し、異常を検知したらポリシーを即座に見直す体制を整えることが求められる。静的なルールに依存したままではゼロトラストの「動的な信頼の評価」という核心を実現できない。
組織文化とガバナンスの整備
技術面の整備と同時に、経営層の理解・支援と組織文化の変革が不可欠である。「境界の内側は安全」という従来の前提を組織全体が捨て去ることが、ゼロトラストの出発点である。NIST CSF 2.0が「ガバナンス（GV）」を独立した機能として追加したように、サイバーセキュリティを経営リスクとして位置づけ、責任の所在を明確にする体制づくりが求められる。
ベンダーロックインへの注意
ゼロトラストを標榜する製品・サービスは数多く存在するが、特定ベンダーの製品体系に過度に依存することは長期的なリスクとなる。NIST SP 800-207が技術中立的な設計を意図しているように、オープンな標準・仕様に基づいたアーキテクチャ設計を心がけ、特定製品への過度な依存を避けることが望ましい。

以上の考慮点を整理すると、以下のとおりである。

やるべきこと・考慮点	要点
(1) ZTAの全体設計から始める	製品選定より先に何を守るかを定義する
(2) アイデンティティを中核に置く	人・デバイス・サービス全体をMFA・最小権限で管理する
(3) 5つの柱を横断的に整備する	ネットワークだけでなくデータ・デバイスなども含めて対処する
(4) 段階的・反復的なアプローチ	1つのプロテクトサーフェスから始め知見を積み上げる
(5) 継続的な監視とポリシー更新	静的なルールに依存せず動的に見直し続ける
(6) 組織文化とガバナンスの整備	経営層の理解と責任体制の明確化が前提となる
(7) ベンダーロックインへの注意	特定製品依存を避け標準ベースの設計を心がける

よくある誤解

誤解1：「ZTNA製品を導入すればゼロトラストが実現できる」

ZTNAはZTAの一要素である。ネットワークアクセス制御が改善されても、アイデンティティ管理・エンドポイントセキュリティ・データ保護が伴わなければ、ゼロトラストの実現とはいえない。

誤解2：「SDPとZTNAは同じものだ」

SDPはZTNAを実現する実装アプローチの一つであるが、ZTNAはSDP以外の技術（IDベースのプロキシ等）でも実現できる。両者は重なるが同義ではない。

誤解3：「ゼロトラストはVPNを完全に置き換えるものだ」

ZTNAはリモートアクセスにおけるVPNの有力な代替であるが、すべてのユースケースでVPNが不要になるわけではない。ZTNAはLayer 7（アプリケーション層）での制御を前提とするため、ネットワーク機器の管理やレガシーシステムへの低レイヤー接続、OT・ICS環境など、ネットワークレベルのアクセスが必要な場面ではVPNが引き続き有効である。また、既にVPNインフラを持つ組織では一度に全面移行することは現実的でない。当面はZTNAとVPNを用途に応じて使い分けながら段階的に移行していくアプローチが現実的である。

まとめ

4つの用語の関係を改めて整理する。

ZTは「すべてを検証する」というセキュリティの概念である
ZTAはその概念を実現するシステムアーキテクチャの設計である
ZTNAはZTAを構成する要素の一つで、ネットワークアクセス制御に特化した技術カテゴリである
SDPはZTNAを実現する具体的な実装アーキテクチャアプローチである

これらは階層的な関係にあり、上位の概念が下位を包含する。組織がゼロトラストを推進する際は、製品・技術の導入に先立ち、ZTの原則とZTAの設計思想を理解した上で取り組むことが重要であると考える。

参考文献

[1] NIST, “Special Publication 800-207: Zero Trust Architecture,” National Institute of Standards and Technology, 2020.

[2] CISA, “Zero Trust Maturity Model Version 2.0,” Cybersecurity and Infrastructure Security Agency, 2023.

[3] NSTAC, “NSTAC Report to the President on Zero Trust and Trusted Identity Management,” National Security Telecommunications Advisory Committee, 2022.

[4] Cloud Security Alliance, “SDP Specification v2.0,” 2022.

[5] J. Kindervag, “Build Security Into Your Network’s DNA: The Zero Trust Network Architecture,” Forrester Research, 2010.

[6] 諸角昌宏（CSAジャパンゼロトラストWG）, “ISMSを基盤としたゼロトラストの展開,” CSAジャパンブログ, 2026年2月16日. https://cloudsecurityalliance.jp/newblog/2026/02/16/isms%e3%82%92%e5%9f%ba%e7%9b%a4%e3%81%a8%e3%81%97%e3%81%9f%e3%82%bc%e3%83%ad%e3%83%88%e3%83%a9%e3%82%b9%e3%83%88%e3%81%ae%e5%b1%95%e9%96%8b/

以上

SPA （Single Packet Authorization）解説

2件の返信

SPA （Single Packet Authorization）解説

2019年8月27日
CSAジャパン
諸角　昌宏

本ブログは、SDP(Software Defined Perimeter)の中核の技術であるSPA （Single Packet Authorization）が、どのようにゼロトラスト環境で有効であるかについて説明します。特に、インターネット上に安全なサービスを提供するため、認証が取れるまでは全てのアクセスを拒否する”Deny-ALL”が、どのように実現できているかについて説明します。

インターネットのアクセスにおける課題とSPA

リクエスト-レスポンス型であるインターネットのアクセス方法は、クライアントからのリクエストを受け取るために必ず口（ポート）を開けて待っています。これは、正しいユーザだけでなく、悪意のある人にも開いているということで、セキュリティ上の問題を引き超す可能性を高めています。悪意のある人は、ポートスキャン等を行って、インターネット上に開いているポートを探し、それに紐づくサービスを特定し、そのサービスの脆弱性を突いて攻撃を仕掛けることができます。また、開いているポートに対してSYNフラッド攻撃によりDoS/DDoS攻撃を行い、サーバを接続不能にすることができます。
このようにインターネットがもともと抱えている課題に対して、アクセスが許可されるまでは全てのポートを閉じておくという、いわゆる”Deny-All”を実現することで対処することが求められています。このための方法として、大きく以下の2つがあります：

ポートノッキング
SPA

これらについて、以下で説明していきます。

ポートノッキング

ポートノッキングは、決められたポートを決められた順番でアクセスすることでファイアーウォールに穴を空ける仕組みです。例えば、ポート1000、2000、3000に対して順番にTCP SYNパケットを送った場合のみ、ポート22 (SSH) へのアクセスが許可されるというような設定ができる機能になります。この場合、最初の状態ではポート22は閉じられており、ポートノッキングに定義されたTCP SYNのシーケンスが来た時のみ、一定時間ポート22を開放します。クライアントは、この開放している時間内にポート22に対してアクセスすることで接続できます。これにより、通常はDeny-Allの状態を維持しつつ、決められたポート番号に決められた順番でパケットが送られてきた時のみアクセスを許可するということが実現できます。

したがって、ポートノッキングには以下のようなメリットがあります。

パケットはデフォルト・ドロップ
サーバに送られてくるパケットは、デフォルトでは全てドロップすることが可能になります。つまり、Deny-allを実現できます。これにより、サーバが提供しているサービスを非可視化することができ、サービス自体を悪意のあるアクセスから保護することができます。
ポートスキャンしても空きポートを見つけることができない
悪意のある攻撃者がポートスキャンを行っても、開いているポートや稼働しているサービスを見つけることができません。したがって、悪意のある攻撃が非常に困難になります。
DoS/DDoS攻撃を最小化できる
ポートノッキング用のシーケンスにならないパケットは全てドロップされますので、SYNフラッド攻撃のようにもともと開いているポートに対する攻撃を行うことができなくなります。

一方、ポートノッキングには以下のようなセキュリティ上の問題があります。

リプレイ攻撃に弱い
ポートノッキングに利用するパケットは、暗号化されずにそのままネットワーク上を流れます。したがって、ネットワークを盗聴し、クライアントからのパケット・シーケンスをそのまま送ることで接続できてしまいます。
悪意のある第三者によるポートノック用のシーケンスの破壊
正しいクライアントに代わってポートノック用のシーケンスの一部を送ることで、シーケンスそのものを破壊することができます。
IDSあるいはポートスキャンによるポートノック用のシーケンスの探索
ポートノック用のシーケンスは一連のパケットの流れになるので探索が可能です。

SPA

SPAは、ポートノッキングの利点を持ちながら、ポートノッキングの課題に対処したものになります。” Software-Defined Perimeter: Architecture Guide”では、SDPの最も重要な要素の1つである「接続前認証（authenticate-before connect）」を実現するために、SPAを通してこれを実現していると述べています。また、このガイドでは、SPAはデバイスまたはユーザの身元を検証し、それから追加のアクセス制御を実施するシステムコンポーネント（コントローラまたはゲートウェイ）へのネットワークアクセスを許可するだけの軽量プロトコルで、これは、TCP / IPの根本的にオープンな（そして安全でない）性質を補うものとしています。SPAにより、要求者のIPアドレスを含むリクエスト情報は、単一のネットワークメッセージの中で暗号化および認証が行われ、デフォルトドロップのファイアウォールを通してサービスを見えなくすることができます。

SPAはプロトコルとして、SDP 1.0の中に仕様として記述されていますが、従わなければならないというような厳格な仕様では無いようです。したがって、SPAは実装の仕方においていくつかの異なる方法が取られています。ただし、SPAを実装するにあたっては、以下の3つの共通の原則を備えることを要求しています。

SPAパケットは、暗号化し、認証機能を持たなければならない。
SPAパケットは、必要な情報をすべて１つのパケットの中に含めなければならない。
SPAパケットを受け取ったサーバは、応答しないし、何も送信しない。

ここでは、SPAの実装方法を説明するにあたって、fwknopが提供するオープンソフトウエアを参照します。これは、LINUX JOURNAL Issue #156, April 2007 ” Single Packet Authorization fills the gaps in port knocking.”の内容を元にしてします。

SPAパケットの構成
fwknopが用いるSPAのパケットは、以下の構成になります。
- 16バイトのランダムデータ
- クライアント・ユーザ名
- クライアント・タイムスタンプ
- fwknop　バージョン
- モード (アクセス、あるいは、コマンド)
- アクセス (あるいは、コマンドストリング)
- MD5　チェックサム

これらのフィールドの内容について以下に説明します：

16バイトのランダムデータ、および、MD5　チェックサム
16バイトのランダムデータを含み、パケット全体のMD5チェックサムを持つことで、１つ１つのSPAパケットが必ずユニークになることを保証します。これにより、サーバ側では、以前来たことのあるパケットと同じパケットが来た場合には、リプレイ攻撃であると判断し、接続を許可しないということができます。
クライアント・ユーザ名、クライアント・タイムスタンプ
クライアント・ユーザ名、クライアント・タイムスタンプは、もう一段のレベルの認証・認可をサーバ側で行うのに用いられます。
fwknop　バージョン
fwknopとして、SPAのバージョン管理、特にバックワード互換性に用いられます。
モードとアクセス
サーバ側に、クライアントからの要求が、サービスへのアクセスなのかコマンドの実行なのかを示します。たとえば、SPAでコネクションが許可された後、SSH（TCPポート22）のアクセスを許可するように設定できます。アクセスの場合には、アクセス・フィールドに直接ストリングを含めます。

この例を元に、SPAの特徴をまとめると以下になります：

Deny-Allの実現
SPAパケットがクライアントからサーバに送られても、サーバがこれに応答することはありません。サーバは単にネットワーク上送られてくるパケットをスキャンする（たとえばlibpcapなど）だけで、SPAパケットでないものは全てドロップし、SPAパケットを受け取ると、その内容に基づいてクライアントとの接続を許可するかどうかを判断します。
リプレイ攻撃への対処
上記の例では、1パケットの中に16バイトのランダムデータを含み、全体のパケットのハッシュ値を入れています。これにより、SPAパケットがユニークになることを保証します。サーバ側では、今まで来たパケットと同じパケットが来た場合には、リプレイ攻撃であると判断し、接続を許可しないということができます。
DDoS攻撃への対処
Deny-Allであること、また、SPAパケットは1パケットであり、シーケンスではないことにより、DDoS攻撃の可能性を非常に下げることができます。
パケット・シーケンスの探索や破壊への対応
SPAパケットは1パケットであることから、スプーフィングしたり解析したりすることが難しくなります。
様々な認証情報の送信が可能
SPAパケットの中には、様々な情報を含めることが可能なため、クライアントのユーザ名など、ユーザに対応した追加の認証等の処理が可能になります。

以上のように、SPAは、ポートノッキングのメリットを維持しつつ、課題を解決し、ゼロトラスト環境における最適なネットワーク環境を提供できるものと考えています。また、ここでは触れませんが、SDPが他に提供している機能(mTLS等)とSPAが組み合わされることにより、ゼロトラスト環境におけるさらに強固なネットワークセキュリティが提供できます。

なお、SPAは、fwknopからオープンソースとして提供されていますので、さらに理解を深めていただければと思います。

本当のSDPよ立ち上がれ！ ~ Will the real SDP please stand up?

コメントをどうぞ

本ブログは、Optiv Security Inc.が公開している “Will the real SDP please stand up?” の日本語版になります。本ブログは、著者およびOptiv Security Inc.の許可を得て翻訳し、公開するものです。本ブログの内容と原文の間で相違があった場合には、原文が優先されます。

本当のSDPよ立ち上がれ！

原文：　2019年7月10日
日本語版：　2019年7月23日

Software Defined Perimeter（SDP）という用語は、ゼロトラスト（Zero Trust）モデルで安全なアクセスを提供するための新たなアジャイルな方法として最近普及してきています。SDPは、クラウドセキュリティアライアンス（CSA）によって定義された要件で、VPN /ファイアウォール/ NACの組み合わせよりも効果的で安全な方法でリモートアクセス機能を提供します。

ただし、SDPはアーキテクチャ的に異なる点があるため、多少新たな考え方が必要です。SDPは、データプレーンとコントロールプレーンを分離するネットワークの概念に基づいて作られています。これは、認証コンポーネントを拡張したポリシー決定ポイント（PDP）とポリシー実行ポイント（PEP）モデルになります。SDPの認証プロセスにおいては、「コントローラ（Controller）」はアクセスを認証するためのポリシー決定ポイントであり、「ゲートウエイ（Gateway）」はサービスへのアクセスに許可または拒否を与えるポイントになります。ゲートウェイから分離されたPDPトラフィックを使用することで、ハイブリッドクラウド環境全体でユーザーが同時にアクセスを許可される集中型のポリシーモデルと認証をサポートしているため、この機能は他のアプローチとの大きな違いになります。接続が確立され、ゲートウェイがユーザーに対して識別されると、ゲートウェイは、コントローラからの変更を定期的に確認しながら、デバイスの状態(device posture)や定義された条件に基づいてリアルタイムで決定を行うというハイブリッドな役割を果たします。これにより、コントローラが停止した場合の可用性が向上するだけでなく、障害ゾーンの分離とコントーラ/ゲートウェイのスケールアウトによりパフォーマンスも向上します。

SDPモデルは包括的で、アーキテクチャ的に異なる点があるため、従来のアクセスメカニズムやトンネリングには依存しません。つまり、SDPに加えてVPNやファイアウォールを必要とするものがあるとすれば、パフォーマンス、セキュリティ、アジリティに制限をかけるようなものであり、今日のリモートアクセスやハイブリッドクラウドにおけるワークロードの要求を満たさない可能性があります。

通信前の認証

SDPのもう1つのユニークな要素はSingle Packet Authorization（SPA）です。これは、すべてのネットワークセッションの最初のパケットで暗号化認証を要求し、許可されたクライアントだけがネットワークにアクセスできるようにします。

もともと2007年に作成されたSPAは、最初のネットワークパケットを暗号検証することで、DDoSに対する認証メカニズムを提供します。また、許可されたデバイスのみにサービスが公開されるため、エクスプロイトに対する保護も提供します。SPAで開始されていないTCPストリームはSDPによってドロップされ、コントローラまたはゲートウェイによって処理されることはないため、DDoSの影響を軽減します。SPAは、なりすまし防止や不正なデバイスによる保護されたリソースへのアクセスの防止など、DDoS防止以外の追加のセキュリティ対策を提供します。これにより、ユーザー名とパスワードが危険にさらされた場合に、資格情報を再利用する攻撃から保護されます。

SDPはどのくらい強力ですか？

2014年2月、CSAはSoftware Defined Perimeter ハッカソンのスポンサーとして、Black HatとDEFCONにSDPセキュリティを破ろうと挑戦する人のため環境を提供しました。世界全体で100億パケットを突破しましたが、攻撃は成功せず、賞品は求められませんでした。これは、SDPアプローチの長所をよく示しています。

私たちは、CSAのSDPワーキンググループに深く参加し、SDPソリューションをまとめることを経験しているSDP分野のリーダーです。ForresterとGartnerの業界調査の専門家が、今後数年間で安全なアクセス環境を大きく変えるであろうと予測しているゼロトラスト・ジャーニーにご参加ください。

原文 “Will the real SDP please stand up?” は、こちらを参照してください。

CSA Japan Congress 2015 盛況裡に閉幕

コメントをどうぞ

一般社団法人日本クラウドセキュリティアライアンス　業務執行理事
勝見　勉

11月18日（水）、日本でのCongressとしては2回目の開催となるCSA Japan Congress 2015が開催されました。朝から空模様があやしく、午後からは雨になった中、140人の多数にご参加いただきました。運営スタッフ、講演者、プレス関係などを入れると170名を超え、ほぼ会場キャパシティ一杯になるという盛況でした。

今回の「目玉」は日本情報経済推進協会（JIPDEC）・情報セキュリティマネジメントセンター、高取敏夫参事による特別招待講演「ISMSをベースにしたクラウドセキュリティ～ISO27017の最新動向」です。クラウドに特化した初めての国際標準規格であるISO/IEC27017の正式リリースがもう間もなく、という時期に、この27017に基づく、ISMSのクラウド情報セキュリティに関するアドオン認証の創設という話題を中心にお話し頂きました。このクラウドセキュリティアドオン認証は、11月16日にJIPDECから発表されたばかりの、湯気がホカホカ立っているような情報で、世界に先駆けてクラウドのISMS認証を制度化するという画期的なものでした。受講者の多くもこの解説を目当てに参加されたものと思われます。27017そのものが日本の提案を基に日本主導で開発が進められたという意味でも、ISO/IECベースの国際標準化の歴史の中では画期的なことでした。クラウドサービスの開発では世界をリード、と言えない日本も、クラウドの最大の関心事であるセキュリティに関しては世界をリードする立場に立っていると言えます。その意味で世界最先端・最新の情報に接することができて、聴衆の皆様共々、感慨深いものがありました。

Japan Congress 2015のもう一つのテーマは、新しいクラウドセキュリティ技術でした。中でも特別テーマ講演にお招きしたヤフー株式会社上席研究員の五味秀仁氏からは、「FIDO－次世代認証方式とクラウド」というタイトルで、クラウドにおけるユーザ認証に親和性の高い、パスワードレスの認証スキームであるFIDO(Fast IDentity Online)について紹介と解説を頂きました。この他にスポンサー講演、ゲスト講演、パネルディスカッション等を通じて取り上げられた新しい技術トピックとしては、CASB(Cloud Access Security Broker)、SDP(Software Defined Perimeter)、コンテナ、トランスペアレントな暗号化、27018（クラウドにおける個人情報保護）が挙げられます。

クラウドはコンピューティングプラットフォームとして広く定着する方向を見せています。昨今のサイバーセキュリティ脅威や情報漏えいに対する管理・防御を考える時、専門家により安定的・トラブルレスの運転が期待でき、セキュリティ管理も充実しているクラウド環境は、ITに多くの予算と人材を割けない中小企業こそ、積極的に活用すべき社会的リソースと言えます。そしてそのセキュリティは、技術面からも、マネジメントシステムの面からも、ますます充実していくことが期待できます。今回のCongressは、こういった流れを明確に打ち出し、理解を深めるとともに、そのための最新トピックを盛りだくさんに提供する素晴らしい機会になったと言えると思います。

更に付け加えるならば、冒頭の日本クラウドセキュリティアライアンス会長・吉田眞東大名誉教授のご挨拶では、春に開催するSummitが発信の場と位置付けられるとすれば、秋に開催するCongressは「クラウドのセキュリティについて多面的に取り上げ、最新の情報を提供し、クラウドとセキュリティのベンダ、サービスプロバイダ、インテグレータ、ユーザ、関係機関が一堂に会し、クラウドを取り巻くセキュリティ課題を議論する」場である、と整理されました。多士済々のスピーカと、パネルも含むプログラム構成はこれを十全に体現したと言え、充実した一日を、多くの関心高い人たちと共有できたと思います。

おわりに、最後まで熱心に聴講いただいた受講者の皆さまと、設営・運営スタッフ、そしてたいへんバリューの高いプレゼンを頂いた講演者の皆さまに、この場をお借りして感謝の意を表して、Congressレポートのブログのまとめにしたいと思います。どうもありがとうございました。

SDPと2015年度データ漏洩/侵害調査報告書の報告（第13回CSA勉強会）

コメントをどうぞ

SDPと2015年度データ漏洩/侵害調査報告書の報告（第13回CSA勉強会）

2015年7月1日
日本クラウドセキュリティアライアンス　諸角昌宏

６月29日に行われた第13回CSA勉強会について報告します。テーマは、「SDPと２０１５年度データ漏洩/侵害調査報告書」ということで、ベライゾンジャパンの皆様に講師をやっていただきました。SDPは、Software Defined Perimeterということで、５月のCSA Summit Japan 2015でJim　Reavisが触れていたクラウドセキュリティの新しい潮流の１つです。ベライゾンは、SDP仕様書V1.0の作成を中心となって行っており、SDPに関しては事例も含めて先進的に進めている会社になります。また、ベライゾンはセキュリティの調査レポートを毎年出しており、今回は8回目として”2015 DATA BREACH INVESTIGATIONS REPORT”を公開しています。

それでは、まずSDPについて勉強会の内容を報告します。

そもそもSDPとは？ということですが、”Temporal Network”ということで「一時的なネットワーク」という表現をされています。つまり、伝統的な固定ネットワークではなく、ダイナミックに接続先が決まることで攻撃のターゲットが明確にならないようにして守っていくという手法になっています。個人的には別のスライドで使われていた” Secure Non Discoverable Network”、つまりデバイスやIDが認証されるまでネットワーク上で見ることができないという表現の方がわかり易い感じがしますが、いずれにしろ、サーバのどこにアクセスするかは認証して接続するまで決まらないことでネットワーク上のセキュリティを保つためのアーキテクチャということになります。以下のような特徴を持っています。

ネットワークベースの攻撃からアプリケーションを守るためのセキュリティ・フレームワーク
“Need-To-Know”という形で、ダイナミックなネットワーク構築に基づいた「必要な時」に接続するモデル
DNSやIPアドレスをあらかじめ見せない

また、SDPは既存の標準に基づいて設計されているため、非常に安定したものであるということが言えます。また、CSAがオープンスタンダードとして使用を公開しているため、誰でも利用することができます。

さて、実際にSDPがどのように動作するかということですが、簡単に言うと以下の流れになります：

デバイス(ブラウザなど)から、SDP Controllerにアクセス
デバイスの認証を実施
ユーザ認証および使用するアプリケーションの認可を確認
アプリケーション・サーバをダイナミックにプロビジョニング
デバイスがアプリケーションを利用

勉強会では、SDPを用いたいくつかの事例について紹介されました。また、CSA Conferenceで行われたハッカソンについての説明もあり、世界中からの150億アタックに対して、一度も破られなかったということでした。また、勉強会参加者から、SDPのユーザーズガイドやインプリメンテーションガイドが欲しいという意見、SDP Controllerでのポリシー管理に対する質問等が出され、活発なディスカッションになりました。今後、CSAジャパンを中心として幅広い情報共有や実装に向けての議論を進めることが必要であることを感じました。

次に、２０１５年度データ漏洩/侵害調査報告書について報告します。

まず、ベライゾンが強調していたのは、実際のデータに基づいたレポートとなっている点です。一般的に、このようなレポートはアンケート結果に基づくものがほとんどで、データに基づいた調査結果であり非常に信頼性が高いということができるようです。2015年の情報漏洩データとして、2,122件の漏洩事故および79,790件のセキュリティインシデントを分析したとのことで、特に今回はJPCERTのデータとして日本でのデータを含めたレポートとなっているとのことです。

この中で、いくつか特徴的な点として感じた点を以下にあげます。

フィッシングメールへの対応フィッシングメールの添付ファイルをクリックする確率が11%ということで、10通送れば1通は開かれるという状況とのことで、攻撃者から見ると非常に効率的な攻め方のようです。対策として最も重要なのはトレーニングで、セキュリティ対策では人が最終的な検知装置であることを認識する必要があるとのことです。
脆弱性脆弱性を突いた攻撃の97%は、わずか10個の脆弱性に対する攻撃だそうです。さらに、攻撃の99.9%が、CVEの公表から1年以上経過したものだそうです。脆弱性に関する情報をきちんと入手および管理することと、パッチ適用などの伝統的な対策をきちんと行うことが重要になります。
情報漏洩情報漏洩の原因として、Webアプリケーションを狙った攻撃はかなり少なくなっていて、反対に人をターゲットにした攻撃が増えていて、全体の90%以上を占めているとのことです。
業界業界別では、製造業、小売業に対する攻撃が目立っているとのことです。また、教育機関への攻撃も多いとのことです。

その他、実際のデータに基づく非常に詳細な分析が行われています。このレポートの日本語版も近々公開されるとのことですので、期待したいと思います。

以上、非常に概略になりますが、勉強会の報告といたします。

CSA Japan Summit 2015　を終えて

コメントをどうぞ

2015年5月25日
日本クラウドセキュリティアライアンス　理事
諸角　昌宏

CSA Japan Summit 2015が、5月20日に開催された。今後のクラウドおよびクラウドセキュリティの動向をグローバルの視点を含めて聞くことのできた講演であった。

さて、全体を通じてまず感じたことは、クラウドに対する見方が大きく変わってきているということである。つまり、「クラウドを使っても大丈夫か」ではなく、「クラウドをどのようにビジネスに活用するか」というように変化していることである。以前のCSA勉強会で渥美俊英氏が述べていたように、もはやクラウドを技術的に考えるのではなくビジネス的に考えなければいけなくなっている。また、クラウドを使わずには、企業が生き残っていくことができないという段階に来ているということを改めて感じた。今回のCSA Japan Summit 2015は、クラウドを支えるべく技術的な動向、IoT等の新たな動向、金融機関における業務のクラウド化の紹介、また、法律の観点からの考察ということで幅広くこのクラウドに対する見方の変化についてカバーしていた。

以下、私なりに3つのポイントで今回のSummitをまとめてみる。

クラウドの利用を支える新しい技術
企業がクラウドを使っていく場合、もはや、「パブリックは危険」で「プライベートは高価」という概念を取り払う段階に来ているようである。パブリッククラウド環境にプライベートクラウドを構築するバーチャルプライベートクラウドを用いて、如何に安全にクラウドに移行するかを考えていくことが重要である。ソニー銀行の大久保光伸氏の講演では、銀行業務のかなりの部分をAWS VPCに移行させた事例を紹介していた。信頼が非常に重要な銀行業務においてクラウド化を実現した理由は、限られたIT予算内で「固定的ITコスト」を減らし「戦略的ITコスト」に振り向けることとのことであった。以前からクラウドに移行するメリットとして挙げられている理由ではあるが、銀行という業種の言葉として非常に重みを感じる。AWS VPCが信頼できるプラットフォームとして選ばれた理由は、ISO27001とFISCの安全対策基準に準拠しているということであった。どのような形でプロバイダを選定するかについて、吉井和明氏の講演では、「利用者側で、事業者側を管理することや責任を取ることはかなり難しい。利用者側ができることは、リスク軽減の考え方に基づいてクラウドの選択を行うことが重要である。経産省/金融庁等のガイドラインやCSA　STARなどを使ってプロバイダの能力を判断することが最良の策である。」とのことであった。このように、バーチャルプライベートクラウドを積極的に利用していくこと、またそのためのセキュリティ対策をきちんと行うことが今後のビジネスにおいて重要になると思われる。
クラウドセキュリティを支える新たなソリューション
Jim Reavis氏の講演では、CSAにおいて以下の技術をもってバーチャルプライベートクラウドのセキュリティの研究を進め、安全なクラウドに向けての活動を行っているとのことであった：
- 暗号化と鍵管理バーチャルプライベートクラウドにおいては、データおよび通信の暗号化は非常に重要である。CSAのSecurity as a Serviceワーキンググループでは、クラウドのセキュリティの研究において、特にこの分野にフォーカスしている。
- CASB: Cloud Access Security Broker クラウドアクセスセキュリティブローカ（クラウドへの安全なアクセスを提供する業者）。クラウドプロバイダのセキュリティ対策を補完し、利用者が必要とするクラウドセキュリティ対策をまさに代行して行うもので、非常に有効なクラウドのセキュリティ対策になる。
- 仮想化バーチャルプライベートクラウドは、基本的に仮想化環境で動くことになる。仮想化のセキュリティに関しては、ガイダンスで扱っている内容であり、引き続き研究を進めていく。また、新たなコンテナ技術(Dockerなど)に対するセキュリティの研究も進めている。
- SDP（Software Defined Perimeter） SDPは、認証ができるまでネットワークを非公開に保つことができ、ネットワークの高い安全性と信頼性を構築できるアーキテクチャとなっている。現在は、パイロットやユースケースの拡大の段階ではあるが、実用化に向けての研究を進めている。
  そのほか、プロバイダの認証としてのSTARプログラムを展開しプロバイダのレベルの透明性や認証を進め、利用者が安全なプロバイダを選定できる体制を整えている。また、利用者のリテラシーの向上に向け、クラウドの認定資格のCCSKを進めている。
  
  また、クラウドで重要となるID管理をSaaS化するIDaaSについて、江川淳一氏からお話があった。IDaaS自体は、4~5年前から米国で増えてきたサービスで、ID情報マスタをIDaaSで管理する。クラウドを利用する場合、オンプレミスよりID管理が面倒になる。また、利用者もクラウド事業者もどちらもID情報は預かりたくないというのが本音である。そうであれば、ID管理を専門に行っていて、信頼できるサービスを利用するというのが、セキュリティの観点からも有用になってくる。もちろん、IDaaS事業者には厳格なリスク評価が要求されるが、サプライチェーンをコントロールできる点を考えてみても有用なサービスになってくると思われる。
  
  もう1つ、夏目道生氏からはシャドーIT対策として、現状（利用状況）の把握、モニタリング、リスク評価、アナライズ、セキュリティ対策というサイクルでの対応が必要となるというお話があった。それを実現する製品としてSkyHighが紹介されていた。SkyHighは、Jim Reavis氏の講演でフォーカスされていたCSABを提供しており、クラウド環境での新たなセキュリティ対策として注目していきたい。バーチャルプライベートクラウドにより、機密性の高い業務をクラウド化することが十分現実味をおびてきている。一方、クラウドに対するセキュリティ技術自体も進化している。アンテナを高く張って、クラウドを安全に使う技術を習得し続ける必要がある。
IoTの動向とセキュリティ
今回のSummitにおけるメインテーマの１つがIoTであった。IoTは、最近流行りのバズワードと思われる点もあるが、森川博之氏によると、バズワードでは終わらないということであった。それは、データが集まれば、様々な産業が集まり、今までなかったもののデータが重要になり、これを扱うIoT自体が、産業セグメントを変えていくということである。特に、IoTが大きな影響を与える分野として、医療（医療に関しては、日本が世界で最大のデータを持っている）、土木系（地すべり対策としてセンサーを設置するなど）など、今までは経験と勘に頼っていたものに新たにデータが加わってくることで生産性の低い分野にチャンスを与えることになるということである。講演タイトルの「未来を創るIoT」において必要とされることについては、「フィールド志向」と「デザイン能力」とのことであった。IoTで最も重要なのはユーザ企業。現場で使っているものを理解する必要がある。自分で飛び込んでいって解決させていく「フィールド志向」が必要になる。また、従来必要とされた能力である「考える、試す」に対して、これから必要とされる能力は、「気づく（柔軟な発想）、伝える（説明の仕方によりインパクトが違ってくる）」ということで、この「デザイン能力」を意識的に磨いていくことが重要とのことである。

また、IoTのセキュリティについて研究を行っている二木真明氏は、いろいろなデバイスがシステムとして動くようになった場合のシステムとしてのリスクとして、システム全体として障害を起こした場合の方がクリティカルになると述べていた。そのため、CSAジャパン IoTクラウドWGでは、システムの中のサービスにフォーカスして活動しているとのことである。このような状況でのセキュリティ対策として、サービス事業者はリスク評価を正しく行い、セキュリティ対策を講じることが必要ということであった。

IoTについては、Jim Reavis氏も触れていたように、CSAとしても重要なテーマの1つとして研究を進めていくということであった。

最後に、クラウドセキュリティには直接関係しないが、飯塚久夫氏のTelecom-ISACの話は興味深かった。詳細には触れないが、「受動的な無責任を改めよ！大事なのは安全の確保であって、安心の確保ではない。日本では、自己の確立ではなく自我の確立に走っていた。また、安全・安心は誰かが与えてくれるという観念があり、リスク対応が不得手である。」ということで、リスク文化の転換が必要であるということを強調されていた。

クラウドセキュリティについて語ると、どうしてもクラウドにおけるリスク中心の話になりがちである。結果、利用者から「クラウドはやっぱり危険なんですね」という意見をいただくことが多い。クラウドセキュリティに関わるものとして、リスクを正しく伝えることは重要であるが、クラウドを安全に使うためのガイドをもっと出していかなければならない。うまく使えば、クラウドの方がセキュリティレベルは高いはずである。

その他、盛りだくさんだったSummitの内容については、後日公開される資料集を参照してください。