SDP(Software Defined Perimeter)の便利な使い方の紹介記事です。（パート１です）

目次

1. 文化省 教育セキュリティポリシーに関するガイドラインハンドブック
2. IAP（Identity Aware Proxy)とはどういうものか？
3. IAP/ZTNA/SDPの違い
4. SDPをIAPとして利用することのメリットとは
   • Appgate SDPはオンプレミスシステムであり、特にID連携が得意です

---

最近、ゼロトラスト/SASEが本当にユーザーの間でも浸透して来ていることの現れとして、本当に勉強会や説明会の依頼が多くなりました。もちろん各ユーザーごとに抱えている問題は色々ですが、セキュリティの課題、利便性の課題という点ではゼロトラストは今後のITシステムにおいて重要なアプローチだということが、現場の方々のお話を通して実感できています。

今回はその中でも、話題によく上がってきている"IAP"(Identity Aware Proxy)というものについて考えてみようかと思います。

そもそもこのIAPというものですが、おそらくBeyondCorp Enterprise、やAkamai EAAで提唱されているIdentity Aware Proxyという機能に関する内容を指しているケースが多くあります。

どちらの製品の説明サイトを見ても、とても詳細にわかりやすく記載されているので、私もよく参考させていただいています。

文化省　教育情報セキュリティポリシーに関するガイドラインハンドブック

教育情報セキュリティポリシーに関するガイドラインハンドブック

ネットワークが混在する環境下においては、ネットワークやユーザー、端末を原則として信頼せず、IAPなどの技術を用いて全てのアクセスをチェックし、接続の可否を判断するのが一般的になりつつあります。これにより、アプリケーション単位で、教職員及び児童生徒が適切な条件を満たした場合にのみ情報へアクセスできるような、事前の設定に基づくアクセス制御が可能になります。外出先からでもアクセスできる点は旧来のVPNと同じですが、アプリケーションはネットワークそのものを接続させるわけではなく、コネクタを経由してアクセスするため、極めて限定的なアクセスに留めることができます。

IAPに関しては、教育情報セキュリティポリシーのガイドラインハンドブックに掲載されたこともあり、注目度が高まっていると考えられます。 上記にも記載がありますが、全てののアクセスをチェック、適切な条件を満たした場合のみ、事前の設定に基づくアクセス制御と完全なゼロトラスト志向の機能要件が明記されています。

このハンドブックにはIAPと記載されていますが、この要件を満たすことができるのソリューションについての紹介です。

IAP（Identity Aware Proxy)とはどういうものか？

ユーザーはインターネットを通して、クラウド、IaaS、オンプレミス上のデーターにアクセスできるようになりました。ただユーザーとして不便だと思うことは、データーの保存場所が分散されていて、ユーザー自身がセキュアにアクセスするためには、明示的に自身がアクセスする宛先のデーターの所在を知る必要があります。

これは、データとアプリケーションの仕組みをよく知っている人なら至極当たり前のことですが、実際アプリケーションを通してデータへアクセスしているユーザーからすると、正直データーの所在がどこにあるかは意識することはありません。

データはDX（デジタルトランスフォーメーション）によって分散された結果、そのデータの場所を一つずつ理解して、アクセス先を制御するというのは、ユーザーにとっては不可能な話です。

現に、複数のサイトが存在するような環境で、それぞれサイトごとにVPNゲートウェイが存在しているような場合、目的のデータやアプリケーションへアクセス単位に、わざわざゲートウェイを切り替えるというのはとても大変です。しかしVPNというアプローチを行う場合、デバイスごとにVPNが接続できるのは1つのゲートウェイだけなので、レガシーVPNの場合は昨今のDXの環境では使いにくくなっていることがわかります。

IAPが提供するセキュリティとは、ユーザーのトラフィックのフローをインターネットを中心に置くことです。認証とアクセス管理を1つのプロキシサーバーで提供することで、ユーザーに唯一の認証ゲートウェイだけを提供し、ユーザービリティとセキュリティの両方を提供するというとても理にかなったアプローチです。

