この記事では、Catoのシングルパスクラウドエンジンアーキテクチャ(SPACE)に基づくPoPにおけるセキュリティエンジンのパケットフローを説明します。
CatoのSPACEアーキテクチャは単一のサービスでトラフィックフローを検査および処理します。 このサービスには、トラフィックフローを同時に分析し処理する複数のネットワークおよびセキュリティエンジンが含まれています。 このアーキテクチャは、サービスチェイニングによる複数のポイントソリューションの組み合わせの制限を回避します。 フローの単一パスはレイテンシーを最小限に抑え、全体的なネットワークパフォーマンスを向上させます。 各PoPは、CatoのすべてのSPACEサービスとエンジンを使用して、これらのネットワークおよびセキュリティの決定を実行できます。
セキュリティおよびネットワークエンジンは、トラフィックフローのデータにフルアクセスし、共有コンテキストで互いにデータを評価および共有します。 エンジンは並行して動作しており、トラフィックを評価する際に他のエンジンより優先されるものはありません。 エンジンは各PoPに配置されており、異なる物理ロケーションのエンジンからの情報を待たずにデータを共有できます。
例えば、ファイアウォールルールがmacOSデバイスをブロックする場合、ファイアウォールエンジンはこのデータを最初のパケットでは取得できず、さらにデータを待ちます。 別のエンジンがmacOSとしてデバイスを識別した場合、ファイアウォールはルールアクションに従ってフローをブロックします。
このセクションでは、パケットフローの異なるフェーズに適用されるPoPのネットワークおよびセキュリティサービスとエンジンを一覧します。
-
Catoポリシーとエンジン
-
ファイアウォール - インターネットおよびWANファイアウォールのファイアウォールポリシー
-
ネットワーク - ルーティングおよびQoS優先順位のためのネットワークルールポリシー
-
IPS/SAM - 侵入防止システム(IPS)による保護と疑わしい活動の監視(SAM)
-
アプリ制御 - アプリケーション制御ポリシーのためのアプリケーション識別
-
App Control gen2 - アクセスに基づくアプリのルール: 許可またはブロック
-
App Control gen3 - 詳細なアクションに基づくアプリのルール: アップロード、ダウンロードなど
-
-
TLSi - HTTPSおよび暗号化トラフィックのTLSインスペクション
-
DLP - データ漏洩防止(DLP)ポリシーのためのコンテンツ検査
-
AM/NGAM - アンチマルウェアおよび次世代アンチマルウェアによるマルウェアスキャン
-
-
トラフィックフロードデータとプロトコル
-
アプリケーション識別 - セキュリティまたはネットワーキングポリシーのための特定のアプリケーションを識別するための様々な基準
-
OS - デバイスのオペレーティングシステム(OS)、例としてデバイスポスチャやクライアント接続ポリシー
-
クライアントクラス - このネットワークフローを作成したオペレーティングシステム上で動作するクライアントアプリケーションのタイプ(例: Chrome)
-
URLF - ウェブサイトのURLに基づくCatoカテゴリーのURLフィルタリング
-
File_type - CASBおよびDLPのための、アップロードまたはダウンロードの方向でのファイル添付
-
以下の項目を含む典型的なHTTPフローの一例です。
-
タイムライン - トラフィックフローの異なるフェーズ
-
利用可能なフィールド - 特定のタイムラインフェーズで利用可能なデータ
-
Catoエンジン - フローを分析し、その後適切なアクション(ブロックまたは許可)を取ることができるSPACEエンジン
-
トラフィックフロードデータ - 各フェーズで、トラフィックフローを評価するために使用されるデータ
下記の詳細のリストを参照できます。 サンプルTCPフローの詳細。
これはSlackアプリケーションを含むルールのトラフィックフローの例で、各段階で利用可能な情報を示しています。
-
最初のパケット - TCP
送信元 - 10.10.2.107 送信元ポート - 55477 宛先IP - 3.68.124.168 宛先ポート - 443 プロトコル - TCP DNS応答 - 3.68.124.168 - slack.com (オプションの応答)
これは、このサンプルの最初のパケットに基づいて利用可能なトラフィックフロー情報です。
-
5タプルでは、このトラフィックがSlackアプリケーションに接続されていることを特定できません。
-
DNS応答 - 前のフローに基づいて、エンジンはこの宛先IPのdnameがslack.comであることをすでに知っています。
-
ASN - 宛先IPに基づいて、セキュリティエンジンはASNを特定できます。
-
アプリケーション識別には、tcpが含まれます。
エンジンは、Slackアプリの識別を完了する前に、TLSハンドシェイクからの追加情報を待ちます。
-
-
tls_handshake
"TLSヘッダー" "sni_host": "slack.com" "定義済みインスペクションバイパス理由": "なし" "ja3_formatted_str": "771,4865-4866-4867-49195-49199-49196-4920…"
これは、このサンプルのtls_handshakeに基づいて利用可能なトラフィックフロー情報です。
-
TLSヘッダーとサーバーポート443 - TLSプロトコルと一致
-
SNIはslack.com - Cato Slackアプリ識別と一致
SNIはまたURLFに送信され、カテゴリ「ビジネス情報」、「コンピューターと技術」、「ソーシャル」と一致します。
-
クライアントクラスはJA3 - TLSフィンガープリンティングに基づいてクライアントをブラウザとして分類
-
TLSインスペクションまたはバイパスアクション - クライアントクラスとアプリ識別に基づく
-
アプリケーション識別には、tcp、tls、slackが含まれます。
-
-
HTTP
"url" : "upload.slack.com: "host_name" : "slack.com" "Content-Type" : "application/pdf" "Content-Disposition" : form-data; name="file"; filename="sample-data.pdf" "Content-Length" : "52765"
このサンプルフローでは、HTTPデータに基づいて以下の情報が利用可能です。
-
アプリケーション識別には、tcp、tls、http、slackが含まれます。
-
TLSインスペクションはフローを復号化し、Slackサーバーのホスト名がslack.comであることを識別します。
-
HTTPヘッダー - HTTPプロトコルと一致
HTTP_hostがSNIと一致する一般的な例であり、アプリ識別には変更がありません。
-
URL - アップロードプレフィックスがより細かい粒度を提供し、アプリケーション制御ポリシーのアップロードアクションと一致できます。
-
Content-Type、Content-Disposition、Content-Length - ファイル名、サイズ、タイプに関する情報を提供します。
-
アプリケーション制御ポリシーアクション:
-
コーポレートSlackテナントのみを使用するポリシーを適用
-
ファイルタイプに基づくファイル制御
アンチマルウェアおよび次世代アンチマルウェアはダウンロード方向でのみファイルをスキャンします。
-
-
-
HTTPボディ
"HTTPボディペイロード" : "ファイル自体"
例として、DLPポリシーはSlackメッセージでクレジットカードデータを使用できないことを強制します。
-
Slackアプリケーションのアプリ識別が完了しました。 それはソーシャルカテゴリに属するトラフィックとして識別されます。
-
ファイルコンテンツが準備完了になると、これらのエンジンはファイルコンテンツを分析します。
-
DLPエンジンはデータ制御ポリシーに基づいてコンテンツをスキャンします。
-
アンチマルウェアおよび次世代アンチマルウェアはダウンロード方向でファイルをスキャンします。
-
-
このセクションでは、トラフィックフローを分析し実行するCatoセキュリティポリシーとエンジンを説明します。
WANファイアウォール、インターネットファイアウォール、およびネットワークルールポリシーは、しばしば最初のパケットでトラフィックフローを評価できます。 例えば、5タプルからのデータに基づいたルールです。 しかし、AzureやSlackなどの特定のアプリケーションにマッチするルールの場合、エンジンがフローを評価するにはトラフィックフローからの追加データが必要です。 これは、エンジンがフローを評価するフェーズが特定のルールの設定に依存することを意味します。
ファイアウォールルールの種類に関する詳細は、インターネットとWANファイアウォールポリシー–ベストプラクティスを参照してください。
この例では、PoPエンジンがIPアドレスとポートを使用する単純なネットワークルールと、Azureアプリのための複雑なファイアウォールルールでトラフィックフローをどのように異なる評価するかを示しています。 ネットワークエンジンは最初のパケットに基づいてフローを評価できますが、PoPはファイアウォールエンジンの分析を完了するために追加のデータを待ちます。
サンプルネットワークルール
次のネットワークルールは、ポート範囲8000 - 8010のIP範囲としての送信元であり、トラフィックはロンドンPoPロケーション経由で流出します。
ネットワークエンジンは、5タプルに基づいてトラフィックフローのルーティング決定を評価できます。
サンプルWANファイアウォールルール
次のWANファイアウォールルールは、上記のネットワークルールのIP範囲と同じ送信元であり、RnDユーザーグループのメンバーであるユーザーに対するトラフィックを許可します。 さらに、ルールはHTTP(S)、TLS、FTP、およびTFTPサービスのAzureアプリケーション用です。
ファイアウォールエンジンは最初のパケットでトラフィックを評価できません。なぜなら、フローのユーザーID、Azureアプリケーション、およびサービスを確認する必要があるからです。 エンジンが評価を完了し、フローがすべての基準を満たした後、エンジンはフローを許可します。 PoPはまた、最初のパケットに基づいてルーティング決定を適用します。
URLフィルタリングサービスはウェブサイトのURLを分析し、既知または疑わしい悪意や不適切なウェブサイトのデータベースと比較することで機能します。 このサービスは、成人向けコンテンツ、ギャンブル、ソーシャルネットワーキング、またはストリーミングメディアなど、そのカテゴリーを決定するためにウェブサイト自体のコンテンツを分析する場合もあります。
カテゴリについて詳しくは、カテゴリの操作を参照してください。
TLSインスペクションエンジンは、パケットフローのtls_handshakeフェーズ中に関与します。 フローを検査するかどうかは不可逆的な決定であり、2段階で行われます。
-
第1段階 - client_helloパケットの最初のペイロードが、TLSインスペクションエンジンがこのトラフィックフローを検査するかどうかの初期の指示を提供します。
-
第2段階 - client_helloが完全に解析され、TLSインスペクションポリシーアクションが適用されます(フローを検査またはバイパス)。
HTTPSフローの場合、第1段階に基づいてパケットをブロックする決定が下される可能性があります。 しかし、エンジンは引き続き通信し、エンドユーザーに正しいファイアウォールまたはIPSブロックページを提示するためにTLS接続を確立します。
IPSエンジンはトラフィックフローのライフサイクル中実行し続けます。 特定のアイテムを異なる段階で検査し、その段階でIPS保護に一致するコンテンツに対処します。 IPSは虫眼鏡のように機能し、常にフローで確認されたトラフィックからの更新を待ち、エンジンに情報を提供し続けます。
次の例は、フローの異なる段階で利用可能なさまざまな情報を示しています。
-
フローのプロトコルはHTTPプロトコルです。
-
ペイロードに基づいて、TLSです。
-
クライアント_ハローがTLS 1.3暗号スイートTLS_AES_256_GCM_SHA384を使用します。
異なるIPS保護は、上記のアイテムのいずれかに一致し、その段階でトラフィックフローに対処できます。
DNSの保護はIPSエンジンの一部であり、(TCPやUDPのようなトランスポートとの接続なしに)リクエストとレスポンスのDNSフローで動作します。
DNSリクエスト中に、ドメイン名はドメインの評判と静的フィードに基づいて分析および評価されます。 次にDNSレスポンス中に、解決されたIPとコンテンツが潜在的に悪意のあるコンテンツについて分析されます。 DNS保護ポリシーは、ブロックまたは許可のトラフィックフローに一致する任意のコンテンツに適用されます。
アプリケーション制御エンジンはトラフィックを検査し、アプリケーション制御ポリシーのアクションを適用し、各新しいHTTPトランザクション(リクエストとレスポンス)で評価されます。
gen2アプリには、アプリ識別を完了するためにTLSとHTTPプロキシが必要です。
セキュリティとコンプライアンス要件を含むルール:
-
他のネットワークおよびセキュリティエンジンからのコンテキストデータに基づいて、アプリケーション制御エンジンはtls_inspectionフェーズ中にこれらの要件を評価できます
-
エンジンがSNIからこの情報を取得し、TLSやアプリケーションの完全な識別(レイヤー7 DPI)を必要とせずにアプリケーションを評価できる場合もあります。
DLPエンジンはトラフィックフローのコンテンツを検査し、アプリ制御エンジンの拡張版です。 ポリシーにファイルタイプまたはファイルサイズが指定されている場合、エンジンはこれらのファイル特性をアプリケーションメタデータとペイロードを検査する必要があります。
-
エンジンはファイルの種類を評価し、コンテンツ検査のためにサポートされているファイルのリストと一致するかどうかを確認します。
-
その後、gen3アプリの識別が完成し、コンテンツとデータが格納されるフィールドの特定のコンテンツ署名が特定されます。
-
コンテンツが検査され、定義されたコンテンツプロファイルに一致するかどうかが確認されます。
アンチマルウェアとSentinelOne次世代アンチマルウェアエンジンは、受信トラフィック(ファイルダウンロード)のファイル添付を既知および未知のマルウェアについてスキャンします。 file_typeはHTTPレスポンス、またはFTPトラフィックのリクエストに基づいています。
HTTP、HTTPS、およびFTPアプリケーションとサービスのみがスキャンされます。
-
エンジンはアプリケーションがアンチマルウェアポリシーのルールと一致するかどうかを確認します。
-
ファイルは次のファイルリストと一致します。
-
Cato管理画面で設定された許可リスト-これらのファイルはダウンロードが許可されます。
-
Catoセキュリティチームによって管理されるブロックリスト-これらのファイルはブロックされます。
-
-
ファイルはアンチマルウェアと次世代アンチマルウェアエンジンによってスキャンされ、判定が返されます:悪意のある、疑わしい、または無害。
-
アンチマルウェアポリシーの適切なアクションがファイルに適用されます。
URLフィルタリングはWANトラフィックに適用されますか?
いいえ、URLフィルタリングはインターネットトラフィックにのみ適用され、WANを介したアカウントトラフィックには適用されません。
ファイアウォール対IPSポリシーのためのGeo-Restriction設定の違いは何ですか?
デバイス設定のWANとインターネットファイアウォールでは、細かいルールのためのソース国を定義できます。 ただし、宛先国の制御はありません。
地理的制限タブは、IPS ポリシーで送信元または送信先のいずれかの制限付きトラフィックを定義します。 ただし、IPSはアカウント全体のグローバルポリシーであり、特定のサイトやオブジェクトにジオ制限設定を適用することはできません。
-
タイムライン - 最初のパケット
-
利用可能な項目 - 5-tuple、ホスト名(dname)
-
Catoエンジン - ファイアウォール、ネットワーク、IPS/SAM
-
トラフィックフローデータ - アプリ識別、クライアントクラス、OS種別
-
-
タイムライン - tls_handshake
-
利用可能な項目 - 暗号スイート、ホスト名(SNI)
-
Catoエンジン - IPS/SAM、アプリ制御gen2、TLSi、ファイアウォール、ネットワーク
-
トラフィックフローデータ - アプリ識別、クライアントクラス、URL
-
-
タイムライン - HTTP_headers
-
利用可能な項目 - ヘッダー、URL、ホスト名(ホストヘッダー)
-
Catoエンジン - アプリ制御gen3、IPS/SAM
-
トラフィックフローデータ - ファイルタイプ(アップロード)、OS
-
-
タイムライン - HTTP_body
-
利用可能な項目 - HTTPリクエスト、HTTPボディ
-
Catoエンジン - アプリ制御gen3、DLP、IPS/SAM
-
トラフィックフローデータ - ファイルタイプ(アップロード)、アプリ識別
-
-
タイムライン - HTTP_response
-
利用可能な項目 - HTTPレスポンスヘッダー、HTTPレスポンスボディ
-
Catoエンジン - マルウェア対策/次世代アンチマルウェア、アプリ制御gen3、DLP、IPS/SAM
-
トラフィックフローデータ - ファイルタイプ(ダウンロード)、アプリ識別
-
0件のコメント
サインインしてコメントを残してください。