Conformity カスタムルールを使用すると、組織のAPIユーザは、APIを使用してカスタムルールを作成、更新、削除、取得、および実行できます。
APIを使用したカスタムルールの作成およびアップデートでは、リクエスト本文のペイロードの一部として設定をサポートし、 organizationに保存されます。
- カスタムルールのドキュメントには、カスタムルールテンプレートのサンプルライブラリがあり、APIリクエストの本文を構成するのに役立ちます。
- APIドキュメントには、クラウドリソースデータのサンプルテンプレートも含まれており、JSON構造の参照に使用できます。
- サンプルテンプレートに加えて、ユーザはアカウント内の既存のクラウドリソースデータをクエリして、リソースデータのJSON構造をさらに参照できます。
Conformity カスタムルールは、1種類のリソースまたは一連の条件に対して非常に具体的なチェックを作成するために設計されており、 JSON と jsonpath の組み合わせを使用します。評価プロセス。
Conformity カスタムルールは、1つのカスタムルールの一部として設定される単一のリソースに対する複数のルールと条件をサポートします。
リソースの種類、リソースID、タグなど、すぐに使用可能なルールと同じ幅広いパラメータに基づいてカスタムルールのチェックをフィルタできます。カスタムルールでは、選択したリソースのリソースデータに含まれるデータを評価することもできます。
柔軟でオープンなフレームワークとして、ネストや複数の条件の関連付けなど、非常に複雑で特定のロジックを作成できます。
カスタムルールを保存する前に、それを使用してカスタムルールを「ドライラン」できます。
「ドライラン」エンドポイントを使用して独自の組織リソースデータをクエリし、カスタムルールロジックを作成するための参照として使用することもできます。
アプリケーションおよびPDFレポートでカスタムルールチェックデータと一緒に表示される、修正手順をカスタムルールに含めることができます。
Conformity カスタムルールは、一部の基本的なデータ検証とエラー処理をサポートします。
Conformity Bot またはRTMによって実行されると、カスタムルールチェックが Conformity コンソールに表示されます。
カスタムルールは現在、次の既存のチェックでサポートされています。
- 閲覧とファイルチェック
- レポート
- 通信チャネル
- 抑制

カスタムルールの使用

組織のカスタムルールを有効にするには、 alloftrendproduct-conformity@trendmicro.comにメールを送信してアクセス権を要求します。
リクエストには次の情報を含めてください。
- Conformityの Organization アカウントの名前
- Cloud One または Conformity Standalone（つまり、cloudconformity.com）を介したアクセスかどうか
- 主要な連絡先のリスト
管理者ユーザであり、 APIキーが設定されていることを確認します。
カスタムルールAPIを使いやすくするために、API管理ツール（Postmanなど）を使用して、テストおよび実装時にAPIペイロードをより簡単に保存、再利用、および管理できるようにすることを強くお勧めします。
使用可能なAPIエンドポイントの使用例と詳細については、 カスタムルールAPIのドキュメントを参照してください。
ワークフロー例を含む入門ガイドについては、Getting Started with Conformity Custom Rulesを参照してください。

カスタムルール設定

カスタムルール設定の構造

定義

属性：ルールのロジック/評価の一部として使用される、ユーザ定義の属性名と関連するリソース値のコレクション
ルール*：カスタムルールのルールセット
条件*：ルールセットの条件オブジェクト
ファクト*：値が見つかる関連する属性名
イベント：ルールセットの名前または説明。

一般なパラメータ

name：カスタムルールの名前またはタイトル
description：オプションの説明の値
重要度：カスタムルールのリスク/重要度。次のいずれかになります。低、中、高、非常に高。
カテゴリ：カテゴリのベストプラクティスを表す一連の文字列。セキュリティ、信頼性、パフォーマンス効率、コストの最適化、操作性のいずれかになります。
remediationNotes：修復に関連するメモまたは手順の説明（オプション）。
enabled：ルールのステータスを示すブール値。無効なルール（つまり、有効に設定されている）は、 Conformity Bot または Real-Time Threat Monitoring (RTM)によって実行されません。
provider：クラウドプロバイダ（aws、azure、gcpなど）。完全なリストについては、Conformity Providers Endpointを参照してください。

リソースパラメータ

service：クラウドプロバイダのサービス名（S3など）。サポートされるサービスの完全なリストについては、 Conformity Services Endpointを参照してください。
resourceType：このカスタムルールが適用されるリソースの種類（例：s3-バケット）。完全なリストについては、Conformity Resource Types Endpointを参照してください。
属性：（オブジェクトの配列）
name：ユーザがパスクエリの結果の値に定義されます。この値は、ルール条件へのファクト入力として使用されます。
パス：リソース値へのjsonpath構文
必須：ルールの実行にこのデータ値が必要かどうかを決定するブール値。「required」がtrueに設定されていて、属性パスの結果が未定義の場合、正確な結果を提供するために必要なデータがないため、ルールは実行されません。未定義のデータが想定される場合は、falseを設定することで、ルールの実行を許可します。

