マーキング

概要

マーキングは、Foundry内のファイル、フォルダー、およびプロジェクトに対するアクセス制御の追加レベルを提供します。マーキングは、視認性とアクションを制限する適格基準を定義します。リソースにアクセスするには、ユーザーはリソースに適用されたすべてのマーキングのメンバーである必要があります。プラットフォーム管理者は通常、組織内でマーキングを管理します。

マーキングへのアクセスは2値（オールオアナッシング）です。役割に関係なく、ユーザーはすべてのマーキング要件を満たさない限り、ファイルに何らかの方法でアクセスできません。

マーキングは、データ保護責任者がどのカテゴリーのデータに誰がアクセスできるかを一元的に管理および監査できるようにすることを目的としています。マーキングの一般的な使用例は、個人を識別可能な情報（PII）へのアクセスを制限することです。たとえば、機密性の高いPIIデータにアクセスする資格がある一連のトレーニングを完了したユーザーグループがある場合があります。プラットフォーム管理者は、PIIマーキングを作成し、機密データセットに適用することができます。このマーキングにより、PIIへのアクセスが適切なユーザーに制限され、そのグループを超えて共有されないことが保証されます。

マーキングは必須の制御であり、役割は任意の制御です。必須の制御は、ユーザーが特定のマーキングを持っていることを要求することでアクセスを制限します。たとえば、共有されたContour 分析に PIIマーキングが付いたデータセットが含まれている場合、ユーザーが PIIデータに対する正しい権限を持っていない限り、分析内のデータへのアクセスは許可されません。対照的に、任意の制御はアクセスを拡大し、データ共有ワークフローを通じてユーザーに付与されます。

ユーザーは、ファイル、フォルダー、またはプロジェクトのすべてのマーキングのメンバーである必要があります。マーキングは連言（ブール AND）です。

継承

マーキングは、ファイル階層と直接依存関係の両方に沿って継承され、変換と分析ロジックを通じて伝播します。マークされたファイル、フォルダー、またはプロジェクトから派生したすべてのリソースは、マーキングが明示的に削除されない限り、マーキングを引き継ぎます。役割ベースのアクセスとは異なり、プラットフォーム内でのデータの配置に基づいているのではなく、マーキングはデータと一緒に移動します。ファイルは、ファイル階層および/またはデータ依存関係を介してマーキングを継承することがあります。

ファイル階層

ファイルは、包含するプロジェクトまたはフォルダーを介してマーキングを継承することがあります。プロジェクトまたはフォルダーにマーキングがある場合、その中のすべてのファイルまたはフォルダーがマーキングを継承します。これは、プロジェクトまたはフォルダーへのアクセスを制限すると、その中のすべてのものへのアクセスが常に制限されることを意味します。

以下のスクリーンショットは、ファイル階層に沿って継承された概念データセットに PII マーキングを示しています。

データ依存関係

データセットへのアクセスを制限すると、それによって派生したデータへのアクセスも常に制限されます。これは、データセットファイルが、上流のデータセットのような依存するデータセットからマーキングを継承することがあるためです。データセットにファイルマーキングがある場合、それに依存するすべてのデータセットがそのマーキングを継承し、継承されたマーキングはデータマーキングとして知られています。

以下のスクリーンショットは、データ依存関係に沿って継承された概念データセットに PII マーキングを示しています。

ユーザーは、上流のデータセットから継承されたデータアクセス要件を満たさずに、ファイルアクセス要件を満たすことができることに注意してください。このシナリオでは、ユーザーは派生データセットの存在を検出し、ファイルのメタデータを表示できますが、ファイルデータセット内のデータにはアクセスできません。これは、ユーザーがファイルマーキング要件を満たさないため、リソースを検出できない場合とは異なります。

マーキングを適用することは、すべてのファイルとデータ依存関係に沿って即時に継承されるため、機密なアクションと見なされます。これにより、意図せず他のユーザーが下流でロックアウトされる可能性があります。マーキングを適用する方法を安全に使用する方法を確認してください。

同様に、マーキングの削除も機密なアクションと見なされます。ファイル、フォルダー、またはプロジェクトからマーキングを削除することができ、これにより即時に下流のファイルとデータ依存関係からマーキングが削除されます。代わりに、変換でマーキングを削除することができ、これによりマーキングがデータ依存関係に沿ってのみ削除されます。マーキングを削除する方法を安全に使用する方法を確認してください。

マーキングの使用

