データ接続と統合パイプラインの構築パイプラインのセキュリティ継承されたマーキングと組織の解除

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

継承されたマーキングと組織を外す

マーキングと組織は、ユーザーの適格性に基づいてリソースへのアクセスを制限します。

依存リソースを派生させる際に、制限されたコンテンツを削除または難読化した場合、その派生リソースからマーキングや組織を外したいことがあります。継承されたマーキングと組織を外す処理は、入力トランスフォームのプロパティである stop_propagating と stop_requiring を使用して実行できます。

stop_propagating は、継承されたマーキング（たとえば、PII）を外すために使用します。
stop_requiring は、継承された組織（たとえば、Palantir）を外すために使用します。

用語

組織は、プロジェクトに適用されるアクセス要件で、ユーザーグループとリソースの間の厳格な分離を保証します。アクセス要件を満たすには、プロジェクトに適用されている組織のうち1つ以上のメンバーまたはゲストメンバーである必要があります。
マーキングは、リソースに適用されるアクセス要件で、全か無かの方式でアクセスを制限します。アクセス要件を満たすには、そのリソースに適用されているすべてのマーキングのメンバーである必要があります。
ロールは、特定のリソースに対してユーザーが実行できる具体的なワークフローを定義する権限の集まりです（たとえば、閲覧者、編集者など）。

重要な注意事項

stop propagating と stop requiring のキーフレーズは、組織とマーキングにのみ適用され、ロールには適用されません。
リポジトリには、保護されたブランチが1つ以上必要です（たとえば、main）。このブランチでは、1人以上の必須承認者を設定する必要もあります。
組織とマーキングを外せるのは、保護されたブランチ上のみです。保護されていないブランチを指定すると（たとえば、on_branches=[..., "not-protected-branch"]）、ビルドに失敗します。
組織とマーキングを外す操作は、Python、Java、SQL でサポートされています。
継承された組織とマーキングを外す操作を承認するには、特別なユーザー権限が必要です。マーキングを外すにはマーキングを削除権限、組織を外すにはアクセスを拡大する権限が必要です。

基本的なワークフロー

下の図では、プロジェクト C 内の灰色のデータセットボックスは、宛先プロジェクト内のすべての入力に対してプロジェクト参照を追加する必要があることを示しています。

基本的なワークフロー

手順

保護されたブランチ（たとえば、main）から新しいブランチを作成します。
入力トランスフォームに stop_propagating と stop_requiring のいずれか、または両方のプロパティを追加します。例：

基本的なコード例

このコードを保護されたブランチにマージするためのプルリクエストを作成します。
マーキングに対するマーキングを削除権限、または組織に対するアクセスを拡大する権限を持つユーザーは、提案された変更を承認または拒否できます。複数のレビュー担当者を追加した場合、いずれかのレビュー担当者が拒否すると、プルリクエスト全体が拒否されます。
承認された場合、コードエディターが PR をマージし、出力データセットをビルドします。出力データセットがビルドされると、伝播されたマーキングや組織は適用されなくなります。

入力トランスフォームのプロパティ

継承されたマーキング（たとえば、PII）を外すには、stop_propagating キーフレーズを使用します。

継承された組織（たとえば、Palantir）を外すには、stop_requiring キーフレーズを使用します。

これらのキーフレーズは、マーキングまたは組織を外す必要があるすべての入力に指定する必要があります。また、外す操作ごとに、その操作を適用する保護されたブランチを指定する必要があります。マーキングID、組織ID、ブランチは、常に引用符で囲んだ文字列として指定してください。

ユーザーは組織のうち1つ以上の要件を満たせばよいため、上流の組織を1つ以上指定する必要があります。指定した組織ごとに承認が必要になります。以下の詳細なワークフローでは、この点を説明する例を示しています。

Python

Python では、入力コンストラクターでマーキングを外す操作を指定します。

Copied!1
2
3
4
5
6
@transform(
  input_1=Input("<input_id>",
      stop_propagating=Markings([markingId1, ...], [branch1, ...]),
      stop_requiring=OrgMarkings([orgMarking1, ...], [branch2, ...])),
  output=Output("<output_id>")
  )

Markings クラスは、マーキングIDのリストと、マーキングを外す操作を適用する保護されたブランチのリストを受け取ります。マーキングIDは、設定ページのマーキングリストで確認できます。

マーキングID

OrgMarking クラスは、組織IDのリストと、マーキングを外す操作を適用する保護されたブランチのリストを受け取ります。組織IDは、設定ページの組織リストで確認できます。内部的には、組織は少し異なる種類のマーキングとして表現されているため、stop_requiring に続くトランスフォームのキーワードは OrgMarkings と呼ばれます。

組織ID

Java

Java の自動登録

Java では、自動登録されるトランスフォームの入力に付ける注釈で、マーキングを外す操作を指定します。

構文：

