さて、Appgate SDPのコントローラー、ゲートウェイの構築が完了しましたので、今回のテーマはポリシーの作成です。

ゼロトラスト的な要素の強いシリーズになるので、しっかり確認していきましょう。

Appgate SDP 6 Layer Trust Model

---

Appgate SDPの象徴的な機能概要で、全てのアクセスデバイスが、ファイアウォールの外側に存在しているという前提で、プライベートなアプリケーションへリモートアクセスする際のイメージ図です。

Appgate SDPが提供するゼロトラストアプローチは、6階層のセキュリティチェックによってパケット、デバイス、ユーザー、コンテキストが常に検証されている状態を保証することです。

1. シングルパケット認証（パケットの検証）
2. 登録されたデバイス（オンボーディング）
3. 正しいアイデンティティ（ユーザー認証）
4. コンテキストの定義とアクセス権限
5. 要求に応じて信頼の昇格
6. 振る舞いの監視

これらの6階層はユーザーから目的のアプリケーションに至る過程において、1つの例外もなくゼロトラストネットワークアクセスとして検証、証明される機能です。

今回のブログでは、この6 Layer Trust Modelの図をイメージしながら確認すると、とても良くわかると思います。

ポリシーを作る（コンテキストの定義とアクセス権限）

---

少し順番は前後しますが、"4. コンテキストの定義とアクセス権限"に該当する設定を見ていきたいと思います。

従来のリモートアクセス型のVPNでも、認証されたユーザーに対してアクセス権限の設定をすると思います。Appgate SDPでも同じように、リモートからアクセスするユーザーやデバイスに対してネットワークの範囲やアプリケーションレベルで権限を付与することができます。

Appgate SDPのアクセスポリシー割り当てのイメージです。わかりにくいかもしれませんが、なんとか伝わるといいですが。。

Appgate SDPの特徴は前回の投稿にも書いていますが、コントローラーとゲートウェイに機能が明確に分離されていることです。この分離によって、パフォーマンスのスケーラビリティを必要に応じて追加したり、減らしたりすることができますが、パフォーマンスの要件だけではありません。

リモートユーザーに対して、状況に応じたアクセス制御を行うためにはこのような仕組みがどうしても必要となります。

