Créez des règles AWS Config personnalisées à l'aide AWS CloudFormation Guard de politiques

Créée par Andrew Lok (AWS), Kailash Havildar (AWS), Nicole Brown (AWS) et Tanya Howell (AWS)

Récapitulatif

AWS Configles règles vous aident à évaluer vos AWS ressources et l'état de leur configuration cible. Il existe deux types de AWS Config règles : les règles gérées et les règles personnalisées. Vous pouvez créer des règles personnalisées avec AWS Lambda des fonctions ou avec AWS CloudFormation Guard(GitHub), une policy-as-code langue.

Les règles créées avec Guard fournissent un contrôle plus granulaire que les règles gérées, et elles sont généralement plus faciles à configurer que les règles Lambda entièrement personnalisées. Cette approche permet aux ingénieurs et aux architectes de créer des règles sans avoir besoin de connaître Python, NodeJS ou Java, qui sont nécessaires pour déployer des règles personnalisées via Lambda.

Ce modèle fournit des modèles pratiques, des exemples de code et des approches de déploiement pour vous aider à adopter des règles personnalisées avec Guard. En utilisant ce modèle, un administrateur peut AWS Config créer des règles de conformité personnalisées dotées d'attributs d'éléments de configuration. Par exemple, les développeurs peuvent utiliser les politiques Guard sur les éléments de AWS Config configuration afin de surveiller en permanence l'état des AWS ressources déployées AWS et non déployées, de détecter les violations des règles et de lancer automatiquement des mesures correctives.

Objectifs

Après avoir lu ce modèle, vous devriez être capable de :

Conditions préalables et limitations

Prérequis

Limites

Architecture

Vous appliquez la syntaxe Guard à une AWS Config règle en tant que politique personnalisée. AWS Config capture le JSON hiérarchique de chacune des ressources spécifiées. Le JSON de l'élément de AWS Config configuration contient des paires clé-valeur. Ces attributs sont utilisés dans la syntaxe Guard en tant que variables assignées à leur valeur correspondante. 

Vous trouverez ci-dessous une explication de la syntaxe Guard. Les variables de l'élément de configuration JSON sont utilisées et précédées d'un % caractère.

# declare variable
let <variable name> = <'value'>

# create rule and assign condition and policy
    rule <rule name> when 
        <CI json key> == <"CI json value"> {
            <top level CI json key>.<next level CI json key> == %<variable name>
        }

Scénario 1 : volumes Amazon EBS

Le scénario 1 déploie une règle AWS Config personnalisée qui utilise la syntaxe Guard pour valider la conformité des volumes chiffrés. Cette règle vérifie que le lecteur est en cours d'utilisation et que le type de lecteur est gp3.

Voici un exemple d'élément de AWS Config configuration pour le scénario 1. Cet élément de configuration comporte trois paires clé-valeur qui sont utilisées comme variables dans la politique Guard : volumestatusvolumeencryptionstatus, et. volumetype De plus, la resourceType clé est utilisée comme filtre dans la politique Guard.

{
  "version": "1.3",
  "accountId": "111111111111",
  "configurationItemCaptureTime": "2023-01-15T19:04:45.402Z",
  "configurationItemStatus": "ResourceDiscovered",
  "configurationStateId": "4444444444444",
  "configurationItemMD5Hash": "",
  "arn": "arn:aws:ec2:us-west-2:111111111111:volume/vol-222222222222",
  "resourceType": "AWS::EC2::Volume",
  "resourceId": "vol-222222222222",
  "awsRegion": "us-west-2",
  "availabilityZone": "us-west-2b",
  "resourceCreationTime": "2023-01-15T19:03:22.247Z",
  "tags": {},
  "relatedEvents": [],
  "relationships": [
    {
      "resourceType": "AWS::EC2::Instance",
      "resourceId": "i-33333333333333333",
      "relationshipName": "Is attached to Instance"
    }
  ],
  "configuration": {
    "attachments": [
      {
        "attachTime": "2023-01-15T19:03:22.000Z",
        "device": "/dev/xvda",
        "instanceId": "i-33333333333333333",
        "state": "attached",
        "volumeId": "vol-222222222222",
        "deleteOnTermination": true,
        "associatedResource": null,
        "instanceOwningService": null
      }
    ],
    "availabilityZone": "us-west-2b",
    "createTime": "2023-01-15T19:03:22.247Z",
    "encrypted": false,
    "kmsKeyId": null,
    "outpostArn": null,
    "size": 8,
    "snapshotId": "snap-55555555555555555",
    "state": "in-use",
    "volumeId": "vol-222222222222",
    "iops": 100,
    "tags": [],
    "volumeType": "gp2",
    "fastRestored": null,
    "multiAttachEnabled": false,
    "throughput": null,
    "sseType": null
  },
  "supplementaryConfiguration": {}
}

