Tester des modules personnalisés pour Security Health Analytics

Cette page explique comment tester les modules personnalisés de Security Health Analytics dans la console Google Cloud en important un fichier YAML contenant des données de test.

Avant de commencer

Avant de pouvoir tester des modules personnalisés, vous devez remplir les conditions préalables suivantes:

  • Toutes les conditions préalables générales qui s'appliquent à l'utilisation des modules personnalisés de Security Health Analytics, y compris les suivantes:

    • Activation du niveau de service Premium
    • Activation de l'API Security Command Center

    Pour obtenir la liste complète des conditions préalables, consultez Utiliser des modules personnalisés pour Security Health Analytics.

  • Votre compte utilisateur doit disposer d'un ou de plusieurs rôles Identity and Access Management (IAM) qui vous permettent non seulement de travailler avec Security Command Center et les modules personnalisés, mais aussi d'inclure l'autorisation securitycenter.securityhealthanalyticscustommodules.test. Pour en savoir plus sur les autorisations et les rôles nécessaires pour travailler avec des modules personnalisés, consultez la section Autorisations IAM requises.

  • Les appels d'API permettant de tester les modules personnalisés sont soumis à un quota. Pour en savoir plus, consultez la section Quotas de modules personnalisés.

Créer des ressources de test dans un fichier YAML

Pour tester un module personnalisé, vous devez définir de fausses définitions de ressources, de fausses définitions de stratégie, ou les deux, dans un fichier YAML.

Les définitions ne correspondent pas aux instances de ressources ou de règles réelles, mais elles doivent être conformes aux schémas des types de ressources ou de règles spécifiés dans vos modules personnalisés.

Dans vos définitions de test, les seules propriétés que vous devez spécifier sont celles évaluées par vos modules personnalisés. Vous n'avez pas besoin d'inclure des propriétés de ressource auxquelles le module personnalisé ne fait pas référence.

Pour tester vos expressions CEL dans le module personnalisé, spécifiez dans le fichier de test les valeurs de propriété qui entraînent la résolution des expressions CEL en true.

Format des données de test

Commencez le fichier par testData: sur la première ligne, suivi d'une ou de plusieurs définitions - asset.

testData:
- asset:
    resource: ARBITRARY_ASSET_NAME_1
    assetType: RESOURCE_TYPE_1
    resourceData:
      PROPERTIES_TO_TEST_1: PROPERTY_VALUE_1
        SUB_PROPERTY: SUB_PROPERTY_VALUE
      PROPERTIES_TO_TEST_2: PROPERTY_VALUE_2
- asset:
    resource: ARBITRARY_ASSET_NAME_2
    assetType: RESOURCE_TYPE_2
    iamPolicyData:
      PROPERTIES_TO_TEST_3: PROPERTY_VALUE_3
      PROPERTIES_TO_TEST_4: PROPERTY_VALUE_4

Remplacez les éléments suivants :

  • ARBITRARY_ASSET_NAME_N: valeur arbitraire qui s'affiche dans les résultats du test une fois celui-ci réussi.
  • RESOURCE_TYPE_N: type d'élément ou de ressource vérifié par le module personnalisé. Il est spécifié comme nom de domaine du point de terminaison du service de l'API et nom de ressource (par exemple, cloudkms.googleapis.com/CryptoKey).
  • PROPERTIES_TO_TEST_N: propriétés utilisées dans la logique de détection du module personnalisé pour déclencher un résultat.
  • PROPERTY_VALUE_N: valeur de la propriété qui déclenche un résultat.
  • SUB_PROPERTY: sous-propriété ou propriété d'une autre ressource référencée par la ressource cible dans sa définition

Exemples de définitions de test

Cette section contient un exemple de définition de ressource de test et de définition de stratégie de test. Bien que les deux exemples soient indiqués comme étant définis dans des fichiers distincts, les définitions asset des ressources et des règles peuvent être combinées dans un seul fichier testData.

Exemple de définition de ressource

L'exemple de définition de ressource de test suivant teste un module personnalisé qui vérifie si la propriété rotationPeriod des ressources CryptoKey dépasse 2592000 secondes (30 jours). Les autres propriétés de la définition ne sont pas utilisées dans le module personnalisé, mais respectent toujours le schéma de la ressource. Pour connaître la définition complète du module personnalisé testé dans cet exemple, consultez la section Exemple de définition de module personnalisé.

testData:
- asset:
    resource: THE CRYPTOKEY TEST WAS SUCCESSFUL!
    assetType: cloudkms.googleapis.com/CryptoKey
    resourceData:
      nextRotationTime:  '2020-02-05T12:00:55.192645Z'
      primary:
        state: 'ENABLED'
      purpose: 'ENCRYPT_DECRYPT'
      rotationPeriod: '2592001s'

Exemple de définition de stratégie

Voici un exemple de définition de test pour une stratégie IAM:

testData:
- asset:
    resource: //cloudresourcemanager.googleapis.com/projects/fake-project
    assetType: cloudresourcemanager.googleapis.com/Project
    iamPolicyData:
      bindings:
      - role: "roles/viewer"
        members:
        - "serviceAccount:fake-service-account@compute-system.iam.gserviceaccount.com"
        - "user:fake-email-account"

Tester un module personnalisé

Vous pouvez tester de nouveaux modules personnalisés ou des modules personnalisés existants dans la console Google Cloud.

Pour tester un module personnalisé, procédez comme suit:

  1. Accédez à la page Modules de Security Health Analytics dans les paramètres de Security Command Center.

    Accéder aux modules

  2. Ouvrez ou créez un module personnalisé à tester:

    • Pour créer un module personnalisé, cliquez sur Créer un module et suivez les instructions de la section Créer des modules personnalisés.
    • Pour ouvrir un module personnalisé existant, cliquez sur l'icône de modification () sous Actions à droite de la ligne du module que vous souhaitez tester.
  3. Sélectionnez l'onglet Test module (Tester le module).

  4. Sous Importer le fichier YAML, cliquez sur Parcourir pour importer un fichier contenant des exemples de données d'éléments. Le test s'exécute dès que le fichier YAML est importé.

  5. Sous Aperçu des résultats des tests, vérifiez les résultats.

    • Si votre fichier YAML comporte des erreurs de syntaxe ou d'autres erreurs, un message d'erreur flottant s'affiche en bas de la page du navigateur.
    • Si le test réussit, il renvoie les informations suivantes:

      • Nom à afficher du module personnalisé.
      • Nom arbitraire que vous spécifiez dans la propriété resource du fichier de données de test.
      • Organisation, dossier ou projet dans lequel le module personnalisé a été ou sera créé.

    Les résultats des tests ne sont ni stockés, ni écrits dans Security Command Center.

Étapes suivantes