アイデンティティ認識の実現 SASE

なぜアイデンティティ意識が必要なのか SASE?

前回のブログでは、 解読 SASE のさまざまなセキュリティコンポーネントにおけるアイデンティティ認識について話しました SASE。 この投稿では、アイデンティティ認識を実現するためのさまざまな方法について説明します SASE.

従来の境界中心のセキュリティにおけるアクセス制御は、IP アドレスとサービスを使用して定義されます。 クライアントはアクセス ポリシーで IP アドレスとして表され、サービスはドメイン名と IP アドレスのいずれかで定義されます。 TCP/UDP ポート (HTTP の場合はポート 80、HTTPS の場合は 443 など)。クライアントにはさまざまな種類があるため、PC/ラップトップ/モバイル、クライアント アプリケーション、IoT デバイス、およびさまざまな人間のユーザー カテゴリを介してサービスにアクセスする人間のユーザーなど、さまざまな種類のクライアントが存在します。さまざまなタイプのクライアントを表す各セグメントが作成されます。 各セグメントには、独自のサブネットまたは IP アドレス範囲が与えられます。 これにより、さまざまな種類のクライアントのアクセス制御を定義できるようになります。

さまざまなクライアントのアクセス制御を定義する際のいくつかの課題には対処しましたが、別の複雑さが生じました。 セグメント管理。 すぐに、多くの組織でセグメントの爆発的な増加が見られ始めました。 組織は、差別化されたセグメントを定義するためにさまざまなセグメントを作成する必要があることに気づき始めました。 QoS, WAN リンクの選択、およびさまざまな種類のセキュリティ アクセス制御。

セグメンテーションに関するもう XNUMX つの大きな課題は、「どこからでも働く」 つまり、ユーザーの IP アドレスは、ユーザーがどこから作業しているかに基づいて変化し続けます。 この場合、ユーザーとセグメントの関連付けがすぐに大きな課題になります。 指定されたオフィス、自宅、コーヒーショップ、別のオフィス、または提携オフィスで勤務しているユーザーは、どこから勤務しているかに関係なく、同様に扱われるものとします。

アイデンティティを意識する SASE 少なくとも人間のユーザーに対して、クライアントを区別するためのセグメントを作成する必要性がなくなるため、セグメント管理が簡素化されます。 ただし、IoT デバイスなどのクライアントのセグメントを完全に削除できない場合もあります。

アイデンティティを意識する SASE 「デジタルフォレンジック」にも必要です。 データ侵害が発生した場合、攻撃者が使用したアプローチや悪用された弱点を理解し、全体的な影響を特定するために、攻撃中に何が起こったのかを知ることが重要です。 による "2022 年ベライゾン データ侵害レポート」によると、データ侵害の 82% には人的要素が関与していました。 したがって、最初の感染の原因となったアクセス パターン、訪問したサイト、ユーザーが使用したデバイスとアプリケーションを理解するために、各接続/セッションの ID が非常に重要になります。 さらに、最終的に侵害につながる横方向の攻撃を発見するのにも役立ちます。

要約すると、アイデンティティ意識は、 SASE 以下に役立ちます:

• ファイアウォール、SWG、 CASB さまざまなユーザー向けの ZTNA
• 全体にわたって差別化されたネットワーク ポリシーを定義する QoS、さまざまなユーザーのルーティング
• デジタルフォレンジック
• ユーザー行動分析

アイデンティティ SASE ポリシー

SASE コンポーネント さまざまなサービス/サイトへのアクセスをさまざまな粒度で制御します。 のファイアウォール SASE L3/L4層でのアクセスを制御します。 SWG は、次のレベルでアクセスを制御します。 URLs. ZTNAと CASB API レベルでアクセスを制御します。 SWG、ZTNA、 CASB DLP を使用すると、データ レベルでアクセスを制御できます。 これらすべての制御は、上で説明した理由から、また NIST によって指定されたゼロトラスト ガイドラインを満たすために、ユーザーがセレクターの XNUMX つとして必要です。

どのアクセス コントロール ポリシーにも一連のルールが含まれており、そのほとんどは順序付けされたルールです。 これらのルールはトラフィック セッションごとにチェックされます。 ルールが一致する場合、一致ルールで指定されたアクションが実行されます。 一般的なアクションには、トラフィックの許可、トラフィックの拒否、またはトラフィックの監視とログのみが含まれます。 ルールのマッチングは、一連の属性と一致します。 各ルールは、これらの属性の値を使用して指定されます。 これらの属性には従来、5 つのタプル (送信元 IP、宛先 IP、プロトコル、送信元ポート、宛先ポート)、ゾーン、および場所が含まれます。 新しいトラフィック セッションでは、パケットとコンテキスト (ゾーン、場所) から値が抽出され、ルール属性の値と照合されます。 それらが一致する場合、ルールは一致したと言われます。