Voici un exemple d'utilisation de la syntaxe Guard pour définir les variables et les règles du scénario 1. Dans l'exemple suivant :

let volumestatus = 'available'
let volumetype = 'gp3'
let volumeencryptionstatus = true

    rule compliancecheck when 
        resourceType == "AWS::EC2::Volume" {
            configuration.state == %volumestatus
            configuration.encrypted == %volumeencryptionstatus
            configuration.volumeType == %volumetype
        }

Pour connaître la politique personnalisée complète de Guard qui implémente cette règle personnalisée, consultez awsconfig-guard-cft.yaml ou awsconfig-guard-tf-ec2vol.json dans le référentiel de code. GitHub Pour le code HashiCorp Terraform qui déploie cette politique personnalisée dans Guard, voir awsconfig-guard-tf-example.json dans le référentiel de code.

Scénario 2 : GuardDuty conformité

Le scénario 2 déploie une règle AWS Config personnalisée qui utilise la syntaxe Guard pour valider la GuardDuty conformité d'Amazon. Cette règle vérifie que Amazon S3 Protection et Amazon EKS Protection sont activées sur les GuardDuty enregistreurs. Il vérifie également que les GuardDuty résultats sont publiés toutes les 15 minutes. Ce scénario pourrait être déployé dans l'ensemble Comptes AWS et Régions AWS au sein d'une organisation (in AWS Organizations).

Voici un exemple d'élément de AWS Config configuration pour le scénario 2. Cet élément de configuration comporte trois paires clé-valeur qui sont utilisées comme variables dans la politique Guard : FindingPublishingFrequencyS3Logs, et. Kubernetes La resourceType clé est également utilisée comme filtre dans la politique.

{
  "version": "1.3",
  "accountId": "111111111111",
  "configurationItemCaptureTime": "2023-11-27T13:34:28.888Z",
  "configurationItemStatus": "OK",
  "configurationStateId": "7777777777777",
  "configurationItemMD5Hash": "",
  "arn": "arn:aws:guardduty:us-west-2:111111111111:detector/66666666666666666666666666666666",
  "resourceType": "AWS::GuardDuty::Detector",
  "resourceId": "66666666666666666666666666666666",
  "resourceName": "66666666666666666666666666666666",
  "awsRegion": "us-west-2",
  "availabilityZone": "Regional",
  "resourceCreationTime": "2020-02-17T02:48:04.511Z",
  "tags": {},
  "relatedEvents": [],
  "relationships": [],
  "configuration": {
    "Enable": true,
    "FindingPublishingFrequency": "FIFTEEN_MINUTES",
    "DataSources": {
      "S3Logs": {
        "Enable": true
      },
      "Kubernetes": {
        "AuditLogs": {
          "Enable": true
        }
      }
    },
    
    "Id": "66666666666666666666666666666666",
    "Tags": []
  },
  "supplementaryConfiguration": {
    "CreatedAt": "2020-02-17T02:48:04.511Z"
  }
}

Voici un exemple d'utilisation de la syntaxe Guard pour définir les variables et les règles du scénario 2. Dans l'exemple suivant :

let s3protection = true
let kubernetesprotection = true
let publishfrequency = 'FIFTEEN_MINUTES'

    rule compliancecheck when 
        resourceType == "AWS::GuardDuty::Detector" {
            configuration.DataSources.S3Logs.Enable == %s3protection
            configuration.DataSources.Kubernetes.AuditLogs.Enable == %kubernetesprotection
            configuration.FindingPublishingFrequency == %publishfrequency
        }

Pour la politique personnalisée complète de Guard qui implémente cette règle personnalisée, voir awsconfig-guard-cft-gd.yaml dans le référentiel de GitHub code. Pour le code HashiCorp Terraform qui déploie cette politique personnalisée dans Guard, voir awsconfig-guard-tf-gd.json dans le référentiel de code.

Outils

Services AWS

Autres outils

Référentiel de code

Le code de ce modèle est disponible dans le AWS CloudFormation Guard référentiel GitHub AWS Config with. Ce référentiel de code contient des exemples pour les deux scénarios décrits dans ce modèle.

Épopées

Résolution des problèmes

Ressources connexes

AWS documentation

AWS articles de blog et ateliers

Autres ressources