ルールパラメータ

ルール：（配列）カスタムルールには複数のルールセットを含めることができます
条件（オブジェクト）：各条件は、すべてのルートまたは任意のルートのルートで始まる必要があります。
任意/すべて（配列）：これらの条件はネストできます（以下の例を参照）。
ファクト：属性値。一致する属性名が必要です
演算子：
パラメータ：
- 文字列（等しい、notEqual、パターン）*注意：パターンは、正規表現（regex）に一致するカスタム演算子です。
- 数値（equal、notEqual、lessThan、lessThanInclusive、greaterThan、greaterThanInclusive）
- 配列（in、notIn、contains、doesNotContain）
- value：属性の予期される値。結果がtrueの場合、条件は成功です。
path：ネストされた値のjsonpath構文
イベント：
パラメータ：
- type：必要なルールセットに対して返される値です。

演算子

各ルール条件の演算子は、 fact の値を value プロパティの設定値と比較します。結果がtrueの場合、条件は成功です。

正規表現：

pattern：ファクトは値に設定された正規表現パターンを渡す必要があります

文字列と数字：

equal：ファクトは値と等しい必要があります
notEqual：ファクトが値と等しくない

これらの演算子では、厳密な等値（ ===）と不等号（ !==）が使用されます。

Numeric：

lessThan：ファクトは値より小さい必要があります
lessThanInclusive：ファクトは値以下である必要があります
greaterThan：ファクトは値より大きくする必要があります
greaterThanInclusive：ファクトは値以上である必要があります

配列：

in：ファクトは値（配列）に含まれている必要があります
notIn：ファクトを値（配列）に含めないでください
contains：ファクト（配列）には値が含まれている必要があります
doesNotContain：ファクト（配列）には値を含めないでください

Null or Undefined：

isNullOrUndefined：値がtrueの場合、factはnullまたは未定義である必要があります

Date:

dateComparison: 日付ファクトを比較する演算子
- value は、 days および operator プロパティを含むオブジェクトである必要があります。
  - days: ファクト日付と比較する日数
  - operator: 比較に使用する演算子。次の within または olderThan を指定できます。
- 例:
```
{
  "fact": "CreationDate",
  "operator": "dateComparison",
  "value": 
    {
      "days": 30,
      "operator": "within"
    }
}
```

設定例

カスタムルールのサンプル設定については、ここのサンプルライブラリを参照してください。

結果の確認

ルールがすべての条件を通過してチェックが成功したと見なされ、 SUCCESS の結果が返される必要があります。ルール条件のいずれかが失敗した場合、ルールは FAILURE の結果を返します。失敗したルールイベントはすべて、チェックメタデータの一部として含まれます。

確認結果メッセージの設定は必要ありません。メッセージは、設定およびルール条件の合否に基づいて自動的にフォーマットされます。

形式： {resourceType}{resourceName} は、 {ruleEvent} および {Number(ruleConditions - 1)} のその他のルール条件に合格/不合格でした。

Success 結果の例

例： S3バケットbobs-website-bucketが「Bucket has encryption enabled」ともう1つのルール条件に合格しました。

{
  "region": "ap-southeast-2",
  "resource": "bobs-website-bucket",
  "ccrn": "ccrn:aws:abc123ABC-:S3:ap-southeast-2:bobs-website-bucket",
  "status": "SUCCESS",
  "message": "S3 Bucket bobs-website-bucket passed 'Bucket has encryption enabled' and 1 more rule condition.",
  "extradata": [
    {
      "name": "successEvent",
      "label": "Passed Condition Event",
      "value": "Bucket has encryption enabled",
      "type": "META"
    },
    {
      "name": "successEvent",
      "label": "Passed Condition Event",
      "value": "Bucket has versioning enabled",
      "type": "META"
    }
  ]
}

Failure 結果の例

例：S3 バケットバケット -website-バケット failed failed 'バケット暗号化が有効になっています。

{
  "region": "ap-southeast-2",
  "resource": "bobs-website-bucket",
  "ccrn": "ccrn:aws:abc123ABC-:S3:ap-southeast-2:bobs-website-bucket",
  "status": "FAILURE",
  "message": "S3 Bucket bobs-website-bucket failed 'Bucket has encryption enabled' and 1 more rule condition.",
  "extradata": [
    {
      "name": "failedEvent",
      "label": "Failed Condition Event",
      "value": "Bucket has encryption enabled",
      "type": "META"
    },
    {
      "name": "failedEvent",
      "label": "Failed Condition Event",
      "value": "Bucket has versioning enabled",
      "type": "META"
    }
  ]
}

