データ保護ルールのルール規則

ルール規約を設定するには、Manage rule settings UIを使用するか、ルール実施設定APIを呼び出して、「governance_access_type」をこれらの値のいずれかに設定する：

データ・ロケーション・ルールのルール規則

ルール規約を設定するには、Manage rule settings UIを使用するか、ルール実施設定APIを呼び出して、「governance_dlr_type」をこれらの値のいずれかに設定する：

ルール・アクションの優先順位

ルール・アクションの優先順位は、ユーザーが資産に対して持つ最もセキュア、最も緩い、または階層的なアクセス権限を指定します。 アクションは、「アクセスの許可」、「マスクとフィルター」、「アクセスの拒否」の順になります。

この優先順位を適用する例としては、人事部門間で人事資産が共有される場合があります。 ルール規則は、アクセスを拒否するように設定されています。 ルールは、資産が人事文書としてマークされるかどうか、およびユーザーが人事ユーザー・グループ内にある場合はアクセスを許可するかどうかを指定します。 別のルールでは、ルールに従業員の財務情報が含まれている場合は、その情報をマスクする必要があることが規定されています。

従業員の財務情報は、ジョブ、給与、および退職データを結合する表とともにデータベースに保持されます。 「ジョブ」表には、すべてのタイプの従業員のデータと、従業員の退職状況を示す RetireType 列があります。 RetireType 列の値が Retiredの場合、3 番目の規則はすべての行を除外します。

すべてのルールが有効な場合、最初のルールからの Allow access の決定は、 Most secure action winsのときに 2 番目のルールのデータをマスクする決定によって却下されます。 3 番目のルールは、 RetireType が Retiredに設定されているすべての行をフィルターで除外します。

ルール・アクションの優先順位としての階層の適用

より限定的なデータ・アクセスが必要で、より一般的なルールを作成する必要がある場合は、特に階層制約が重要です。 ただし、結果として生じる動作は、ユーザーとデータのタイプの組み合わせごとに非結合ルールを作成することによって可能になります。 ルール・アクションの優先順位としての階層的適用オプションは、以下の 2 つの別個の質問として考えることにより、簡素化された思考プロセスを提供します。

1. どのユーザーにどの資産へのアクセス権限を付与できますか? その後、特定のデータ・タイプのマスキングに関する多くの質問を削除し、その決定を Allow または Denyの 2 つのオプションのみに単純化することができます。

2. マスキングが必要なデータ これにより、ほとんどの場合、アクセス権限を付与するための最初の質問の状態を無視できます。 If data asset contains column of data class sensitive personal data then redact columns with data class sensitive personal dataなど、より抽象的なマスキング・ルールを作成できるようになりました。 階層構成の外部でのこのルールには、マスキングが適用された資産へのアクセス権限の暗黙的な付与が含まれます。

ルール決定の優先順位を 「階層制約」 に設定するオプションは、 「ルール設定の管理」 ウィザードから設定することも、 access_decision_precedence APIの HIERARCHICAL 値を設定することもできます。 「階層制約」 設定では、データ保護ルールの 2 層評価を構成します。 最初の層では、意思決定のルールが評価されます。これにより、マスキング・アクションは考慮されずに、 Allow アクションまたは Deny アクションのいずれかが実行されます。 次に、最初の層からの決定が Allow アクセスである場合にのみ、 Transform アクションを持つルールを考慮して 2 番目の層が評価されます。 マスクされたデータまたは生データを表示するには、少なくとも 1 つの Allow 決定が必要です。

• Locked 規則の場合、この Allow 決定は、 Allow アクションを含むルールでのみ行うことができます。 Locked 規則では、結果が Transform または Mask の決定になるルールがあるが、アクセス権限を付与する Allow ルールがない場合、結果は Denyのままになります。 ただし、アクションが Allow および Transformの複数のルールがある場合、 Allow は Transform の評価に進み、結果の結合された決定が結果のマスキング・アクションになります。
• Unlocked の規則では、階層の優先順位は 「最もセキュアなアクションが優先されます」 (RESTRICTIVE API オプション) の優先順位と同等になります。これは、最初の階層層からの Allow 決定は、 Denyになる有効なルールがない場合にのみ達成可能であるためです。 したがって、 Deny アクションと Transform アクションの両方がある場合、 「階層制約」 (HIERARCHICAL API オプション) と 「最もセキュアなアクションが優先されます」 (RESTRICTIVE API オプション) の両方の結果が Deny アクションになります。

マスキング方式の優先順位

マスキング方式の優先順位は、最もプライバシーの高いユーティリティーまたは最もユーティリティーの高いユーティリティーからのデータ値の変換を指定します。 この優先順位は、ルール・アクションがマスクの場合に適用され、データ値のマスク方法を決定します。 マスキング方式は、プライバシーの観点では「編集」、「置換」、「難読化」の順です。 マスキング方式は、実用性の観点では「難読化」、「置換」、「編集」の順です。

この優先順位を適用する例としては、クレジット・カード番号を難読化する必要があることを指定するルールを作成した会計士があります。 番号をマスキングすると、商品の返品を希望するお客様を支援するカード番号を請求者のみが表示できるようになります。 会計士は、営業部門にいる場合にすべてのクレジット・カード番号を編集する別のルールを作成しました。

販売部門と請求部門の両方にいる従業員が同じクレジット・カード情報にアクセスすると、両方のマスキング方法が同じデータに対して作用します。 ルール規則が最もセキュアである場合、マスキング方式の優先順位によって、営業部門がアクセスする情報が編集されます。 ただし、その従業員は請求部門にも所属しているため、難読化されたクレジット・カード番号の最後の 4 桁を見ることができます。

シナリオ: 規則と優先順位の設定

「ルール設定の管理 (Managing rule settings)」から、Clarice は以下のオプションを選択しました。

• 規則: 「すべての作成者による拒否を許可」 (AEAD) 規則に従う 「アンロック」 データ・アクセス規則。
• ルール・アクションの優先順位: 最も寛容なアクションが優先されます
• ルール・マスキング方式の優先順位: 最もプライバシーが優先される方式

シナリオ: データ保護ルールの作成

Clarice は、以下の従業員スプレッドシート内のデータを保護するための 3 つのルールを作成します。

ルール 1: If the user group is the Sales team, then deny access to the data in the asset. 営業チームの誰も Clarice が所有するデータを表示できません。

ルール 2: If the asset name is Employee Spreadsheet and it contains columns named Last Name, Email Address, then mask by obfuscating all columns named Last Name and Email Address. 以下の例は、財務部門の誰かが従業員スプレッドシートにアクセスしたときに、「姓 (Last Name)」列と「E メール・アドレス (Email Address)」列が難読化されることを示しています。

ルール 3: If the user group is the Sales team and that user is accessing the Employee Spreadsheet, then mask by redacting the column named Email Address. 以下の例は、販売チームがスプレッドシートにアクセスしたときに、緩やかなルールの優先順位のためにアクセスが拒否されないことを示しています。 難読化された姓を確認できます。 ただし、Clarice が最もプライベートなマスキング方式の優先順位を選択したため、E メール・アドレスは編集されます。