IAPを構成するにはWebサーバーと認証サーバー（IDP）そして、アクセスするためのリソース（アプリケーション）が必要です。更に、オンプレミスのシステムにアクセスする際に登場するのが、コネクターと呼ばれる、インターネットからオンプレミスのネットワークへトラフィックを引き込むための装置が必要となります。

IAPの特徴としては、ユーザーに取ってのインターフェースがWebサーバーなので、基本的にブラウザでIAPにアクセスさえできれば、自身の認証をを行い、IAPのサービスを経由することで、認証と通信をコントロールできるようになります。つまりIAPの特徴を一言で表現するなら、クライアントレス型の認証アクセスと言えるかと思います。

昔からあるテクニックとしては、リバースプロキシであり、IAPの基盤がGoogleやAkamaiといったSaaSによって運用されることで、SaaS、IaaS/PaaSやオンプレミスなどの各種アプリケーションへのアクセスをインターネットを経由して安全に快適に利用できるメリットがあります。

IAP/ZTNA/SDPの違い

SDPについては過去何度かブログで紹介してきていますが、機能的な面と概念的な面があるため、どちらの側面で捉えるかで意味合いが若干変わってくるのですが、とても万能感のあるワードです。さらにSDP関連として、IAP（Identity Aware Proxy）やZTNA（ZeroTrust Network Access）などもこのSDPと密接した機能であるため、相談を受けるケースとしては、ユーザー参考にしたメーカーの表現によって異なるケースが多くあります。

IAP/ZTNA/SDP機能の目的

• SDP (Software Defined Perimeter)
  • 境界線をソフトウェアで定義するネットワーク的な機能
• ZTNA (ZeroTrust Networks Access)
  • SASEのコンポーネントにおいてのプライベートアクセス機能、エージェントアクセス
• IAP (Identity Aware Proxy)
  • Webのプロキシによってアプリケーションアクセスに認証を提供するクライアントレスアクセス

これらの3つの機能は、名称こそ違いますが、基本的には同じような目的を提供することです。 もし明確な定義があるとするなら、制御対象のレイヤーや利用するための環境、コンポーネントレベルでの違いに言及するべきですが、それよりも現状としては各メーカーごとにおける機能差異のほうが大きいため、個人的にはこの細かい機能差異はほとんど意識せずに説明をしています。

各方向性としては一つ違いがあるとするなら、IAPはブラウザベースの提供で、アプリケーションレベルでの制御に対して、ZTNA/SDPはそれよりもレイヤの低いネットワークレベルでの制御という形になります。

ユーザーのアクセスリクエストレベルでの認証とアクセス制御をするなら、IAPのアプローチは便利です。ユーザー環境への依存性を減らしながら、正規のユーザーがアプリケーションを利用するという前提においては、ユーザーの利便性を高められる方法です。

一方ZTNA/SDPはもう泥臭いやり方かも知れません。IAPに対して制御しているレイヤーが低いです。L3/L4での制御となります。しかしネットワークアクセス時に求められる条件はユーザー情報だけではなく、デバイスの信頼情報が加味されます。SDPでは更にコンテキストが利用されるため、ユーザーのアクセス背景情報をソフトウェアで定義するというアプローチになります。

つまり、IAPはユーザーにとっては、ブラウザと自身の正しい認証情報を持っていれば、どんな環境からでも比較的手軽にアプリケーションアクセスができるものに対して、ZTNA/SDPはユーザー側で環境を維持するための負担を課すことになります。この負担とは、デバイスのことですが、それはエージェントを使うことによってより多くの情報を集めることになるため、ユーザービリティとセキュリティがトレードオフの関係だと考えています。

IAPかZTNA/SDPを選ぶかが問題ではない

すべてのアプリケーションがWebで完結する世界であれば、IAPは最も洗練されたゼロトラストアクセスになりえます。ユーザーが利用するデバイスに左右されることなく、ブラウジングさえ可能であれば、自身の情報に即したアクセス権限がどんな状況でも即座に再現できます。

GoogleのChromeがまさにそれを体現しているかのようで、chromeさえ使えれば後は自身の環境をすぐに再現できるというとても便利な世界です。特に公共性の高いアプリケーションにおいては、このIAPはとても取り組みやすいセキュリティアプローチの一つです。

