セキュリティ用語集

以下は、理解しておきたいセキュリティ用語のすべてです。

• アクセス: ユーザーがリソースの存在を認識できるかどうかを示します。ユーザーがアクセス権を持っている場合、彼らはロールを通じてリソースを使用するためのさまざまな機能を受け取ることができます。ユーザーがアクセス権を持っていない場合、彼らはリソースの存在を知ることはありません。 参照: リソース、ロール
• アクセス要件: ユーザーがプロジェクトまたはリソースにアクセスできるかどうかを決定するユニークなセキュリティ要件です。これらの要件は、組織と/またはマーキングから構成されます。ユーザーがプロジェクトまたはリソースのアクセス要件を満たす場合、そのユーザーはそのプロジェクトまたはリソースの存在を認識でき、それに対してロールを付与されることができます。 参照: 組織、マーキング、ロール
• 属性: ユーザーに関する構造化された情報のタイプで、名前、メール、職種などがあります。
• クレデンシャルコレクター: ユーザーの資格情報を収集するためのシステムで、これらは認証ソースによって検証されます。主要なコレクタータイプはSAMLです。
• デフォルトロール（プラットフォーム上）: Foundryプラットフォームには4つのロールが付属しています：オーナー、エディター、ビューアー、ディスカバラー。ロール管理者は、これらのロールをカスタマイズするか、またはこれらのデフォルトに基づいて全く新しいものを作成することを選択できます。ロール定義は、同じリソース上で他のロールを付与できるロールを指定することもできます。これにより、ロールの階層が作成されます。 参照: ロール
• デフォルトロール（プロジェクト上）: プロジェクト上のデフォルトロールは、アクセス要件を満たすすべてのユーザーに自動的に付与されるロールを定義します。プロジェクトにデフォルトのロールがない場合、ユーザーはプロジェクトの名前と説明を見ることができ、プロジェクトへのアクセスをリクエストすることができますが、プロジェクトの内容を調査することはできません。共同作業と発見を促進するために、プロジェクト作成は、特に指定がない限り、ビューアーのデフォルトロールを使用します。 参照: ロール、プロジェクト
• 裁量制御: ユーザーがアクセス上に持つ全体的な能力を拡張し、ロールを通じて付与されます。裁量制御は加算的であり、裁量制御はユーザーの許可を追加することしかできず、ユーザーの許可を制限することはできません。裁量制御は、データ共有ワークフローを通じてユーザーに付与することができます。例えば、レポートを作成して同僚と共有すると、その同僚はレポートの表示許可を得ます。
• アクセスの拡大: リソースのアクセス要件が変更され、そのリソースにアクセスできる可能性のある対象者が拡大することを指します。マーキングの場合、任意のマーキングの削除はアクセス拡大イベントです。組織の場合、アクセスの拡大は、（1）最低一つが適用されている場合に追加の組織を追加する、または（2）唯一適用されている組織を削除することによって発生することがあります。 参照: アクセス要件、組織、マーキング
• グループ: ユーザーおよび/または他のグループのセットです。グループは内部的なものである可能性があり、これはFoundryで定義されていることを意味します。また、グループは外部的なものである可能性があり、これは外部のIDプロバイダ（Active Directoryのような）またはユーザーマネージャーによって定義されていることを意味します。内部グループは、外部グループとユーザーを含むことができます。 参照: IDプロバイダー、ユーザーマネージャー
• IDプロバイダー: アプリケーションにユーザーやサービスのログインを検証する能力を提供し、またユーザー、グループ、属性に関する情報を提供するシステムです。IDプロバイダ（IdP）は、ユーザーとグループ情報、属性のソースです。IdPは、ユーザーやサービスがログインする際にアプリケーションがユーザーを検証し、これらのユーザーに関する情報を理解する能力を提供します。 参照: 属性、ユーザー、グループ
• 継承/継承された権限: プロジェクトレベルで適用されるアクセス要件は、プロジェクト内の他のファイルやフォルダーに継承されます。同様に、プロジェクトレベルで付与されたロールは、プロジェクト内のすべてのリソースで継承により付与されます。 参照: ロール
• 必須制御: 一括りのアクセス制限です。必須制御がある場合、ユーザーのロールに関係なく、ユーザーはリソースの必須制御を満たさない限り、いかなる方法でもリソースにアクセスすることはできません。これらの制御は、組織とマーキングの形を取ります。例えば、同僚がレポートを共有し、レポートを裏付けるデータセットが最高機密マーキングでマークされていた場合、ユーザーが最高機密レベルのデータに対してクリアされていない限り、レポートへのアクセスは許可されません。 参照: ロール、組織、マーキング
• マーキング: リソースに適用され、一括りの方式でアクセスを制限するアクセス要件です。アクセス要件を満たすためには、ユーザーはリソースに適用されたすべてのマーキングのメンバーでなければなりません。マーキングは必須制御です。 参照: アクセス要件、リソース、必須制御
• マーキングカテゴリー: マーキングの集まりです。マーキングカテゴリーの可視性は特定の組織に制限され、可視または非表示にすることができます。可視カテゴリーは、必要な組織のメンバーまたはゲストメンバーである誰でも発見できます。非表示のカテゴリーは、カテゴリーまたはカテゴリーのマーキングに明示的に許可が付与された必要な組織のユーザーのみが発見できます。 参照: マーキング、組織
• スペース（以前は名前空間として知られていました）: プロジェクトの高次元のグルーピングで、ファイルシステムや使用追跡アカウントなどの均一な設定を定義できます。 参照: プロジェクト
• 組織: プロジェクトに適用されるアクセス要件で、ユーザーとリソースの間の厳格なシロを強制します。すべてのユーザーは正確に一つの組織のメンバーになります。アクセス要件を満たすためには、ユーザーはプロジェクトに適用された一つの組織のメンバーでなければなりません。組織は必須制御です。 参照: アクセス要件、リソース、必須制御
• 組織の発見可能性: 一つの組織のユーザーが他の組織をどのように見るか、またその逆です。組織間の発見可能性は設定可能で、組織のユーザー、グループ、および/またはリソースを発見可能にするか、非表示にすることができます。 参照: 組織
• 許可: ユーザーまたはグループに付与され、プラットフォーム内またはリソース上で特定のタスクを実行することを許可する一連の機能です。 参照: ロール、マーキング、リソース
• プロジェクト: プロジェクトは、特定の目的のために人々とリソースを組織する共同作業スペースです。プロジェクトはFoundryの主要なセキュリティ境界であり、共有作業の集合を表します。プロジェクト内のユーザーは、その内容に対してほぼ均一なアクセスを持ちます（特定のアクセスは裁量制御により異なる可能性があります）。つまり、アクセス要件とロールはプロジェクトレベルで適用するべきです。 参照: リソース、アクセス要件
• レルム: Foundryの認証ソースです。各ユーザーのレルムはプラットフォーム設定で確認できます。 参照: ユーザー
• リファレンス: リソースへのリンクで、プロジェクトの範囲内にリソースが含まれるようにします。リファレンスは通常、データパイプラインを構築する際に、現在のプロジェクトの外部からデータセットを含めるために使用されます。 参照: プロジェクト
• リソース: Foundryプラットフォーム内で一意に識別可能なものすべて、たとえばプロジェクト、フォルダー、分析、データセットなどです。リソースはアクセス要件と許可で保護されます。 参照: プロジェクト、ロール
• 制限付きビュー: 定義されたルールに基づいてファイル内のデータへの詳細なアクセスを制御する特別な種類のデータセットです。これらのルールはユーザー属性に基づいており、ユーザーのアクセスレベルに応じてデータセットの行を非表示または表示します。 参照: 属性、ユーザー
• ロール: ユーザーが特定のリソースで実行できる特定のワークフローを定義する許可の集まりです。ロールは裁量制御であり、一般的にはプロジェクトレベルで付与され、プロジェクトの範囲内のすべてのリソースに均一な機能を提供します。 参照: ワークフロー、リソース、裁量制御
• タグ: リソースに適用できる構造化されたメタデータで、カテゴリ分けと発見のために使用されます。タグはカテゴリに組織され、その可視性は一つ以上の組織に制限されることがあります。タグは有用な構造であることがありますが、タグは何らかの形でセキュリティを追加または暗示しません。
• ユーザー: 認証され、Foundryにアクセスすることができる個人です。ユーザーは外部のIDプロバイダ（例えばActive Directoryシステム）によって定義されます。 参照: レルム
• ユーザーマネージャー: ログインフローにカスタムロジックを追加するために使用されるオプションのFoundryモジュールです。通常はログイン中にユーザーグループと属性を割り当てます。例えば、ユーザーマネージャーは特定のユーザーのログインを許可しながら、他のすべてのユーザーのログインを不許可にすることができます。最も単純なユーザーマネージャーは同期的で、つまりFoundryはログイン中にサービスに同時に（同時に）連絡し、ユーザーのインタラクションはありません。非同期ユーザーマネージャー（AUM）は、サーバーにリダイレクトし、ログインが進行する前にページを表示し、ユーザーのインタラクション（エンドユーザーライセンス契約の確認など）をサポートすることができます。 参照: ユーザー
• ワークフロー: 単一のロールで一緒に付与するべき特定のユーザーアクションを実行するために必要な許可のセットです。 参照: ロール