インターネットとSaaSへのセキュアなアクセス(ZIA)
完全データ一致インデックステンプレートを理解する
Exact Data Match (EDM)インデックス テンプレートを作成する場合は、データ レコードのトークン(つまり、条件)を定義し、少なくとも1つのプライマリー フィールドを指定する必要があります。プライマリー フィールドは、DLPポリシー ルールの基になる一意のキーです。これは必須フィールドであり、データ レコードに基づいて一意である必要があります。
EDMは、プライマリー フィールドまたはセカンダリー フィールドなしで機能するように設定できます。詳細は、「DLP詳細設定の構成」を参照してください。
主フィールドには、可変長の標準フォーマット(例:クレジットカード番号)または固定長のカスタムフォーマット(例:アルファベット値)を含めることができます。詳しくは、 完全データ一致テンプレートの作成をご覧ください。
EDMテンプレートの作成と使用に関する詳細は、以下を参照してください。
- データおよびDLPポリシーの評価
Zscalerでは、EDMインデックス テンプレートを作成する前に、次の点を考慮することをお勧めします。
- 作成するDLPポリシーと保護したいデータを確認します。
- DLPポリシーを確認しながら、EDMインデックス・テンプレートに含める必要のあるデータを検討します。
- データレコードのインデックスを一度作成すれば、可能な限り再インデックス作成の必要がないようなテンプレートを作成してみてください。
- 重複の可能性を避けるため、データ記録を確認します。
次のような例で考えてみましょう。
従業員データベースを持つ銀行で、従業員の個人を特定できる情報(PII)と会社のクレジット カード情報を保護したいとします。
データベースのレコードには、姓(FName)、名(LName)、社会保障番号(SSN)、クレジットカード番号(CCN)、携帯電話番号、郵便番号、住所(Street Address)などのデータフィールドがあります。
ZIAで作成するDLP辞書やエンジンは、DLPポリシーで使用するため、従業員の情報を適切に保護するために、一連のフィールドの組み合わせをカバーする必要があります。したがって、この例のレコードに基づいて、次のデータフィールドの組み合わせのいずれかを使用してDLP辞書を作成することができます。
- SSN、FName、LName
- CCN、FName、LName
- SSN、CCN、LName
- SSN、CCN、FName、LName
ただし、Index Toolを使って作成するEDMインデックステンプレートは、必要なフィールドの組み合わせを辞書でカバーできるようにする必要があります。これは、必要なデータフィールドの組み合わせに基づいて主フィールドを選択することで実現できます。
閉じる - EDMインデックステンプレート内のプライマリーフィールドの特定
前のセクションで説明した例を使用すると、主フィールドを指定することで、従業員の情報を保護するための1つのEDMインデックステンプレートを作成することができます。
- 従業員のPII DLP辞書と関連するポリシーに必要なすべてのデータフィールドの組み合わせが網羅されています。
- クレジットカードのDLP辞書と関連するポリシーに必要なすべてのデータフィールドの組み合わせが、会社のクレジットカードが従業員に発行されるたびにカバーされます。
- 従業員データレコードのインデックス作成は1回で済みます。
そこで、Index Toolを使用して、以下のフィールドを含むEDMインデックステンプレートを作成することになる。
- SSN
- CCN
- FName
- LName
必要な従業員PII DLPディクショナリーを作成するには、プライマリー フィールドとしてSSNを選択します。ただし、同じテンプレートを使用して会社発行の従業員クレジット カードDLPディクショナリーを作成するには、セカンダリー プライマリー フィールドとしてCCNも選択する必要があります。その他の含まれるフィールド(FName、LNameなど)は、両方のディクショナリーのセカンダリー フィールドとして適用されます。
最後に、この例では、BankNumは後で作成するDLPポリシーの必須データフィールドではないので、テンプレート内に含まれません。
ZIA管理ポータル内でPII固有のDLPディクショナリーを作成する場合は、SSNとFNameおよびLNameを含むデータ フィールドの組み合わせをカバーする必要があります。そのため、[ディクショナリーのタイプ]として[完全データ一致]を選択し、作成したEDMインデックス テンプレートに基づいて次の定義を追加します。
- 従業員PIIの定義
- プライマリフィールドとして選択されたSSN
- セカンダリーフィールドとして選択されたFNameとLName
- Secondary Match On向けに選択されたすべてのフィールド
Zscalerサービスは、プライマリー フィールドとセカンダリー フィールドの間でANDブール演算を想定しています。また、セカンダリー一致条件の場合、「Any」(セカンダリー フィールドから少なくとも1件一致、セカンダリー フィールドから少なくとも2件一致)はOR演算を想定し、「All」(つまり、すべてのフィールド)はAND演算を想定します。
つまり、上記の定義は、Zscalerサービスによって「SSN AND (FName AND LName)」と評価されます。
CCNはEDMインデックス テンプレート内のセカンダリー プライマリー フィールドとして含まれているため、会社のクレジット カード固有のDLPディクショナリーに同じテンプレートを使用できます。この例では、CCNとFNameまたはLNameを含むデータ フィールドの組み合わせをカバーする必要があります。そのため、従業員のデータ レコードのインデックスを再作成することなく、次の定義を追加できます。
- 会社発行の従業員CCNの定義
- プライマリフィールドとして選択されたCCN
- セカンダリーフィールドとして選択されたFNameとLName
- Secondary Match On向けに選択されたMatch At Least 1 from Secondary Fields
つまり、上記の定義は、Zscalerサービスによって「CCN AND (FName または LName)」と評価されます。
この2つのDLP辞書を使用することで、本サービスは以下のデータフィールドの組み合わせがDLPエンジンに追加された際に評価し、DLPポリシーのルールを作成するために使用することができます。
- SSN AND (FName AND LName)
- CCN AND (FName OR LName)
詳細については、DLPエンジンについてを参照してください。
閉じる - [EDMインデックステンプレート]でデータレコードを評価する
Zscalerサービスがデータ レコードを評価する場合、3文字以上の文字列のみが評価されます。サービスは空白のセルを無視します(つまり、サービスは空白のセルを暗黙的な一致とは見なしません)。
たとえば、名、姓、生年月日(DD MM YYYY)を含むSSNを含む PII固有のDLPディクショナリーが必要です。まず、次のCSVファイルを使用してEDMインデックス テンプレートを作成します。
SSN 名 姓 生年月日 123-45-6789 ヨハネ 鍛冶屋 234-56-7891 メアリー 01 01 1990 354-67-8912 褐色 02 02 1985 次に、EDM インデックス テンプレートに基づいて次の定義を持つ辞書を作成します。
- 従業員PIIの定義
- プライマリフィールドとして選択されたSSN
- セカンダリフィールドとして選択された名と姓
- Secondary Match On向けに選択されたMatch At Least 1 from Secondary Fields
この定義では、1 次フィールドと少なくとも 1 つの 2 次フィールドが存在する場合に一致が行われます。ただし、2 次フィールドが空白の場合、一致は発生しません。
従業員がSSN「123456789」と名「John」を含むファイルをアップロードすると、一致が発生します。従業員が代わりにSSN「345678912」を含むファイルをアップロードした場合、セカンダリー フィールドが一致しなかったため、一致は発生しません。この例では、使用可能なセカンダリー フィールドは「Brown」のみで、ドキュメントには存在しませんでした。
定義の 2 次フィールドの数を増やすことに決めます。
- 従業員PIIの定義
- プライマリフィールドとして選択されたSSN
- セカンダリフィールドとして選択された名、姓、生年月日
- セカンダリマッチオン用に選択されたセカンダリフィールドから少なくとも2つを一致させます
この定義では、プライマリフィールドと少なくとも2つのセカンダリフィールドが存在するときに一致が発生します。しかしながら、セカンダリフィールドの少なくとも1つが空白の場合、一致は発生しません。
従業員がSSN「234567891」、名「Mary」、生年月日「01 01 1990」を含むファイルをアップロードすると、一致が発生します。従業員が代わりにSSN「123456789」と名「John」を含むファイルをアップロードした場合、姓は存在せず、生年月日は空白であるため、一致は発生しません。
閉じる - 従業員PIIの定義
- EDMテンプレート処理を理解する
インデックス ツールでのEDMテンプレートの作成中に[送信]ボタンをクリックすると、ZIAはEDMテンプレートを処理して、テンプレートが正しく作成されたことを確認します。ZIAによる処理では、データ エラー、プライマリー フィールド重複エラー、通信エラーなど、EDMテンプレートに関連する問題がチェックされます。ZIAで問題が見つからない場合は、インデックス ツールでEDMテンプレートに対して完了のステータスが表示され、テンプレートをZIA管理ポータルで使用できます。ZIAで問題が見つかった場合は、インデックス ツールのEDMテンプレートに対してエラーの状態が表示されます。
EDMテンプレートのプロセスの詳細は、テンプレートの詳細]ページで表示できます。このページにアクセスするには、インデックスツールでEDMテンプレート行を選択します。[テンプレートの詳細]ページには、EDMテンプレートプロセスが正常に完了したか、またはプロセス中にエラーが発生したかに応じて、さまざまな情報が表示されます。完了したEDMテンプレートの場合、次の情報がページに表示されます。
- テンプレートの詳細
- テンプレートの定義
EDMテンプレートが誤っている場合、次の情報の一部またはすべてがページに表示されます。
- タイプ
- 原因
- 推奨される措置
- ログの詳細
- テンプレートの詳細
- テンプレートの定義
この情報は、エラーのあるEDMテンプレートを修正する方法に関する解析を提供します。
複数のEDMテンプレートでプライマリー キーの制限を超えたことがエラーの場合は、EDMインデックス作成失敗スキーマ通知も生成され、ZIA管理ポータルの[通知]ウィンドウに表示されます。この通知には、プライマリー キーの制限を超えた原因となったEDMテンプレートが一覧表示されます。組織では、1つ以上のEDMテンプレートで2,048個を超える重複プライマリー キーを持つことはできません。
このタイプのEDMテンプレート エラーの場合、エラーは複数のEDMテンプレートに関連付けられていますが、[通知]ウィンドウには、制限を超えた原因となった最後のEDMテンプレートのみが一覧表示されます。この問題を解決するには、インデックス ツールで問題の原因となった最後のEDMテンプレートを分析し、エラーの原因となったプライマリー キーを特定します。次に、そのEDMテンプレート、または重複した同じプライマリー キーを含むその他の以前のEDMテンプレートを削除または修正します。
詳細については、通知についてを参照してください。
EDMテンプレートのプライマリ重複キー超過の例
次の例は、1つまたは複数のEDMテンプレートで重複プライマリー キーを超える方法を示しています。すべての例では、個々のEDMテンプレートに対して512個の重複キー制限を使用し、複数のEDMテンプレート間で2,048個の重複キー制限を使用しています。
- 重複プライマリキーが1つのEDMテンプレートで超過する例
この例では、重複は1つのEDMテンプレート内で発生します。
この例では、EDMテンプレート1が処理された後、インデックスツールでエラーステータスを受け取り、エラータイプとしてプライマリキーの重複が多すぎます。このテンプレートには600個の重複が含まれていますが、これは個々のEDMテンプレートの512個の重複制限を超えています。
閉じる - 単一のフィールドを使用して複数のEDMテンプレートで重複するプライマリキーを超える例
この例では、重複は複数のEDMテンプレートで1タイプのフィールドについて同一です。同一のSSN番号がすべてEDMテンプレートで複製されます。
テンプレート名 テンプレートのフィールド EDMテンプレート1 SSN(プライマリキー)
400個の重複
CCN(プライマリキー)
重複なし
FName
重複なし
LName
重複なし
EDMテンプレート2 SSN(プライマリキー)
300個の重複
CCN(プライマリキー)
重複なし
FName
重複なし
LName
重複なし
EDMテンプレート3 SSN(プライマリキー)
400個の重複
CCN(プライマリキー)
重複なし
FName
重複なし
LName
重複なし
EDMテンプレート4 SSN(プライマリキー)
300個の重複
CCN(プライマリキー)
重複なし
FName
重複なし
LName
重複なし
EDMテンプレート5 SSN(プライマリキー)
400個の重複
CCN(プライマリキー)
重複なし
FName
重複なし
LName
重複なし
EDMテンプレート6 SSN(プライマリキー)
300個の重複
CCN(プライマリキー)
重複なし
FName
重複なし
LName
重複なし
この例では、EDMテンプレートが処理された後、EDMテンプレート1からEDMテンプレート5はインデックス ツールで完了ステータスを受け取ります。これらの各テンプレートは、個々EDMテンプレートの512個のプライマリー重複制限を超えておらず、組織全体のプライマリー重複の合計数は1,800個であり、複数のEDMテンプレートの2,048個の重複キー制限を下回っています。
EDMテンプレート6は、プライマリー キー制限エラーの種類を持つエラー状態をインデックス ツールで受け取り、このテンプレート名を一覧表示するZIA管理ポータルの[通知]ウィンドウに[EDMインデックス作成の失敗スキーマ]という通知が表示されます。このテンプレートは、個々のテンプレートの512個のプライマリー重複制限を超えていませんが、このテンプレートの追加により、組織の複数のEDMテンプレートにわたる2,048個の重複プライマリー キーの制限を超えています。EDMテンプレート5の処理後は1,800個の重複がありましたが、300個のEDMテンプレート6を追加すると、2,100個の重複が作成されます。
EDMテンプレート6で発生したプライマリ重複エラーを修正するには、そのテンプレートだけでなく、そのテンプレートに先行する他のすべてのテンプレートを分析して、プライマリ重複エラーを修正および修正する方法を特定する必要があります。
閉じる - 複数のフィールドを使用する複数のEDMテンプレート間で重複するプライマリキーを超える例
この例では、複数のEDMテンプレートでの異なるタイプのフィールドの重複は同じです。同じ番号がSSN、アカウント番号、ギャンブラー番号および患者ID間で重複しています。
テンプレート名 テンプレートのフィールド EDMテンプレート1 SSN(プライマリキー)
400個の重複
CCN(プライマリキー)
重複なし
FName
重複なし
LName
重複なし
EDMテンプレート2 アカウント番号(プライマリキー)
300個の重複
CCN(プライマリキー)
重複なし
FName
重複なし
LName
重複なし
EDMテンプレート3 SSN(プライマリキー)
400個の重複
CCN(プライマリキー)
重複なし
FName
重複なし
LName
重複なし
EDMテンプレート4 ギャンブラー番号(プライマリキー)
300個の重複
CCN(プライマリキー)
重複なし
FName
重複なし
LName
重複なし
EDMテンプレート5 SSN(プライマリキー)
400個の重複
CCN(プライマリキー)
重複なし
FName
重複なし
LName
重複なし
EDMテンプレート6 患者ID (プライマリキー)
300個の重複
CCN(プライマリキー)
重複なし
FName
重複なし
LName
重複なし
この例では、EDMテンプレートが処理された後、EDMテンプレート1からEDMテンプレート5はインデックス ツールで完了ステータスを受け取ります。これらの各テンプレートは、個々EDMテンプレートの512個のプライマリー重複制限を超えておらず、組織全体のプライマリー重複の合計数は1,800個であり、複数のEDMテンプレートの2,048個の重複キー制限を下回っています。
EDMテンプレート6は、プライマリー キー制限エラーの種類を持つエラー状態をインデックス ツールで受け取り、このテンプレート名を一覧表示するZIA管理ポータルの[通知]ウィンドウに[EDMインデックス作成の失敗スキーマ]という通知が表示されます。このテンプレートは、個々のテンプレートの512個のプライマリー重複制限を超えていませんが、このテンプレートの追加により、組織の複数のEDMテンプレートにわたる2,048個の重複プライマリー キーの制限を超えています。EDMテンプレート5の処理後は1,800個の重複がありましたが、300個のEDMテンプレート6を追加すると、2,100個の重複が作成されます。
EDM テンプレート6で発生したプライマリ重複エラーを修正するには、そのテンプレートだけでなく、そのテンプレートに先行する他のすべてのテンプレートを分析して、プライマリ重複エラーの修正方法と修正方法を特定する必要があります。
閉じる
- EDMレポートについて
レポートにおいて、Zscalerサービスは、合計
matchCount
、およびその数を決定するのに役立つtriggers
を提供します。matchCount
を計算する際、Zscalerサービスはスキャンされたテキスト(つまり、triggers
)内の一致したトークンをカウントし、その数に、EDMディクショナリーのインデックス ツールでトークンを定義するために使用されるCSVファイルで一致したトークンの数を掛けます。- 実施例1
次の例では、スキャンされたファイルに一致したトークンのインスタンスが1つ含まれていますが(
example_trigger_text
として表示)、CSVファイル内で同じトークンが1回一致します。その結果、Zscalerサービスは、matchCount
が1
(すなわち、インスタンス数1、一致数1件)となります。"dictionaries": [ { "name": "my dictionary", "matchCount": 1, "assignedToHitRule": true, "triggers": [ "example_trigger_text", ] }
閉じる - 実施例2
次の例では、スキャンされたファイルに一致したトークンのインスタンスが2つ含まれていますが(
example_trigger_text
として表示)、CSVファイル内で同じトークンが3回一致します。その結果、Zscalerサービスは、matchCount
が6
(すなわち、インスタンス数2つ、一致数各2件)となります。"dictionaries": [ { "name": "my dictionary", "matchCount": 6, "assignedToHitRule": true, "triggers": [ "example_trigger_text", "example_trigger_text", ] }
閉じる
- 実施例1