概要

所有権エージェントは、セキュリティ上の所見があるクラウドリソースのサブセットを選択し、それぞれの所有者を推測します。デフォルトでは、クラウドリソースのタグ、サービスカタログデータ、およびその他のデータソースを使用して、所有権を推測します。

所有権設定により、このプロセスを独自のルールでカスタマイズできます。それらは Datadog のリファレンステーブルに保存され、所有権エージェントが自動的に読み取って結果を向上させます。

所有権設定ファイルを作成する

1. 以下に記載された形式に従って CSV ファイルを作成してください。オプションで、所有権エージェント AI スキルを AI コーディングアシスタント共に使用して、CSV を対話的に生成できます。
2. それを k9_ownership_preferences という名前のリファレンステーブルとしてアップロードします。設定は 24 時間以内に有効になります。

設定タイプ

リファレンステーブルの各行は 1 つの設定です。preference_type 列は、その行が何をするかを決定します。

タグマッピング

タグマッピングは「リソースにタグ X:Y がある場合、それはこの所有者に属します。」と言います。

所有権エージェントは、クラウドリソースのタグをあなたのマッピングと照合します。一致するものが見つかると、指定された所有者を候補として追加します。複数のマッピングが同じリソースに一致することがあり、所有権エージェントは他のデータソースと並べて複数の候補をランク付けします。

タグマッピングは、既存の所有権データソースを補完します。リソースにすでに存在する直接の所有権タグ (例えば、dd-team) が上書きされることはありません。

列

所有者タイプ

owner_type フィールドは、所有者がどのようなエンティティであるかを所有権エージェントに伝えます。これは、AI エンジンが候補のランク付けを行う際により良い判断を下す助けになります。

照合動作

• タグのキーと値の照合で大文字小文字は区別されません。Cost-Centerはcost-centerに一致します。
• 空のtag_valueは、そのタグキーの任意の値に一致します (ワイルドカード)。
• 複数のマッピングが一致する場合、すべてが候補を生成します。所有権エージェントは、それらを信頼度でランク付けします。

信頼度レベル

例: コストセンターをチームにマッピングする

id,preference_type,tag_key,tag_value,owner,owner_type,confidence,handle,exclusion_type,exclusion_resource_type,prompt_text,priority
1,tag_mapping,cost-center,CC-100,team-platform,team,high,,,,,
2,tag_mapping,cost-center,CC-200,team-data-eng,team,high,,,,,
3,tag_mapping,cost-center,CC-300,team-security,team,high,,,,,

例: プロジェクトを所有者にマッピングする

id,preference_type,tag_key,tag_value,owner,owner_type,confidence,handle,exclusion_type,exclusion_resource_type,prompt_text,priority
1,tag_mapping,project,atlas,team-atlas,team,medium,,,,,
2,tag_mapping,project,hermes,alice@example.com,user,medium,,,,,
3,tag_mapping,project,payments,team-fintech,team,high,,,,,

例: ワイルドカードは managed-by タグを持つ任意のリソースに一致する

id,preference_type,tag_key,tag_value,owner,owner_type,confidence,handle,exclusion_type,exclusion_resource_type,prompt_text,priority
1,tag_mapping,managed-by,,team-infra,team,low,,,,,

これは managed-by タグの任意の値に一致し、低い信頼度でそれを team-infra に割り当てます。信頼度が低いため、より強力なデータソースが優先されます。

除外

除外は所有権エージェントに「このハンドルをリソースオーナーとして割り当てないでください」と伝えます。

ボットアカウント、CI ランナー、および共有サービスアカウントは、クラウドリソースのメタデータにしばしば現れます (例えば、作成者や最終修正者として)。除外は、これらを所有権の結果から除外するので、実際の所有者のみが結果に表示されます。

列

照合動作

• handle の照合は、大文字小文字を区別せずに行います。
• オプションのフィルターは、AND ロジックを使用します。除外を適用するには、すべての非空フィールドが一致している必要があります。
• exclusion_typeとexclusion_resource_typeを空白のままにすると、すべての結果からハンドルが除外されます (最も一般的です)。