Copied!1
2
3
4
5
6
7
8
@Compute
public void myComputation(
  @StopPropagating(markings = {markingId1, ...}, onBranches = {branch1, ...})
  @StopRequiring(orgMarkings = {orgId1, ...}, onBranches = {branch2, ...})
  @Input("<input_id>")
  FoundryInput input,
  @Output("<output_id>")
  FoundryOutput output)

@StopPropagating と @StopRequiring の注釈は、マーキングIDの集合と、マーキングを外す操作を適用する保護されたブランチの集合を受け取ります。マーキングまたはブランチを1つだけ指定する場合は、{} で囲む必要はありません（たとえば、@StopPropagating(markings = marking1, onBranches = "my-branch")）。

Java の手動登録

手動登録される Java トランスフォームでは、MyPipelineDefiner.java ファイルでの登録時に、次の構文を使用してマーキングを外す操作を指定します。

Copied!1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
  @Override
    public void define(Pipeline pipeline) {
        HighLevelTransform highLevelManualTransform = HighLevelTransform.builder()
                .computeFunctionInstance(new HighLevelManualFunction())
                .putParameterToInputAlias("myInput", "/path/to/input/dataset")
                .returnedAlias("/path/to/output/dataset")
                        .desiredUnmarkings(Set.of(
                                    Unmarking.builder()
                                        .branch("branch1")
                                        .input(alias("/input1"))
                                        .output(alias("/output"))
                                        .markingId(MarkingId.valueOf("markingId"))
                                        .build(),
                                    Unmarking.builder()
                                        .branch("branch1")
                                        .input(alias("/input1"))
                                        .output(alias("/output"))
                                        .markingId(MarkingId.valueOf("orgId1"))
                                        .build()
                                    ))
                .build();
        pipeline.register(highLevelManualTransform);
    }

SQL

SQL では、SparkSQL のヒント文を使用してマーキングを外す操作を指定します。

Copied!1
2
3
CREATE TABLE <output_id> AS
  SELECT /*+ foundry_stop_propagating(markingId1, ...) foundry_stop_requiring(orgMarkingId1, ...) foundry_on_branches(branch1, ...) */ *
  FROM <input_id>

SQL でマーキングと組織を外す操作は、任意の SELECT 文に追加できます。例：

Copied!1
2
CREATE TABLE <output_id> AS SELECT * FROM <input_1_id>
  CROSS JOIN (SELECT /*+ foundry_stop_propagating(markingId1) foundry_on_branches("my-branch") */ * FROM <input_2_id>)

外す操作の権限

一般に、コードを閲覧してプルリクエストを承認するには、承認者はプロジェクトとリポジトリ自体に適用されている組織およびマーキングの要件を満たし、基本的な Stemma の View Repository ワークフローを含むロールも持っている必要があります（デフォルトでは閲覧者ロールに含まれます）。また、承認モードを設定したり、組織やマーキングを外すプルリクエストを承認したりするには、それぞれの組織とマーキングに対する権限が必要です。ユーザーは、必ずしもその組織やマーキングのメンバーである必要はありません。

マーキングを外す操作を承認するユーザーは、そのマーキングに対するマーキングを削除ロールを持っている必要があります。

削除ロール

組織を外す操作を承認するユーザーは、そのマーキングに対するアクセスを拡大するロールを持っている必要があります。

アクセスの拡大

承認モード

データガバナンスユーザーは、リポジトリごと、および組織とマーキングごとに、新しい承認を必要とする条件を決めるモードを定義できます。

再承認を必須にする： これは、すべての組織とマーキングのデフォルトモードです。この組織とマーキングが削除されたブランチに対してプルリクエストを作成すると、リポジトリでは常にセキュリティ承認が必要になります。このモードはロジックの変更をチェックすることで、組織とマーキングが安全に削除されるようにします。
再承認を必須にしない： ある入力について、トランスフォームでこの組織やマーキングを初めて削除するときには、承認が必要です。その後のロジックの変更は、セキュリティ承認待ちでブロックされることはありません。

例1

example_1

example_1_code

上の例は、再承認が必要なマーキング PHI が1個あるリポジトリ内のトランスフォームです。

上記の設定では、次のようになります。

ユーザーが PHI マーキングの伝播を停止するために最初の PR を作成すると、PHI マーキングに対する削除ロールを持つユーザーから承認を得る必要があります。
その後、ユーザーが次の PR で上記のトランスフォームを変更すると、再び承認を求められます。
ユーザーがリポジトリ内で、このファイルかほかのファイルかを問わず何かを変更すると、PHI マーキングについて再び承認を求められます。

例2

example_2

example_2_code

上の例は、再承認が不要な組織 PALANTIR が1個あるリポジトリ内のトランスフォームです。

上記の設定では、次のようになります。

ユーザーが PALANTIR 組織を必須としないようにするために最初のプルリクエストを作成すると、PALANTIR 組織に対するアクセスを拡大するロールを持つユーザーから承認を得る必要があります。
その後、ユーザーが次のプルリクエストで上記のトランスフォームを変更しても、承認は求められません。
その後、ユーザーがこのリポジトリ内で何かを変更しても、承認は求められません。

