

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Ejemplos y sintaxis de políticas de Security Hub
<a name="orgs_manage_policies_security_hub_syntax"></a>

Las políticas de Security Hub siguen una sintaxis JSON estandarizada que define la habilitación y configuración de Security Hub en la organización. La comprensión de la estructura de las políticas permite crear políticas eficaces para sus requisitos de seguridad.

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

Antes de crear políticas de Security Hub, comprenda estos puntos esenciales sobre la sintaxis de las políticas:
+ Las listas `enable_in_regions` y `disable_in_regions` son obligatorias en la política, aunque puedan estar vacías
+ A la hora de procesar políticas en vigor, `disable_in_regions` prevalece sobre `enable_in_regions`
+ Las políticas secundarias pueden modificar las principales mediante operadores de herencia, a menos que estén explícitamente restringidas
+ La designación `ALL_SUPPORTED` incluye las regiones actuales y futuras
+ Los nombres de las regiones deben ser válidos y estar disponibles en Security Hub

## Estructura básica de las políticas
<a name="security-hub-basic-structure"></a>

Una política de Security Hub utiliza la siguiente estructura básica:

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

## Componentes de política
<a name="security-hub-policy-components"></a>

Las políticas de Security Hub contienen los siguientes componentes escenciales:

`securityhub`  
Contenedor de nivel superior para configurar políticas  
Obligatorio para todas las políticas de Security Hub

`enable_in_regions`  
Lista de regiones en las que se debe habilitar Security Hub  
Puede contener nombres de regiones específicos o `ALL_SUPPORTED`  
Campo obligatorio, pero puede quedar vacío  
Al utilizar `ALL_SUPPORTED`, significa que incluye regiones futuras

`disable_in_regions`  
Lista de regiones en las que se debe deshabilitar Security Hub  
Puede contener nombres de regiones específicos o `ALL_SUPPORTED`  
Campo obligatorio, pero puede quedar vacío  
Tiene prioridad sobre `enable_in_regions` cuando las regiones aparecen en ambas listas

Operadores de herencia  
@@assign: Sobrescribe los valores heredados  
@@append: Agrega valores nuevos a los existentes  
@@remove: Elimina valores específicos de la configuración heredada

## Ejemplos de políticas de Security Hub
<a name="security-hub-policy-examples"></a>

En los siguientes ejemplos se muestran las configuraciones de las políticas frecuentes de Security Hub. 

El siguiente ejemplo habilita Security Hub en todas las regiones actuales y futuras. Con el uso de `ALL_SUPPORTED` en la lista `enable_in_regions` y al dejar `disable_in_regions` vacío, esta política garantizará una cobertura de seguridad integral a medida que haya nuevas regiones disponibles.

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

En este ejemplo, se deshabilita Security Hub en todas las regiones, entre ellas, las futuras, ya que la lista `disable_in_regions` tiene prioridad sobre `enable_in_regions`.

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

El siguiente ejemplo demuestra cómo las políticas secundarias pueden modificar la configuración de la política principal mediante operadores de herencia. Este enfoque permite un control detallado, mientras se mantiene la estructura general de la política. La política secundaria agrega una nueva región a `enable_in_regions` y elimina una región de `disable_in_regions`.

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

En este ejemplo se muestra cómo habilitar Security Hub en varias regiones específicas sin dejar de utilizar `ALL_SUPPORTED`. Esto ofrece un control preciso sobre las regiones que tienen habilitado Security Hub, mientras que deja las regiones no especificadas sin administrar por la política.

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

El siguiente ejemplo muestra cómo gestionar los requisitos de conformidad regionales mediante la habilitación de Security Hub en la mayoría de las regiones, mientras se deshabilita explícitamente en ubicaciones específicas. La lista `disable_in_regions` tiene prioridad, lo que garantiza que Security Hub permanezca deshabilitado en esas regiones, independiente de otras configuraciones de políticas.

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