アイデンティティ意識を持って SASE、ルール一致属性にはユーザー属性が含まれます。 ユーザー属性には、個々のユーザー名、ユーザー グループ、ユーザー ロール、クライアント証明書サブジェクト名、または証明書サブジェクトの代替名のセットを指定できます。 ポリシーの照合には、ID ベースのユーザー コンテキストとの照合が含まれます。 SASE.

新しいトラフィック セッションでの一般的なポリシー マッチングは次のとおりです。

• パケットから 5 つのタプル (送信元 IP アドレス、宛先 IP アドレス、IP プロトコル、送信元ポート、宛先ポート) を抽出します。
• トラフィック セッションの発信元ゾーンと場所を取得します。
• トラフィック セッションを開始したユーザーの情報 (名前、ユーザー グループ、ユーザー ロール) を取得します。
• トラフィック セッションが開始された場所からマシンのデバイスの状態を取得します。
• 上記で抽出した情報をルール一致属性値と照合することにより、ポリシーの上から下までルールを確認します。 一致するものがあれば、そのルールで指定されたアクションを実行します。 そうでない場合は、次のルールに進みます。
• 一致するルールがない場合は、そのポリシー テーブル レベルに設定されたアクションを実行します。

ユーザーの識別と認証

トラフィック セッションに対するポリシー チェックの前にユーザーを識別する必要があるため、次のような疑問が生じます。

• どのように SASE ユーザーを認証しますか?
• どのように SASE トラフィックを受信したときにユーザーを識別しますか?

そこに行く前に、いくつかの考慮事項を見てみましょう SASE ソリューション 世話をすることになる。 SASE 次のタイプのクライアントを考慮する必要があります。

• 人間のユーザーがブラウザを使用してサービスにアクセスする
• 人間のユーザーがブラウザ以外のアプリケーションを使用してサービスにアクセスする
• サービスにアクセスするために人間の介入なしで動作する非ブラウザー アプリケーション
• CA 証明書ピンニングを使用した非ブラウザー アプリケーション
• サービスにアクセスする IoT デバイス

その意味は SASE ソリューションでは、トラフィック セッションを開始する人間のユーザーが常に存在するとは想定できません。 トラフィック セッションを開始するプログラム エンティティやデバイスが存在する可能性があります。 SASE 両方の種類のクライアントにサービスを提供することが期待されているため、 SASE ソリューションは複数の認証方法をサポートしています。

SASE 次のユーザー エクスペリエンスの課題を考慮する必要があります。

• 人間のユーザーには、ユーザー資格情報を取得するためのポップアップ画面が表示されないか、表示されるポップアップ画面が少なくなるユーザー エクスペリエンス
• 人間のユーザーに特定のアクセスが拒否される理由を通知するユーザー エクスペリエンス
• ユーザーが自分のデバイスを使用してサービスにアクセスする
• 雇用主が管理するデバイスを使用してサービスにアクセスするユーザー
• 在宅勤務でもオフィス勤務でも、ユーザーに均一なエクスペリエンスを提供

上記の要件と影響により、 SASE ソリューションはさまざまな認証モードを実装します。 でサポートされているほとんどの認証モード SASE 解決策はここにリストされています。

• リバースプロキシ認証
• フォワードプロキシ認証
• ポータルベースの認証
• トンネル認証
• クライアント証明書の認証
• APIキーベースの認証

クライアントが認証されると、 SASE 上記を経由して、 SASE ユーザーが開始したトラフィックセッションを適切なユーザーに関連付ける方法を持たなければなりません。 XNUMX つの識別マッピング手法が使用されます。 彼らです：

• トークンマッピング: SASE ソリューションは、HTTP/HTTPS トラフィック セッションのリクエスト ヘッダーの認証/アイデンティティ/ベアラー トークンからユーザーを識別します。 クライアントには認証の一部としてトークンが与えられ、トラフィック セッションでも同じトークンがクライアントによって提示されます。
• 代表的な IP マッピング: このアプローチでは、IP アドレスがユーザーを表します。 SASE ソリューションは、トラフィック セッションの送信元 IP アドレスを使用してユーザーを識別します。 ユーザーが最初に認証するとき、 SASE 正常に、 SASE そのユーザーのユーザー IP アドレスを記録します。 この IP アドレスから送信されるトラフィック セッションは、後でユーザーに関連付けられます。

