ビュー:

ワークフローは、初めてカスタムルールを作成、実行、更新、削除するシナリオを案内します。

ワークフロー1: カスタムルールの作成、実行、更新、削除

独自のカスタムルールを作成する前に、主要な機能を示すためにテンプレートのいずれかを使用することをお勧めします。
  1. 成功した会社カスタムルールを取得リクエストを複製します。POSTリクエストタイプに変更し、カスタムルールを作成と名前を変更して保存をクリックします。これは、https://api.xdr.trendmicro.com/beta/cloudPosture/customRulesのようなエンドポイントへのPOSTコマンドになります
  2. PostmanのBodyヘッダーの下で、Rawを選択し、JSON形式が選択されていることを確認して、以下のカスタムルールテンプレートを貼り付けて、保存をクリックします。PostmanではリクエストボディをBeautifyすることもできます。このルールはS3 bucketの暗号化をチェックするための基本的なデモルールです。 
    {
    "name": "S3 bucket has any Encryption",
    "description": "We want to demonstrate Custom Rules V1",
    "categories": [
        "security"
    ],
    "riskLevel": "MEDIUM",
    "provider": "aws",
    "enabled": true,
    "service": "S3",
    "resourceType": "s3-bucket",
    "remediationNote": "To remediate, follow these steps:\n1. Step one \n2. Step two\n",
    "attributes": [
        {
            "name": "bucketEncryption",
            "path": "data.Encryption",
            "required": true
        }
    ],
    "eventRules": [
        {
            "conditions": {
                "all": [
                    {
                        "fact": "bucketEncryption",
                        "operator": "notEqual",
                        "value": null
                    }
                ]
            },
            "description": "Bucket has encryption enabled"
        }
    ]
}
  3. 保存して送信をクリックします。成功すると、対応は201 HTTP応答を返します。これでカスタムルールが組織に保存されました。このルールは、通常のCloud Risk Management検索プロセスの一環として、関連する各クラウドアカウント (この場合はAWS) のリソースデータに対して自動的に実行されます。
  4. 確認するには、前の会社カスタムルール取得クエリに戻り、そのリクエストを再度実行してください。保存されたルールを詳述するデータが対応で返されるのが確認できるはずです。
  5. 任意 (環境と時間に依存 - それ以外の場合は次のセクションに進む): Cloud Risk Managementでクラウドアカウントの検索を行うことができます。保存されたカスタムルールは次回の検索で自動的に適用され、他のルールと同じ形式でチェックが生成されます。
  6. 推奨 (トラブルシューティングの注意): Conformityコンソールでチェックを表示したい場合、カスタムルールを作成した後にブラウザウィンドウを更新してください。これにより、Conformityウェブアプリケーションがチェックを正しく表示するために必要なデータを読み込むことができます。この更新を行わないと、Conformityアプリケーションがチェックを正しく表示するために必要なデータの一部しか読み込まない可能性があります。
  7. ブラウザを更新した後、Cloud Risk Management > Misconfiguration and Complianceページでクラウドアカウントをクリックし、Browse All Checksをクリックします。カスタムルールIDを使用してフィルタリングし、アカウントで最初のカスタムルールがライブでアクティブになっていることを確認します。

既存の保存されたカスタムルールを更新、テスト、無効化、削除します

保存されたカスタムルールを更新、無効化、永久に削除することができます。既存のカスタムルールは、基本的な構成変更 (例: riskLevelやcategory) や、ルールロジックを含むより大幅な変更のために更新できます。更新されたルールは、最新のロジックが実行されるまでチェックを保持します。
注意: ルールを削除しても、関連するデータ、例えば関連するチェックの削除/除去には即座に影響を与えません。まずルールを無効にすることをお勧めします。つまり、enabled: false とし、削除する前にCloud Risk Management検索を1サイクル実行してください。これにより、検索が関連するチェックを削除し、統計の更新、作成されたJIRA/ServiceNowチケットのクローズなど、関連するタスクを完了することができます。
  1. POSTクエリCreate a custom ruleを複製し、PATCHリクエストに変更してUpdate custom ruleに名前を変更します。
  2. URLに/<custom-rule-id>を追加します。例: https://api.xdr.trendmicro.com/beta/cloudPosture/customRules/CUSTOM-QqVHDF6JVdUE
  3. ルールテンプレートの本文を次のように変更します: a. nameの値 (ルール名は任意) とriskLevelの値 (例: 低に変更)。 b. rules → conditions → all → operatorの下で、notEqualをequalに変更 (これによりルールのロジックが反転します)。
  4. 保存して送信をクリックします。既存のルールは対応に表示され、更新されます。Get company custom rulesを再実行して確認できます。
  5. カスタムルール設定のテストを実行して、新しく更新されたルールをテストしてください。以前のFAILUREチェックがSUCCESSチェックに置き換えられていることに気付くはずです。Cloud Risk Management検索でルールを実行すると、チェックのデータが更新されるのがわかります。
  6. 最終的なクリーンアップとして、保存されたルールを無効化および削除する準備をします。まず、保存されたルールを無効化します。これにより、Cloud Risk Management検索がチェックの削除に関連するタスク (関連するチェックの削除、統計の更新、作成されたJIRA/ServiceNowチケットのクローズなど) を処理できるようになります。カスタムルールに対してチェックが作成されていない場合は、手順8に進んでカスタムルールを永久に削除してください。PATCHリクエストカスタムルールの更新の本文を修正し、enabledプロパティをfalseに変更します。
  7. 送信をクリックしてください。既存のルールは対応に示されているように更新されます。会社のカスタムルールを取得を再実行することで確認できます
  8. Cloud Risk Management検索がカスタムルールに関連するアカウント全体で完全なサイクルを実行することを許可します。
  9. PATCHリクエストで保存されたルールを複製し、DELETEリクエストに変更して新しいリクエスト名をDelete custom ruleに変更します。
  10. 本文をクリアすることができます (任意)、削除したい会社のカスタムルールIDを含むURLを確認し、保存をクリックして送信します。会社のカスタムルールを取得クエリを再実行して、カスタムルールの配列が空であるかどうかを再確認できます。