APIエンドポイント

エンドポイント
POST /custom-rules/-新しいカスタムルールを作成します。
PUT /custom-rules/{id} カスタムルール設定のアップデート
GET /custom-rules/-カスタムルールのリスト
GET /custom-rules/{id} 指定したルールを取得する
DELETE /custom-rules/{id} カスタムルールを完全に削除します。注意：これはただちに実行される処理です。削除する前に、アカウント間で1つの Conformity Bot サイクルのカスタムルールを無効にすることをお勧めします。
POST /custom-rules/run-カスタムルールを実行します。

パラメータを使用してカスタムルールの「実行」エンドポイントを実行する
POST /custom-rules/run?accountId={accountId}&id={ruleId} ルールIDを指定してこのルートに投稿すると、指定したアカウントに対してこのルールが実行され、応答の一部として結果が返されます。
POST /custom-rules/run?accountId={accountId} 要求本文の一部としてルール設定を使用してこのルートに投稿すると、このルール設定が実行され、応答の一部として結果が返されます。
POST /custom-rules/run-リクエスト本文の一部としてルール設定とリソースデータを指定してこのルートに投稿すると、指定されたリソースデータに対してこのルール設定が実行され、応答の一部として結果が返されます。
POST /custom-rules/run?accountId={accountId}&resourceData=true ルール設定要求の本文に特定のリソースIDを指定してこのルートに投稿すると、チェック結果とともにリソースデータが返されます。

よくある質問

Conformity カスタムルールにアクセスする方法

組織のカスタムルールを有効にするには、 alloftrendproduct-conformity@trendmicro.comにメールを送信してアクセス権を要求します。
リクエストには次の情報を含めてください。
- Conformityの Organization アカウントの名前
- Cloud One または Conformity Standalone（つまり、cloudconformity.com）を介したアクセスかどうか
- 主要な連絡先のリスト
- 共有製品Slackチャネルに追加されるメールアドレスを持つユーザのリスト
- これは、カスタムルールについて質問したりフィードバックを提供したりするためのフォーラムになります。

Conformity でまだサポートされていないサービスのカスタムルールを作成できますか？

すべてのサービスが自動的にサポートされるわけではありませんが、使用可能なデータがある任意のサービスに対してカスタムルールを作成することは可能です。 Conformity Bot は、特定のデータにアクセスするために、関連するAPI呼び出しを実行するインベントリプロセスと呼ばれるものを使用して、アカウントからそのデータを取り込む必要があります。現在サポートされているサービスに加えて、サポートを希望するサービスがある場合は、機能のリクエストを送信してください。

カスタムルールに例外を実装する方法を教えてください

Conformity カスタムルールには、そのまま使用できる Conformity ルールなどの従来の設定はありません（例外など）。代わりに、特定のリソース名を識別する一意の属性を定義して、その条件をファクトとして参照する特定の条件文を作成し、適切な演算子との条件の一致に基づいてチェックを除外または含めることができます。

特定のパラメータに一致するリソースに対して SUCCESS を自動的に渡す条件を構築することで、例外と同等の機能を実装する方法があります。

バケットアクセスブロックの両方をチェックする設定の例を示します。

{
  "configuration": {
    "name": "S3 encrypted and public access block - with safelist for 'test'",
    "description": "Check S3 has encryption AND public access block, but safelist 'test' buckets",
    "service": "S3",
    "resourceType": "s3-bucket",
    "severity": "HIGH",
    "enabled": true,
    "provider": "aws",
    "categories": [
      "security"
    ],
    "remediationNotes": "To remediate, follow these steps:\n1. Do as you wish \n2. Step two\n",
    "attributes": [
      {
        "name": "bucketEncryption",
        "path": "data.Encryption",
        "required": true
      },
      {
        "name": "publicAccessBlockConfiguration",
        "path": "data.PublicAccessBlockConfiguration",
        "required": true
      },
      {
        "name": "safeList",
        "path": "data.resourceId",
        "required": true
      }
    ],
    "rules": [
      {
        "conditions": {
          "any": [
            {
              "fact": "safeList",
              "operator": "pattern",
              "value": ".*test.*"
            },
            {
              "all": [
                {
                  "fact": "bucketEncryption",
                  "operator": "notEqual",
                  "value": null
                },
                {
                  "fact": "publicAccessBlockConfiguration",
                  "operator": "notEqual",
                  "value": null
                }
              ]
            }
          ]
        },
        "event": {
          "type": "Bucket has encryption enabled"
        }
      }
    ]
  }
}