しかし、現状のエンタープライズネットワークアクセスにおいては、全てシステムがブラウザで完結しているでしょうか。また企業のポリシーとしては完全にBYODが認められているわけではないです。このことから、IAPでなければならない理由があるとするなら、BYODが前提で、なるべく幅広い対象の端末からのアクセスを提供することが前提であり、特定のデバイス、カスタマイズされたシステムを考慮すると、ZTNA/SDPといった方法でも同じ目的を達成することが可能だと考えています。

SDPをIAPとして利用することのメリットとは

IAPに対してSDPはちょっと面倒なしくみのように思えるでしょう。実際にはその通りで、ユーザーにはエージェントアクセスを強制するのでユーザーに負担を課しています。この点だけで考えるとSDPにおいてはメリットはないように見えますが、このデメリットを十分に補える点がSDPには存在し得るのです。

SASEベンダーの多くがZTNAをネットワークアクセスのコアとして提供しているケースが多くあります。

SASE製品ではないAppgate SDPはZTNA/SDPのカテゴリーにおいて、実に際立った存在だと考えています。 SaaS型のサービスでもなく、コンテンツセキュリティ（マルウェア対策やIPSといった）さえ搭載していません。

完全なオンプレミスのシステムなので、システム管理者に対して構築という作業を必要として、昨今のSASEブームからすると管理者に敬遠されるかもしれません。

しかし、Appgate SDPはちょっとした構築の労力はあるものの、IAPとしても使える十分な機能備わっていて、セキュリティを重視するならまずは検討ラインにいれるべき理由があります。

Appgate SDPをIAPとして検討する３つの理由

Appgate SDPはオンプレミスシステムであり、特にID連携が得意です。

Appgate SDPのIDP登録画面 複数のIDPを１つのシステム上に設定可能。IDPはSAML/LDAP/Radiusの連携が可能

SASEはとても便利です。私も相談いただく多くのユーザーにSASEをおすすめしています。でもIAPとしての認証連携を必要とするなら、ID基盤との連携性能を重視するべきです。

SASEのよくあるケースですが、特に認証DBとの連携性において、以下のような制約があります。

• 特定のIDaaSのサービスしか連携できない
• ローカルのUserDBと連携できない（AD/LDAP/Radius)
• システム基盤として1つのIDソースのみと連携しかできない

メーカーによって連携状況はまちまちですが、ここはぜひSASE選びの際に確認するべきポイントです。 Appgate SDPは、ほとんどのユーザーDBと連携可能です。ローカルDB、Radius、LDAP/ADに加えて、SAMLによる連携が可能です。 また、登録できるIDPは1つのSDPシステムに対して制限がありません。つまり1つのAppgate SDPのシステム基盤に異なるユーザーDBを複数連携することができます。

SASEにおいては、1つのSASEシステムに付き、1つのIDシステムだけが関連します。1企業あたり1つのID基盤しかなければそれでいいですが、1つのシステムの中に複数のID基盤が混在するような環境だと、ID基盤ごとにSASEの契約が必要です。例えば複数のテナントを収容したい、システムを共有するが、ユーザーDBによってはアクセス制御ルールを管理したいといった要望においては、Appgate SDPの優位性が発揮されます。

今後時間をかけて、システムがゼロトラスト化していく過程で、既存のDBを使ったIAP基盤として活用することも可能です。リプレースする過程においては、IDaaSとActive Directoryの両方をハイブリッドにサポートするなど柔軟な認証連携が必要となります。

特にゼロトラスト/SASE界隈では、IDaaSとの連携はもはや必須です。 IDaaS側でテンプレート化されたZTNAを利用する方法もありますが、今後IDaaSの選択肢も増える可能性もあります。特に国産IDaaSの選択肢を考えるとテンプレート化されたSAML連携だけでなく、オープンな方法で連携が必要となります。

Appgate SDPのSAML連携はAzureADやOktaを始め、一般的なSAMLが使えるなら連携可能です。

残り２つの理由については次編へ続きます。