今回のテーマはレガシーVPNでは真似ができない、コンディショナルアクセス編です。

リモートアクセスをゼロトラスト化するための重要なファクターなのでしっかり見ていきましょう。

Appgate SDP 6 Layer Trust Model

---

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

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

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

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

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

コンテキストとは

---

ZTNA/SDPとVPNを比べて真価している点は"コンテキスト"だと思います。

ZTNA/SDPはコンテキストによってユーザーやデバイスを識別し、最も適切なポリシーを適用するためのソリューションです。つまりコンテキストをどれだけ正確に定義できるかが、ZTNA/SDPを選択する上で重要な条件となるわけです。

組織のユーザーが正しいデバイスを利用してリモートアクセスいるということをどのようにすれば証明できるでしょうか。

従来のアクセス元を特定する方法としては

• ユーザーアカウント（知っている情報）
• デバイス情報-MACアドレス/デバイス証明書（持っている情報）

を組み合わせることで安全性を担保するケースが多いと思います。

しかし、実際のところ、ユーザーアカウントは簡単に使いまわしもできますし、デバイス情報のようなものは、複製や偽装、またはその入手先の根拠が曖昧だったりします。

接続元を特定しているつもりで採用している、認証機能は、どれだけ複雑なパスワードを使っても、あるいは形だけのデバイス証明書の採用も、接続元の根拠としてはやや不完全な状態です。

コンテキストのイメージ

コンテキストとは、正規のユーザーなら気にもせず使っている環境情報です。もちろんアイデンティティ情報（ユーザーアカウント、デバイス証明書など）が中心ですが、そういった利用者の背景情報を論理的に表現して、それを接続条件にポリシーすることができれば理想的だと思います。

例えば、日本で働くユーザーなら、日本語の環境のOSを利用することが前提です。企業の端末ならドメインに参加していることが前提だったり、管理者権限を持っていないことやファイアウォール機能が有効になっていることなどです。

SDPの"どはまりパターン"とは、この前提を制御することができるということです。前提=コンテキスト。正規のユーザーが当たり前に使っている状態をコンテキストとしてルール化することです。

コンテキストの見え方

接続中のユーザーのコンテキストはAppgate SDPからこのように見えます。

ここの情報を組み合わせることで、コンテキストを作り上げることができます。

コンテキストにポリシーが関連するわけ

---

Appgate SDPのポリシーやアクセス権限の適用というのは、認証されたユーザーやデバイスに適用しているのではありません。

接続される時に収集されたコンテキストに合わせたセキュリティポリシーが適用されます。

同じユーザーアカウント、同じデバイスを使っていても、アクセスしている場所が変わるだけでもコンテキストは変わります。

同じように、同じユーザーアカウントでもパソコンとモバイルデバイスではコンテキストが変わります。

コンテキストが従来のIDベースの認証より優れているのは、ユーザーにとっては些細な状態変化をシステムが検知し、それをポリシーへ適用することができるということです。

コンテキストの評価は継続することこそがゼロトラスト

---

リモートアクセスVPNのよくあるケースとして、安全性のために、パスワードを強化、デバイス認証、ホストチェッカーを利用するという手法がよく利用されます。

安全性を優先するために、利用者へワンタイムパスワードの入力や定期的なパスワードの更新などの業務を強いる必要があります。

レガシーVPNの場合は認証を通過するまではとても強力な認証機能で守られますが、1度VPNの接続が完了した後の状態はどのようになっているでしょうか？

接続前の状態と接続中/後の状態は同一だという保証はどのように証明することができますか？ 接続前の状態が"A"だとした場合、接続後の状態が"A"であることの証明がとてもむずかしいです。

こちらはAppgate SDPのコンディショナルアクセスの例です。

Appgate SDPの特徴は、前シリーズにも記載していますが、SPAや接続時のコンテキストの検証です。それ以外にもデバイス証明書を利用したデバイスの検証も行われています。

Appgate SDPは接続する前の状態を接続している間も評価し続けることができます。

認証情報をコンテキストに置き換えること、コントローラーとゲートウェイの2つの役割の異なるコンポーネントを利用すること、その2つのコンポーネントがコンテキストを評価し合うことで、接続前の状態"A"が接続後の状態"A"であることを検証することができます。

そして、もし状態"A"が保持できていないと確認できると、速やかに"A"の条件に関連している資格情報を失効させることができる仕組みになっています。

これが真のゼロトラストネットワークアクセスであり、たとえ安全なVPNを利用したとしても、そこにある暗黙の了解を放置せずに、全ての通信を検証することが可能となるわけです。

従来のリモートアクセスVPNよりも柔軟なポリシー、ユーザーへの負荷軽減、拡張性とパフォーマンス、そして何よりも安全性を優先したネットワークアクセスを同時に実現します。

例えばWindowsファイアウォールの有効/無効化、管理者権限の昇格、レジストリ値の書き換え、または送信元IPの変化など監視するべき状態の変化は多岐に渡ります。

ユーザーが無意識に操作しても、コンテキスト常に変化します。このコンテキストを継続して監視し続けて、その状況に応じたアクセス資格を適用することがコンディショナルアクセスとなります。

コンディショナルアクセスの設定

---