トークンは、HTTP/HTTPS トラフィック セッションに対してのみ有効です。 トークンはすべての HTTP セッションに直接または Cookie を介して間接的に存在するため、「代表 IP」よりも安全であると考えられます。 非 HTTP/HTTPS トラフィック セッションの場合、「代表 IP」マッピングが使用されます。 SASE ソリューション。 IP アドレスはマシン内のすべてのアプリケーションで使用されるため、「代表 IP」マッピング方法にはいくつかの課題があることに注意してください。 つまり、ブラウザ ユーザーが認証されていても、 SASE このソリューションでは、ブラウザだけでなく、マシン上で実行されている他のすべてのクライアント アプリケーションも同じアクセス権を持つようになります。 マルチユーザー システムの場合、XNUMX 人のユーザーが認証に成功した場合でも、そのシステムのすべてのユーザーがアクセスできるようになります。 SASE 解決。 さらに危険なのは、システムが認証に使用されている場合です。 SASE システムは NAT デバイスの背後にあります。 その NAT IP アドレスの背後にあるすべてのユーザーがアクセスできるようになります。 したがって、必要な場合にのみ「代表 IP」機能を使用し、このマッピングを非 HTTP/HTTPS セッションのみに制限することが特に重要です。

トークン (プロキシ認可ヘッダーまたは認可ヘッダー、または Cookie 経由) は各 HTTP リクエストの一部であるため、クライアント アプリケーションのみが認証されます。 SASE ソリューションはトークンを送信できます。 アクセスを必要とする他の Web ベースのクライアント アプリケーションは、それ自身を認証することが期待されます。 SASE アクセスを取得するためのソリューション。 セキュリティ上の利点があるため、すべての HTTP/HTTPS セッションに対してトークン マッピング アプローチを使用することを強くお勧めします。

各種認証・本人確認 SASE コンポーネント

その他にもたくさんのグーグルの SASE Web ベースのアプリケーション/サービスにセキュリティを提供するコンポーネントは、HTTP リクエスト ヘッダー、クライアント証明書、または API キー内のトークンを介してユーザーを識別し、トラフィック セッションに関連付ける傾向があります。

次のセクションでは、関連する最適な認証モードとさまざまな認証モードのマッピングを示します。 SASE コンポーネント。

ZTNA

ZTNAについては、この記事で説明されているように、 前のブログ、エントを保護することを目的としています。erpマリからの申請が増えるcio私たちと感染したクライアント。 ZTNA は、フロントエンド アプリケーション サービスにより、次の機能を提供します。

• TLS/SSL 非 TLS のセキュリティ/SSL アプリケーションおよび強力な暗号化アルゴリズムをサポートしていないアプリケーション向け
• RBAC をサポートしないアプリケーションおよび第 XNUMX レベルの RBAC を必要とするアプリケーションに対する RBAC / 最小特権アクセスのサポート
• もう XNUMX レベルの MFA による特権アクセス管理
• 複数のアプリケーションインスタンスにわたるトラフィックの負荷分散
• アプリケーションに対する WAF および API レベルの脅威保護セキュリティ

ZTNA は、アプリケーション サービスからセキュリティの責任を奪われるため、ますます必要性が高まっています。 結果として生じる利点には、Ent の生産性の向上が含まれます。erpアプリケーション開発の向上、複数のアプリケーション サービスにわたる均一なセキュリティ構成、攻撃対象領域の減少。

ZTNA は主に Web ベースのアプリケーションを保護することを目的としています。 アプリケーション開発者は、Web プロトコルを使用して新しいアプリケーションを作成するだけでなく、Web プロトコルで起こっているイノベーションを活用するために既存のアプリケーションも Web 化しています。 SSH などの従来の管理プロトコルでさえ、次のようなプロジェクトを使用して Web 化されています。 アパッチワカモレ。 とはいえ、Web 以外のアプリケーションは常に存在します。 ファイアウォールの一部として SASE Ent にアクセス制御と脅威保護セキュリティを提供しますerpインスタンス化された非 Web サービスが増加します。 詳細については、ファイアウォールのセクションを参照してください。

ZTNA はどのようにしてトラフィックにアクセスしますか?