マーキングは、ファイル、フォルダー、およびプロジェクトなどのリソースへのアクセスを制限するように設計されています。マーキングはアクセスを許可するために使用するべきではありません。ユーザーがマーキング基準のセットを満たすと、マーキングと関連リソースへのアクセスが許可されます。ただし、アクセスが可能なユーザーが常にアクセスを持っているべきではありません。ユーザーは、プロジェクトの役割ベースの権限に基づいてファイルへのアクセスを許可されるべきです。

たとえば、PII マーキングが、従業員の個人識別情報（PII）を含むすべての Foundry データへのアクセスを制限するために使用されると仮定します。この PII には、財務記録（社会保障番号など）、健康記録（年齢、性別、診断などの情報）、または名前や住所などの個人データが含まれる場合があります。

PII を扱うには、ユーザーは適切なトレーニングを受ける必要があります。財務部門のユーザーが必要なトレーニングを完了し、PIIマーキングへのアクセスが可能になったと仮定します。このユーザーは財務部門から来ているため、財務データプロジェクトの Viewer 役割が付与されます。このユーザーは他の従業員 PII を含むデータを表示する資格がありますが、プロジェクトの役割はアクセスレベルを制御します。

マーキングは、追加の保護が必要な機密データに対するアクセス制限を定義するために使用する必要があります。データ感度に関連するマーキングを適用するいくつかの方法があります。

• 機密データカテゴリーごとに 1 つのマーキング
  • 最も一般的に使用されるマーキング構造では、機密データカテゴリーごとに 1 つのマーキングが作成されます。各マーキングは、データカテゴリーを含むすべてのリソースへのアクセスを制限します。データに複数のタイプの機密性がある場合、対応するすべてのマーキングがリソースに適用され、関連する機密カテゴリーにアクセスできるユーザーだけがリソースにアクセスできます。
  • マーキング要件や機密性タイプに明確な基準を設定することが有益であるかもしれません。たとえば、性別、年齢、民族性などの個人属性を含むデータには、PII マーキングを付けることができます。
• 機密データ所有者ごとに 1 つのマーキング
  • この構造では、データ所有者が自分が所有するデータへのアクセスを制限する方法を決定できます。機密データ所有者ごとに 1 つのマーキングがあると、チームやユーザーのグループが所有する機密データがマークされ、データ所有者の裁量でマーキングへのアクセスが許可されます。たとえば、営業チームが生成、消費、管理するすべてのデータは、データ所有者によって Sales Data マーキングが付けられ、営業データにアクセスする資格があるユーザーにのみアクセスが許可されます。
  • データ所有者がデータ資産をより制御できるように、マーキングは伝播します。これは、データへのアクセスを持つユーザーが、データから派生リソースを作成して別のユーザーと共有しようとする場合、データ所有者はその他のユーザーにマーキングへのアクセスを許可する必要があることを意味します。
• パイプラインの異なる段階のマーキング
  • データセットは、Foundry に生の形式で取り込まれ、通常は処理および変換が行われてから、最終ユーザーと共有する準備が整います。生データには、下流のユーザーに適さない機密情報が含まれている場合があり、管理者は Raw Data マーキングを適用して、権限のないユーザーからのアクセスを制限することを選択できます。PII (ハッシュ化や暗号化など) の削除後の処理により、管理者は Raw Data マーキングを削除し、パイプラインのさらに先のデータを保護するために他の関連マーキングを適用できます。
• データの発見を制限するためのマーキングの使用
  • マーキングは一括でアクセスを制限するため、ファイル、フォルダー、またはプロジェクトの存在を隠す必要がある場合に使用する必要があります。マーキングは、マーキングへのアクセス権がないユーザーが、検索結果やプロジェクト/フォルダー表示でマークされたデータを表示しないようにすることができます。

Foundry でのマーキングの実装は、上記で説明した戦略の組み合わせを使用することができます。たとえば、処理後の機密データカテゴリーごとに 1 つのマーキングを持つパイプラインの始めに Raw Data マーキングを持つことができます。

例: 医療データを保護する

仮想の医療機関で患者データの 3 つの機密レベルを考慮してください。

• 合成データ: 実際の患者記録を模倣するために作成された、最も機密性の低いデータです。すべての合成データは Synthetic Data マーキングでマークされます。
• 除名データ: このタイプのデータには機密性のあるフィールドがいくつか含まれていますが、すべての直接識別子が削除されています。このデータは、患者を特定するために他のデータファイルと組み合わせて使用される可能性があります。このようなデータはすべて、De-identified Data マーキングでマークされます。
• 識別子を含むデータ: このタイプのデータには、個々の患者を直接特定するために使用できる識別子が含まれる可能性があります。これは、患者データの最高レベルの機密性です。このようなデータはすべて、Identifiable Data マーキングでマークされます。