例: 共通ボットアカウントをすべての結果から除外する

id,preference_type,tag_key,tag_value,owner,owner_type,confidence,handle,exclusion_type,exclusion_resource_type,prompt_text,priority
1,exclusion,,,,,,deploy-bot,,,,
2,exclusion,,,,,,ci-runner,,,,
3,exclusion,,,,,,github-actions,,,,
4,exclusion,,,,,,terraform-automation,,,,

例: 特定のリソースタイプに対してのみサービスアカウントを除外する

id,preference_type,tag_key,tag_value,owner,owner_type,confidence,handle,exclusion_type,exclusion_resource_type,prompt_text,priority
1,exclusion,,,,,,k8s-node-controller,service,aws_ec2_instance,,
2,exclusion,,,,,,autoscaler-svc,service,aws_ec2_instance,,

これらの除外は EC2 インスタンスにのみ適用されます。同じハンドルは、他のリソースタイプでは所有者として認められます。

例: 特定のリソースタイプに対してチームハンドルを除外する

id,preference_type,tag_key,tag_value,owner,owner_type,confidence,handle,exclusion_type,exclusion_resource_type,prompt_text,priority
1,exclusion,,,,,,legacy-ops,team,aws_ec2_instance,,

これにより、EC2 インスタンスのチーム候補として現れる場合にのみ、legacy-ops は除外されます。S3 バケットや他のリソースタイプでは、引き続き考慮されます。

カスタムプロンプトテキスト

カスタムプロンプトテキストは、AI 推論エンジンに自由な形式でガイダンスを提供します。AI がより良い所有権の決定に役立つ組織のコンテキスト (命名規則、チーム構造、優先すべきデータソースなど) を共有するために使用します。

最大で 3 つのプロンプトテキストエントリを提供できます。各優先度レベル (high、medium、low) に 1 つずつです。同じ優先度のエントリは連結されます。優先度を使って、AI エンジンがどのガイダンスを最初に考慮するかを制御します。

列

効果的なガイダンスを書くためのヒント

• 具体的で実行可能であること。「タグを使用してください」よりも「cost-center タグは私たちの最も信頼できる所有権シグナルです」の方が良いです。
• あなたの組織の規則、チームの命名パターン、特定のタグの解釈方法などを説明します。
• 所有者であるはずのないアカウントを特定します (また、これらを実行のための除外行として追加します)。
• 優先レベルごとに 1 つのエントリを使用し、ガイダンスを重要度別に整理します。

例: 優先度別に分割された組織固有のコンテキスト

id,preference_type,tag_key,tag_value,owner,owner_type,confidence,handle,exclusion_type,exclusion_resource_type,prompt_text,priority
1,prompt_text,,,,,,,,Our organization assigns ownership by cost center. The cost-center tag is the primary ownership signal for all cloud resources. Team identifiers always use the team- prefix followed by the team name (e.g. team-platform team-data-eng).,high
2,prompt_text,,,,,,,,Shared infrastructure accounts (deploy-bot ci-runner github-actions terraform-automation) are automation accounts and should never be assigned as resource owners. Look for the human or team that configured the automation instead.,medium
3,prompt_text,,,,,,,,For container images the repository owner in our GitHub organization is a reliable secondary signal when cost-center tags are missing.,low

リファレンステーブル形式

列スキーマ

リファレンステーブルは、名前が k9_ownership_preferences で、以下の 12 列を含む必要があります。

各行は preference_type に応じて列のサブセットを使用します。未使用の列は空のままにしてください。

設定タイプによる列の使用

完全な例

3 種類の設定タイプすべてを含む、すぐに使える CSV です。