例3

example_3

example_3_part1_code

トランスフォーム1：上の例は、マーキング PII が1個と組織 PALANTIR が1個あるトランスフォームです。PII マーキングには再承認が必要で、PALANTIR 組織には再承認が不要です。

example_3_part2_code

トランスフォーム2：上の例は、再承認が不要なマーキング USA が1個あるトランスフォームです。

上記の設定では、次のようになります。

ユーザーがトランスフォーム1で最初のプルリクエストを作成すると、PII マーキングに対するマーキングを削除ロールを持つユーザー、および PALANTIR 組織に対するアクセスを拡大するロールを持つユーザーから承認を得る必要があります。
その後、ユーザーが次のプルリクエストでトランスフォーム1を変更すると、PII マーキングに対するマーキングを削除ロールを持つユーザーからのみ承認を求められます。
ユーザーがトランスフォーム2で最初のプルリクエストを作成すると、USA マーキングに対するマーキングを削除ロールを持つユーザー、および PII マーキングに対するマーキングを削除ロールを持つユーザーから承認を得る必要があります。
その後、ユーザーが次のプルリクエストでトランスフォーム2を変更すると、PII マーキングに対するマーキングを削除ロールを持つユーザーからのみ承認を求められます。
その後、ユーザーがこのリポジトリ内で何かを変更すると、PII マーキングに対するマーキングを削除ロールを持つユーザーからのみ承認を求められます。

詳細なワークフロー

このシナリオ例では、コード編集者が機密性の高い上流プロジェクトの2個のデータセットを使用し、特定の情報を削除して、作成されたデータセットをより広い対象ユーザーが利用できるようにしようとしています。それぞれ2個のマーキングを持つ2個のデータセットは、下流プロジェクトに参照として追加されています。コード編集者は、4個のマーキングのうち3個の伝播を停止し、出力データセットに表示されないようにしようとしています。また、上流プロジェクトは OrgA または OrgB のユーザーに制限されており、下流のデータを OrgC のユーザーに配布することを意図しています。

before_unmarking

変更前：コード編集者のブランチ上の出力データセットは、4個のマーキングすべてを継承しており、引き続き OrgA または OrgB のユーザーに制限されています。

after_unmarking

変更後：保護されたブランチ（たとえば、メイン）にマージすると、出力データセットが継承するマーキングは1個だけになり、ユーザーが OrgA または OrgB のメンバーである必要はなくなります。

手順

コード編集者は、下流プロジェクトのリポジトリの feature/clean-data ブランチに新しいトランスフォームを記述します。

detailed_workflow

マーキングの変更はすべて master ブランチに対して申請されるため、feature/clean-data で作業する際に承認は不要です。つまり、feature/clean-data ブランチで出力データセットをビルドしても、上流のマーキングはすべて引き続き継承されます。
コード編集者はメインブランチへのプルリクエストを作成し、lemon、apple、cherry のマーキングで制限されたデータを管理するデータガバナンスユーザーに承認を申請します。また、OrgA のデータをほかの組織と共有する必要がある場合に承認できる、アクセスを拡大する権限を持つ OrgA の組織管理者にも承認を申請します。

継承された組織を削除してアクセスを拡大すると、継承された組織がすべて削除されますが、承認が必要なのは、トランスフォームに記載された組織に対する適切な権限を持つユーザーからのみです。すべての組織からの承認を必須にするには、`stop_requiring` コンポーネントにすべての ID を記載する必要があります。この例では、上流プロジェクトのデータに対して主に責任を持つのが OrgA であるため、編集者は組織間の承認プロセスに OrgA を選択しました。そのため、継承された組織を削除するには、OrgA の管理者からの承認のみが必要です。承認を申請する組織に応じて、編集者は `stop_requiring` の対象として次のいずれかを選択できます。 (1) OrgA（OrgA の管理者による承認）、 (2) OrgB（OrgB の管理者による承認）、または (3) OrgA と OrgB の両方（両方の組織の管理者による承認）。

結果として、出力データセットは入力から組織を一切継承せず、配置先のプロジェクトの組織のみを適用します。

データガバナンスユーザーと組織管理者は、承認が申請されたことを知らせる Foundry の通知を受け取ります。
PR が承認されたとすると、コード編集者はそれをマージし、上記の変更後の画像に示すように出力データセットをビルドします。
翌週、別のコード編集者が別のコードファイルを変更し、master にマージするための PR を作成します。再承認が必要なマーキングが1個もなければ、この PR はセキュリティレビューなしで承認できます。いずれかのマーキングで再承認が必要な場合、PR には、そのマーキングを管理するデータガバナンスユーザーまたは組織管理者によるセキュリティレビューが必要になります。

←

PREVIOUSマーキングの解除に関するガイダンス

NEXTパイプラインの最適化とデバッグ / 概要

→