カスタムルールを特定のアカウントに異なる方法（プロファイルなど）でのみ適用する方法を教えてください。

カスタムルールは組織レベルで保存されます。つまり、グローバルに実行されます。「チェックなし」のシナリオを定義する概念はありませんが、特定のアカウントに適用するとルールが自動的に SUCCESS を返すように、特定の条件を含むようにルール設定を定義することができます。たとえば、リソースデータからAWSアカウントIDのパス値を指定する条件を割り当て、関連するロジックを適用できます。

クエリに使用できるリソースデータオプションはどのように決定しますか？データスキーマまたは辞書はありますか？

Conformity カスタムルールでは、すべてのクラウドリソースデータの完全な公開リソーススキーマが提供されるわけではありませんが、実行エンドポイントを使用して独自のリソースデータを取得する機能は提供されます。これは、クラウドリソースのデータが、サービスや有効になっている設定によって大きく異なるためです。つまり、すべてのサービスで使用可能なすべてのオプションを網羅した辞書を生成するのは、非常に複雑でコストがかかります。共通サービスのサンプルデータと「run」エンドポイントを使用して独自のデータにクエリを実行する機能の両方を提供することで、カスタムルールを作成および調整するために必要なデータにアクセスできます。

リソースデータへのアクセスについてサポートが必要な場合は、サンプルデータの生成を支援するために、 Conformityの制作エンジニアにサポート要求を送信することもできます。

複数のサービスの複数のチェック結果を組み合わせた複雑なワークフローを作成できますか？

高度なユーザは、複数のクラウドサービスの条件を考慮する高度なカスタムルールを作成できます。

現在、カスタムルールでは、この方法で複数のチェックを接続することはできませんが、後のバージョンで構築されるカスタムルールフレームワークの最初の層が提供されます。サービスを組み合わせることができる、より複雑なワークフローを追加する機能は、今後の反復で検討される予定です。これには、既存の Conformity ルール、カスタムルール、またはカスタムデータを結合できる「チェーン」ルールを作成する機能が含まれ、フィードバックに基づいて実行されます。

ルールが想定どおりに機能するかどうかをテストする方法

ユーザは、リクエストの本文にあるサンプルリソースデータを使用して、ルールの「ドライラン」を完了し、出力をテストできます。これにより、ユーザは既知の数量に対して構文と目的の結果を検証できます。

予行演習機能の使用の詳細については、 カスタムルールAPIのドキュメントを参照してください。

**APIを使用してアカウントに対してルールをテストすると、クラウドアカウントの最新情報に基づいてカスタムルールデータが正しく反映されないのはなぜですか？

反映される最新のデータは、 Conformity の最新の実行で保存されたデータに基づいています。ルールをテストする場合は、 Conformity データが更新される前に、基になるリソースの状態が変化する可能性があることに注意してください。

Conformity カスタムルールエンジンは、 Real-Time Threat Monitoring (RTM)をサポートしていますか？

はい。RTMは、 Conformityの関連イベントおよびサービスのサポートに基づいて、他のルールと同じカスタムルールにアクセスできます。

たとえば、S3 バケットのカスタムルールがあり、RTMがS3設定変更イベントを検出した場合、RTMはカスタムルールを含むS3バケット関連ルールのチェックを生成します。

サービスのエンドポイントをチェックし、RTMでサポートされている同等の Conformity ルールを確認することで、サポートされているサービスを確認できます。

ルールの作成にJSONパスを使用しています。 Conformityの実装で注意が必要な点はありますか？

json.path クエリの結果が結果を返さない場合は、エラー処理に役立つように、空の配列ではなく値「undefined」が返されます。

初期設定では、クエリに応じて結果が1つしかない場合でも、特定の応答は配列でラップされます。単一の配列はプリミティブな値にラップ解除されます。これは、ルール設定

具体的なサポートが必要な場合は、お問い合わせください。

リソースデータのスキーマはどのように表示しますか？

カスタムルールの最初の反復用の一般的なスキーマは作成されていません。これは、リソースデータがプラットフォームやサービスによって大きく異なり、 Conformity Botのアップデートに基づいて頻繁に変更される可能性があるためです。

代わりに、「ドライラン」機能を使用して特定のリソースにクエリを実行し、作成したルールに関連するリソースデータの構造の参照として使用できます。これにより、参照元は常に実際のデータに基づいて最新になります。

実行エンドポイントを使用してリソースデータをクエリする方法のワークフローの例は、Custom Rules-Getting Started Guide に含まれています。

参照

https://goessner.net/articles/JsonPath/
jsonpath-plus
JsonPath Evaluator

このページのトピック

Conformityカスタムルールの概要

はじめに

主な機能の概要