id,preference_type,tag_key,tag_value,owner,owner_type,confidence,handle,exclusion_type,exclusion_resource_type,prompt_text,priority
1,tag_mapping,cost-center,CC-100,team-platform,team,high,,,,,
2,tag_mapping,cost-center,CC-200,team-data-eng,team,high,,,,,
3,tag_mapping,cost-center,CC-300,team-security,team,high,,,,,
4,tag_mapping,project,atlas,team-atlas,team,medium,,,,,
5,tag_mapping,project,hermes,alice@example.com,user,medium,,,,,
6,tag_mapping,env,production,sre-team,team,low,,,,,
7,tag_mapping,managed-by,,team-infra,team,low,,,,,
8,exclusion,,,,,,deploy-bot,,,,
9,exclusion,,,,,,ci-runner,service,,,
10,exclusion,,,,,,github-actions,service,,,
11,exclusion,,,,,,legacy-ops,team,aws_ec2_instance,,
12,prompt_text,,,,,,,,Our organization assigns ownership by cost center. The cost-center tag is the primary ownership signal for all cloud resources. Team identifiers always use the team- prefix followed by the team name (e.g. team-platform team-data-eng).,high
13,prompt_text,,,,,,,,Shared infrastructure accounts (deploy-bot ci-runner github-actions) are automation accounts and should never be assigned as resource owners. Look for the human or team that configured the automation instead.,medium
14,prompt_text,,,,,,,,For container images the repository owner in GitHub is a reliable secondary signal when cost-center tags are missing.,low

検証ルール

すべての設定データは、所有権エージェントがリファレンステーブルを読み取る際に検証されます。検証は 100% 合格か不合格かのどちらかです。いずれかの行が検証に失敗すると、所有権エージェントはその同期サイクルにおける設定セット全体を拒否します。このような場合、有効なセットがアップロードされるまで設定は空のままになります。

この厳格なアプローチは、一貫性があり、完全に有効な設定セットで作業していることを確実にするのに役立ちます。

許可される文字

異なるフィールドは異なる文字セットを受け入れます。

注目すべき制限

• 山括弧 (<、>) は、プロンプトテキストを含むいかなるフィールドでも許可されていません。
• 波括弧 ({、}) はいかなるフィールドでも許可されていません。
• パイプ文字 (|) はいかなるフィールドでも許可されていません。

これらの制限は書式設定の不具合を防ぎ、AI エンジンによる適切な処理を確実にするのに役立ちます。

サイズ制限

重複検出

以下に示すように、所有権エージェントは、矛盾または重複するエントリが含まれている場合、設定セット全体を拒否します。

• タグマッピング: 2 つの行で tag_key と tag_value が同じだが owner 値が異なる場合、これは矛盾です。2 つの行で tag_key、tag_value、および owner が同じでも confidence レベルが異なるも矛盾です。完全な重複 (すべてのフィールドが同一) は許可されます。
• 除外: handle、exclusion_type、および exclusion_resource_type が同じである 2 つの行は重複です。比較は大文字小文字を区別しません。

所有権エージェントが矛盾または重複を検出すると、設定セット全体が拒否されます。

プロンプトテキストのコンテンツガイドライン

AI エンジンは、プロンプトテキストを組織のコンテキストとして処理します。あなたのガイダンスが効果的であることを確保するのに役立つのは以下の点です。

• 平易で断定的な文を使用する: あなたの組織に関する事実を説明します。
• 特別な書式設定を避ける: Markdown の見出し、HTML タグ、および XML のようなタグは処理中に削除されます。
• 所有権データソースに焦点を当てる: 所有権を示すタグ、命名規則、またはチーム構造について説明します。

例

• “コストセンタータグは、すべてのクラウドリソースに対する最も信頼できる所有権信号です。”
• “チーム識別子には常に team- プレフィックス (例: team-platform、team-data-eng) を使用します。”
• “us-east-1/prod アカウントのリソースは team-sre によって管理されます。”

所有権設定のアップロード

Datadog はあなたの設定をリファレンステーブルとして保存します。このテーブルは、名前が k9_ownership_preferences で、12 個の列ヘッダーすべてを含む必要があります。一部の行で空であっても構いません。

