プロジェクトの仕組み

これは、プロジェクトの仕組みに関する概念上の概要です。プロジェクトを設定する方法については、プロジェクト参照してください。

複数のプロバイダーにわたる多数のクラウドアカウントまたはリソースを管理することは容易ではなく、特にアカウントの作成と削除が頻繁に行われる場合には困難です。Tenable One Cloud Exposure のプロジェクトは、アカウントまたはリソースを論理的にグループ化することで、アクセスの管理を簡素化し容易にします。

たとえば、プロジェクトを使用すると、クラウド環境の組織の異なる運用グループに基づいてコンソールデータを表示できます。アカウントまたはリソースをプロジェクトに整理することで、可視性とアクセス許可を既存の組織構造に合わせて調整でき、より直感的で効率的な管理エクスペリエンスを実現できます。プロジェクトでは、ユーザーに必要なアカウントやリソースに固有のアクセス許可を付与できるため、アクセス制御も合理化され、手作業の労力が削減され、クラウド管理が改善されます。

開始方法

プロジェクトの仕組み、サポートされている機能、およびプロジェクトの一般的なユースケースについて説明します。
プロジェクトを追加するとプロジェクトフォルダーを追加するを追加します。
アカウント階層とフォルダーことで、ユーザーに特定のプロジェクトスコープへのコンソールアクセス権を付与します。

プロジェクトの仕組み

プロジェクトは、クラウド環境内のリソースを論理的にグループ化したものであり、複数のクラウドプロバイダーにまたがる場合でも柔軟な組織化と管理が可能になります。1 つのアカウントが複数のプロジェクトに属することができるため、さまざまな運用ニーズに応じてアクセスや可視性を構築できます。プロジェクトを作成した後、その範囲内でコンソールデータを表示するアクセス許可をコンソールユーザーに割り当てることができます。さらに、プロジェクトの設定により、プロジェクトに割り当てられたユーザーが、そのプロジェクトのスコープ内のアカウントへのアクセス権を自動的に取得することもできます。

プロジェクトは、1 つ以上のスコープグループで構成されます。各範囲グループは以下で構成されます。

クラウドアカウントのグループ*. これは、次のうちの 1 つ以上の任意の組み合わせです。
- アカウント (AWS など)
- ID プロバイダーテナント (Google Workspace など)。
- コードリポジトリの接続 (GitHub 企業など)
上記のそれぞれに対して、ルートフォルダー全体 (AWS など)、個別のフォルダー、個別のアカウントなど、任意の範囲を選択できます。たとえば、範囲グループは、すべての AWS と Azure の開発アカウントで構成できます。さらに、企業全体を範囲グループとして選択できます。
(オプション) 1 つ以上の論理条件*。
- 含めるアカウントが一致するパターンを指定して、プロジェクトの範囲を制限します。
- 条件パターンは、アカウント名、アカウントタグ、リソースタグ、Azure リソースグループ名に基づく場合があります。これらの設定方法の詳細については、プロジェクトを追加する参照してください。

プロジェクトを使用するタイミング

プロジェクトの作成かどうかと方法を決定する際は、クラウドアカウントのフォルダー構造を自動的に更新選択しているかどうかを検討してください。

このオプションを有効にした場合、オンボード組織のフォルダー構造は、プラットフォームにそのままコピーされ、組織でフォルダーやアカウントを移動、編集、作成することはできなくなります。その結果、アカウントのグループ化の柔軟性をさらに高めるために、プロジェクトは役立つことがわかりました。
このオプションを無効にすると、各プロバイダーのフォルダー構造内でアカウントを整理しやすくなります。この場合、 Tenable では、可能な限りプロバイダー固有のフォルダー内でアカウントを手動でグループ化し、手動のグループ化がニーズを満たさない場合にのみプロジェクトを使用することを推奨します。

プロジェクトの一般的なユースケース

このセクションでは、企業がプロジェクトとプロジェクトフォルダーを使用してクラウドアカウント管理を合理化する一般的な方法をいくつか紹介します。たとえば、次のようなプロジェクトを作成できます。

所有権と責任別にアカウントを整理します。
- プロジェクト
- プロジェクト
インフラとオペレーション別にアカウントを整理します。
- プロジェクト
- アプリケーションおよびサービス境界用のプロジェクトを作成する (Azure)

