ビュー:
プレビューで利用可能

はじめに 親トピック

Conformityカスタムルールを使用すると、Conformityによって保存されたクラウド構成データに基づいてチェックを行うカスタマイズ可能なルールを作成できます。
ConformityのコアエンジンはConformity Botであり、クラウドアカウントからRead-only APIメタデータを取り込み、'ルール'と呼ばれるベストプラクティスロジックを通じて情報を評価します。
一般的なユースケースとコンプライアンス基準は、Conformityによって標準でカバーされています。ただし、Organizationにはカスタマイズが必要なさまざまなユースケースがあるかもしれません。
柔軟なフレームワークを提供することで、独自のニッチなルールを作成できます。
Conformity Custom Rulesの目的:

手順

  1. Conformityに保存されたクラウド構成データに基づいてチェックを形成するカスタマイズ可能で特定のルールを作成することを可能にします。
  2. 既存のRule settingsフレームワークに依存せず、カスタムルール設定にすべての構成オプションを埋め込む自由を提供します。
  3. 開発者としてのあなたのために、汎用的な言語とツールのセットを最適化します。
  4. 既存のConformity機能 (ルールフィルタリング、チェックの抑制、通信チャネル、レポートなど) を活用して、コア体験が標準のルールと同じになるようにします。

主な機能のSummary 親トピック

  • Conformity Custom Rulesは、OrganizationのAPIユーザがAPIを介してカスタムルールを作成、更新、削除、取得、および実行することを可能にします。
    • APIを介したカスタムルールの作成および更新は、リクエスト本文ペイロードの一部としてConfiguration Settingsをサポートし、[organization]に保存されます。
      • カスタムルールのドキュメントには、APIリクエスト本文を構築するのに役立つカスタムルールテンプレートの例のライブラリが含まれています。
      • APIドキュメントには、ユーザがJSON構造を参照するために使用できるクラウドリソースデータの例のテンプレートも含まれています。
      • サンプルテンプレートに加えて、ユーザはアカウント内の既存のクラウドリソースデータをクエリして、リソースデータのJSON構造をさらに参照することができます。
  • 特定のリソースタイプまたは条件セットに対して非常に具体的なチェックを作成するために設計されたConformity Custom Rulesは、リソースデータをクエリするための十分に文書化されたJSON構文であるJSONjsonpathの組み合わせを使用し、ルールのロジック/評価プロセスの一部として使用されます。
  • Conformity Custom Rulesは、1つのカスタムルールの一部として構成される単一のリソースに対して複数のルールと条件をサポートします。
  • カスタムルールチェックは、リソースタイプ、Resource id、タグなど、既製ルールと同じ幅広いパラメータに基づいてフィルタリングできます。カスタムルールは、選択したリソースのリソースデータに含まれる任意のデータを評価することもできます。
  • 柔軟でオープンなフレームワークとして、複数の条件をネストおよび関連付けることを含む、非常に複雑で特定のロジックを作成することが可能です。
  • カスタムルールを保存する前に、ダミーデータを使用してドライランすることができます。
  • ‘dry run’エンドポイントを使用して、独自のOrganizationリソースデータを照会し、カスタムRuleロジックを作成するためのレファレンスとして使用することもできます。
  • カスタムルールに修復手順を含めることができ、アプリケーションおよびPDFレポートのカスタムルールチェックデータと一緒に表示されます。
  • Conformity Custom Rulesは、基本的なデータ検証とエラーハンドリングをサポートします。
  • Conformity BotまたはRTMによって実行されると、カスタムルールチェックはConformityコンソールに表示されます。
    • カスタムルールは現在、以下の既存のチェックによってサポートされています:
      • ブラウジングおよびフィルタリングチェック
      • Reports
      • 通信チャネル
      • 抑制

カスタムルールの使用 親トピック

  • カスタムルールをOrganizationで有効にするには、alloftrendproduct-conformity@trendmicro.comにメールを送信してアクセスをリクエストしてください。
    • リクエストに以下の詳細を提供してください:
      • ConformityのOrganizationアカウントの名前
      • アクセスがCloud One経由であれ、Conformity Standalone (つまりcloudconformity.com) 経由であれ
      • 主要な連絡先を一覧表示
  • 管理者ユーザであり、APIキーを設定していることを確認してください。
  • カスタムルールAPIに慣れるために、API管理ツール (例: Postman) を使用して、テストおよび実装中にAPIペイロードをより簡単に保存、再利用、および管理することを強くお勧めします。
  • より完全な使用例と利用可能なAPIエンドポイントの詳細については、[Custom Rules API documentation]を参照してください。
  • 入門ガイドとワークフローの例については、Conformity Custom Rulesの使い方を参照してください

