ユーザー アカウントには、Security Command Center とカスタム モジュールの操作に必要な権限だけでなく、securitycenter.securityhealthanalyticscustommodules.test 権限も付与されるように、1 つ以上の Identity and Access Management（IAM）ロールを付与する必要があります。カスタム モジュールの操作に必要な権限とロールの詳細については、必要な IAM 権限をご覧ください。
カスタム モジュールをテストするための API 呼び出しには割り当てが適用されます。詳細については、カスタム モジュールの割り当てをご覧ください。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-05 UTC。"],[],[],null,["| Premium and Enterprise [service tiers](/security-command-center/docs/service-tiers)\n\nThis page explains how to test Security Health Analytics custom modules in the\nGoogle Cloud console by uploading a YAML file that contains test data.\n\nBefore you begin\n\nBefore you can test custom modules, you need to satisfy the following\nprerequisites:\n\n- All of the general prerequisites that apply to using Security Health Analytics custom modules. For the full list of prerequisites, see [Using custom modules for Security Health Analytics](/security-command-center/docs/custom-modules-sha-create#before_you_begin).\n- Your user account must be granted one or more Identity and Access Management (IAM) roles that allow you to not only work with Security Command Center and custom modules, but also includes the `securitycenter.securityhealthanalyticscustommodules.test` permission. For more about the permissions and roles you need to work with custom modules, see [Required IAM permissions](/security-command-center/docs/custom-modules-sha-create#iam-for-custom-modules).\n- API calls to test custom modules are subject to a quota. For more information, see [Custom module quotas](/security-command-center/docs/custom-modules-sha-overview#custom_module_quotas).\n\nCreate test resources in a YAML file\n\nTo test a custom module, you define fake resource definitions, fake policy\ndefinitions, or both in a YAML file.\n\nThe definitions do not correspond to real resource or policy instances, but the\ndefinitions must conform to the schemas of the resource or policy types\nthat are specified in your custom modules.\n\nIn your test definitions, the only properties that you need to specify are\nthe properties that your custom modules evaluate. You don't need to include\nresource properties that the custom module doesn't reference.\n\nTo test your CEL expressions in the custom module, specify property values\nin the test file that cause the CEL expressions to resolve to `true`.\n\nFormat of the test data\n\nStart the file with `testData:` on the first line, followed by\none or more `- asset` definitions. \n\n```\ntestData:\n- asset:\n resource: ARBITRARY_ASSET_NAME_1\n assetType: RESOURCE_TYPE_1\n resourceData:\n PROPERTIES_TO_TEST_1: PROPERTY_VALUE_1\n SUB_PROPERTY: SUB_PROPERTY_VALUE\n PROPERTIES_TO_TEST_2: PROPERTY_VALUE_2\n- asset:\n resource: ARBITRARY_ASSET_NAME_2\n assetType: RESOURCE_TYPE_2\n iamPolicyData:\n PROPERTIES_TO_TEST_3: PROPERTY_VALUE_3\n PROPERTIES_TO_TEST_4: PROPERTY_VALUE_4\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eARBITRARY_ASSET_NAME_N\u003c/var\u003e: An arbitrary value that displays in the test results when the test is successful.\n- \u003cvar translate=\"no\"\u003eRESOURCE_TYPE_N\u003c/var\u003e: The type of asset or resource that the custom module checks, specified as the domain name of the API's service endpoint and resource name---for example, `cloudkms.googleapis.com/CryptoKey`.\n- \u003cvar translate=\"no\"\u003ePROPERTIES_TO_TEST_N\u003c/var\u003e: The properties that are used in the detection logic of the custom module to trigger a finding.\n- \u003cvar translate=\"no\"\u003ePROPERTY_VALUE_N\u003c/var\u003e: A value of the property that triggers a finding.\n- \u003cvar translate=\"no\"\u003eSUB_PROPERTY\u003c/var\u003e: A sub-property or property of another resource that the target resource references in its resource definition.\n\nExample test definitions\n\nThis section contains an example of a test resource definition and a\ntest policy definition. Although the two examples are shown as being defined\nin separate files, `asset` definitions for resources and policies can be\ncombined in a single `testData` file.\n\nExample resource definition\n\nThe following example of a test resource definition, tests a custom module\nthat checks whether the `rotationPeriod` property of\n`CryptoKey` resources exceeds `2592000` seconds (30 days). The other\nproperties in the definition are not used in the custom module, but still\nconform to the schema of the resource. For the full\ndefinition of the custom module that this example tests, see\n[Example custom module definition](/security-command-center/docs/custom-modules-sha-code#example_custom_module_definition). \n\n```\ntestData:\n- asset:\n resource: THE CRYPTOKEY TEST WAS SUCCESSFUL!\n assetType: cloudkms.googleapis.com/CryptoKey\n resourceData:\n nextRotationTime: '2020-02-05T12:00:55.192645Z'\n primary:\n state: 'ENABLED'\n purpose: 'ENCRYPT_DECRYPT'\n rotationPeriod: '2592001s'\n```\n\nExample policy definition\n\nThe following is an example of a test definition for an\nIAM policy: \n\n```\ntestData:\n- asset:\n resource: //cloudresourcemanager.googleapis.com/projects/fake-project\n assetType: cloudresourcemanager.googleapis.com/Project\n iamPolicyData:\n bindings:\n - role: \"roles/viewer\"\n members:\n - \"serviceAccount:fake-service-account@compute-system.iam.gserviceaccount.com\"\n - \"user:fake-email-account\"\n```\n\nTest a custom module\n\nYou can test new custom modules or existing custom modules in the\nGoogle Cloud console.\n\nTo test a custom module, follow these steps:\n\n1. Go to the Security Health Analytics **Modules** page in Security Command Center\n settings.\n\n [Go to Modules](https://console.cloud.google.com/security/command-center/config/services/security-health-analytics/modules)\n2. Open or create a custom module for testing:\n\n - To create a new custom module, click **Create module** and follow the instructions in [Create custom modules](/security-command-center/docs/custom-modules-sha-create#create_module).\n - To open an existing custom module, click the edit (*edit* ) icon under **Actions** on the right side of the row for the module you want to test.\n3. Select the **Test module** tab.\n\n4. Under **Upload the YAML file** , click **Browse** to upload a file that\n contains sample asset data. The test runs as soon as the YAML file is uploaded.\n\n5. Under **Test results preview**, check the results.\n\n - If there are syntax or other errors in your YAML file, a floating error message displays near the bottom of the browser page.\n - If the test is a success, the test returns the following information:\n\n - The display name of the custom module.\n - The arbitrary name that you specify on the `resource` property in the test data file.\n - The organization, folder, or project in which the custom module was, or will be, created.\n\n Test results are not stored or written to Security Command Center.\n\nWhat's next\n\n- To work with custom modules, see [Using custom modules for Security Health Analytics](/security-command-center/docs/custom-modules-sha-create)\n- To work with findings in the Google Cloud console, see [Work with findings](/security-command-center/docs/how-to-work-with-findings-in-the-dashboard)"]]
