データ接続と統合パイプラインの構築パイプラインのセキュリティマーキングの解除に関するガイダンス

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

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

プラットフォームリソースのアクセス要件は、マーキングによって制御されます。マーキングは、すべての条件を満たす場合にのみアクセスを許可する方式でアクセスを制限します。リソースにアクセスするには、そのリソースに適用されたすべてのマーキングのメンバーである必要があります。また、マーキングはファイル階層と直接の依存関係の両方に沿って継承されます。適切な権限があれば、リソースから直接マーキングを削除したり、直接の依存関係に沿ってマーキングを削除したりできます。

マーキングは、プラットフォーム全体で確認でき、直接の依存関係に沿って伝播して機密データを保護するため、よく使われます。状況によっては、パイプラインの初期段階でマーキングを適用し、後の段階で削除する必要があります。このページでは、パイプラインの構造に応じてマーキングを削除する方法を詳しく説明します。

パイプラインにマーキングを適用し始める場合は、意図せずエンドユーザーのアクセスを遮断しないよう、以下のシナリオセクションを読むことを推奨します。
また、マーキングの適用と削除にはベストプラクティスに従い、より高度な情報については継承されたマーキングと組織を削除する方法のドキュメントを参照することを推奨します。

Pipeline Builder でマーキングや組織を削除することもできます。

シナリオ

以下では、パイプラインの初期段階でマーキングを適用し、後の段階で削除することに関連する3つのシナリオを紹介します。

シナリオ1：切断をマーキングの削除に置き換える

このシナリオは、パイプラインが次の条件に該当する場合を対象としています。

すでにマーキングが適用されている。
切断によってマーキングが削除されている。
プロジェクトレベルの閲覧要件を伝播する権限が有効になっていない。

つまり、切断（非推奨の機能）の使用から、継承されたマーキングの削除に移行する場合です。

上の例に示す以前の状態では、マーキングの伝播を防ぐために切断が使われています。切断がマーキングの削除のためだけに使われている場合は、上の例の新しい状態のように、切断をマーキングの削除に置き換えることを強く推奨します。マーキングを削除する際は、マーキングを削除するトランスフォームを含むリポジトリの承認モード設定を検討するとよいでしょう。

閲覧要件の伝播が有効になっている場合は、以下のシナリオ2をお読みください。

シナリオ2：マーキングを適用してから削除し、「閲覧要件を伝播する」を無効にする

このシナリオでは、プロジェクトレベルの閲覧要件の伝播設定を無効にするために、パイプライン内のデータセットにマーキングを適用します。

上に示すように、新しいプロジェクトでは、閲覧要件を伝播するオプションがデフォルトで無効になっています。これらの新しいプロジェクトでは、下流の派生データセットに閲覧要件は適用されません。具体的には、別のプロジェクトにある下流バージョンのデータにアクセスするユーザーは、この設定が無効になっているプロジェクト内の上流データへのアクセスも必要とするわけではありません。

マーキングは閲覧要件の設定にかかわらず伝播します

マーキングは常に伝播します。新しいプロジェクト内のデータにマーキングが適用されている場合、そのマーキングは「閲覧要件を伝播する」設定にかかわらず、すべての下流データセットに伝播します。

上の画像のように閲覧要件を伝播するオプションが有効になっているプロジェクトでは、そのプロジェクト内のデータセットの閲覧要件が伝播しています。つまり、別のプロジェクトにある下流バージョンのデータにアクセスするユーザーは、この設定が有効になっている上流プロジェクトへのアクセスも必要になります。

閲覧要件の伝播を無効にして、代わりにマーキングを使うことを強く推奨します。

閲覧要件の伝播を無効にしてパイプラインにマーキングを導入する前に、閲覧要件の伝播を有効にした当初の目的を検討するとよいでしょう。

「閲覧要件を伝播する」を有効にしておく明確な理由がない場合もあります。その場合は、この設定を単に無効にし、ユーザーには明示的にアクセスが必要なデータセットへのアクセスのみが付与されていることを確認できるかもしれません。ユーザーは、以前に閲覧要件を伝播していた上流データセットへのアクセスも必要とすることはなくなります。
プロジェクト内に機密性の高いデータセットがいくつかある場合です。この場合は、機密性の高いデータセットをそれ以外のデータセットから分離し、以下の手順に従うことが最適です。これらの手順では、閲覧要件の伝播を、こうしたシナリオに適したセキュリティの基本要素であるマーキングに置き換える方法を示します。
以下の手順で要件を満たせない場合は、Palantir の担当者にお問い合わせください。

以下の例では、データソースプロジェクトの「閲覧要件を伝播する」を無効にすることが目標です。上記の手順に従った結果、このプロジェクトで「閲覧要件を伝播する」が有効になっている理由は、機密データを含む raw_dataset_1 データセットを保護するためだとわかりました。