1. リモートユーザーからコントローラーで、デバイス認証とユーザー認証を行い、アクセスポリシーを払い出します。
2. アクセスポリシーに従って、リモートユーザーはゲートウェイに目的のアプリケーション宛の通信を行います。(エンタイトルメント）
3. このエンタイトルメントは常時コンディションチェックが行われていて、Appgate SDPで定義されたコンディションを維持していることを求めます。

この3つの関係性により、Appgate SDPはVPN接続時にユーザーに割り当てたポリシーを接続中に何らかのコンディションの変化を検知すると、ポリシーではなくエンタイトルメントを制御することで、ポリシーの中身を変えることができます。

従来のVPNのように管理機能とデータプレーンが1つのOS上で制御されている仕組みだと、VPN認証時に払い出したポリシーについては、「VPNトンネルを切断しない限りポリシーの更新ができないこと」に対してのかなりのアドバンテージになると思います。

Appgate SDPは従来のVPNと同じように、ログイン時に割り当てたVPNポリシー自体の変更はできないですが、ポリシーの中に作られたエンタイトルメント情報をゲートウェイ側で制御することで、ユーザーやデバイスの状態に応じた"適用型ポリシー"を提供することができるということです。

少し乱暴な表現をすると、

• コントローラーのAssignment機能によって、リモートデバイスへアプリケーションへのルーティングテーブルを提供します。
• エンタイトルメントはファイアウォールとして動作しており、コンディション違反があった場合は、ルーティングを書き換えるのではなく、ファイアウォールポリシーをブロックすることで目的のアプリケーションへの接続を制御することができます。

システムの中に2段階の制御コンポーネントが組み込まれていて、状況の変化に応じて、動的に制御できるというのが強みです。

そのためポリシーを作成するためには、ポリシーと言う箱の中に、Assignement、Entitlementを埋め込む必要があり、またEntitlmentにはConditionを連携しておく必要があります。

ちょっとなんのことかイメージがわかりにくいと思いますので、この関係性を頭にイメージしながら設定をするとわかりやすいので、先に説明だけ入れておきました。

ポリシーの新規作成

OperationsからPolicyと進んで新規作成を行います。

つまり、ポリシーという箱を設定します。このポリシーはユーザー/デバイスが認証されたときに提供される情報です。

このポリシーの中には2つの要素が設定できます。

• Assignment
• Entitlement

Assignmentとは

Assignmentとは、ポリシーをユーザー、デバイスに提供するための条件設定です。

Appgate SDPではユーザー、デバイス、システムの情報を取得することで、単純なユーザーやデバイス情報だけではなく、コンテキストと呼ばれる接続元の背景情報をポリシーの提供条件とします。

例えば以下のようなAssigmentポリシーをセットします。

• ローカルの認証DBに登録されているユーザー *　接続元は日本からアクセスすること
• 月曜日から金曜日の間
• デバイスのファイアウォールが有効になっている
• デバイスはドメインに参加している
• デバイスのユーザーは管理者権限を持っていない
• OSの言語は日本語となっている

このようなポリシーを渡すための条件文を自由に組み合わせることができます。

このAssignmentの条件に設定するクライテリアは予めセットされており、非常に多く用意されています。組織のユーザー、デバイスを定義するための十分なクライテリアがあります。

Entitlementとは

Assignmentはポリシーを渡すための条件ですが、Entitlmentとは条件が合致した際に提供するアクセスするための資格情報です。（通行手形のようなものです）

注意として、この手順だと予めEntitlementの設定をしていなかったので、ポリシーに埋め込む情報がありませんので以下のように"No match"となってしまいます。

一旦、ポリシーの作成を中断し、Entitlementの作成を先に行います。

Entitlmentは通信のアクセス制御を行うためのルール設定です。そのため、関連付けはSite（サイト）/ゲートウェイに関連づく必要があります。

※今回は1サイト構成の例なので"Default Site"に関連付ければ問題ありません。

Action

アクションは以下のようにIPアドレスとポート番号で接続先のオブジェクトを定義することができます。

このActionもとても高度な制御ができて、

• ルールは許可、ブロック、モニター
• プロトコルはTCP、UDP、ICMP、AH、ESP、GREが指定可能で、通信の方向（UP/クライアント起点、Down/サーバー起点）
• ターゲットはIPアドレス、FQDN、リソース名、エンタイトルメントスクリプト
• ポート番号（TCP/UDPは1-65535、ICMPは0-255）

で表現することが可能です。

Technical Tip: Action

SASE/ZTNA関連お多くの製品が"Service-Initiated"型のZTNAサービスを提供しています。クラウド上にZTNAのコントローラーを用意し、リバースプロキシのような形で組織内に設置されたコネクターを経由してリモートアクセスを提供する方式です。

この方式のメリットとしては、

• コネクターの展開がシンプル
• コントローラーはSaaSとして提供される
• エージェントレス方式に対応
• ネットワークの設計が簡単

というメリットがある反面、通信プロトコル/接続方法にかなりの制約があります。

メーカーごとに対応状況はかなり変わってきているようですが

• 直接IPアドレスの通信ができない（コントローラーがセッションを管理しているため）
• TCPベースの通信しか許容されない(WebやRDP、SSHなど）
• ICMPが使えない
• SNATしかサポートされない

手軽な反面、いくつか制約があるというのが現状です。もちろんこの範囲でリモートアクセスの要件が満たせれるのであれば十分です。

ただ既存のリモートアクセスVPNからのリプレースを想定すると、ネットワーク的なリモートアクセスの要件としては若干足りない（UDPやICMP通信）やクライアント/サーバーの双方向通信などは"Endpoint-Initiated"方式のSDPがより柔軟なネットワーク制御ができることがわかります。

Actionの設定

今回は以下のようにアクションを設定しました。実環境ではもっと細かく宛先の制御を行いますが、一旦AWSのVPCの宛先を許可（TCP/UDP/ICMP）をしている状態です。

なおConditionについては、今回はデフォルトで用意されている"Always"をそのまま利用します。

これで、Entitlememtが完了したので、再度ポリシーの設定に戻ります。

ポリシーの設定

とても簡易的なポリシーです。必要に応じて適宜AssignmentとEntlementを設定してください。

シリーズ3まとめ

---

今回はZTNAの違いがわかるポリシー（AssigmentとEntitlment）を取り上げてみました。

実際のところAppgate SDPの運用で最も時間をかかる部分で、接続元のユーザ、デバイスを正しく定義する際は最も重要な場所となります。

いわゆるSDP（Software Defined Perimeter）における、組織内の状態をこのポリシーのAssignmentで表現できるか、またEntitlmentで最小権限を提供できるかというゼロトラストの真価が問われる部分です。

もちろん時間をかけてじっくりSDPの設計をすることも正しいです。しかし最初から最適なポリシーを作ることはできないので、まずは既存のレガシーVPN同等のポリシーからスタートして、じっくり時間をかけてユーザーの働く場所を定義していくアプローチを行っていけば、組織のネットワークは次第にゼロトラスト化することができるようになると思っています。

次回はAppgate SDPの特殊機能 "SPA (Single Packet Authorization)"について特集します。