カスタムルール設定 親トピック

カスタムルール構成の概要 親トピック

Definitions 親トピック

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

一般パラメータ 親トピック

  • name: カスタムRuleの名前またはタイトル
  • 説明: オプションの説明値
  • 重大度: カスタムRuleのリスク/重大度レベルは、次のいずれかになります: 低、中、高、Very high。
  • categories: カテゴリのベストプラクティスの柱の文字列の配列で、次のいずれかになります: security, reliability, performance-efficiency, cost-optimisation, operation-excellence.
  • 修復メモ: 修復に関連するメモや手順の任意のテキスト説明。
  • 有効: ルールのステータスを示すブール値。無効なルール (つまり、有効がfalseに設定されている場合) は、Conformity BotやReal-Time Threat Monitoring (RTM) によって実行されません。
  • プロバイダ: クラウドプロバイダ (例: aws, azure, gcp)。完全なリストについては、Conformity Providers Endpointを参照してください

リソースパラメータ 親トピック

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

ルールパラメータ 親トピック

  • rules: (array) カスタムRuleには複数のルールセットを含めることができます
  • 条件 (オブジェクト): 各条件はルートにallまたはanyで始める必要があります。
  • any/all (配列): これらの条件はネストできます (以下の例を参照)
  • 事実: 属性値は、一致する属性名を持っている必要があります
  • オペレーター:
    • パラメータ:
      • 文字列 (equal, notEqual, pattern)* 注: patternは正規表現 (regex) に一致するカスタムオペレーターです
      • 数値 (equal, notEqual, lessThan, lessThanInclusive, greaterThan, greaterThanInclusive)
      • 配列 (in, notIn, contains, doesNotContain)
      • value: 属性の期待値。結果が真であれば、条件は合格します。
  • path: ネストされた値のためのjsonpath構文
  • イベント:
    • パラメーター:
      • type: これは必要なルールセットに対して返される値です

オペレーター 親トピック

各ルール条件のオペレーターは、factの値をvalueプロパティに設定された値と比較します。結果が真であれば、条件は合格します。
[Regex:]
  • pattern: factはvalueに設定された正規表現パターンを通過する必要があります
[String and Numbers:]
  • equal: ファクトは値と等しくなければなりません
  • notEqual: 値と等しくない必要があります
これらの演算子は厳密等価 (===) と不等価 (!==) を使用します
[Numeric]:
  • lessThan: 値は基準値未満でなければなりません
  • lessThanInclusive: 値は指定された値以下でなければなりません
  • greaterThan: 値は指定された値より大きくなければなりません
  • greaterThanInclusive: 値は指定された値以上でなければなりません
[Array]:
  • in: 値 (配列) に事実が含まれている必要があります
  • notIn: factは値 (配列) に含まれてはなりません
  • contains: fact (配列) には値が含まれている必要があります
  • doesNotContain: fact (配列) には値を含めないでください
[Null or Undefined]:
  • isNullOrUndefined: 値がtrueの場合、factはnullまたはundefinedでなければなりません
[Date]:
  • dateComparison: 日付ファクトを比較するための演算子
    • valuedaysoperatorプロパティを含むオブジェクトである必要があります
      • days: 実際の日付と比較する日数
      • operator: 比較に使用するオペレーター。次のいずれかを指定できます: within, olderThan
    • 例:
      {
        "fact": "CreationDate",
        "operator": "dateComparison",
        "value": 
          {
            "days": 30,
            "operator": "within"
          }
      }

例の構成 親トピック

カスタムRuleのサンプル構成を確認するには、こちらの例のライブラリを参照してください。

チェック結果 親トピック