設定方法は以下の通りです。

コンディションはEntitlementに関連します。特に何も設定せずに進めている場合は、Alwaysというコンディションが適用されているはずです。

コンディションの新規作成は以下の通りです。

デフォルトではAlwaysのみが設定されていますので、Add Newから新規作成を行います。

コンディションの作成は以下の通り設定します。

設定は

• Access Criteria
• User Action
• Re-Evaluate Periodically(UTC)

の3点です。

Action Criteria

Access Criteriaとはコンテキストのことです。Appgate SDPに接続しているユーザーのコンテキストとして、保持しているべき状態を定義します。

User Action

User ActionとはAccess Criteriaが保持できなかった時のアクションです。

• メッセージの表示（任意のメッセージ）
• MFAの入力を求める
• Provide Reason
• パスワードの入力

から違反検出時のアクションが選べます。

Re-evaluate periodically

コンディションの検証間隔です。

• 再検証なし
• 1時間に1回
• 15分に1回
• 5分に1回

というように、ポリシーに設定したAccess Criteriaとは別の角度からEntitlmentを維持するための条件を定義します。

私のイメージとしては

コントローラーは総合窓口として、ポリシーの払い出しをするけれども、ゲートウェイは払い出された資格情報を維持しているかを監視することができる仕組みを作っています。

極端な例ですが、たとえパスワードが漏洩して、なりすましユーザーがコントローラーを突破したとしても、ゲートウェイによって定義されているコンディション状態を維持できていないと目的のアプリケーションには到達できません。

そのため、ポリシーに設定するAccess Criteriaはポリシーを提供するための固定の情報を定義し、コンディションに設定するAccess Criteriaはシステムやデバイスの状態によって変化する可能性のある内容を定義するという２つの異なる要素を接続条件としても設定することができます。（作り方は組織それぞれによります）

Entitlmentへコンディションの適用

以下の要領で"Always"の設定から先程作成したコンディションを適用するだけで完了します。

コンディショナルアクセスの動作

---

わかりやすく、ファイアウォールのON/OFFでWebサーバーへのアクセス権限を失効させる例です。（時間は短縮再生しています）

このように、リモートアクセス後もシステムの状態をAppgate SDPが監視しつづけているため、ユーザーが気づかずやってしまっている些細なことから、内部ユーザーの悪意のある状態を素早く検知してアクセスを遮断することもできます。

ユーザーに負荷をかけず、利便性の高さと安全性を両立することがゼロトラストネットワークアクセスです。

シリーズ５まとめ

---

さて、全5シリーズを通して、Appgate SDPの基本設定をベースに私からお伝えしたいAppgate SDPの魅力を投稿させていただきました。多少ファンタジー的な表現もあるかもしれませんが、イメージを掴んでいたければ幸いです。まだまだ語るべき機能はたくさんありますが、"構築するシリーズ"としては一旦ここまでとして、次回以降は拡張機能編ということで不定期に更新していきますので、乞うご期待ください。

リモートアクセスVPNはユーザー認証や暗号化通信によって、安全なリモート接続を提供するためのソリューションでしたが、残念ながらVPNの仕組みを悪用されるケースも増えてきています。

ユーザー認証ができたからと言って、そのユーザーが正しい操作をする根拠もなければ、そのログインしているユーザー自体がなりすましの可能性もあります。

ZTNA/SDPは、働き方の変化とともにとても重要な役割を担うことは間違いありません。ユーザーのアクセスを1本化することは、ユーザービリティの向上、システム管理者としても監視のポイントを集約することは重要です。

5Gの普及やテレワークが更に一般化すると、ユーザーのロケーションの分だけ働く場所が存在しえます。SDP（Software Defined Perimeter）はその全ての働く人の環境を強制するのではなく、開放することと同時にガバナンスを効かせることができる優れた手法です。

今回のコンディショナルアクセスは、リモートアクセス機能としては必須の機能ではないですが、昨今のセキュリティリスク（VPNの不正アクセス、サプライチェーン攻撃など）を見てみると、信頼されているはずの場所やアカウントを使った攻撃が増えています。

外部からの直接的な攻撃はさまざまな対策手法が存在しますが、信頼している場所を保護するソリューションは実のところ多くはなく、ユーザーの良心に頼っていることが現状です。もちろん組織のユーザーは信頼するべきですが、ユーザー自身が無意識に、何らかのマルウェアに感染することもあれば、ほんの少し魔が差すことで、許容されていないアクセス方法で、プライベートデータへアクセスしてしまうケースもあります。

プライベートデータを守ることも重要ですが、この無意識のユーザーの些細な悪意をシステムが検知して制御することで、コンプライアンスを守るという考え方も重要だと思います。

Appgate SDPはZTNA/SDPに必要な機能だけを提供する、とてもシンプルなソリューションです。クラウドの基盤（IaaS/PaaS）へ導入することもできれば、オンプレミスの環境にも導入できます。

100%ソフトウェアで提供され、ハードウェアに依存せず、今ある環境に素早く導入することもできれば、必要に応じてスケールアップ、スケールアウトすることも可能です。

本ブログを読んでいただいて、小さな環境からゼロトラストネットワークアクセスを初めて、その安全性を実感していただければ幸いです。