この場合、データ階層は階層的であり、Identifiable Data マーキングにアクセスできるユーザーは、De-identified Data マーキングおよび Synthetic Data マーキングにもアクセスできます。同様に、De-identified Data マーキングにアクセスできるユーザーは、Synthetic Data マーキングにもアクセスできます。

Foundry 内で、識別子を含むデータ（Identifiable Data マーキングでマークされている）は、識別子フィールドを削除することで、除名データ（De-identified Data マーキングでマークされている）に変換されます。マーキングマネージャーやデータ所有者は、変換ロジックの変更を確認し、除名データからすべての識別子が欠けていることを確認します。さらに複雑な変換によって、Synthetic Data マーキングでマークされた合成データが生成されます。以下のスクリーンショットに示す概念的なデータで示されるこれらの変換ステージごとに、前のマーキングが削除され、データの更新された状態を示すマーキングが追加されます。

例: 調査データを保護する

ケース調査データは、マネーロンダリング対策調査など、特に機密性が高いです。あるケースのデータは、別のケースのデータと混ざらないようにする必要があります。また、あるケースのデータは、その調査者が別のケースを調査しているときに、その調査者には表示されないようにする必要があります。マーキングは、これらのケースアクセス制限を可能にします。

• 特定のケースに関連するデータ、リソース、画像、データセット、その他の証拠は、xxxxxx がケース番号を表す一意の Case - xxxxxx マーキングでマークされます。
• 特定のケースの調査者である調査者のみが、ケースマーキングへのアクセスを許可されます。調査者は、与えられた時点で複数のケースにアクセスすることができますが、そのようなアクセスは個々のマーキングで区別されます。

例: 銀行データを保護する

仮想の銀行では、各チームや部門は、それが生成または管理するデータに対して完全なコントロールを行使します。つまり、各チームは、他のチームがデータ資産にアクセスできるかどうか、全体または一部で決定します。この例では、組織の設定を簡素化するために、対応するマーキングを持つチームを考慮しています。消費者金融、内部コンプライアンス、マーケティングです。

• 消費者金融チームとマーケティングチームがそれぞれ、内部コンプライアンスチームに Consumer Finance および Marketing マーキングへのアクセスを与えると仮定します。その後、内部コンプライアンスチームは、データが事前に承認されたワークフローに適切に使用されていることを確認し、四半期ごとの監査を実施できます。
• 四半期ごとの監査結果は、Internal Compliance マーキングで報告され、他の 2 つのマーキングは削除されます。これらの監査結果は、内部コンプライアンスチームのみがアクセスできます。内部コンプライアンスチームが DPO（データ保護オフィス）と四半期ごとの監査報告書を共有したい場合、内部コンプライアンスチームは DPO に Internal Compliance マーキングへのアクセスを許可し、DPO がコンプライアンス報告書を確認できるようにすることができます。

マーキングの設定方法については、管理ドキュメントをご確認ください。

スコープ化されたセッションを使用する

スコープ化されたセッション では、ユーザーが Foundry セッション中にアクセスする事前定義されたマーキングのサブセットを選択し、異なるタイプの作業間で視覚的な区切りを作成できます。組織でスコープ化されたセッションが有効になっている場合、Foundry にログインした後に、スコープ化されたセッションを選択する必要があり、スコープ化されたセッション内のマーキングのサブセットにのみ Foundry でのアクセスが制限されます。

スコープ化されたセッションを選択すると、ワークスペースバナーにスコープ化されたセッションの名前が表示されます。

複数のスコープ化されたセッションにアクセスできる場合は、ワークスペースバナーにカーソルを合わせて Change scoped session を選択できます。これにより、ログイン時に表示されるスコープ化されたセッションダイアログが表示され、スコープ化されたセッションを選択できます。現在のスコープ化されたセッションと異なるスコープ化されたセッションを選択すると、ページが更新され、選択した新しいスコープ化されたセッションに制限されます。

一部のユーザーは、No scoped session オプションにアクセスできる場合があります。このオプションでは、ユーザーはスコープ化されたセッションの制限を回避し、すべてのマーキングにアクセスできます。

例: 医療データの保護

仮想の医療機関における患者データの3つのセンシティブなレベルを考慮してください：

