Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Syntax und Beispiele für Security Hub Hub-Richtlinien
<a name="orgs_manage_policies_security_hub_syntax"></a>

Security Hub-Richtlinien folgen einer standardisierten JSON-Syntax, die definiert, wie Security Hub in Ihrem Unternehmen aktiviert und konfiguriert wird. Wenn Sie die Richtlinienstruktur verstehen, können Sie effektive Richtlinien für Ihre Sicherheitsanforderungen erstellen.

## Überlegungen
<a name="security-hub-policy-considerations"></a>

Bevor Sie Security Hub Hub-Richtlinien erstellen, sollten Sie sich mit den folgenden wichtigen Punkten zur Richtliniensyntax vertraut machen:
+ `enable_in_regions`Sowohl als auch `disable_in_regions` Listen sind in der Richtlinie erforderlich, obwohl sie leer sein können
+ Hat bei der Verarbeitung wirksamer Richtlinien `disable_in_regions` Vorrang vor `enable_in_regions`
+ Richtlinien für Kinder können die Richtlinien der Eltern mithilfe von Vererbungsoperatoren ändern, sofern diese nicht ausdrücklich eingeschränkt werden
+ Die `ALL_SUPPORTED` Bezeichnung umfasst sowohl aktuelle als auch future Regionen
+ Regionsnamen müssen gültig und in Security Hub verfügbar sein

## Grundlegende Richtlinienstruktur
<a name="security-hub-basic-structure"></a>

Eine Security Hub Hub-Richtlinie verwendet diese grundlegende Struktur:

```
{
  "securityhub": {
    "enable_in_regions": {
      "@@append": ["ALL_SUPPORTED"],
      "@@operators_allowed_for_child_policies": ["@@all"]
    },
    "disable_in_regions": {
      "@@append": [],
      "@@operators_allowed_for_child_policies": ["@@all"]
    }
  }
}
```

## Richtlinienkomponenten
<a name="security-hub-policy-components"></a>

Die Security Hub Hub-Richtlinien enthalten die folgenden Schlüsselkomponenten:

`securityhub`  
Der Container auf oberster Ebene für Richtlinieneinstellungen  
Für alle Security Hub Hub-Richtlinien erforderlich

`enable_in_regions`  
Liste der Regionen, in denen Security Hub aktiviert werden sollte  
Kann spezifische Regionsnamen enthalten oder `ALL_SUPPORTED`  
Pflichtfeld, kann aber leer sein  
Schließt bei `ALL_SUPPORTED` der Verwendung future Regionen ein

`disable_in_regions`  
Liste der Regionen, in denen Security Hub deaktiviert werden sollte  
Kann spezifische Regionsnamen enthalten oder `ALL_SUPPORTED`  
Pflichtfeld, kann aber leer sein  
Hat Vorrang vor der Angabe `enable_in_regions` von Regionen in beiden Listen

Vererbungsoperatoren  
@ @assign — Überschreibt geerbte Werte  
@ @append - Fügt neue Werte zu bestehenden hinzu  
@ @remove — Entfernt bestimmte Werte aus übernommenen Einstellungen

## Beispiele Security Hub Hub-Richtlinien
<a name="security-hub-policy-examples"></a>

Die folgenden Beispiele zeigen gängige Security Hub Hub-Richtlinienkonfigurationen. 

Das folgende Beispiel aktiviert Security Hub in allen aktuellen und future Regionen. Wenn diese Richtlinie `ALL_SUPPORTED` in der `enable_in_regions` Liste verwendet und `disable_in_regions` leer gelassen wird, gewährleistet sie einen umfassenden Sicherheitsschutz, sobald neue Regionen verfügbar werden.

```
{
   "securityhub":{
      "enable_in_regions":{
         "@@assign":[
            "ALL_SUPPORTED"
         ]
      },
      "disable_in_regions":{
         "@@assign":[
            
         ]
      }
   }
}
```

In diesem Beispiel wird Security Hub in allen Regionen deaktiviert, auch in future Regionen, da die `disable_in_regions` Liste Vorrang vor hat. `enable_in_regions`

```
{
   "securityhub":{
      "enable_in_regions":{
         "@@assign":[
            "us-east-1",
            "us-west-2"
         ]
      },
      "disable_in_regions":{
         "@@assign":[
            "ALL_SUPPORTED"
         ]
      }
   }
}
```

Das folgende Beispiel zeigt, wie untergeordnete Richtlinien die Einstellungen der übergeordneten Richtlinie mithilfe von Vererbungsoperatoren ändern können. Dieser Ansatz ermöglicht eine detaillierte Steuerung unter Beibehaltung der allgemeinen Richtlinienstruktur. Die Kinderrichtlinie fügt der Region eine neue Region hinzu `enable_in_regions` und entfernt eine Region aus `disable_in_regions` ihr.

```
{
   "securityhub":{
      "enable_in_regions":{
         "@@append":[
            "eu-central-1"
         ]
      },
      "disable_in_regions":{
         "@@remove":[
            "us-west-2"
         ]
      }
   }
}
```

Dieses Beispiel zeigt, wie Security Hub in mehreren spezifischen Regionen aktiviert wird, ohne es zu verwenden`ALL_SUPPORTED`. Dies ermöglicht eine genaue Kontrolle darüber, in welchen Regionen Security Hub aktiviert ist, während nicht spezifizierte Regionen nicht von der Richtlinie verwaltet werden.

```
{
   "securityhub":{
      "enable_in_regions":{
         "@@assign":[
            "us-east-1",
            "us-west-2",
            "eu-west-1",
            "ap-southeast-1"
         ]
      },
      "disable_in_regions":{
         "@@assign":[
            
         ]
      }
   }
}
```

Das folgende Beispiel zeigt, wie Sie mit regionalen Compliance-Anforderungen umgehen können, indem Security Hub in den meisten Regionen aktiviert und an bestimmten Standorten explizit deaktiviert wird. Die `disable_in_regions` Liste hat Vorrang und stellt sicher, dass Security Hub in diesen Regionen unabhängig von anderen Richtlinieneinstellungen deaktiviert bleibt.

```
{
   "securityhub":{
      "enable_in_regions":{
         "@@assign":[
            "ALL_SUPPORTED"
         ]
      },
      "disable_in_regions":{
         "@@assign":[
            "ap-east-1",
            "me-south-1"
         ]
      }
   }
}
```