以前の状態では、データセット A の内容を閲覧するには、データソースプロジェクトと下流プロジェクトの両方で、少なくとも「閲覧者」のアクセス権限が必要です。その後、データセット B の閲覧要件の伝播を解除するために切断が使われています。

新しい状態では、データセット A の内容を閲覧するには、下流プロジェクトで少なくとも「閲覧者」のアクセス権限と、マーキングへのアクセスが必要です。「閲覧要件を伝播する」が無効になっているため、データセット C と D にアクセスするには、下流プロジェクトで「閲覧者」のアクセス権限のみが必要です。

この変更により、セキュリティマーキングを使って「閲覧要件を伝播する」を無効にできます。以下で提案する解決策では、raw_dataset_1 にマーキングを適用すると、raw_dataset_1 の切断されていないトランザクションを入力として持つすべての下流データセットに、そのマーキングが即座に伝播します。ここでは、切断がすでに設定されていること、そして切断をマーキングの削除に置き換えるだけであることを前提としています。この前提が当てはまらない場合は、データセットへのマーキングの適用による影響を詳しく説明しているシナリオ3を参照してください。

データソースプロジェクトで「閲覧要件を伝播する」を無効にした後にマーキングを適用しても、ユーザーがデータセット B へのアクセスを失わないよう、この変更を導入する際には次の手順を推奨します。

新しいマーキングを作成し、関係するユーザーにそのマーキングへのアクセスを付与します。
raw_dataset_1 にマーキングを適用します。
マーキングが適用されたので、データソースプロジェクトの「閲覧要件を伝播する」を安全に無効にできます。
トランスフォーム内の切断をマーキングの削除に置き換え、切断の解除とマーキングの削除が同時に行われることを確認します。
パイプライン内のすべてのデータセットがビルドされていることを確認します。
データソースプロジェクトへのアクセスが不要になったユーザーを、そのプロジェクトから外します。

シナリオ3：新しいマーキングを適用してからデータセットレベルでマーキングを削除する

このシナリオは複雑になる可能性があり、既存のパイプラインの初期段階で新しいマーキングを導入しつつ、パイプラインの後続の段階でユーザーが誤ってアクセスできなくなることを防ぎます。

データセット A に導入したマーキングは、トランザクションリネージに沿って、そのデータセットの下流にあるすべてのリソースに即座に伝播します。マーキングがついたデータセットから派生したリソースにアクセスするには、ユーザーはそのマーキングを持っている必要があります。

これをよりよく理解するため、上記の例を次のパイプラインに拡張して考えます。データセット A → データセット B → 下流データセット：

データセット A は生データのデータセットです（これからマーキングをつけます）。
データセット B は、データセット A から機密データを削除して派生したものです（そのため、マーキングを削除できます）。
下流データセットは、データセット B から派生した、ユーザーがアクセスする必要のあるデータセットです。

この例の目標は、下流データセットがデータセット A のマーキングを一切継承しないようにすることです。

まず理解しておく必要があるのは、データセット A（またはデータセット A を含むフォルダー）にマーキングをつけると、実質的にデータセット A の全履歴にわたるすべてのトランザクションにマーキングがつくということです。その結果、データセット B と下流データセットは即座にマーキングを継承します。

次の手順を実行した場合：

データセット A → データセット B のトランスフォームにマーキングの削除を追加する
データセット B のコードを更新する
データセット B を再ビルドする...

...データセット B の最新の SNAPSHOT トランザクションにはマーキングがつかなくなりますが、データセット B の古いトランザクションにはすべてマーキングがついたままになります。

データセットにマーキングをつけるとすべてのトランザクションにマーキングがつきますが、トランスフォームでマーキングを削除しても、マーキングが削除されるのは新しい出力トランザクションのみです。既存のトランザクションからはマーキングは削除されません。この動作は対称ではありません。

つまり、インクリメンタルにビルドされる下流データセットなど、データセット B の古いトランザクションから派生した下流データセット内のデータは、引き続きマーキングを継承します。ただし、Foundry はデータセットビューの権限を確認する際に、各入力の最新のトランザクションのみをチェックします。インクリメンタル（差分処理）データセットの場合、通常のビルドだけでマーキングを削除できます。

インクリメンタルな下流データセットのすべてからマーキングを削除するには、データセット B にマーキングを削除するトランスフォームを適用した後、そのトランスフォームからインクリメンタルな下流データセットまでの間にあるすべてを再ビルドする必要があります。これにより、各下流データセットは、データセット B の以前の（マーキングがついた）トランザクションではなく、最新の（マーキングのない）トランザクションのみに依存するようになります。

下流データセットの数が多く、手動で再ビルドをトリガーすることが現実的でない場合は、次の手順を推奨します。