ZTNA は XNUMX つの方法でトラフィックにアクセスします。 DNS 方式と透過プロキシ方式です。

ENTの管理者erprise アプリケーションは、アプリケーションの ZTNA を指すように権限のあるドメイン サーバーを構成します。 つまり、管理者が設定する DNS ZTNA IP アドレスで応答するサーバー DNS アプリケーションの FQ に関するクエリDNs。 透過プロキシ方式では、ZTNA がトラフィックの線上にあることが期待されるか、トラフィックの線上にあるエンティティがトラフィックを傍受して ZTNA にトラフィックを送信することが期待されます。 アプリケーション管理者は、TLS/を使用して ZTNA を構成することもできます。SSL アプリケーション サービスに代わって証明書と秘密キーのペア。

ZTNA はどのようにユーザーを認証し、トラフィック セッションをユーザーにマッピングしますか?

ZTNA は、リバース プロキシ認証、クライアント証明書、および API キー認証モードをサポートし、人間のユーザーやプログラム エンティティなど、さまざまな種類のクライアントを認証します。 次のように動作します。

• ZTNA は TLS/を終端します。SSL 接続
• クライアント証明書がネゴシエートされると、クライアント証明書が検証されます。 有効な場合は、証明書のサブジェクト名と SAN (サブジェクト代替名) が抽出されます。 これらはクライアント ユーザーの ID です。 ユーザー グループまたはロールがプロビジョニングされると、プロビジョニングされたデータベースからグループとロールの情報が抽出されます。
• クライアントが API キーを提示すると、(プロビジョニングされた) 内部データベースを参照してユーザー ID を抽出します。 ユーザー グループまたはロールがプロビジョニングされると、プロビジョニングされたデータベースからグループとロールの情報が抽出されます。
• HTTP リクエストに認証/アイデンティティ トークンが関連付けられている場合は、ユーザーが以前に認証されていることを意味します。 これは、ユーザー コンテキスト (ユーザー名、ユーザー グループ、およびユーザー ロール (存在する場合)) が ZTNA に認識されていることも意味します。
• トークンが無効な場合、またはトークンがない場合は、ユーザーに OIDC 経由での識別と認証を要求します。 ZTNA の OIDC ブローカーは、さまざまな認証プロトコルを使用して、ユーザーが Ent で認証できるようにする場合があります。erp認証サービスが上昇します。 特権アカウントの場合、ZTNA は独自の MFA を実行して、ユーザーが実際に本物のユーザーであることを確認します。
• ユーザーが正常に認証されると、ZTNA の OIDC コンポーネントが ID トークンをセットアップします。 また、ユーザー情報 (ユーザー名、ユーザー グループ (存在する場合)、およびユーザー ロール (存在する場合)) も書き留めます。
• 次に、ZTNA はアプリケーション サービス インスタンスの XNUMX つへの接続を確立します。
• HTTP トランザクションごとにユーザーベースのアクセス制御の決定を実行します。
• ZTNA が高度な脅威保護用に構成されている場合、トラフィックをスキャンしてエクスプロイト、マルウェア、機密データの漏洩がないかどうかも調べます。

ID トークンの有効期限が切れるまで、ユーザーには資格情報を入力する画面が XNUMX 回だけ表示されます。 クライアントの同一生成元ポリシーにより、クライアントはアプリケーション サービスに対する HTTP トランザクションで常に正しい ID トークンを提示します。 ID トークンが有効な場合、ZTNA はその情報を使用してセッションを適切なユーザーにマッピングします。

SWGと CASB

SWG コンポーネントは、マルウェア、フィッシング、安全でないサイトへのアクセスからユーザーを保護します。 また、感染時にクライアント アプリケーションが C&C ボットネット サイトに接触するのを防ぎます。 さらに、SWG は、組織内のユーザーの役割およびユーザーが属するグループに基づいて、さまざまなサイトへの差別化されたアクセスを提供する方法を提供します。 SWG は、さまざまな分析やデジタル フォレンジックに役立つユーザー情報とともにトラフィック セッションのメタデータも記録します。 CASB コンポーネントが耳鼻咽喉科を保護しますerpによって維持される上昇データ SaaS さまざまなデータに対する API レベルのアクセス制御を使用して、適切なユーザーのみがデータにアクセスして変更できるようにすることで、プロバイダーを保護します。 SaaS 分野の様々なアプリケーションで使用されています。 CASBは、SWG と同様に、さまざまな分析やデジタル フォレンジックのためにユーザー情報を含む API メタデータを記録します。