製品グループのプロジェクトの作成

大規模な企業には多くの場合、独自のクラウドアカウントを管理する複数の製品チーム (グループ A、グループ B、グループ C など) があります。各グループは、アカウントを区別するために異なるアカウント命名規則またはアカウントタグを使用する場合があります。

実装方法

製品グループごとにプロジェクトを追加します (例: 「グループ A プロジェクト」、「グループ B プロジェクト」)。
条件を追加し 、アカウントタグ または命名規則を使用してアカウントを適切なプロジェクトに動的に割り当てます。
- タグキー/値パターンの例
  - キーは product、値は GroupA
  - キーは team、値は GroupB
- 名前パターンの例:
  - group-a-prod-001
  - group-b-dev-002
プロジェクトフォルダーを追加して、地域または他の関連カテゴリ別にプロジェクトを整理します。
ユーザーとグループことで、ユーザーに特定のプロジェクトスコープへのコンソールアクセス権を付与します。以下に例を挙げます。
- 地域の管理者に、プロジェクトフォルダーレベルですべての子プロジェクトを一度に管理するアクセス権を付与します。
- 個別のプロジェクトへのチーム固有のアクセス権を付与します。

ビジネス機能用のプロジェクトの作成

多くの企業は、財務、コンプライアンス、オペレーションなどの事業の機能に基づいてクラウドリソースを分類します。リソースタグパターンを利用することで、事前定義されたタグキーと値のペアに基づいてアカウントをプロジェクトに動的に割り当て、ビジネス機能に基づいてプロジェクトを作成できます。

実装方法

各事業の機能に対してプロジェクトを追加します。
条件を追加し、 リソースタグ パターンを使用して適切なプロジェクトにアカウントを動的に割り当てます。
- タグキー/値パターンの例
  - キーは business_unit、値は finance
  - キーは compliance_level、値は high*
(オプション) プロジェクトフォルダーを追加し、プロジェクトをより広いカテゴリでグループ化します。
ユーザーとグループことで、ユーザーに特定のプロジェクトスコープへのコンソールアクセス権を付与します。以下に例を挙げます。
- すべての環境でより広いアクセスを許可するには、プロジェクトフォルダーレベルでアクセス権を付与します。
- プロジェクト固有のアクセス権を付与します。

開発アカウントと本番アカウント用のプロジェクトを作成する

多くの企業では、開発環境と本番環境を厳格に分離しています。これを徹底するには、環境タイプに基づいてアカウントをグループ化するプロジェクトを作成し、本番プロジェクトにテスト関連のアカウントが含まれないようにします。

実装方法

開発アカウント用のプロジェクトを追加します。
条件を追加し、 アカウントタグ または名前パターンを使用して適切なプロジェクトにアカウントを動的に割り当てます。
- タグキー/値パターンの例
  - キーは environment、値は dev*
  - キーは stage、値は staging*
- 名前パターンの例
  - dev*
テストアカウントをプロジェクトから除外します。
- 名前パターンの除外の例
  - ない test
プロジェクトから実稼働アカウントを除外します。
- タグキー/値パターンの除外の例
  - キーは typeではありません、値は prod*ではありません
本番環境 のアカウントにプロジェクトを追加します。
アカウントタグまたは命名規則を使用して、アカウントを適切なプロジェクトに動的に割り当てるための条件を追加します。
- 実稼働 タグの鍵/値のパターンの例:
  - キーは environment、値は prod*
  - 名前パターンの例
  - prod*
(オプション) 開発プロジェクトフォルダーを追加して、すべての開発プロジェクトを整理します。
(オプション) 生産プロジェクトフォルダーを追加して、すべての開発プロジェクトを整理します。
ユーザーとグループことで、ユーザーに特定のプロジェクトスコープへのコンソールアクセス権を付与します。以下に例を挙げます。
- すべての環境でより広いアクセスを許可するには、プロジェクトフォルダーレベルでアクセス権を付与します。
- プロジェクト固有のアクセス権を付与します。

アプリケーションおよびサービス境界用のプロジェクトを作成する (Azure)

Azure を使用する企業の場合、リソースグループは、クラウド資産を管理するための主要な組織構造として機能します。Azure リソースグループの名前のパターンを利用することで、アプリケーションの所有権、ワークロードのタイプ、地理的リージョンなどの運用境界に合わせたプロジェクトを作成できます。