データセット A′ を作成し、その内容がデータセット A と同一であることを確認します。
データセット B のコードを書き換えて、データセット A の代わりにデータセット A′ を入力として使用します。同時に、トランスフォームに適切なマーキングの削除を必ず追加し、その直後にデータセット B をビルドします。データセット B のスナップショットビルドは必要ありません。

この入れ替えによってデータセット B の SNAPSHOT ビルドがトリガーされる可能性があるため、パフォーマンスへの影響を考慮してください。

データセット A′ にマーキングをつけます。
データセット A をゴミ箱に移動します。
この時点で、これ以上の再ビルドは必要ありません。

重要なパイプラインでこれらの変更を行う場合や、いずれかの手順について不明な点がある場合は、Palantir の担当者にお問い合わせください。

ベストプラクティス

絶対に必要な場合を除き、リポジトリを「再承認を必須にしない」モードに設定しないでください。
- このモードを有効にする必要がある場合は、そのリポジトリの編集者を最小限に抑え、この設定について（必要な場合は）承認を必ず得てください。
リソースにマーキングが必要となる条件を、明確に定義してください。
マーキングの削除トランスフォームは、マーキングを必要としないデータを積極的に選択するように記述してください。
マーキングが必要なデータを除外するマーキングの削除トランスフォームは記述しないでください。マーキングが必要な新しいデータは上流で導入されることがよくあり、そのデータが誤ってマーキングの削除トランスフォームを通過するのを防ぐ必要があるためです。
- 「対象を選択する」アプローチの例（推奨）：
```
Copied!1
2
3
4
5
6
# 列ベース
df.select("salary","title","department")

# 行ベース
states_to_keep =["OH","CA","DE"]
df.filter(df.state.isin(states_to_keep))
```
- 「対象を除外する」アプローチの例（非推奨）：
```
Copied!1
2
3
4
5
6
# 列ベース
df.drop("firstname","lastname")

# 行ベース
states_to_drop =["FL","TX","IL"]
df.filter(~df.state.isin(states_to_drop))
```
機密データの削除ロジックが実装されているトランスフォームで、マーキングの削除を実行してください。
- このロジックを別のリポジトリで抽象化したり隠したりしないでください。
- 同様に、（データをそのまま出力するトランスフォームを集めた）マーキング削除専用のリポジトリを作成しないでください。マーキングの削除ロジックは、マーキング削除の PR レビュー時に明示的に承認されるべきです。
プロジェクト内でマーキングの削除を実行する際は、可能な限り上流（マーキングがついたデータセットをインポートとして追加するとき）、または可能な限り下流（プロジェクトのエクスポートを作成する直前のステップ）で、データからマーキングを削除してください。

よくある質問

コードのロジックに変更があるたびに、マーキングの削除について承認が必要ですか？

マーキングの削除トランスフォームを含むリポジトリに、再承認を必須にする承認モードと再承認を必須にしない承認モードのどちらが設定されているかによって異なります。承認モードについて詳しくはこちら。

マーキング削除のワークフローと「プロジェクトごとに1つのリポジトリ」という推奨事項は、あまりうまく両立しません。マーキング削除のワークフローでは、プロジェクトごとにいくつのリポジトリを用意すべきですか？

理想的には、マーキングの削除トランスフォームのロジックが変更されるたびに、セキュリティ承認を受けるべきです。承認プロセスの過度な負担と良好なセキュリティ状態を両立するため、可能であれば、マーキングの削除ロジック（データの難読化、列の削除など）を含むすべてのトランスフォームを別のリポジトリに移動し、そのリポジトリを「再承認を必須にする」に設定することを推奨します。

トランスフォームの出力にマーキングの削除プロパティ（stop_propagating と stop_requiring）を追加できますか？

いいえ、これらは入力プロパティであり、出力には追加できません。特定の出力からマーキングを削除することが目的の場合は、マーキングを持つすべての入力を特定し、その各入力に stop_propagating ステートメントを追加する必要があります。詳細については、入力トランスフォームプロパティのドキュメントを参照してください。

マーキングの削除はどの言語でサポートされていますか？

次の言語でマーキングの削除がサポートされています。

切断よりもマーキングの削除が推奨されるのはなぜですか？

機密区分の解除は慎重に行うべきであり、プロジェクトやリポジトリの各所に分散させるべきではありません。プラットフォームのマーキング削除機能では、権限の伝播に対する変更をきめ細かく制御でき、そのような変更が適切にレビューされることを保証します。

リポジトリで切断の代わりにマーキングの削除を使用するよう移行しています。新しいトランスフォームに対して切断を無効にするにはどうすればよいですか？

これまで切断が有効になったことのないデータセットに切断を追加できないようにするには、Palantir の担当者にお問い合わせください。