SWGも CASB コンポーネントでは、ユーザーからインターネット サイトに送信される HTTP/HTTPS トラフィックの検査が必要です。 SWGと CASB クライアント接続を終了します。 SSL 許可されている場合は傍受し、さらに詳細なコンテンツ検査を行ってマルウェアを検出して防止し、機密データの漏洩を阻止します。

SWG と CASB トラフィックにアクセスできますか？

SWG& CASB プロキシは、プロキシ/PAC 方式と透過的方式という XNUMX つの方式でトラフィックを取得します。

プロキシ/PAC 方式では、クライアント マシン/アプリケーションはプロキシ設定で手動で構成されるか、クライアント アプリケーションがプロキシの自動検出によって自動構成されます。 クライアント アプリケーションがプロキシを認識すると、クライアント アプリケーションは HTTP CONNECT メソッドを使用してデータ セッション (通常は HTTP および HTTPS トランザクション) をトンネリングします。 HTTP CONNECT URI は、内部 HTTP および HTTPS トランザクションの目的の宛先を示します。 プロキシはこれを使用します URL 宛先サイトに接続します。 プロキシは、クライアントとサーバーからのデータの受け渡し、またはその逆のデータの受け渡しを許可する前に、アクセス制御および脅威防御サービスを実行します。

透過的プロキシ方式では、クライアントはプロキシについて知りません。 プロキシがトラフィックを把握するためにトラフィックの線上にあることが期待されます。

SWG/CASB プロキシはユーザーを認証し、トラフィックセッションをユーザーにマッピングしますか?

プロキシ/PAC 方式を使用して SWG/CASB プロキシに接続すると、プロキシは HTTP CONNECT トランザクションの一部としてユーザーを認証する機会を取得します。 これを「フォワードプロキシ認証」と呼びます。 HTTP CONNECT ベースのフォワード プロキシ認証について説明します ここ 結構。 このリンクでは NTLM 認証について説明していますが、同様のフローが Kerberos 認証にも同様に適用できます。 HTTP CONNECT はすべての HTTP/HTTPS トラフィック セッションに先行するため、ユーザーは各セッションでプロキシに認識されます。 この方法の利点の XNUMX つは、ブラウザ アプリケーションに加えて、ほとんどのネイティブ クライアント アプリケーションもプロキシ設定を尊重し、プロキシで認証できるため、インターネット アクセスのほとんどのユースケースをカバーできることです。

透過プロキシ方式では、HTTP CONNECT トランザクションはありません。 したがって、フォワードプロキシ認証はできません。 ユーザー認証はすべて、HTTP リクエストをリダイレクトするなど、通常の HTTP 認証スキームを使用して行う必要があります。 SASE ポータルでは、OIDC および SAML メソッドを使用してユーザーを認証します。 このような認証を「ポータルベース認証」と呼びます。 ユーザーが正常にログインすると、ポータルは Cookie を設定できますが、ブラウザーの同一生成元ポリシーにより、ユーザーがインターネット サイトを閲覧するとき、これはプロキシには表示されません。 この課題のため、ユーザーがログインに成功すると、ポータルはユーザー名とユーザー認証セッションの送信元 IP アドレス間のマッピングを作成し、このマッピングをプロキシに通知します。 プロキシは後でこのマッピングを使用して、トラフィック セッションをユーザーにマッピングします。 使用可能なマッピングがない場合、プロキシはログインのためにトラフィック セッションをポータルにリダイレクトします。 この「マッピング」を「代表 IP マッピング」と呼びます。 前述したように、このマッピング方法は意図しない関係者にアクセスを公開する可能性があるため、慎重に使用する必要があります。

透過的プロキシ メソッドは、受信 HTTP トランザクションのリダイレクトに依存します。 これは、経由でクリアなトラフィックを把握する必要があることを意味します。 SSL 傍受。 場合があります。 SSL/TLS インターセプトは許可されていないか、不可能です。 このような場合にはリダイレクトは不可能であるため、ユーザーは次のように認証されることが期待されます。 SASE ポータルによるプロアクティブ認証や「トンネル認証」などの他のメカニズムを介して。

ファイアウォールおよびL3/L4ベースの機能

ファイアウォールと関連する NAT、ルーティング、 QoS 関数は L3/L4 層レベルでパケットを処理します。 これらの機能は、トラフィックの線上にあるシステム内にある必要があります。 もっと頻繁に、 SASE これらの機能を備えたシステムは、サイトやリモート ユーザーからのトラフィックへのゲートウェイとなります。

