なぜSASEでアイデンティティを意識するのですか？

アイデンティティを意識したSASEの実現 前回のブログ「SASEを読み解く」では、SASEの様々なセキュリティ・コンポーネントにおけるアイデンティティの認識についてお話しました。 この投稿では、IDを意識したSASEを実現するための様々な方法について説明します。 従来の境界中心のセキュリティにおけるアクセス制御は、IPアドレスとサービスを使用して定義されます。 クライアントはアクセスポリシーのIPアドレスとして表され、サービスはドメイン名とIPアドレス、HTTPのポート80やHTTPSのポート443などのTCP/UDPポートで定義されます。 PC/ノートPC/モバイル、クライアントアプリケーション、IoTデバイス、そして様々な種類の人間ユーザーがサービスにアクセスするため、各セグメントが様々なタイプのクライアントを表すセグメンテーションアプローチを考案しました。 各セグメントには、独自のサブネットまたはIPアドレス範囲が与えられます。 これにより、異なるタイプのクライアントに対するアクセス制御を定義することが可能になります。 さまざまなクライアントのアクセス制御を定義するという課題には対処できましたが、セグメント管理という別の複雑さが生じました。 瞬く間に、多くの組織がセグメントの爆発的な増加に気づき始めました。 組織は、差別化されたQoS、WANリンクの選択、さまざまなタイプのセキュリティ・アクセス制御を定義するために、さまざまなセグメントを作成する必要性を認識し始めました。 セグメンテーションのもうひとつの大きな課題は、”どこでも働ける “ことに関連しています。 つまり、ユーザーのIPアドレスは、ユーザーがどこから作業しているかに応じて変化し続けます。 この場合、ユーザーとセグメントの関連付けはすぐに大きな課題となります。 指定されたオフィス、自宅、喫茶店、他のオフィス、またはパートナーオフィスから勤務しているユーザーは、どこから勤務しているかにかかわらず、同じように扱われるものとします。 アイデンティティを意識したSASEは、少なくとも人間のユーザーにとっては、クライアントを区別するためのセグメントを作成する必要性をなくし、セグメント管理をよりシンプルにします。 しかし、IoTデバイスのようなクライアントのセグメントを完全に削除することはできません。 ID を認識する SASE は、「デジタル・フォレンジック」にも必要です。何らかのデータ侵害があった場合、攻撃者の使用したアプローチ、悪用された弱点を理解し、全体的な影響を特定するために、攻撃中に何が起こったかを知ることが重要です。 2022 Verizon Data Breach Report」によると、データ漏えいの82%に人的要因が関与しています。 したがって、最初の感染を引き起こしたアクセスパターン、訪問したサイト、ユーザーが使用したデバイスやアプリケーションを理解するためには、各接続/セッションの身元が非常に重要になります。 そうすれば、最終的に侵害につながる横からの攻撃を見つけるのに役立ちます。 要約すると、SASEにおけるアイデンティティの認識は、以下のことに役立ちます：

  • ファイアウォール、SWG、CASB、ZTNAにまたがる、さまざまなユーザーに対する差別化されたアクセス・ポリシーの定義
  • 様々なユーザーのためのQoS、ルーティングにわたる差別化されたネットワーク・ポリシーの定義
  • デジタル・フォレンジック
  • ユーザー行動分析

SASEポリシーにおけるアイデンティティ

SASEコンポーネントは、様々なサービス/サイトへのアクセスを様々な粒度で制御します。 L3/L4層でのSASE制御アクセスのファイアウォール。 SWGはURLレベルでアクセスをコントロールします。 ZTNAとCASBはAPIレベルでアクセスを制御します。 DLPによるSWG、ZTNA、CASBはデータレベルでのアクセス制御が可能です。 これらのコントロールはすべて、上記で説明した理由と、NISTによって指定されたゼロ・トラスト・ガイドラインを満たすために、ユーザーをセレクタの1つとする必要があります。 アクセス・コントロール・ポリシーには、ルールのセットが含まれています。 これらのルールはトラフィックセッションごとにチェックされます。 ルールが一致した場合、一致したルールで指定されたアクションが実行されます。 典型的なアクションには、トラフィックの許可、拒否、またはトラフィックの監視とログが含まれます。 ルールのマッチングは属性のセットで行われます。 各ルールは、これらの属性の値で指定されます。 これらの属性には、伝統的に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はユーザが開始したトラフィックセッションを正しいユーザに関連付ける方法を持たなければなりません。 2つの識別マッピングアプローチを使用。 それは

  • トークンのマッピング：SASEソリューションは、HTTP/HTTPSトラフィックセッションのリクエストヘッダ内のAuthentication/Identity/Bearerトークンからユーザーを識別します。 クライアントには認証の一部としてトークンが与えられ、同じトークンがトラフィック・セッションでクライアントから提示されます。
  • 代表IPマッピング：このアプローチでは、IPアドレスがユーザーを代表します。 SASE ソリューションは、ユーザーを識別するために、トラフィック・セッションのソース IP アドレスを使用します。 ユーザが初めてSASEで認証に成功すると、SASEはそのユーザのIPアドレスを記録します。 後日、このIPアドレスから来るトラフィックセッションはすべて、そのユーザーに関連付けられます。

