Search
Palantir
Documentation
ドキュメントの検索
Search
karat
+
K
APIリファレンス ↗
Send feedback
JP
en
jp
kr
zh
AB
XY
AB
XY
AB
XY
AB
XY
AB
XY
AB
XY
ドキュメンテーション
AI Platform (AIP)
データ接続と統合
モデルの接続と開発
オントロジーの構築
開発者ツールチェーン
ユースケース開発
観測可能性
分析
製品の提供
セキュリティとガバナンス
管理と活用支援
はじめに
アーキテクチャセンター
プラットフォームの更新
お知らせ
セキュリティとガバナンス
Hide sidebar
概要
セキュリティの共有責任モデル
セキュリティ用語集
プラットフォームセキュリティ
はじめに
データ基盤の保護
業務アプリケーションの保護
機密データの保護
組織間のコラボレーション
権限の確認
機密性の高い操作に対する理由の要求
概念
組織とスペース
プロジェクトとロール
ポートフォリオ
ユーザーとグループ
表紙
プロジェクトの制約
制限付きビュー
制限付きビューのブランチ作成
マーキング
機密情報区分ベースのアクセス制御
エミュレーションモード
プロパティのセキュリティマーキング
アクセス制御の伝播
管理
組織とスペースの管理
ロールの管理
ユーザーの管理
グループの管理
マーキングの管理
プロジェクトの制約の管理
プロジェクトテンプレートの管理
Granular Policy の管理
制限付きビューの管理
[閲覧要件を伝播する]設定からの移行と無効化 [廃止予定]
[継承された権限を無効化する]設定からの移行とオフへの切り替え [廃止予定]
サードパーティアプリケーション
概要
サードパーティアプリケーションの管理
サードパーティアプリケーションの登録
サードパーティアプリケーションによるアクセスの有効化
サードパーティアプリケーションによるアクセスの承認
危険な操作
Foundry 用の OAuth2 クライアントの作成
ユーザー生成トークン
Foundry のサードパーティアプリケーションと API に関するガイダンス
ダウンロード制御
プライバシーと市民的自由
原則と実践
概要
プライバシーと市民的自由の実践
データ保護とデータガバナンス
Approvals
概要
リクエストのレビュー
Checkpoints
概要
基本概念
Checkpoint タイプ
Checkpoint の設定
Checkpoint レコードのレビュー
Marketplace 製品への Checkpoint 設定の追加
Cipher
概要
基本概念
はじめに
ワークフロー
データセットの列への操作の適用
各アプリケーションでの個々の値の復号
関数とアクションでの CipherText プロパティの使用
ユースケースの例
Marketplace 製品への Cipher の追加
Cipher を使用した視覚的な難読化
Compass
概要
Quicksearch
プロジェクトの作成
タグ
リソースのステータス
データの手動アップロード
リソースの移動と共有
プロジェクトのナビゲーションパネルの使い方
プロジェクトの詳細パネルの使い方
データカタログ
Sensitive Data Scanner
概要
基本概念
機密データスキャンの作成
一致条件の作成
一致アクションの作成
ベストプラクティス
メディアセットのスキャン
Data Lifetime
概要
基本概念
はじめに
ワークフロー
削除ポリシーの影響
削除ポリシーの作成
削除ポリシーの解除
ポリシーのアクティビティ履歴の表示
ポリシーのオーバーライドの作成
よくある質問
エンタープライズセキュリティ
セキュリティ監査
監査ログ
監査ログのカテゴリー
監査ログの監視
ID の保護
インフラストラクチャセキュリティ
セルフホスト型 Foundry インストールの保護
オンプレミスの Foundry Data Connector の保護
トークンとAPIキーの保護
フィッシングからの保護
悪意のあるファイルからの保護
脆弱性の監視
セキュリティ上の懸念の報告
災害復旧
コード品質
コードスキャン
コードスキャンの概要
コードスキャンの有効化
コードスキャンルールの管理
セキュリティとガバナンス
セキュリティ用語集
Markdown 形式でコピー
Markdown 形式でコピー
コピーしました
注: 以下の翻訳の正確性は検証されていません。
AIP
を利用して英語版の原文から機械的に翻訳されたものです。
セキュリティ用語集
以下に、把握しておくべきセキュリティ用語をすべて示します。
アクセス:
ユーザーがリソースの存在を知ることができるかどうかを示します。アクセス権がある場合、ユーザーはロールを通じてリソースを使用するためのさまざまな機能を付与されます。アクセス権がない場合、ユーザーはリソースの存在を知ることができません。
参照:リソース、ロール
アクセス要件:
プロジェクトやリソースにアクセスできるユーザーを決める、固有のセキュリティ要件です。これらの要件は、組織やマーキングで構成されます。プロジェクトやリソースのアクセス要件を満たしている場合、ユーザーはそのプロジェクトやリソースの存在を知ることができ、それに対するロールを付与されることができます。
参照:組織、マーキング、ロール
属性:
名前、メール、役職など、ユーザーに関する構造化情報の種類です。
資格情報コレクター:
ユーザーの資格情報を収集するシステムです。収集された資格情報は、認証ソースによって検証されます。主なコレクターの種類は SAML です。
デフォルトロール(プラットフォーム):
Foundry プラットフォームには、所有者、編集者、閲覧者、発見者の4つのロールが用意されています。ロール管理者は、これらのロールをカスタマイズするか、これらのデフォルトロールに基づいてまったく新しいロールを作成できます。ロールの定義では、同じリソースに対してほかのロールを付与できるロールも指定でき、これによりロールの階層が作られます。
参照:ロール
デフォルトロール(プロジェクト):
プロジェクトのデフォルトロールは、アクセス要件を満たすすべてのユーザーに自動的に付与されるロールを定義します。プロジェクトにデフォルトロールがない場合、ユーザーはプロジェクトの名前と説明を閲覧し、プロジェクトへのアクセス権をリクエストできますが、プロジェクトの内容を発見することはできません。共同作業と発見を促進するため、特に指定がない限り、プロジェクトの作成時には閲覧者がデフォルトロールとして使用されます。
参照:ロール、プロジェクト
任意アクセス制御:
ユーザーのアクセス権に加えて、ユーザーが利用できる機能全体を拡大する制御で、ロールを通じて付与されます。任意アクセス制御は加算的に働きます。つまり、ユーザーの権限を追加することしかできず、制限することはできません。任意アクセス制御は、データ共有ワークフローを通じてユーザーに付与できます。たとえば、レポートを作成して同僚と共有すると、その同僚にレポートの閲覧権限が付与されます。
組織を適用する:
ユーザーがリソースにアクセス要件として組織を適用できる権限です。この権限を持つユーザーは、リソース、フォルダー、プロジェクトに組織を適用できます。
参照:組織、アクセス要件。
組織の権限
も参照してください
アクセスを拡大する:
リソースにアクセスできる可能性がある対象ユーザーを拡大する、リソースのアクセス要件のあらゆる変更を指します。マーキングの場合、どのマーキングを外しても、アクセスを拡大するイベントになります。組織の場合、アクセスの拡大は、(1)組織が1つ以上適用されている状態で組織を追加するか、(2)適用されている唯一の組織を外すことで発生します。
参照:アクセス要件、組織、マーキング。
組織の権限
も参照してください
グループ:
ユーザーやほかのグループをまとめたものです。グループには、Foundry で定義される内部グループと、外部の IDプロバイダー(Active Directory など)やユーザーマネージャーで定義される外部グループがあります。内部グループには、外部グループやユーザーを含めることができます。
参照:IDプロバイダー、ユーザーマネージャー
IDプロバイダー:
アプリケーションがログイン時にユーザーやサービスを検証できるようにし、ユーザー、グループ、属性に関する情報も提供するシステムです。IDプロバイダーは、ユーザーとグループの情報や属性のソースです。IDプロバイダーにより、アプリケーションはログイン時にユーザーやサービスを検証し、これらのユーザーに関する情報を把握できます。
参照:属性、ユーザー、グループ
継承/継承された権限:
プロジェクトレベルで適用されたアクセス要件は、プロジェクト内のほかのファイルやフォルダーに継承されます。同様に、プロジェクトレベルで付与されたロールは、継承を通じてプロジェクト内のすべてのリソースに付与されます。
参照:ロール
強制アクセス制御:
アクセスを完全に許可するか、まったく許可しないかを決める制限です。強制アクセス制御が設定されている場合、ユーザーのロールにかかわらず、ユーザーはリソースの強制アクセス制御の要件を満たさない限り、そのリソースにいかなる方法でもアクセスできません。これらの制御は、組織とマーキングの形で設定されます。たとえば、同僚がレポートを共有しても、そのレポートの元データセットに最高機密のマーキングがついている場合、ユーザーに最高機密レベルのデータを扱う資格がない限り、レポートへのアクセス権は付与されません。
参照:ロール、組織、マーキング
マーキング:
リソースに適用され、アクセスを完全に許可するか、まったく許可しないかを決めるアクセス要件です。アクセス要件を満たすには、ユーザーはリソースに適用されている
すべて
のマーキングのメンバーである必要があります。マーキングは強制アクセス制御です。
参照:アクセス要件、リソース、強制アクセス制御
マーキングカテゴリー:
マーキングをまとめたものです。マーキングカテゴリーの公開範囲は特定の組織に制限でき、表示または非表示に設定できます。表示カテゴリーは、要件となる組織のメンバーまたはゲストメンバーであれば誰でも発見できます。非表示カテゴリーは、要件となる組織に属し、そのカテゴリーまたはカテゴリー内のマーキングに対する権限を明示的に付与されたユーザーのみが発見できます。
参照:マーキング、組織
スペース(旧称:名前空間):
プロジェクトをまとめる上位の単位で、ファイルシステムや使用状況追跡アカウントなどの共通設定を定義できます。
参照:プロジェクト
組織:
プロジェクトに適用され、ユーザーとリソースのグループ間に厳格な隔離を強制するアクセス要件です。すべてのユーザーは、必ず1つの組織のメンバーになります。アクセス要件を満たすには、ユーザーはプロジェクトに適用されているいずれか1つの組織のメンバーである必要があります。組織は強制アクセス制御です。
参照:アクセス要件、リソース、強制アクセス制御
組織の発見可能性:
ある組織のユーザーからほかの組織がどのように見えるか、また、その逆を指します。組織間の発見可能性は設定できます。組織のユーザー、グループ、リソースを発見可能にするか、非表示にすることができます。
参照:組織
権限:
プラットフォームやリソースに対して特定のタスクを実行できるようにするために、ユーザーやグループに付与される機能です。
参照:ロール、マーキング、リソース
プロジェクト:
プロジェクトは、特定の目的のために人とリソースをまとめる共同作業の場です。プロジェクトは Foundry の主要なセキュリティ境界であり、共有された作業をまとめたものです。プロジェクト内のユーザーは、その内容に対してほぼ同じアクセス権を持ちます(具体的なアクセス権は任意アクセス制御によって異なる場合があります)。そのため、アクセス要件とロールはプロジェクトレベルで適用する必要があります。
参照:リソース、アクセス要件
レルム:
Foundry の認証ソースです。各ユーザーのレルムは、プラットフォーム設定で確認できます。
参照:ユーザー
参照:
リソースをプロジェクトの範囲に含めるための、リソースへのリンクです。参照は通常、データパイプラインを構築する際に、現在のプロジェクトの外部にあるデータセットを含めるために使用されます。
参照:プロジェクト
リソース:
プロジェクト、フォルダー、分析、データセットなど、Foundry プラットフォーム内で一意に識別できるものすべてを指します。リソースは、アクセス要件と権限によって保護されます。
参照:プロジェクト、ロール
制限付きビュー:
定義されたルールに基づいて、ファイル内のデータへのきめ細かなアクセスを制御する特殊なデータセットです。これらのルールはユーザー属性に基づいており、ユーザーのアクセスレベルに応じてデータセットの行を非表示または表示にします。
参照:属性、ユーザー
ロール:
特定のリソースに対してユーザーが実行できる具体的なワークフローを定義する権限の集まりです。ロールは任意アクセス制御であり、一般にプロジェクトレベルで付与され、プロジェクトの範囲内のすべてのリソースに対して一律の機能を提供します。
参照:ワークフロー、リソース、任意アクセス制御
タグ:
分類や検索のためにリソースに適用できる構造化メタデータです。タグはカテゴリーに整理され、カテゴリーを閲覧できる組織を1つ以上に制限できます。タグは便利な仕組みですが、タグによってセキュリティが追加されたり、セキュリティがあることが示されたりすることは一切
ありません
。
ユーザー:
認証済みで Foundry にアクセスできる個人です。ユーザーは外部の IDプロバイダー(たとえば Active Directory システム)によって定義されます。
参照:レルム
ユーザーマネージャー:
ログインフローにカスタムロジックを追加するために使用する、任意の Foundry モジュールです。通常は、ログイン時にユーザーグループや属性を割り当てるために使用します。たとえば、ユーザーマネージャーを使うと、特定のユーザーにはログインを許可し、それ以外のすべてのユーザーにはログインを許可しないようにできます。最も単純なユーザーマネージャーは同期型です。つまり、ログイン時にユーザーのインタラクションなしで、Foundry がサービスに同期的に(同時に)アクセスします。非同期ユーザーマネージャー(AUM)はサーバーにリダイレクトします。このサーバーでは、ログインの続行を許可する前にページを表示し、ユーザーのインタラクション(エンドユーザー使用許諾契約の了承など)をサポートできます。
参照:ユーザー
ワークフロー:
特定のユーザーアクションを実行するために必要な権限の集まりです。これらの権限は、単一のロールでまとめて付与する必要があります。
参照:ロール
←
PREVIOUS
セキュリティの共有責任モデル
NEXT
プラットフォームセキュリティ / はじめに /
データ基盤の保護
→