このテーブルを作成および更新する方法はいくつかあります。

オプション 1: 手動 CSV アップロード (Datadog UI)

このアプローチは、新しく始める場合や時折の更新を行うのに最適です。

1. CSV ファイルを準備します (完全な例を参照してください)。
2. Datadog で、Integrations (インテグレーション) > [Reference Tables] (リファレンステーブル) に移動します。
3. [New Reference Table] (新しいリファレンス テーブル) をクリックします。
4. CSV ファイルをアップロードします。
5. テーブル名を k9_ownership_preferences に設定します。
6. プライマリキーとして id を選択します。
7. [Save] (保存) をクリックします。

リファレンステーブルを更新するには、新しい CSV を同じテーブルにアップロードして、その内容を完全に置き換えます。

手動アップロードは、最大 4MB のファイルをサポートします。

オプション 2: クラウドストレージ同期 (S3、Azure Blob、GCS)

このアプローチは、自動化された定期的な更新に最適です。CSV をクラウドストレージバケットに保存し、Datadog が定期的にインポートできるようにします。

1. CSVを Amazon S3 バケット、Azure Blob Storage コンテナ、または Google Cloud Storage バケットにアップロードします。
2. Datadog で、Integrations (インテグレーション) > [Reference Tables] (リファレンステーブル) に移動します。
3. [New Reference Table] をクリックし、ソースとして [Cloud Storage] (クラウドストレージ) を選択します。
4. ストレージパスと認証情報を入力します (S3 の場合は IAM ロール、Azure の場合はコネクション文字列、GCS の場合はサービスアカウント)。
5. テーブル名を k9_ownership_preferences に設定します。
6. プライマリキーとして id を選択します。
7. [Save] (保存) をクリックします。

Datadog は定期的にファイルを再インポートするので、バケット内の CSV の更新は自動的に取得されます。

クラウドストレージのアップロードは、最大 200MB までのファイルをサポートします。

各クラウドプロバイダーの詳細なセットアップ手順については、リファレンステーブルのドキュメントを参照してください。

オプション 3: Terraform

このアプローチは、他のDatadogリソースと併せて設定を Infrastructure as Code として管理するのに最適です。

Datadog Terraformプロバイダーはリファレンステーブルをサポートします。宣言的にテーブルを作成および更新するために使用します。

詳細については、Datadog Terraform プロバイダーのドキュメントにあるdatadog_reference_table (リソース) を参照してください。

API

リファレンステーブル API を使用して、プログラムでリファレンステーブルを管理することもできます。利用可能なエンドポイントについては、API ドキュメントを参照してください。

該当する場合は、api.datadoghq.com をあなたのDatadog サイト URL に置き換えてください (例えば、api.datadoghq.eu や api.us3.datadoghq.com)。

設定が有効になるタイミング

1. リファレンステーブルをアップロードまたは更新する。
2. 所有権エージェントが定期的に (組織ごとに約1日1回) テーブルを読み取る。
3. 所有権エージェントがテーブル内の設定を検証する。検証に合格すると、新しい設定が以前のセットを置き換えます。
4. 各リソースの次回の所有権推論実行時:
   • タグマッピングは、タグルールに基づいて所有権候補を追加します。
   • 除外は、結果から不要なハンドルを削除します。
   • カスタムプロンプトテキストは、AI 推論エンジンをガイドします。
5. 更新された結果は、Cloud Security ポスチャ管理 UI に表示されます。

リファレンステーブルへの変更は、24 時間以内に反映されます。

トラブルシューティング

検証は 100% 合格か不合格かのどちらかです。いずれかの行に問題がある場合、所有権エージェントは全体の設定を拒否し、有効な設定セットをアップロードするまですべての設定を空にします。

参考資料

お役に立つドキュメント、リンクや記事:

Cloud Security フロンティアグループドキュメント リファレンステーブルドキュメント