トークンは、HTTP/HTTPSトラフィック・セッションに対してのみ有効です。 トークンは全てのHTTPセッションに直接またはクッキーを介して間接的に存在するため、「代表IP」よりも安全であると考えられています。 IPアドレスはマシン内の全てのアプリケーションによって使用されるため、「代表IP」マッピング方法にはいくつかの課題があることに注意してください。つまり、ブラウザのユーザがSASEソリューションで認証されたとしても、ブラウザだけでなく、マシン上で実行されている他のすべてのクライアントアプリケーションも同じアクセスを持つことになります。マルチユーザシステムの場合、一人のユーザが SASE ソリューションの認証に成功しても、そのシステムの全てのユーザがアクセスすることになります。さらに危険なのは、SASEシステムの認証に使用されるシステムがNATデバイスの背後にある場合です。そのNAT IPアドレスの後ろにいる全てのユーザがアクセスすることになります。したがって、「代表IP」機能は必要な場合にのみ使用し、このマッピングを非HTTP/HTTPSセッションのみに制限することが特に重要です。 トークンは(proxy-authorizationヘッダ、authorizationヘッダ、クッキーを介して)各HTTPリクエストの一部であるため、SASEソリューションで認証されたクライアントアプリケーションのみがトークンを送信することができます。 アクセスを必要とする他のウェブベースのクライアントアプリケーションは、SASEソリューションにアクセスするために自分自身を認証する必要があります。 セキュリティ上の利点から、すべての HTTP/HTTPS セッションでトークンマッピングアプローチを使用することを強くお勧めします。

様々なSASEコンポーネントによるユーザー認証と識別

ウェブベースのアプリケーション/サービスにセキュリティを提供する多くの SASE コンポーネントは、HTTP リクエストヘッダのトークン、クライアント証明書、または API キーによって、ユーザを識別し、トラフィックセッションに関連付ける傾向があります。 以下のセクションでは、関連する認証モードと最適な認証モードを、様々な SASE コンポーネントにマッピングしています。

ゼットエヌエー

ZTNA は、この前のブログで説明したように、悪意のある感染クライアントからエンタープライズアプリ ケーションを保護するためのものです。 ZTNAは、フロントエンドのアプリケーションサービスにより、以下の機能を提供します。

  • 非TLS/SSLアプリケーションや強力な暗号アルゴリズムをサポートしないアプリケーションのためのTLS/SSLセキュリティ
  • RBACをサポートしていないアプリケーションや、セカンドレベルのRBACを必要とするアプリケーションのためのRBAC / 最小特権アクセスサポート
  • もう1つのレベルのMFAによる特権アクセス管理
  • 複数のアプリケーション・インスタンスにまたがるトラフィックの負荷分散
  • アプリケーションのWAFおよびAPIレベルの脅威防御セキュリティ