• シンセティックデータ：これは実際の患者記録を模倣して作成された最も低いセンシティブレベルのデータです。すべてのシンセティックデータは、Synthetic Data マーキングでマークされています。
• 匿名化データ：このタイプのデータには、いくつかのセンシティブなフィールドがありますが、すべての直接識別子が削除されています。このデータは、他のデータファイルと組み合わせて患者を特定するために使用される可能性があります。このようなデータはすべて、De-identified Data マーキングでマークされています。
• 識別子付きデータ：このタイプのデータには、個々の患者を直接識別するために使用できる識別子が含まれる可能性があります。これは、患者データの最も高いセンシティブレベルです。このようなデータはすべて、Identifiable Data マーキングでマークされています。

この場合、データのレベルは階層的であり、Identifiable Data マーキングへのアクセスがあるユーザーは、De-identified Data マーキングと Synthetic Data マーキングへのアクセスも持っています。同様に、De-identified Data マーキングへのアクセスがあるユーザーは、Synthetic Data マーキングへのアクセスも持っています。

Foundry内では、識別子付きデータ（Identifiable Data マーキングでマークされている）は、識別子フィールドを削除することによって、匿名化データ（De-identified Data マーキングでマークされている）に変換されます。マーキングマネージャーまたはデータオーナーは、変換ロジックの変更をレビューし、匿名化データからすべての識別子が欠落していることを確認します。さらに複雑な変換によって、Synthetic Data マーキングでマークされたシンセティックデータが生成されます。以下のスクリーンショットに示されているように、これらの変換ステージのそれぞれで、以前のマーキングが削除され、データの更新された状態を強調するマーキングが追加されます。

例: 調査データの保護

ケース調査データは、マネーロンダリング対策調査のように、特にセンシティブです。あるケースのデータは、別のケースのデータと混ざらないようにしなければなりません。また、あるケースのデータは、その調査員が別のケースをレビューしているときに、その調査員には見えないようにしなければなりません。マーキングは、これらのケースアクセス制限を可能にします。

• 特定のケースに関連するデータ（リソース、画像、データセット、その他の証拠を含む）は、Case - xxxxxx マーキングでマークされます。ここで、xxxxxx はケース番号を表します。
• 特定のケースの調査員である調査員のみが、ケースマーキングへのアクセスが許可されます。調査員は、特定の時点で複数のケースにアクセスできる場合がありますが、そのようなアクセスは個々のマーキングによって区別されます。

例: 銀行データの保護

仮想の銀行では、各チームまたは部門は、それが生成または管理するデータに対して完全なコントロールを行使します。つまり、各チームは、他のチームが自分たちのデータアセットにアクセスできるかどうか、全体または一部を決定します。この例では、対応するマーキングを持つチームを考慮して、組織のセットアップを簡略化します：消費者金融、内部コンプライアンス、マーケティング。

• 消費者金融チームとマーケティングチームがそれぞれ、内部コンプライアンスチームに Consumer Finance および Marketing マーキングへのアクセスを許可すると仮定します。その場合、内部コンプライアンスチームは、事前に承認されたワークフローでデータが適切に使用されていることを確認し、四半期ごとの監査を実施することができます。
• 四半期ごとの監査結果は、Internal Compliance マーキングのレポートに記録され、他の2つのマーキングは削除されます。これらの監査結果は、内部コンプライアンスチームのみがアクセスできます。内部コンプライアンスチームが四半期ごとの監査レポートをDPO（データ保護オフィス）と共有したい場合、内部コンプライアンスチームはDPOに Internal Compliance マーキングへのアクセスを許可し、DPOがコンプライアンスレポートを確認できるようにします。

マーキングの設定方法については、管理ドキュメントを参照してください。

スコープ化されたセッションを使用する

スコープ化されたセッションにより、ユーザーは、Foundryセッション中にアクセスする事前定義されたマーキングのサブセットを選択して、異なるタイプの作業間で視覚的な分離を作成できます。組織でスコープ化されたセッションが有効になっている場合、Foundryにログインした後、スコープ化されたセッションを選択する必要があり、そのスコープ化されたセッション内のマーキングのサブセットに対するアクセスのみが制限されます。

スコープ化されたセッションを選択すると、スコープ化されたセッションの名前が表示されるワークスペースバナーが表示されます。

複数のスコープ化されたセッションにアクセスできるユーザーは、ワークスペースバナーの上にマウスを置いて Change scoped session を選択できます。これにより、ログイン時に表示されるスコープ化されたセッションのダイアログが表示され、スコープ化されたセッションを選択できます。現在のスコープ化されたセッションとは異なるスコープ化されたセッションを選択した場合、ページが更新され、選択した新しいスコープ化されたセッションに制限されます。

一部のユーザーは、No scoped session オプションにアクセスできる場合があります。このオプションにより、ユーザーはスコープ化されたセッションの制限を回避し、すべてのマーキングにアクセスできます。