実装方法

関連する Azure グループごとにプロジェクトを追加します (例: 「顧客向けのアプリ」または内部 IT サービス)。
条件を追加し、 Azure リソースグループ名の パターンを使用して適切なプロジェクトにアカウントを動的に割り当てます。
- リソースグループ名のパターンの例
  - cust-facing-apps-* (外部向けのアプリケーション用)
  - internal-it-* (内部 IT サービス用)
(オプション) プロジェクトフォルダーを追加し、プロジェクトをより広いカテゴリでグループ化します。
ユーザーとグループことで、ユーザーに特定のプロジェクトスコープへのコンソールアクセス権を付与します。以下に例を挙げます。
- すべての環境でより広いアクセスを許可するには、プロジェクトフォルダーレベルでアクセス権を付与します。
- プロジェクト固有のアクセス権を付与します。たとえば、開発者にはお客様向けアプリへのアクセス権のみを付与し、IT 管理者には内部 IT サービスプロジェクトへのアクセス権を付与します。

サポートされている機能

クラウドサイバーエクスポージャーの多くの機能はプロジェクトをサポートしており、特定のプロジェクトスコープ内でアクションを実行できます。一致するプロジェクト範囲が割り当てられたユーザーのみがこれらの機能を表示/管理できます。

たとえば、プロジェクトスコープに対して以下を実行できます。

したがって、たとえば、プロジェクト A に割り当てられたユーザーのみが、そのスコープの API トークンを作成できます。

プロジェクトのアクセス許可と機能

プロジェクトのアクセス許可は、プロジェクト内で論理的にグループ化されたリソースに対してユーザーが実行できるアクションを定義します。これらのアクセス許可は、直接ロール割り当てを使用して明示的に付与されたり、プロジェクトスコーププロパゲーションを介して自動的に拡張されたりすることができます。このセクションでは、プロジェクト関連のアクセス許可の合計数が決定される方法と、それらのアクセス許可によって有効になる特定のアクションについて説明します。

プロジェクトのアクセス許可

プロジェクト権限により、プロジェクト内で何を実行できるかが決まります。これらのロールは、管理者がプロジェクトスコープへのアクセスを付与すると、あなたに直接付与されます。このロールにより、プロジェクト自体を表示および管理できますが、プロジェクト内の個別のスコープを設定するアクセス権は自動的に付与されません。

プロジェクトのアクセス許可:

主に、データの整理やフィルタリングのための表示専用アクセスを提供します。
プロジェクトのスコープ内でほとんどの設定変更を許可しないようにします。たとえば、に組み込まれているポリシーでは設定変更できません。
注意: ただし、以下の操作は実行できます。
- リソースを機密としてマークします。
- 検出結果のステータスを変更します。

プロジェクト内のアカウントに対するユーザーの有効なアクセス許可は、それらのアカウントに対して他の直接割り当てがある場合、より高くなる可能性があります。

伝播

プロパゲーションは、プロジェクトからユーザー権限を自動的に拡張し、そのプロジェクトにスコープも含める機能です。プロジェクトが伝播を有効にして設定されると、そのプロジェクト内のすべての対象範囲にプロジェクトレベルのロールが自動的に適用されます。

重要: 伝播は、このプロジェクトで定義されたリソースベースの条件でフィルターされていない範囲にのみ適用されます。

仕組み

伝播なし: アクセス許可はプロジェクト自体にのみ適用されます。
伝播ありの場合: アクセス許可が拡張されます。伝播が有効になっているプロジェクトの管理者である場合、そのプロジェクト内のすべての対象範囲で自動的に管理者になります。これにより、アクセス管理が合理化され、管理する必要があるリソース全体で一貫したアクセス許可が得られます。つまり、プロジェクトレベルで自分に割り当てられたロールに基づいて、伝播されたアカウントで設定の変更やその他のアクションを実行できるようになります。

有効なアクセス許可

複数のロールが割り当てられている場合、最後のアクセス許可 (有効なアクセス許可) が常に、自分に付与される最高レベルのアクセス権となります。たとえば、あるスコープの表示者であるが、プロジェクトプロジェクトを通じて同じスコープへの管理者アクセス権を取得した場合、そのアカウントの有効なアクセス許可は管理者となります。より高いレベルのアクセス許可が常に優先されます。