Blog

Verwenden Sie benutzerdefinierte Regeln, um Ihre Compliance zu überprüfen

Joris Conijn

Joris Conijn

Aktualisiert Oktober 15, 2025
4 Minuten

AWS verfügt über eine Menge integrierter Kontrollen, aber was, wenn Sie mehr brauchen? Mit AWS Config können Sie Ihre eigenen Regeln erstellen. Diese Regeln können dann Ihre Ressourcen überprüfen und feststellen, ob sie konform sind. Dies ist nützlich, wenn Sie bestimmte Konfigurationseinstellungen durchsetzen möchten. So erhalten Sie einen Überblick darüber, wie konform Ihre Arbeitslasten sind.

Lassen Sie uns ein konkretes Beispiel verwenden, aber Sie können dieses Konzept auch auf andere Szenarien anwenden.

Konfiguration der S3-Zugriffsprotokolle prüfen

Wenn ein Techniker einen Amazon S3-Bucket erstellt, muss er die Zugriffsprotokollierung für diesen Bucket aktivieren. AWS hat dafür eine integrierte Konfigurationsregel namens . Wenn Sie den Standard AWS Foundational Security Best Practices v1.0.0 im Security Hub aktivieren, wird er verfügbar.

Wenn wir ein neues Konto erstellen, ist die Einrichtung eines Buckets Teil des Bootstrappings. Die Techniker, die das Konto verwenden, haben nur Leserechte für diesen Bucket. Wenn ein Techniker einen Bucket erstellt, erwarten wir, dass er diesen Bucket für die Zugriffsprotokolle verwendet.

Regeln erstellen: Lambda vs. CloudFormation Guard

Sie können benutzerdefinierte Konfigurationsregeln auf 2 Arten erstellen: mit AWS Lambda und CloudFormation Guard. Lambda bietet Ihnen viel Flexibilität, ist aber auch mit einem hohen Wartungsaufwand verbunden. CloudFormation Guard ist in dieser Hinsicht ein wenig leichter. Ja, Sie müssen immer noch die Logik pflegen, um zu bestimmen, wann Ihre Ressource konform ist oder nicht. Aber das müssen Sie in beiden Fällen tun, daher bevorzuge ich CloudFormation Guard.

Konfig-Regel

Wenn Sie mit der Definition Ihrer benutzerdefinierten Konfigurationsregel beginnen, müssen Sie sich Gedanken über die möglichen Szenarien machen:

  • Wenn es sich bei der Ressource nicht um einen S3-Bucket handelt, sollten wir die Regel auslassen.
  • Wenn die Ressource der eigentliche Logging Bucket ist, sollten wir die Regel überspringen.
  • Wenn für die Ressource keine Protokollierung konfiguriert ist, sollte die Regel fehlschlagen.
  • Wenn für die Ressource die Protokollierung in einem anderen Bucket als dem gewünschten konfiguriert ist. Wir sollten die Regel nicht anwenden.
  • Wenn die Ressource die Protokollierung mit dem erwarteten Bucket konfiguriert hat, sollten wir die Regel übergeben.

Mit AWS Config können Sie InputParameter definieren. Wir verwenden diesen Parameter, um den Namen des Buckets zu übergeben, in dem die Zugriffsprotokolle gespeichert werden. Wir haben den Parameter loggingBucket genannt. Sie können den Wert dieses Parameters referenzieren mit: CONFIG_RULE_PARAMETERS.loggingBucket.

Deployment

Ich verwende CloudFormation für die Bereitstellung der Regel, hier ein Ausschnitt aus der Vorlage:

Resources:
  S3AccessLogging:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: lz-s3-access-logging
      Description: Validate that access logging has been enabled and that the correct logging bucket is used.
      EvaluationModes:
        - Mode: DETECTIVE
      InputParameters:
        Fn::Sub: '{"loggingBucket": "s3-access-logs-${AWS::AccountId}-${AWS::Region}"}'
      Scope:
        ComplianceResourceTypes: ["AWS::S3::Bucket"]
      Source:
        Owner: CUSTOM_POLICY
        SourceDetails:
          - EventSource: aws.config
            MessageType: ConfigurationItemChangeNotification
          - EventSource: aws.config
            MessageType: OversizedConfigurationItemChangeNotification
        CustomPolicyDetails:
          EnableDebugLogDelivery: 'true'
          PolicyRuntime: guard-2.x.x
          PolicyText: |-
            rule s3_logging_configuration when resourceType == "AWS::S3::Bucket" resourceName != CONFIG_RULE_PARAMETERS.loggingBucket {
                supplementaryConfiguration.BucketLoggingConfiguration exists
                <<
                Violation: S3 Bucket needs to have access logging configured
                Fix: Configure the destinationBucketName on your S3 bucket
                >>
            }

            rule s3_logging_correct_bucket when s3_logging_configuration {
                supplementaryConfiguration.BucketLoggingConfiguration {
                    destinationBucketName == CONFIG_RULE_PARAMETERS.loggingBucket
                    <<
                    Violation: S3 Bucket needs to have access logging configured
                    Fix: Configure the destinationBucketName on your S3 bucket
                    >>
                }
            }

Lassen Sie uns diese Richtlinie durchgehen und erklären, was passiert. Die erste Regel gilt nur, wenn es sich bei der Ressource um einen S3-Bucket handelt und der Name nicht mit dem Namen des Logging-Buckets übereinstimmt. Der Name des loggingBucket ist über die InputParameter konfigurierbar. Als Nächstes prüfen wir, ob der Bucket den konfigurierten Logging Bucket für die Zugriffsprotokolle verwendet hat. Wenn die Protokollierungskonfiguration existiert, muss destinationBucketName mit dem angegebenen Namen übereinstimmen.

Sie können die oben erwähnten Szenarien mit Unit-Tests testen. Lesen Sie: So können Sie Ihre cfn-guard Regeln testen, um mehr darüber zu erfahren, wie Sie das tun können.

Nachdem Sie diese Regel in Ihren Konten implementiert haben. Config überprüft alle Ihre S3-Buckets, ob sie mit dieser benutzerdefinierten Konfigurationsregel konform sind.

Beschränkungen

Derzeit unterstützt AWS Config nur CloudFormation Guard 2.x.x. Ich warte auf die Unterstützung für 3.x. Denn das bringt noch leistungsfähigere Funktionen wie die json_parse Methode. Damit können Sie auch JSON-Strukturen wie zum Beispiel die Bucket-Policy überprüfen.

Fazit

Sie können mit CloudFormation Guard benutzerdefinierte Konfigurationsregeln erstellen. Mit CloudFormation Guard müssen Sie keine Abhängigkeiten von Ihren Funktionen pflegen. Und Sie müssen Ihre Lambda-Laufzeit nicht aktualisieren, wenn sie veraltet ist.

Möchten Sie wissen, wie Sie Ihre Regeln verbreiten können? Lesen Sie meinen nächsten Blog, um mehr zu erfahren.

Foto von Pixabay

Verfasst von

Joris Conijn

Joris is the AWS Practise CTO of the Xebia Cloud service line and has been working with the AWS cloud since 2009 and focussing on building event-driven architectures. While working with the cloud from (almost) the start, he has seen most of the services being launched. Joris strongly believes in automation and infrastructure as code and is open to learning new things and experimenting with them because that is the way to learn and grow.

Contact

Let’s discuss how we can support your journey.