ルールはすべての条件を満たす必要があり、成功したチェックと見なされ、SUCCESS結果を返します。いずれかのルール条件が失敗した場合、ルールはFAILURE結果を返し、失敗したルールイベントをチェックメタデータの一部として含めます。
チェック結果メッセージには設定は不要です。メッセージは設定およびRule条件の合否に基づいて自動的にフォーマットされます。
[Format:] {resourceType} {resourceName}は{ruleEvent}および{Number (ruleConditions - 1)}のルール条件に合格/不合格です。
[Example Success Result]
例: S3バケットbobs-website-bucketはバケットに暗号化が有効になっていると1つのRule条件をPassedしました。
custom-rule-check-response-success=4b4ee3b1-7a49-4168-b3cd-75f4d8ca5a4c.png
{
  "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"
    }
  ]
}
[Example Failure Result]
例: S3バケットbobs-website-bucketは失敗しました。'バケットに暗号化が有効になっています'。
custom-rule-check-response-failure=e7a34dcd-12de-43d3-b441-84e05c00e0e5.png
{
  "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エンドポイント 親トピック

[Endpoint]
POST /custom-rules/ - 新しいカスタムRuleを作成
PUT /custom-rules/{id} - カスタムルール設定を更新
GET /custom-rules/ - list custom rules
GET /custom-rules/{id} - 指定されたRuleを取得
DELETE /custom-rules/{id} - カスタムルールを完全に削除します。 注: これは即時のアクションです。削除する前に、アカウント全体で1つのConformity Botサイクルの間、カスタムルールを無効にすることをお勧めします。
POST /custom-rules/run - カスタムRuleを実行
  • パラメーターを使用してカスタムルールrunエンドポイントを実行中
  • POST /custom-rules/run?accountId={accountId}&id={ruleId} - このルートにルールIDを使用してPOSTすると、指定されたアカウントに対してこのRuleが実行され、結果がレスポンスの一部として返されます。
  • POST /custom-rules/run?accountId={accountId} - このルートにルール設定をリクエスト本文の一部として投稿すると、このルール設定が実行され、結果がレスポンスの一部として返されます。
  • POST /custom-rules/run - このルートにルール構成とリソースデータをリクエスト本文の一部として投稿すると、提供されたリソースデータに対してこのルール構成が実行され、結果がレスポンスの一部として返されます。
  • POST /custom-rules/run?accountId={accountId}&resourceData=true - このルートに特定のResource idを含むルール設定リクエスト本文をPOSTすると、リソースデータとチェック結果が返されます。

よくある質問 親トピック

[How do get access to Conformity Custom Rules?]
  • カスタムルールをOrganizationで有効にするには、alloftrendproduct-conformity@trendmicro.comにメールを送信してアクセスをリクエストしてください。
    • リクエストに以下の詳細を提供してください:
      • ConformityのOrganizationアカウントの名前
      • アクセスがCloud One経由であれ、Conformity Standalone (つまりcloudconformity.com) 経由であれ
      • 主要な連絡先を一覧表示
      • 共有製品のSlackチャンネルに追加されるメールアドレスを持つユーザのリスト
      • これはカスタムルールに関する質問やフィードバックを提供するためのフォーラムです。
[Can I create custom rules for services Conformity does not yet support?]
すべてのサービスが自動的にサポートされるわけではありませんが、データが利用可能なサービスに対してカスタムルールを作成することは可能です。特定のデータにアクセスするためには、Conformity Botが関連するAPIコールを行うインベントリプロセスを使用して、アカウントからそのデータを取り込む必要があります。現在サポートしているサービスに加えてサポートしてほしいサービスがある場合は、機能リクエストを提出してください。
[How do I implement exceptions in my custom rule?]
Conformityカスタムルールには、標準のConformityルール (例: 例外) のような従来の設定構成はありません。代わりに、特定のリソース名を識別する一意の属性を定義し、適切なオペレーターで条件と一致させてチェックを除外または含めるための条件文を作成することができます。
特定のパラメータに一致するリソースに対して自動的にSUCCESSを渡す条件を構築することで、例外に相当するものを実装する方法があります。
これは、S3暗号化とパブリックアクセスブロックの両方をチェックする構成の例ですが、名前にtestを含むバケットは自動的に成功します。
{
  "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"
        }
      }
    ]
  }
}
[How can I make a custom rule only apply to certain accounts in different ways (e.g. like profiles)?]
カスタムルールはOrganizationレベルで保存されるため、グローバルに実行されます。チェックなしのシナリオを定義する概念はありませんが、特定の条件を含むルール構成を定義することで、特定のアカウントに適用されたときにルールが自動的にSUCCESSを返すようにすることが可能です。例えば、リソースデータからAWS Account Idパス値を指定し、関連するロジックを適用する条件を割り当てることができます。
[How do I determine the resource data options available to query, and is there a data schema or dictionary?]
Conformity Custom Rulesは、すべてのクラウドリソースデータに対して完全な公開リソーススキーマを提供しているわけではありませんが、runエンドポイントを使用して独自のリソースデータを取得する機能を提供しています。これは、クラウドリソースデータがサービスや有効化されている設定によって非常に多様であり、すべてのサービスのすべての可能なオプションに対する包括的な辞書を生成することが非常に複雑で高価であるためです。一般的なサービスのサンプルデータと、runエンドポイントを使用して独自のデータをクエリする機能の両方を提供することで、カスタムルールを作成および微調整するために必要なデータにアクセスできます。
リソースデータへのアクセスに関して支援が必要な場合は、Conformityのプロダクションエンジニアにサンプルデータの生成を依頼するサポートリクエストを提出することもできます。
[Can I create complex workflows that combine the result of multiple checks from multiple services?]
上級ユーザは、複数のクラウドサービスの条件を考慮した高度なカスタムルールを作成したい場合があります。
カスタムルールは現在、この方法で複数のチェックを接続する機能を提供していませんが、後のバージョンで構築されるカスタムルールフレームワークの最初のレイヤーを提供します。サービスを組み合わせることができるより複雑なワークフローを追加する機能は、将来のバージョンで検討されます。これには、既存のConformityルール、カスタムルール、またはカスタムデータを結合できる連鎖ルールを作成する機能が含まれる可能性があり、皆様のフィードバックによって推進されます。
[How do I test a rule is working as expected?]
Usersは、リクエストの本文にあるサンプルリソースデータを使用して、ルールのドライランを実行し、出力をテストできます。ルールを作成する際、これによりユーザは既知の量に対して構文と望ましい結果を検証する機会を得ることができます。
ドライラン機能の使用に関する詳細については、[custom rules API documentation]を参照してください。
[When I test the rule against an account using the API, why is my custom rule data not reflecting correctly based on my latest information in my cloud account?]
最新のデータは、最新のConformity実行によって保存されたデータに基づいています。ルールをテストする際には、Conformityデータが更新される前に基礎となるリソースの状態が変わる可能性があることに注意してください。
[Does the Conformity Custom Rules engine support Real-Time Threat Monitoring (RTM)?]
はい、RTMは、関連するイベントおよびサービスに対するConformityのサポートに基づいて、他のルールと同様にカスタムルールへのアクセス権を持っています。
例えば、S3バケットにカスタムルールがあり、RTMがS3の設定変更イベントを検出した場合、RTMはカスタムルールを含むS3バケット関連のルールのチェックをGenerateします。
services endpointを確認して、RTMでサポートされている同等のConformityルールを確認できます。
[I am using JSON path to create my rule. Is there anything unique to Conformity’s implementation I need to be mindful of?]
デフォルトでは、[json.path]クエリの結果が返されない場合、エラー処理を支援するために、空の配列ではなく値undefinedを返します。
デフォルトでは、クエリに応じて、結果が1つだけの場合でも特定のレスポンスが配列でラップされ、単一の配列はそのプリミティブ値にアンラップされます。これは、ルール設定に応じてケースバイケースで対処できます。
具体的な支援が必要な場合は、サポートリクエストを提出してください。
[How do I see a schema for the resource data?]
カスタムルールの最初のイテレーションのための一般スキーマは構築されていません。これは、リソースデータがプラットフォームやサービスによって大きく異なる可能性があり、Conformity Botの更新に基づいて頻繁に変更される可能性があるためです。
代わりに、ドライラン機能を使用して特定のリソースをクエリし、作成しているRuleに関連するリソースデータの構造の参照情報として使用できます。これにより、参照情報は常に実際のデータに基づいて最新の状態に保たれます。
実行エンドポイントを使用してリソースデータをクエリする方法のワークフロー例は、カスタムルール - はじめにガイドに含まれています。
[References]