ZTNAは、アプリケーション・サービスからセキュリティの責任を奪いつつあるため、ますますその必要性が高まっています。 その結果、エンタープライズアプリケーション開発の生産性が向上し、複数のアプリケーションサービスにわたって統一されたセキュリティ構成が実現し、攻撃対象領域が減少するというメリットが得られます。 ZTNAは、主にウェブベースのアプリケーションを保護するためのものです。 アプリケーション開発者は、ウェブ・プロトコルで新しいアプリケーションを作成するだけでなく、既存のアプリケーションもウェブ・プロトコルで起きているイノベーションを利用するためにウェブ化しています。 SSHのような伝統的な管理プロトコルでさえ、Apache Guacamoleのようなプロジェクトを使ってウェブ化されています。 とはいえ、ウェブ以外のアプリケーションは常に存在します。 SASEの一部であるファイアウォールは、エンタープライズがインスタンス化した非ウェブサービスに対して、アクセス制御と脅威防御のセキュリティを提供します。 詳しくはファイアウォールの項をご覧ください。 ZTNAはどうやってトラフィックにアクセスするのですか？ ZTNAは、DNS方式と透過プロキシ方式の2つの方法でトラフィックにアクセスします。 エンタープライズアプリケーションの管理者は、アプリケーションの ZTNA を指すように、 権威ドメインサーバーを構成します。 つまり、管理者は、アプリケーションのFQDNに対するDNSクエリに対して、ZTNA IPアドレスで応答するようにDNSサーバーを設定します。 トランスペアレントプロキシ方式では、ZTNAはトラフィックのライン上に存在するか、トラフィックのライン上に存在するエンティティがトラフィックをインターセプトし、ZTNAにトラフィックを送信することが期待されます。 また、アプリケーション管理者は、アプリケーションサービスに代わって、TLS/SSL証明書/秘密鍵ペアを使用してZTNAを設定します。 ZTNAはどのようにユーザーを認証し、トラフィックセッションをユーザーにマッピングするのですか？ ZTNAは、リバースプロキシ認証、クライアント証明書、APIキー認証モードをサポートし、人間ユーザーやプログラムエンティティなど、さまざまなタイプのクライアントを認証します。 仕組みは以下の通り：

  • ZTNAがTLS/SSL接続を終了
  • クライアント証明書がネゴシエートされていれば、クライアント証明書を検証します。 有効であれば、証明書のサブジェクト名とSAN（Subject Alt Name）を抽出します。 これらはクライアント・ユーザーのIDです。 ユーザーグループまたはロールがプロビジョニングされている場合、プロビジョニングされたデータベースからグループとロールの情報を抽出します。
  • クライアントがAPIキーを提示すると、内部データベース（プロビジョニング済み）を参照してユーザーIDを抽出します。 ユーザーグループまたはロールがプロビジョニングされている場合、プロビジョニングされたデータベースからグループとロールの情報を抽出します。
  • HTTP リクエストに関連する認証/ID トークンがある場合は、そのユーザーが以前に認証されたことを意味します。 また、ユーザーコンテキスト（ユーザー名、ユーザーグループ、ユーザーロール（もしあれば）がZTNAに知られていることを意味します。
  • トークンが無効な場合、またはトークンが存在しない場合は、OIDCを介した識別と認証をユーザーに要求します。 ZTNA の OIDC ブローカは、さまざまな認証プロトコルを使用して、Enterprise 認証サービスでユーザーを認証できます。 特権アカウントについては、ZTNAは独自のMFAを実行し、ユーザーが本当に本物のユーザーであることを確認します。
  • ユーザーの認証に成功すると、ZTNAのOIDCコンポーネントがIDトークンを設定します。 また、ユーザー情報（ユーザー名、ユーザーグループ（ある場合）、ユーザーロール（ある場合））をメモします。
  • 次にZTNAは、アプリケーション・サービス・インスタンスの1つへの接続を確立します。
  • HTTPトランザクションごとにユーザーベースのアクセス制御決定を行います。
  • ZTNAが高度な脅威防御に設定されている場合、エクスプロイトやマルウェア、機密データの漏えいについてもトラフィックをスキャンします。

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

SWGとCASB

SWGコンポーネントは、マルウェア、フィッシング、安全でないサイトへのアクセスからユーザーを保護します。 また、感染時にクライアントアプリケーションがC&Cボットネットサイトに接触しないように保護します。 さらにSWGは、組織内でのユーザーの役割や、ユーザーが所属するグループに基づいて、様々なサイトへの差別化されたアクセスを提供する方法を提供します。 SWGはまた、様々な分析やデジタルフォレンジックに役立つユーザー情報とともに、トラフィックセッションのメタデータを記録します。 CASB コンポーネントは、さまざまな SaaS アプリケーションの API レベルのアクセス制御を使用して、適切なユーザのみがデータにアクセスおよび変更できるようにすることで、SaaS プロバイダが保持するエンタープライズデータを保護します。 CASBもSWGと同様、APIのメタデータをユーザー情報と一緒に記録し、様々な分析やデジタルフォレンジックに活用します。 SWGとCASBの両コンポーネントは、ユーザーからインターネットサイトに向かうHTTP/HTTPSトラフィックの検査を必要とします。 SWGとCASBは、クライアント接続を終了し、許可されている場合はSSL傍受を行い、マルウェアを検出・防止し、機密データの漏洩を阻止するために、より深いコンテンツ検査を行います。 SWGとCASBはどうやってトラフィックにアクセスするのですか？ SWGとCASBのプロキシは、プロキシ/PAC方式とトランスペアレント方式の2つの方法でトラフィックを取得します。 Proxy/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トラフィックセッションの前にあるので、ユーザーは各セッションでプロキシに知られています。 この方法の良い点は、ブラウザアプリケーションだけでなく、ネイティブクライアントアプリケーションの大半もプロキシ設定を尊重し、プロキシで認証できるため、インターネットアクセスのほとんどのユースケースをカバーできることです。 透過プロキシ方式では、HTTP CONNECTトランザクションはありません。 したがって、フォワードプロキシ認証は不可能です。 ユーザ認証は、HTTPリクエストをSASEポータルにリダイレクトするなど、通常のHTTP認証スキームで行う必要があります。 このような認証は「ポータル・ベース認証」と呼ばれます。 ユーザがログインに成功すると、ポータルはクッキーを設定できますが、ブラウザの同一生成元ポリシーにより、ユーザがインターネットサイトを閲覧する際、このクッキーはプロキシには見えません。 この課題のため、ユーザがログインに成功すると、ポータルはユーザ名とユーザ認証セッションのソースIPアドレスの間のマッピングを作成し、このマッピングをプロキシに通知します。 後でプロキシはこのマッピングを使用して、トラフィックセッションをユー ザーにマッピングします。 利用可能なマッピングがない場合、プロキシはログインのためにトラフィックセッションをポータルにリダイレクトします。 この「マッピング」は「代表IPマッピング」と呼ばれています。 前述したように、このマッピング方法は、意図しない相手にアクセスを許してしまう可能性があるため、慎重に使用しなければなりません。 透過的なプロキシは、HTTPトランザクションのリダイレクトに依存します。 つまり、SSL傍受によってクリアなトラフィックを入手する必要があるということです。 SSL/TLSの傍受が許可されない、または不可能な場合があります。 このような場合、リダイレクトは不可能であるため、ポータルやトンネル認証など、他の方法でSASEに認証されることが期待されます。

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

