データ保護ルールおよびデータ・ロケーション・ルールを作成する前に、ビジネス用語の継承、データ・アクセス規則の定義、ルール・アクションの優先順位、およびマスキング・メソッドの優先順位を指定することで、作成されるルールの動作を簡素化し、データを一貫して保護します。
データ保護ルールおよびデータ・ロケーション・ルールが評価されるときに、依存するビジネス用語が含まれる関係のタイプであるビジネス用語が含まれるようにするかどうかを決定します。
データ保護ルールとデータ・ロケーション・ルールの 2 つのタイプのデータ・アクセス規則から選択します。 ルールによって禁止されていない限りデータへのアクセスを許可することも、ルールによって許可されていない限りデータへのアクセスを拒否することもできます。
また、ルールおよびマスキング方式の優先順位を選択することもできます。 ルール・アクションの優先順位は、同じデータ値に適用される異なるアクションが複数のルールにある場合に適用されます。 マスキング方式は、異なるマスキング方式を持つ複数のルールが同じデータ値に適用される場合に適用されます。
データ保護ルールおよびデータ・ロケーション・ルールを作成する前に、データへのアクセスを許可するルール、またはデータへのアクセスを拒否するルールを計画して評価します。 慎重な計画の後にルールを設計することにより、ルールを適用するための基準および対応する適用アクションを決定するための強固な基盤が提供されます。 この慎重な計画プロセスにより、ルール・アクセスを切り替える将来の決定の機会も最小限に抑えられます。 後でルールのアクセス・パラダイムを変更することにした場合は、まず既存のルールをすべて削除してから、そのルール・クラスの新規ルールを再作成する必要があります。
以下のビジネス用語のオプション、規則、および前例は、データ保護ルールとデータ・ロケーション・ルールの両方に適用されます。
必要な権限
ルール規則を設定するには、 IBM Cloud アカウント管理者でなければなりません。
データ保護規則の施行決定
データ・アクセスに関する評価の決定を照会するすべてのアクティビティーは、監査可能イベントです。 監査可能なイベントが生成され、監査ログ サービスに転送されます。 以下の強制決定を監査イベントとして追跡することができます。ポリシー評価を監査ログに送信するチェックボックスが選択されています:
wdp-policy-service.policy_item.evaluateItem
– アイテムを評価します。wdp-policy-service.policy_item.evaluateItems
– アイテムを評価します。wdp-policy-service.policy_resource.evaluateResource
– リソースを評価します。wdp-policy-service.policy_resource.evaluateResources
– リソースを評価します。
ルールおよびビジネス用語の継承の評価
データ保護ルールおよびデータ・ロケーション・ルールの評価時に、階層タイプ関係の従属ビジネス用語を含める場合は、 「ビジネス用語の継承」 を選択します。 例えば、ビジネス用語 Loan には、 Student loan および Personal loanというタイプの関係があります。 ビジネス用語 Loan とそのサブタイプ Student loan および Personal loan はすべて、データ保護ルールとデータ・ロケーション・ルールが評価されるときに組み込まれます。 ビジネス用語間の階層タイプ関係について詳しくは、 ビジネス用語の設計を参照してください。
データ規則へのアクセスの許可
アクセス許可規則におけるデフォルトの動作では、データ・アクセスが許可されます。 特定のデータを保護する場合は、ユーザー属性またはデータ属性に基づいて特定のデータ・アクセスを明示的に拒否するルールを作成する必要があります。
アクセス許可データ規則を使用すると、データ保護ルールとデータ・ロケーション・ルールで以下のアクションを実行できます。
- データへのアクセスの拒否
- マスク・データ
- 行のフィルター
この規則の使用例としては、すべての社内従業員が従業員データ全体にアクセスできるようにする一方で、給与計算情報へのアクセスを制限するデータ保護規則の作成が挙げられます。 これを行うには、給与計算データに関連していることを示す属性を含む資産を、人事部門に属していないすべてのユーザーに対して拒否する必要があることを指定するルールを作成します。 したがって、すべてのタイプのすべてのデータが許可され、人事以外の従業員の給与計算データの例外のみが拒否されます。
アクセス許可規則は、データ保護規則のデフォルトのデータ規則です。
データ規則へのアクセスの拒否
アクセス拒否規則のデフォルトの動作は、データへのアクセスを拒否することです。 特定のデータを表示する場合は、特定のユーザーにデータの表示を明示的に許可するルールを作成する必要があります。 ほとんどのデータ・アクセスを制限する必要がある環境では、拒否規則により、データを制限する必要があるすべてのケースについてルールを作成する代わりに、データが許可されるいくつかのルールを作成することができます。
データ保護ルールの拒否規則の使用例としては、部門間での表示が許可されていない機密性の高い個人情報を含むカタログがあります。 その場合、マーケティング・グループのメンバー以外のユーザーがアクセスしている marketing としてタグ付けされたデータ資産は、すべて拒否される必要があります。 ただし、マーケティング・ユーザー・グループのメンバーであるユーザーは、 marketingというタグが付いた資産を表示できます。 この規則では、データ保護ルールによって marketing としてタグ付けされたデータへのアクセスを許可されているマーケティング・ユーザー・グループのユーザーを除き、すべてのユーザーがすべてのデータへのアクセスを拒否されます。
この例はデータ・ロケーション・ルールにも適用され、データ・ロケーション・ルールのデフォルトのデータ規則はアクセスの拒否です。
データ・ロケーション・ルールに対して拒否規則を使用する例としては、国の境界を越えることが許可されていない機密性の高い個人情報を含むカタログがあります。 その場合は、任意のロケーションから別のロケーションに移動するデータを拒否することを指定するデータ・ロケーション・ルールを作成します。 ただし、特定のロケーション間にデータ共有アローワンスがあるため、チリのロケーションからアルゼンチンのロケーションへのデータ移動が許可されることを指定する規則を除き、すべてのデータ移動が拒否されます。
アクセス拒否データ規則を使用すると、データ保護ルールとデータ・ロケーション・ルールで以下のアクションを実行できます。
- データへのアクセスを許可する
- マスク・データ
- 行のフィルター
データ・アクセス規則の設定
チームがデータ保護ルールおよびデータ・ロケーション・ルールを作成する前に、ルール規則を設定する必要があります。 規則を変更する前に、既存の規則を削除する必要があります。 規則を変更すると、許可されるアクションのセットが規則によって異なります。
ルール規則を設定するには、 「ガバナンス」>「ルール」 を選択して 「ルール設定の管理」 ページに移動し、 「ルール設定の管理」をクリックします。 あるいは、ルール実施設定APIを呼び出すこともできる。
データ保護ルールのルール規則
ルール規約を設定するには、Manage rule settings UIを使用するか、ルール実施設定APIを呼び出して、「governance_access_type
」をこれらの値のいずれかに設定する:
UI 設定 | API 設定 | 表記方法 |
---|---|---|
アンロック済み | AEAD | デフォルト。 すべての作成者の拒否を許可 (AEAD) 規則に従います。 ルールによって拒否されない限り、データへのアクセスを許可します。 データへのアクセスを拒否し、データをマスクし、データから行をフィルタリングするルールを作成します。 |
ロック済み | 「DEAA」 | deny 全作成者許可 (DEAA) 規則に従います。 ルールで許可されていない限り、データへのアクセスを拒否します。 データへのアクセス、データのマスク、およびデータからの行のフィルタリングを許可するルールを作成します。 |
変換規則を評価できない場合、結果はデフォルトで以下の規則の決定になります。
Deny
for ロック済みAllow
for アンロック済み
データ・ロケーション・ルールのルール規則
ルール規約を設定するには、Manage rule settings UIを使用するか、ルール実施設定APIを呼び出して、「governance_dlr_type
」をこれらの値のいずれかに設定する:
UI 設定 | API 設定 | 表記方法 |
---|---|---|
アンロック済み | AEAD | すべての作成者の拒否を許可 (AEAD) 規則に従います。 ルールによって拒否されない限り、データへのアクセスを許可します。 データへのアクセスを拒否し、データをマスクし、データから行をフィルタリングするルールを作成します。 |
ロック済み | 「DEAA」 | デフォルト。 deny 全作成者許可 (DEAA) 規則に従います。 ルールで許可されていない限り、データへのアクセスを拒否します。 データへのアクセス、データのマスク、およびデータからの行のフィルタリングを許可するルールを作成します。 |
ルール・アクションおよびマスキング・メソッドの優先順位の設定
ルール規則を定義した後、ルールおよびマスキング・メソッドの優先順位を設定すると、以下を判別するのに役立ちます。
- 異なるアクションを持つ複数のルールが同じデータ値に適用される場合に適用されるアクション。
- 異なるマスキング方式を持つ複数のルールが同じデータ値に適用される場合に適用されるマスキング方式。
ルールの優先度を設定するには、 「ガバナンス」>「ルール」 を選択して 「ルール設定の管理」 ページに移動し、 「ルール設定の管理」をクリックします。
ルール・アクションの優先順位
ルール・アクションの優先順位は、ユーザーが資産に対して持つ最もセキュア、最も緩い、または階層的なアクセス権限を指定します。 アクションは、「アクセスの許可」、「マスクとフィルター」、「アクセスの拒否」の順になります。
この優先順位を適用する例としては、人事部門間で人事資産が共有される場合があります。 ルール規則は、アクセスを拒否するように設定されています。 ルールは、資産が人事文書としてマークされるかどうか、およびユーザーが人事ユーザー・グループ内にある場合はアクセスを許可するかどうかを指定します。 別のルールでは、ルールに従業員の財務情報が含まれている場合は、その情報をマスクする必要があることが規定されています。
従業員の財務情報は、ジョブ、給与、および退職データを結合する表とともにデータベースに保持されます。 「ジョブ」表には、すべてのタイプの従業員のデータと、従業員の退職状況を示す RetireType 列があります。 RetireType 列の値が Retired
の場合、3 番目の規則はすべての行を除外します。
すべてのルールが有効な場合、最初のルールからの Allow access
の決定は、 Most secure action wins
のときに 2 番目のルールのデータをマスクする決定によって却下されます。 3 番目のルールは、 RetireType が Retired
に設定されているすべての行をフィルターで除外します。
ルール・アクションの優先順位としての階層の適用
より限定的なデータ・アクセスが必要で、より一般的なルールを作成する必要がある場合は、特に階層制約が重要です。 ただし、結果として生じる動作は、ユーザーとデータのタイプの組み合わせごとに非結合ルールを作成することによって可能になります。 ルール・アクションの優先順位としての階層的適用オプションは、以下の 2 つの別個の質問として考えることにより、簡素化された思考プロセスを提供します。
どのユーザーにどの資産へのアクセス権限を付与できますか? その後、特定のデータ・タイプのマスキングに関する多くの質問を削除し、その決定を
Allow
またはDeny
の 2 つのオプションのみに単純化することができます。マスキングが必要なデータ これにより、ほとんどの場合、アクセス権限を付与するための最初の質問の状態を無視できます。 If data asset contains column of data class
sensitive personal data
then redact columns with data classsensitive 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 桁を見ることができます。
シナリオ: 規則と優先順位の適用
以下の例では、ルール規則、ルール・アクションの優先順位、およびマスキング方式の優先順位を結合しています。 これらを組み合わせて使用することで、データを保護するための柔軟なオプションが作成されます。
Clarice は、従業員スプレッドシートを作成し、ルール設定とデータ保護ルールを使用して、社内の他のチームから従業員データを保護します。 彼女は、まず自分が作成する規則の規則と優先順位を設定し、次に規則を設計することによって、従業員データを保護します。
シナリオ: 規則と優先順位の設定
「ルール設定の管理 (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 メール・アドレスは編集されます。