ファイアウォールは、アクセス制御、リバース プロキシ、フォワード プロキシに関して HTTP および HTTPS を超えるあらゆる種類のプロトコルを処理するため、オンデマンドのポータル認証メカニズムは不可能です。 ユーザーの認証には主に、明示的ポータル認証とトンネル認証という XNUMX つのモードが使用されます。

明示的ポータル認証モードでは、ユーザーは、 SASE ブラウザでポータルを指定して、 SASE ポータル。 の SASE ポータルは OIDC とともにユーザーを認証します。 この場合も、 SASE 「代表 IP」マッピング方法を使用します。 の SASE ポータルは、ユーザー認証が成功すると、IP アドレスとユーザーのマッピングをファイアウォールに送信します。 ファイアウォールおよび L3/L4 機能は、これらのマッピング レコードを使用して、トラフィック セッションをユーザーに関連付けます。

トンネル認証モードでは、クライアント デバイスに特別なソフトウェアをインストールする必要があります。 クライアントはトンネル セッションを確立します SASE 積極的に。 そのトンネルの一部は、 SASE。 IPSec ベースのトンネルが使用されている場合、トンネル認証は SASE/IKEv2 コンポーネント。 SASE/IKEv2 コンポーネントは、ユーザー (イニシエーター ID) と仮想 IP アドレスのマッピングをアドバタイズします。 SASE セキュリティおよびネットワーク サービス。 ファイアウォールおよび L3/L4 機能は、「代表 IP」マッピング方法を使用して、トラフィック セッションをユーザーにマッピングします。

ここではこれら XNUMX つの認証モードについて明示的に説明していますが、ユーザーが「リバース プロキシ」モードまたは「フォワード プロキシ」モードでプロキシに対して認証する場合、IP アドレスからユーザーへのマッピングもプロキシから取得される可能性があります。

ここで注意すべき点は、ユーザー固有のルールが有効である場合にはユーザー認証が行われることが期待されるということです。 ユーザーが認証されていない場合、ポリシー一致ロジックはユーザーが不明であると想定します。 このため、ファイアウォールおよび L3/L4 レベルでのユーザーベースのポリシーは便宜的であると考えられます。 ユーザーに積極的にログインするよう奨励/思い出させるには、 SASE ソリューションは、ユーザーにログインするよう通知するブラウザ通知を生成する傾向があります。 SASE ポータル。

企業間とアプリ間の SASE そしてアイデンティティ

企業間とアプリ間の SASE 議論されました ここ、そしてその投稿はさまざまな利点を提供しました。erp「統一」から得られる上昇 SASE」の提供品。

Status SASE はさまざまな個別のコンポーネントから構築されているため、ユーザー認証が複数回行われる可能性があり、優れたユーザー エクスペリエンスとは言えません。 「統一」とは SASE、' ユーザーは、全体にわたって XNUMX 回だけ認証されることが期待されます。 SASE。 これは、「統合」の追加の利点の XNUMX つです。 SASE。 '

企業間とアプリ間の SASE これらの製品は、統一的かつ包括的な方法で、共通の可観測性プラットフォームにユーザー情報を関連するログ メッセージに追加します。 SD全体でユーザーの行動を監視することで、さまざまな分析や異常検出に役立ちます。WAN およびセキュリティサービス。

まとめ

マイクロセグメンテーションのアプローチは必要ですが、マイクロセグメンテーションを拡張してさまざまなユーザーを分類することは、スケーラブルなソリューションではありません。 SASE ソリューションでは、ID ベースのポリシーの定義と適用が可能になることが増えています。 SASE ソリューションでは、ユーザーを認証し、トラフィック セッションをユーザーにマッピングすることでこれを行います。 SASE ソリューションは、ユーザーが認証するためのさまざまな方法を提供します。 SASE。 この投稿では、いくつかの方法について説明しました。 Aryaka 「アイデンティティ認識」の旅が始まりました SASE'。  Aryaka SWG ソリューションは、ユーザー固有のポリシーの適用をサポートします。 詳しくはこちら Aryaka SWG ソリューションはこちら: https://www.aryaka.com/secure-web-gateway/

• CTO の洞察ブログ

  　 Aryaka CTO Insights ブログ シリーズでは、ネットワーク、セキュリティ、およびセキュリティに関するソート リーダーシップを提供します。 SASE トピック。 のために Aryaka 製品仕様を参照してください Aryaka データシート。