ファイアウォールおよび関連するNAT、ルーティング、QoS機能は、L3/L4レイヤーレベルのパケットに対して機能します。 これらの機能は、トラフィックのラインにあるシステムにある必要があります。 より多くの場合、これらの機能を持つSASEシステムは、サイトやリモートユーザーからのトラフィックのゲートウェイとなります。 ファイアウォールは、アクセス制御、リバースプロキシ、フォワードプロキシに関して、HTTPとHTTPS以外のあらゆる種類のプロトコルを扱うため、オンデマンドのポータル認証メカニズムは不可能です。 ユーザー認証には、主に明示的ポータル認証とトンネル認証の2つのモードがあります。 明示的ポータル認証モードでは、ユーザはブラウザをSASEポータルに向けることで、SASEポータルに認証されます。 SASEポータルは、OIDCと共にユーザーを認証します。 この場合も、SASEは「代表IP」マッピング法を使用します。 SASEポータルは、ユーザ認証に成功すると、IPアドレスとユーザのマッピングをファイアウォールに送信します。 ファイアウォールとL3/L4機能は、これらのマッピングレコードを使用して、トラフィックセッションをユーザーに関連付けます。 トンネル認証モードでは、クライアント・デバイスに特別なソフトウェアをインストールする必要があります。 クライアントは、SASEとのトンネルセッションを積極的に行います。 そのトンネルの一部はSASEで認証されます。 IPSec ベースのトンネルが使用される場合、トンネル認証は SASE/IKEv2 コンポーネントによって処理されます。 SASE/IKEv2コンポーネントは、ユーザー（イニシエータID）と仮想IPアドレスのマッピングをSASEのセキュリティとネットワーキングサービスにアドバタイズします。 ファイアウォールとL3/L4機能は、「代表IP」マッピング方法を使用して、トラフィックセッションをユーザーにマッピングします。 これらの2つの認証モードがここで明示的に言及されているとしても、IPアドレスとユーザのマッピングは、ユーザが「リバースプロキシ」、「フォワードプロキシ」モードでプロキシに認証する場合、プロキシからも来る可能性があります。 ここで注意すべき点は、ユーザー固有のルールを有効にするためには、ユーザー認証が必要であるということです。 ユーザが認証されていない場合、ポリシー一致ロジックはユーザが不明であるとみなします。 このため、ファイアウォールやL3/L4レベルでのユーザーベースのポリシーは、日和見的と見なされます。 ユーザーに積極的にログインするよう促すために、SASEソリューションは、SASEポータルにログインするようユーザーに通知するブラウザ通知を生成する傾向があります。

統一されたSASEとアイデンティティ

Unified SASEについては、ここでも取り上げました。その投稿では、「Unified SASE」の提供から得られる企業の様々な利点が紹介されています。 SASEが様々な個別のコンポーネントから構築されている場合、ユーザ認証は何度も行われるかもしれません。 Unified SASE “では、ユーザはSASE全体で一度だけ認証されます。 これは、’Unified SASE’の追加的な利点の一つです。Unified SASEは、統一的かつ包括的な方法で、関連するログメッセージにユーザー情報を追加し、共通の観測可能なプラットフォームに提供します。 SDWANとセキュリティサービス全体のユーザー行動を監視することで、さまざまな分析と異常検知に役立ちます。

概要

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

  • CTOインサイトブログ

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