Esta página se ha traducido con Cloud Translation API.

Corregir resultados de Security Health Analytics

En esta página se ofrece una lista de guías de referencia y técnicas para corregir los resultados de Security Health Analytics con Security Command Center.

Necesitas los roles de Gestión de Identidades y Accesos (IAM) adecuados para ver o editar las detecciones, así como para acceder a los recursos o modificarlos. Google Cloud Si se producen errores de permisos al acceder a Security Command Center en laGoogle Cloud consola, pide ayuda a tu administrador. Para obtener información sobre los roles, consulta Control de acceso. Para resolver los errores de recursos, consulte la documentación de los productos afectados.

Corrección de Security Health Analytics

En esta sección se incluyen instrucciones de corrección para todos los resultados de Security Health Analytics.

Para encontrar los tipos que se han asignado a las recomendaciones de CIS, la guía de corrección procede del Center for Internet Security (CIS), a menos que se indique lo contrario. Para obtener más información, consulta Detectores y cumplimiento.

Desactivación automática de las detecciones

Después de corregir una vulnerabilidad o un error de configuración, Security Health Analytics cambia automáticamente el estado del resultado a INACTIVE la próxima vez que lo busque. Si inhabilita un detector en Security Health Analytics, también se cambiará el estado de los resultados que haya generado a INACTIVE. El tiempo que tarda Security Health Analytics en cambiar el estado de un hallazgo corregido a INACTIVE depende de cuándo se corrija el hallazgo y de la programación del análisis que lo detecte.

Security Health Analytics también define el estado de un hallazgo como INACTIVE cuando una exploración detecta que se ha eliminado el recurso afectado por el hallazgo. Si quieres quitar de la pantalla una detección de un recurso eliminado mientras esperas a que Security Health Analytics detecte que el recurso se ha eliminado, puedes silenciar la detección. Para silenciar un resultado, consulta Silenciar resultados en Security Command Center.

No uses la opción de silenciar para ocultar las detecciones corregidas de los recursos. Si el problema se repite y Security Health Analytics restaura el estado ACTIVE del resultado, es posible que no veas el resultado reactivado, ya que los resultados silenciados se excluyen de cualquier consulta de resultados que especifique NOT mute="MUTED", como la consulta de resultados predeterminada.

Para obtener información sobre los intervalos de análisis, consulta Tipos de análisis de Security Health Analytics.

`Access Transparency disabled`

Nombre de la categoría en la API: ACCESS_TRANSPARENCY_DISABLED

Transparencia de acceso registra cuándo acceden los Google Cloud empleados a los proyectos de tu organización para ofrecer asistencia. Habilita Transparencia de acceso para registrar quién de Google Cloud accede a tu información, cuándo y por qué. Para obtener más información, consulta el artículo sobre Transparencia de acceso.

Para habilitar Transparencia de acceso en un proyecto, este debe estar asociado a una cuenta de facturación.

Roles obligatorios

Para obtener los permisos que necesitas para realizar esta tarea, pide a tu administrador que te conceda el rol de gestión de identidades y accesos Administrador de transparencia de acceso (roles/axt.admin) a nivel de organización. Para obtener más información sobre cómo conceder roles, consulta el artículo sobre cómo gestionar el acceso.

Este rol predefinido contiene los permisos axt.labels.get y axt.labels.set, que son necesarios para realizar esta tarea. También puedes obtener estos permisos con un rol personalizado u otros roles predefinidos.

Pasos de resolución

Para solucionar este problema, siga estos pasos:

Comprueba los permisos a nivel de organización:
1. Ve a la página Gestión de Identidades y Accesos de la consola deGoogle Cloud .
  
  Ir a Gestión de Identidades y Accesos
2. Si se te solicita, selecciona la Google Cloud organización en el menú de selección.
Elige cualquier Google Cloud proyecto de la organización con el menú de selección.

Transparencia de acceso se configura en la página de un Google Cloud proyecto pero se habilita para toda la organización.
Ve a la página IAM y administración > Configuración.
Haz clic en Habilitar Transparencia de acceso.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`AlloyDB auto backup disabled`

Nombre de la categoría en la API: ALLOYDB_AUTO_BACKUP_DISABLED

Un clúster de AlloyDB para PostgreSQL no tiene habilitadas las copias de seguridad automáticas.

Para evitar que se pierdan datos, activa la copia de seguridad automática de tu clúster. Para obtener más información, consulta Configurar copias de seguridad automáticas adicionales.

Para solucionar este problema, siga estos pasos:

Ve a la página de clústeres de AlloyDB para PostgreSQL en laGoogle Cloud consola.

Ir a clústeres de AlloyDB para PostgreSQL
Haga clic en un clúster de la columna Nombre del recurso.
Haga clic en Protección de datos.
En la sección Política de copia de seguridad automática, haz clic en Editar en la fila Copias de seguridad automáticas.
Marca la casilla Automatizar copias de seguridad.
Haz clic en Actualizar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`AlloyDB backups disabled`

Nombre de la categoría en la API: ALLOYDB_BACKUPS_DISABLED

Un clúster de AlloyDB para PostgreSQL no tiene habilitadas las copias de seguridad automáticas ni las continuas.

Para evitar que se pierdan datos, activa la copia de seguridad automática o continua de tu clúster. Para obtener más información, consulta Configurar copias de seguridad adicionales.

Para solucionar este problema, siga estos pasos:

Ve a la página de clústeres de AlloyDB para PostgreSQL en laGoogle Cloud consola.

Ir a clústeres de AlloyDB para PostgreSQL
En la columna Nombre del recurso, haga clic en el nombre del clúster que se identifica en la detección.
Haga clic en Protección de datos.
Configura una política de copias de seguridad.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`AlloyDB CMEK disabled`

Nombre de la categoría en la API: ALLOYDB_CMEK_DISABLED

Un clúster de AlloyDB no usa claves de cifrado gestionadas por el cliente (CMEK).

Con las CMEK, las claves que creas y gestionas en Cloud KMS cifran las claves que usa Google para cifrar tus datos, lo que te da más control sobre el acceso a tus datos. Para obtener más información, consulta el artículo Acerca de las CMEK. CMEK implica costes adicionales relacionados con Cloud KMS.

Para solucionar este problema, siga estos pasos:

Ve a la página de clústeres de AlloyDB para PostgreSQL en laGoogle Cloud consola.

Ir a clústeres de AlloyDB para PostgreSQL
En la columna Nombre del recurso, haga clic en el nombre del clúster que se identifica en la detección.
Haz clic en Crear copia de seguridad. Define un ID alternativo.
Haz clic en Crear.
En la sección Copia de seguridad/Restaurar, haz clic en Restaurar junto a la entrada ID de copia de seguridad que hayas elegido.
Define un nuevo ID de clúster y una nueva red.
Haz clic en Opciones de cifrado avanzadas. Selecciona la CMEK que quieras usar para cifrar el nuevo clúster.
Haz clic en Restaurar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`AlloyDB log min error statement severity`

Nombre de la categoría en la API: ALLOYDB_LOG_MIN_ERROR_STATEMENT_SEVERITY

Una instancia de AlloyDB para PostgreSQL no tiene la marca de base de datos log_min_error_statement con el valor error ni otro valor recomendado.

La marca log_min_error_statement controla si las declaraciones SQL que provocan errores se anotan en los registros del servidor. Se registran las declaraciones SQL que tengan la gravedad especificada o una superior. A mayor gravedad, menos mensajes se registran. Si se le asigna una gravedad demasiado alta, puede que no se registren algunos mensajes de error.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página de clústeres de AlloyDB para PostgreSQL en laGoogle Cloud consola.

Ir a clústeres de AlloyDB para PostgreSQL
Haga clic en el clúster de la columna Nombre del recurso.
En la sección Instancias de tu clúster, haz clic en Editar en la instancia.
Haz clic en Opciones de configuración avanzada.
En la sección Marcas, asigna a la marca de base de datos log_min_error_statement uno de los siguientes valores recomendados, conforme a la política de registro de tu empresa.
- debug5
- debug4
- debug3
- debug2
- debug1
- info
- notice
- warning
- error
Haz clic en Actualizar instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`AlloyDB log min messages`

Nombre de la categoría en la API: ALLOYDB_LOG_MIN_MESSAGES

Una instancia de AlloyDB para PostgreSQL no tiene la marca de base de datos log_min_messages establecida en warning como mínimo.

La marca log_min_messages controla qué niveles de mensajes se anotan en los registros del servidor. A mayor gravedad, menos mensajes se registran. Si el umbral es demasiado bajo, los registros pueden aumentar en tamaño y en longitud, lo que dificulta la localización de errores reales.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página de clústeres de AlloyDB para PostgreSQL en laGoogle Cloud consola.

Ir a clústeres de AlloyDB para PostgreSQL
Haga clic en el clúster de la columna Nombre del recurso.
En la sección Instancias de tu clúster, haz clic en Editar en la instancia.
Haz clic en Opciones de configuración avanzada.
En la sección Marcas, asigna a la marca de base de datos log_min_messages uno de los siguientes valores recomendados, conforme a la política de registro de tu empresa.
- debug5
- debug4
- debug3
- debug2
- debug1
- info
- notice
- warning
Haz clic en Actualizar instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`AlloyDB log error verbosity`

Nombre de la categoría en la API: ALLOYDB_LOG_ERROR_VERBOSITY

Una instancia de AlloyDB para PostgreSQL no tiene la marca de base de datos log_error_verbosity establecida en default u otro valor menos restrictivo.

La marca log_error_verbosity controla la cantidad de detalles que incluyen los mensajes registrados. A mayor verbosidad, más detalles se registran en los mensajes. Te recomendamos que asignes a esta marca el valor default u otro valor menos restrictivo.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página de clústeres de AlloyDB para PostgreSQL en laGoogle Cloud consola.

Ir a clústeres de AlloyDB para PostgreSQL
Haga clic en el clúster de la columna Nombre del recurso.
En la sección Instancias de tu clúster, haz clic en Editar en la instancia.
Haz clic en Opciones de configuración avanzada.
En la sección Marcas, asigna a la marca de base de datos log_error_verbosity uno de los siguientes valores recomendados, conforme a la política de registro de tu empresa.
- default
- verbose
Haz clic en Actualizar instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`AlloyDB Public IP`

Nombre de la categoría en la API: ALLOYDB_PUBLIC_IP

Una instancia de base de datos de AlloyDB para PostgreSQL tiene una dirección IP pública.

Para reducir la superficie de ataque de tu organización, usa direcciones IP privadas en lugar de públicas. Las direcciones IP privadas refuerzan la seguridad de redes y reducen la latencia de tu aplicación.

Para solucionar este problema, siga estos pasos:

Ve a la página de clústeres de AlloyDB para PostgreSQL en laGoogle Cloud consola.

Ir a clústeres de AlloyDB para PostgreSQL
En la columna Nombre del recurso, haga clic en el nombre del clúster que se identifica en la detección.
En la sección Instancias de tu clúster, haz clic en Editar en la instancia.
En la sección Conectividad, desmarca la casilla Habilitar IP pública.
Haz clic en Actualizar instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`AlloyDB SSL not enforced`

Nombre de la categoría en la API: ALLOYDB_SSL_NOT_ENFORCED

Una instancia de base de datos de AlloyDB para PostgreSQL no requiere que todas las conexiones entrantes usen SSL.

Para que no se filtren datos sensibles en tránsito a través de comunicaciones sin encriptar, todas las conexiones entrantes a tu instancia de base de datos de AlloyDB deben usar SSL. Consulta más información sobre cómo configurar SSL/TLS.

Para solucionar este problema, siga estos pasos:

Ve a la página de clústeres de AlloyDB para PostgreSQL en laGoogle Cloud consola.

Ir a clústeres de AlloyDB para PostgreSQL
En la columna Nombre del recurso, haga clic en el nombre del clúster que se identifica en la detección.
En la sección Instancias de tu clúster, haz clic en Editar en la instancia.
En la sección Seguridad de red, marca la casilla Requerir cifrado SSL.
Haz clic en Actualizar instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Admin service account`

Nombre de la categoría en la API: ADMIN_SERVICE_ACCOUNT

Una cuenta de servicio de tu organización o proyecto tiene asignados los privilegios de administrador, propietario o editor. Estos roles tienen permisos amplios y no deben asignarse a cuentas de servicio. Para obtener información sobre las cuentas de servicio y los roles disponibles, consulta el artículo Cuentas de servicio.

Para solucionar este problema, siga estos pasos:

Ve a la página de la política de gestión de identidades y accesos en la Google Cloud consola.

Ir a la política de gestión de identidades y accesos
En cada principal identificado en la detección:
1. Junto al principal, haz clic en Editar principal.
2. Para quitar permisos, haz clic en Eliminar rol junto al rol.
3. Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Alpha cluster enabled`

Nombre de la categoría en la API: ALPHA_CLUSTER_ENABLED

Las funciones de clúster alfa están habilitadas en un clúster de Google Kubernetes Engine (GKE).

Los clústeres alfa permiten a los primeros usuarios experimentar con cargas de trabajo que emplean funciones nuevas antes de que se pongan a disposición del público en general. Los clústeres alfa tienen habilitadas todas las funciones de la API de GKE, pero no están cubiertos por el acuerdo de nivel de servicio de GKE, no reciben actualizaciones de seguridad, tienen inhabilitadas las funciones automáticas de actualización y reparación de nodos, y no se pueden actualizar a una versión mejor. Además, se eliminan automáticamente al cabo de 30 días.

Para solucionar este problema, siga estos pasos:

Los clústeres alfa no se pueden inhabilitar. Debes crear un clúster con las funciones alfa inhabilitadas.

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
Haz clic en Crear.
Selecciona Configurar junto al tipo de clúster que quieras crear.
En la pestaña Funciones, comprueba que no esté marcada la opción Habilitar las funciones alfa de Kubernetes en este clúster.
Nota: Si has seleccionado GKE Autopilot, no verás esta opción porque los clústeres alfa no son compatibles.
Haz clic en Crear.
Para mover cargas de trabajo al nuevo clúster, consulta Migrar cargas de trabajo a diferentes tipos de máquinas.
Para eliminar el clúster original, consulta Eliminar un clúster.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`API key APIs unrestricted`

Nombre de la categoría en la API: API_KEY_APIS_UNRESTRICTED

Se están usando claves de API de forma demasiado generalizada.

Las claves de API sin restricciones no son seguras porque se pueden obtener de los dispositivos en los que se almacenan o se pueden ver públicamente (por ejemplo, en un navegador). De acuerdo con el principio de mínimos accesos, configura las claves de API para que solo llamen a las APIs que necesite la aplicación. Para obtener más información, consulta Aplicar restricciones a claves de API.

Para solucionar este problema, siga estos pasos:

Ve a la página Claves de API de la Google Cloud consola.

Ir a Claves de API
En cada clave de API:
1. En la sección Claves de API, en la fila de cada clave de API para la que quieras restringir APIs, haz clic en Acciones.
2. En el menú Acciones, haz clic en Editar clave de API. Se abrirá la página Editar clave de API.
3. En la sección Restricciones de API, selecciona Restringir APIs. Aparecerá el menú desplegable Seleccionar APIs.
4. En la lista desplegable Seleccionar APIs, elige las que quieres permitir.
  Advertencia: No definas la restricción APIs de Google Cloud, ya que esta opción permite el acceso a todos los servicios que ofreceGoogle Cloud.
5. Haz clic en Guardar. Los ajustes pueden tardar hasta cinco minutos en aplicarse.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`API key apps unrestricted`

Nombre de la categoría en la API: API_KEY_APPS_UNRESTRICTED

Se están usando claves de API sin restricciones, lo que permite que las use cualquier aplicación no fiable.

Las claves de API sin restricciones no son seguras porque se pueden obtener en los dispositivos donde se almacenan o se pueden ver de forma pública (por ejemplo, en un navegador). De acuerdo con el principio de mínimos accesos, restringe el uso de claves de API a hosts, URLs referentes con formato HTTP y aplicaciones de confianza. Para obtener más información, consulta Aplicar restricciones a claves de API.

Para solucionar este problema, siga estos pasos:

Ve a la página Claves de API de la Google Cloud consola.

Ir a Claves de API
En cada clave de API:
1. En la sección Claves de API, en la fila de cada clave de API para la que quieras restringir aplicaciones, haz clic en Acciones.
2. En el menú Acciones, haz clic en Editar clave de API. Se abrirá la página Editar clave de API.
3. En la página Editar clave de API, en Restricciones de aplicación, selecciona una categoría de restricción. Puedes definir una restricción de aplicación por clave.
4. En el campo Añadir un elemento que aparece cuando seleccionas una restricción, haz clic en Añadir un elemento para añadir restricciones según las necesidades de tu aplicación.
5. Cuando hayas terminado de añadir elementos, haz clic en Hecho.
  Advertencia: No uses comodines en las URLs referentes con formato HTTP que permitan el acceso a todas o a muchas de esas URLs, como *, *.[TLD] o .[TLD]/*. No uses direcciones IP ni URLs referentes para permitir el acceso a cualquier host (0.0.0.0, ::0 o 0.0.0.0/0).
6. Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`API key exists`

Nombre de la categoría en la API: API_KEY_EXISTS

Un proyecto usa claves de API en lugar de la autenticación estándar.

Las claves de API son menos seguras que otros métodos de autenticación porque son cadenas encriptadas sencillas que otros usuarios pueden descubrir y usar más fácilmente. Se pueden obtener en los dispositivos donde se almacenan o se pueden ver de forma pública (por ejemplo, en un navegador). Además, las claves de API no identifican de forma única a los usuarios ni a las aplicaciones que hacen solicitudes. Como alternativa, puedes usar un flujo de autenticación estándar con cuentas de servicio o cuentas de usuario.

Para solucionar este problema, siga estos pasos:

Comprueba que tus aplicaciones se hayan configurado con un método de autenticación alternativo.
Ve a la página Credenciales de API de la Google Cloud consola.

Ir a las credenciales de API
En la sección Claves de API de las filas correspondientes a cada una de las claves de APIs que quieres eliminar, haz clic en Acciones.
En el menú Acciones, haz clic en Eliminar clave de API.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`API key not rotated`

Nombre de la categoría en la API: API_KEY_NOT_ROTATED

Una clave de API no se ha rotado en más de 90 días.

Las claves de API no vencen nunca, de modo que, si se roban, pueden usarse de manera indefinida hasta que el propietario del proyecto las revoque o las rote. Rotar las claves de API con frecuencia reduce el tiempo que se puede usar una clave robada para acceder a los datos de una cuenta vulnerada o desactivada. Rota las claves de API al menos cada 90 días. Para obtener más información, consulta las prácticas recomendadas para gestionar las claves de API.

Para solucionar este problema, siga estos pasos:

Ve a la página Claves de API de la Google Cloud consola.

Ir a Claves de API
En cada clave de API:
1. En la sección Claves de API, en la fila correspondiente a cada clave de API que quieras rotar, haz clic en Acciones.
2. En el menú Acciones, haz clic en Editar clave de API. Se abrirá la página Editar clave de API.
3. En la página Editar clave de API, si la fecha del campo Fecha de creación tiene más de 90 días, haz clic en Rotar clave. Se genera una clave nueva.
4. También puedes cambiar el nombre de la clave de API.
5. Haz clic en Crear.
6. Actualiza tus aplicaciones para que usen la nueva clave.
7. Una vez que hayas actualizado tus aplicaciones, vuelve a la página Editar clave de API y haz clic en Eliminar la clave anterior para eliminar la clave antigua. La clave antigua no se eliminará automáticamente.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Audit config not monitored`

Nombre de la categoría en la API: AUDIT_CONFIG_NOT_MONITORED

Las métricas de registro y las alertas no están configuradas para monitorizar los cambios en la configuración de auditoría.

Cloud Logging genera registros de actividad de administración y de acceso a los datos que sirven para hacer análisis de seguridad, un seguimiento de los cambios en los recursos y auditorías de cumplimiento. Monitorizar los cambios en la configuración de auditorías asegura que todas las actividades de tu proyecto puedan auditarse en cualquier momento. Para obtener más detalles, consulta la información general sobre las métricas basadas en registros.

En función de la cantidad de información, los costes de Cloud Monitoring pueden ser significativos. Para entender el uso que haces del servicio y sus costes, consulta los precios de Google Cloud Observability.

En el caso de las activaciones a nivel de proyecto del nivel Premium de Security Command Center, esta detección solo está disponible si el nivel Standard está habilitado en la organización principal.

Para solucionar este problema, crea métricas y políticas de alertas, si es necesario:

Crear métrica

Ve a la página Métricas basadas en registros de la consola de Google Cloud .

Ir a Métricas basadas en registros
Haz clic en Crear métrica.
En Tipo de métrica, selecciona Contador.
En Detalles:
1. Especifica un nombre para la métrica de registro.
2. Añade una descripción.
3. Asigna a Unidades el valor 1.
En Selección de filtro, copia el texto siguiente y pégalo en el cuadro Crear filtro en lugar del texto que haya, si es preciso:
```
  protoPayload.methodName="SetIamPolicy"
  AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*
```
Haz clic en Crear métrica. Aparece una confirmación.

Crear política de alertas

En la Google Cloud consola, ve a la página Métricas basadas en registros:
Ve a Métricas basadas en registros.

Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Registro.
En la sección Métricas definidas por el usuario, selecciona la métrica que has creado en la sección anterior.
Haz clic en Más y, a continuación, en Crear alerta a partir de la métrica.

Se abrirá el cuadro de diálogo Nueva condición con las opciones de métrica y transformación de datos rellenadas automáticamente.
Haz clic en Siguiente.
1. Revisa los ajustes que se han rellenado automáticamente. Puede que quieras modificar el valor del umbral.
2. Haz clic en Nombre de la condición y escribe el nombre de la condición.
Haz clic en Siguiente.
Para añadir notificaciones a tu política de alertas, haz clic en Canales de notificación. En el cuadro de diálogo, selecciona uno o más canales de notificación y, luego, haz clic en Aceptar.

Para recibir notificaciones cuando se abran y se cierren incidentes, marca la opción Notificar cuando se cierre un incidente. De forma predeterminada, las notificaciones solo se envían cuando se abren incidentes.
Opcional: Actualiza la duración del cierre automático de incidentes. Este campo determina cuándo cierra Monitoring los incidentes si no hay datos de métricas.
Opcional: Haz clic en Documentación y añade la información que quieras incluir en las notificaciones.
Haz clic en Nombre de la alerta y escribe el que quieras asignar a la política de alertas.
Haz clic enCreate Policy (Crear política).

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Audit logging disabled`

Nombre de la categoría en la API: AUDIT_LOGGING_DISABLED

Este hallazgo no está disponible para las activaciones a nivel de proyecto.

El registro de auditoría está inhabilitado en uno o varios servicios, o bien una o varias cuentas principales están exentas del registro de auditoría de acceso a datos. Google Cloud

Habilita Cloud Logging en todos los servicios para monitorizar las actividades de administración y los accesos de lectura y escritura a los datos de los usuarios. En función de la cantidad de información, los costes de Cloud Logging pueden ser significativos. Para conocer el uso que haces del servicio y su coste, consulta los precios de Google Cloud Observability.

Si algún principal está exento del registro de auditoría de acceso a datos en la configuración predeterminada o en la configuración de registro de algún servicio concreto, elimina la exención.

Para solucionar este problema, siga estos pasos:

Ve a la página Configuración predeterminada de registros de auditoría de acceso a datos en la consolaGoogle Cloud .

Ir a la configuración predeterminada
En la pestaña Tipos de registros, activa el registro de auditoría de acceso a datos en la configuración predeterminada:
1. Selecciona Actividad de administración, Lectura de datos y Escritura de datos.
2. Haz clic en Guardar.
En la pestaña Principales exentos, elimina todos los usuarios exentos de la configuración predeterminada:
1. Elimina cada principal de la lista haciendo clic en Eliminar junto a cada nombre.
2. Haz clic en Guardar.
Ve a la página Registros de auditoría.

Ir a los registros de auditoría
Elimina los principales exentos de la configuración del registro de auditoría de acceso a datos de servicios concretos.
1. En Configuración de registros de auditoría de acceso a datos, haz clic en cada uno de los servicios que muestre un principal exento. Tras esta acción, se abre un panel de configuración del registro de auditoría correspondiente al servicio en cuestión.
2. En la pestaña Principales exentos, elimina todos los principales exentos haciendo clic en Eliminar junto a cada nombre.
3. Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Auto backup disabled`

Nombre de la categoría en la API: AUTO_BACKUP_DISABLED

No se han habilitado las copias de seguridad automáticas de una base de datos de Cloud SQL.

Para evitar que se pierdan datos, activa la copia de seguridad automática de tus instancias de SQL. Para obtener más información, consulta Crear y gestionar copias de seguridad automáticas y bajo demanda.

Para solucionar este problema, siga estos pasos:

En la Google Cloud consola, ve a la página Instancias de Cloud SQL.

Ir a Instancias
Haz clic en el nombre de la instancia.
Haz clic en Copias de seguridad.
Junto a Configuración, haz clic en Editar.
Selecciona la casilla Copias de seguridad diarias automatizadas.
Opcional: En el cuadro Número de días, indica cuántos días quieres conservar las copias de seguridad.
Opcional: En la lista Ventana de copia de seguridad, selecciona el periodo en el que se harán las copias de seguridad.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Auto repair disabled`

Nombre de la categoría en la API: AUTO_REPAIR_DISABLED

La función de reparación automática de un clúster de Google Kubernetes Engine (GKE), que mantiene los nodos en perfecto funcionamiento, está inhabilitada.

Cuando está habilitada, GKE comprueba periódicamente el estado de cada uno de los nodos del clúster. Si un nodo no supera sucesivas comprobaciones del estado durante un periodo prolongado, GKE inicia el proceso de reparación. Para obtener más información, consulta Reparación automática de nodos.

Para solucionar este problema, siga estos pasos:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
Haz clic en la pestaña Nodos.
En cada grupo de nodos:
1. Haz clic en el nombre del grupo de nodos para ir a su página de detalles.
2. Haz clic en Editar.
3. En Gestión, selecciona Habilitar reparación automática.
4. Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Auto upgrade disabled`

Nombre de la categoría en la API: AUTO_UPGRADE_DISABLED

La función de actualización automática de un clúster de GKE, que mantiene los clústeres y los grupos de nodos en la versión estable más reciente de Kubernetes, está inhabilitada.

Para obtener más información, consulta Actualizar nodos automáticamente.

Para solucionar este problema, siga estos pasos:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
En la lista de clústeres, haz clic en el nombre del clúster.
Haz clic en la pestaña Nodos.
En cada grupo de nodos:
1. Haz clic en el nombre del grupo de nodos para ir a su página de detalles.
2. Haz clic en Editar.
3. En Gestión, selecciona Habilitar actualización automática.
4. Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`BigQuery table CMEK disabled`

Nombre de la categoría en la API: BIGQUERY_TABLE_CMEK_DISABLED

Una tabla de BigQuery no está configurada para usar una clave de cifrado gestionada por el cliente (CMEK).

Con las CMEK, las claves que creas y gestionas en Cloud KMS cifran las claves que usa Google Cloud para cifrar tus datos, lo que te da más control sobre el acceso a tus datos. Para obtener más información, consulta Proteger datos con claves de Cloud KMS.

Para solucionar este problema, siga estos pasos:

Para definir una clave CMEK predeterminada que cifre todas las tablas nuevas de un conjunto de datos, consulta Definir una clave predeterminada para un conjunto de datos.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Binary authorization disabled`

Nombre de la categoría en la API: BINARY_AUTHORIZATION_DISABLED

La autorización binaria está inhabilitada en un clúster de GKE.

La autorización binaria incluye una función opcional que protege la seguridad de la cadena de suministro permitiendo que, durante el proceso de desarrollo, solo se desplieguen en el clúster imágenes de contenedor firmadas por autoridades de confianza. Al aplicar el despliegue basado en firmas, tienes un control más estricto sobre tu entorno de contenedores, ya que solo se pueden desplegar las imágenes verificadas.

Para solucionar este problema, siga estos pasos:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
En la sección Seguridad, haz clic en Editar en la fila Autorización binaria.

Si la configuración del clúster ha cambiado recientemente, puede que el botón Editar esté inhabilitado. Si no puedes modificar la configuración del clúster, espera unos minutos y vuelve a intentarlo.
En el cuadro de diálogo, selecciona Habilitar la autorización binaria.
Haz clic en Guardar cambios.
Ve a la página de configuración de la autorización binaria.

Ir a Autorización binaria
Asegúrate de que haya configurada una política que requiera attestors y de que la regla predeterminada del proyecto no esté configurada como Permitir todas las imágenes. Para obtener más información, consulta Configuración para GKE.

Para asegurarte de que se puedan desplegar las imágenes que infringen la política y de que las infracciones se registren en los registros de auditoría de Cloud, puedes habilitar el modo de prueba.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Bucket CMEK disabled`

Nombre de la categoría en la API: BUCKET_CMEK_DISABLED

Un segmento no está encriptado con claves de encriptado gestionadas por el cliente (CMEK).

Si defines una CMEK predeterminada en un segmento, ejerces más control sobre el acceso a tus datos. Para obtener más información, consulta el artículo Claves de cifrado gestionadas por el cliente.

Para solucionar este problema, usa CMEK con un segmento siguiendo los pasos de Usar claves de cifrado gestionadas por el cliente. Las CMEK conllevan costes adicionales relacionados con Cloud KMS.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Bucket IAM not monitored`

Nombre de la categoría en la API: BUCKET_IAM_NOT_MONITORED

Las métricas de registro y las alertas no están configuradas para monitorizar los cambios en los permisos de gestión de identidades y accesos de Cloud Storage.

Monitorizar los cambios en los permisos de segmentos de Cloud Storage te permite identificar a usuarios con demasiados privilegios o detectar actividades sospechosas. Para obtener más detalles, consulta la información general sobre las métricas basadas en registros.

Para solucionar este problema, siga estos pasos:

Crear métrica

Ve a la página Métricas basadas en registros de la consola de Google Cloud .

Ir a Métricas basadas en registros
Haz clic en Crear métrica.
En Tipo de métrica, selecciona Contador.
En Detalles:
1. Especifica un nombre para la métrica de registro.
2. Añade una descripción.
3. Asigna a Unidades el valor 1.
En Selección de filtro, copia el texto siguiente y pégalo en el cuadro Crear filtro en lugar del texto que haya, si es preciso:
```
  resource.type=gcs_bucket
  AND protoPayload.methodName="storage.setIamPermissions"
```
Haz clic en Crear métrica. Aparece una confirmación.

Crear política de alertas

En la Google Cloud consola, ve a la página Métricas basadas en registros:
Ve a Métricas basadas en registros.

Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Registro.
En la sección Métricas definidas por el usuario, selecciona la métrica que has creado en la sección anterior.
Haz clic en Más y, a continuación, en Crear alerta a partir de la métrica.

Se abrirá el cuadro de diálogo Nueva condición con las opciones de métrica y transformación de datos rellenadas automáticamente.
Haz clic en Siguiente.
1. Revisa los ajustes que se han rellenado automáticamente. Puede que quieras modificar el valor del umbral.
2. Haz clic en Nombre de la condición y escribe el nombre de la condición.
Haz clic en Siguiente.
Para añadir notificaciones a tu política de alertas, haz clic en Canales de notificación. En el cuadro de diálogo, selecciona uno o más canales de notificación y, luego, haz clic en Aceptar.

Para recibir notificaciones cuando se abran y se cierren incidentes, marca la opción Notificar cuando se cierre un incidente. De forma predeterminada, las notificaciones solo se envían cuando se abren incidentes.
Opcional: Actualiza la duración del cierre automático de incidentes. Este campo determina cuándo cierra Monitoring los incidentes si no hay datos de métricas.
Opcional: Haz clic en Documentación y añade la información que quieras incluir en las notificaciones.
Haz clic en Nombre de la alerta y escribe el que quieras asignar a la política de alertas.
Haz clic enCreate Policy (Crear política).

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Bucket logging disabled`

Nombre de la categoría en la API: BUCKET_LOGGING_DISABLED

Hay un segmento de almacenamiento sin el registro habilitado.

Para investigar los problemas de seguridad y monitorizar el consumo del almacenamiento, habilita los registros de acceso y la información de almacenamiento de tus segmentos de Cloud Storage. Los registros de acceso proporcionan información sobre todas las solicitudes hechas en un segmento concreto, mientras que los registros de almacenamiento informan sobre el uso de almacenamiento de dicho segmento.

Para corregir este resultado, configura el registro del segmento indicado en el resultado de Security Health Analytics siguiendo los pasos de la guía de registros de uso y de almacenamiento.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Bucket policy only disabled`

Nombre de la categoría en la API: BUCKET_POLICY_ONLY_DISABLED

El acceso uniforme a nivel de segmento, antes llamado "Solo política del segmento", no está configurado.

El acceso uniforme a nivel de segmento simplifica el control del acceso a los segmentos, ya que inhabilita los permisos a nivel de objeto (LCA). Cuando se habilita, solo los permisos de gestión de identidades y accesos a nivel de segmento dan acceso al segmento y a los objetos que contiene. Para obtener más información, consulta Acceso uniforme a nivel de segmento.

Para solucionar este problema, siga estos pasos:

Ve a la página Navegador de Cloud Storage de la consola deGoogle Cloud .

Ve al navegador de Cloud Storage.
En la lista de segmentos, haz clic en el nombre del segmento que quieras.
Haz clic en la pestaña Configuration (Configuración).
En Permisos, haz clic en Control de acceso y, a continuación, en Editar modelo de control de acceso.
En el cuadro de diálogo, selecciona Uniforme.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Cloud Asset API disabled`

Nombre de la categoría en la API: CLOUD_ASSET_API_DISABLED

El servicio Inventario de recursos de Cloud no está habilitado en el proyecto.

Para solucionar este problema, siga estos pasos:

Ve a la página Biblioteca de APIs de la Google Cloud consola.

Ir a la biblioteca de APIs
Buscar Cloud Asset Inventory.
Selecciona el resultado del servicio API Cloud Asset.
Asegúrate de que se muestra API habilitada.

`Cluster logging disabled`

Nombre de la categoría en la API: CLUSTER_LOGGING_DISABLED

El registro no está habilitado en un clúster de GKE.

Para investigar los problemas de seguridad y monitorizar el uso, habilita Cloud Logging en tus clústeres.

En función de la cantidad de información, los costes de Cloud Logging pueden ser significativos. Para conocer el uso que haces del servicio y su coste, consulta los precios de Google Cloud Observability.

Para solucionar este problema, siga estos pasos:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
Seleccione el clúster que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.

Si la configuración del clúster ha cambiado recientemente, puede que el botón Editar esté inhabilitado. Si no puedes modificar la configuración del clúster, espera unos minutos y vuelve a intentarlo.
En la lista desplegable Stackdriver Logging antiguo o Stackdriver Kubernetes Engine Monitoring, selecciona Habilitado.

No se pueden activar ambas opciones a la vez. Utiliza solo Stackdriver Kubernetes Engine Monitoring, o bien Stackdriver Logging antiguo con Stackdriver Monitoring antiguo.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Cluster monitoring disabled`

Nombre de la categoría en la API: CLUSTER_MONITORING_DISABLED

La monitorización está inhabilitada en los clústeres de GKE.

Para investigar los problemas de seguridad y monitorizar el uso, habilita Cloud Monitoring en tus clústeres.

Para solucionar este problema, siga estos pasos:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
Seleccione el clúster que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.

Si la configuración del clúster ha cambiado recientemente, puede que el botón Editar esté inhabilitado. Si no puedes modificar la configuración del clúster, espera unos minutos y vuelve a intentarlo.
En la lista desplegable Stackdriver Monitoring antiguo o Stackdriver Kubernetes Engine Monitoring, selecciona Habilitado.

No se pueden activar ambas opciones a la vez. Utiliza solo Stackdriver Kubernetes Engine Monitoring, o bien Stackdriver Monitoring antiguo con Stackdriver Logging antiguo.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Cluster private Google access disabled`

Nombre de la categoría en la API: CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

Los hosts del clúster no están configurados para usar solo direcciones IP privadas e internas para acceder a las APIs de Google.

Acceso privado de Google permite que las instancias de máquina virtual (VM) que solo tienen direcciones IP internas privadas lleguen a las direcciones IP públicas de las APIs y los servicios de Google. Para obtener más información, consulta el artículo Configurar Acceso privado de Google.

Para solucionar este problema, siga estos pasos:

Ve a la página Redes de nube privada virtual de la Google Cloud consola.

Ve a Redes de VPC.
En la lista de redes, haz clic en el nombre de la red que quieras.
En la página Detalles de la red de VPC, haz clic en la pestaña Subredes.
En la lista de subredes, haz clic en el nombre de la subred asociada al clúster de Kubernetes de la detección.
En la página Detalles de la subred, haga clic en Editar.
En Acceso privado de Google, selecciona Activado.
Haz clic en Guardar.
Para quitar las IPs públicas (externas) de las instancias de VM cuyo tráfico externo se dirija únicamente a las APIs de Google, consulta el artículo Anular la asignación de una dirección IP externa estática.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Cluster secrets encryption disabled`

Nombre de la categoría en la API: CLUSTER_SECRETS_ENCRYPTION_DISABLED

El encriptado de secretos de la capa de aplicación está inhabilitado en un clúster de GKE.

El encriptado de secretos de la capa de aplicación asegura que los secretos de GKE se encripten con claves de Cloud KMS. Esta función proporciona una capa adicional de seguridad para los datos sensibles, como los secretos definidos por el usuario y los secretos necesarios para que funcione el clúster (por ejemplo, claves de cuentas de servicio), que se almacenan en etcd.

Para solucionar este problema, siga estos pasos:

Ve a la página Claves de Cloud KMS de la consola de Google Cloud .

Ir a las claves de Cloud KMS
Revisa las claves de tus aplicaciones o crea una clave de cifrado de base de datos (DEK). Para obtener más información, consulta Crear una clave de Cloud KMS.
Ve a la página Clústeres de Kubernetes.

Ir a clústeres de Kubernetes
Selecciona el clúster en el resultado.
En el campo Encriptado de secretos de la capa de aplicación de Seguridad, haz clic en Editar el encriptado de secretos en la capa de la aplicación.
Marca la casilla Activar encriptado de secretos de la capa de aplicación y, a continuación, selecciona la clave DEK que has creado.
Haz clic en Guardar cambios.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Cluster shielded nodes disabled`

Nombre de la categoría en la API: CLUSTER_SHIELDED_NODES_DISABLED

Los nodos de GKE blindados no están habilitados en un clúster.

Si no tienes nodos de GKE blindados, los atacantes pueden aprovechar las vulnerabilidades de los pods para filtrar al exterior las credenciales de arranque y suplantar la identidad de los nodos del clúster. La vulnerabilidad puede dar a los atacantes acceso a los secretos del clúster.

Para solucionar este problema, siga estos pasos:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
Selecciona el clúster en el resultado.
En el campo Nodos de GKE blindados de Seguridad, haz clic en Editar nodos de GKE blindados.
Marca la casilla Habilitar nodos de GKE blindados.
Haz clic en Guardar cambios.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Compute project wide SSH keys allowed`

Nombre de la categoría en la API: COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

Se usan claves SSH de todo el proyecto, lo que permite iniciar sesión en todas las instancias del proyecto.

Usar claves SSH de proyecto facilita la gestión, pero, si se vulneran, suponen un riesgo para la seguridad que puede afectar a todas las instancias del proyecto en cuestión. Te recomendamos que uses claves SSH específicas de instancias, ya que, si se vulneran, la superficie de ataque es más limitada. Para obtener más información, consulta Gestionar claves SSH en metadatos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de VM de la Google Cloud consola.

Ir a instancias de VM
En la lista de instancias, haz clic en el nombre de la instancia del hallazgo.
En la página Detalles de la instancia de VM, haz clic en Editar.
Nota: No puedes editar las instancias creadas con plantillas de instancias. Para cambiar la configuración de una plantilla de instancia, consulta Cómo actualizar plantillas de instancia.
En Claves SSH, selecciona Bloquear claves SSH del proyecto.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Compute Secure Boot disabled`

Nombre de la categoría en la API: COMPUTE_SECURE_BOOT_DISABLED

Una VM blindada no tiene habilitado el arranque seguro.

El arranque seguro te ayuda a proteger tus máquinas virtuales contra rootkits y bootkits. En Compute Engine, el arranque seguro no se habilita de forma predeterminada porque algunos controladores sin firma y software básico no son compatibles. Si tu VM no usa software incompatible y se inicia con el arranque seguro habilitado, te recomendamos que no lo inhabilites. Si usas módulos de terceros con controladores de Nvidia, asegúrate de que sean compatibles con el arranque seguro antes de habilitarlo.

Para obtener más información, consulta Arranque seguro.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de VM de la Google Cloud consola.

Ir a instancias de VM
En la lista de instancias, haz clic en el nombre de la instancia del hallazgo.
En la página Detalles de la instancia de VM, haz clic en Detener.
Cuando la instancia se detenga, haz clic en Editar.
En VM blindada, selecciona Activar el arranque seguro.
Haz clic en Guardar.
Haz clic en Iniciar para iniciar la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Compute serial ports enabled`

Nombre de la categoría en la API: COMPUTE_SERIAL_PORTS_ENABLED

Los puertos serie están habilitados en una instancia, lo que permite establecer conexiones con la consola en serie de la instancia.

Si habilitas la consola en serie interactiva en una instancia, los clientes pueden tratar de conectarse a ella desde cualquier dirección IP. Por tanto, la compatibilidad con la consola en serie interactiva debe inhabilitarse. Para obtener más información, consulta Habilitar el acceso a un proyecto.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de VM de la Google Cloud consola.

Ir a instancias de VM
En la lista de instancias, haz clic en el nombre de la instancia del hallazgo.
En la página Detalles de la instancia de VM, haz clic en Editar.
En Acceso remoto, desmarca Habilitar la conexión a los puertos serie.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Confidential Computing disabled`

Nombre de la categoría en la API: CONFIDENTIAL_COMPUTING_DISABLED

Una instancia de Compute Engine no tiene habilitado Confidential Computing.

Confidential Computing añade un tercer pilar al cifrado de extremo a extremo, ya que cifra los datos mientras están en uso. Con los entornos de ejecución confidencial que ofrecen Confidential Computing y AMD Secure Encrypted Virtualization (SEV), Google Cloud mantiene el código sensible y otros datos encriptados en la memoria durante el procesamiento.

Confidential Computing solo se puede habilitar cuando se crea una instancia. Por lo tanto, debes eliminar la instancia actual y crear otra.

Para obtener más información, consulta Máquinas virtuales confidenciales y Compute Engine.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de VM de la Google Cloud consola.

Ir a instancias de VM
En la lista de instancias, haz clic en el nombre de la instancia del hallazgo.
En la página Detalles de la instancia de VM, haz clic en Eliminar.
Crea una Confidential VM mediante la Google Cloud consola.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`COS not used`

Nombre de la categoría en la API: COS_NOT_USED

Las VMs de Compute Engine no usan Container-Optimized OS, que se ha diseñado para ejecutar contenedores Docker de forma Google Cloud segura.

Container-Optimized OS es el sistema operativo que recomendamos en Google para alojar y ejecutar contenedores en Google Cloud. El tamaño reducido de este SO minimiza los riesgos de seguridad y las actualizaciones automáticas aplican parches para las vulnerabilidades de manera pertinente. Para obtener más información, consulta la información general de Container-Optimized OS.

Para solucionar este problema, siga estos pasos:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
En la lista de clústeres, haz clic en el nombre del clúster de la detección.
Haz clic en la pestaña Nodos.
En cada grupo de nodos:
1. Haz clic en el nombre del grupo de nodos para ir a su página de detalles.
2. Haz clic en Editar .
3. En Nodos -> Tipo de imagen, haz clic en Cambiar.
4. Selecciona Container-Optimized OS y, a continuación, haz clic en Cambiar.
5. Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Custom role not monitored`

Nombre de la categoría en la API: CUSTOM_ROLE_NOT_MONITORED

Las métricas de registro y las alertas no están configuradas para monitorizar los cambios en los roles personalizados.

IAM ofrece roles personalizados y predefinidos que otorgan acceso a recursos Google Cloud específicos. Monitorizar las actividades de creación, eliminación y actualización de roles te permite identificar usuarios que tengan demasiados privilegios en una fase temprana. Para obtener más información, consulta el artículo Información general sobre las métricas basadas en registros.

Para solucionar este problema, siga estos pasos:

Crear métrica

Ve a la página Métricas basadas en registros de la consola de Google Cloud .

Ir a Métricas basadas en registros
Haz clic en Crear métrica.
En Tipo de métrica, selecciona Contador.
En Detalles:
1. Especifica un nombre para la métrica de registro.
2. Añade una descripción.
3. Asigna a Unidades el valor 1.

En Selección de filtro, copia el texto siguiente y pégalo en el cuadro Crear filtro en lugar del texto que haya, si es preciso:

  resource.type="iam_role"
  AND (protoPayload.methodName="google.iam.admin.v1.CreateRole"
  OR protoPayload.methodName="google.iam.admin.v1.DeleteRole"
  OR protoPayload.methodName="google.iam.admin.v1.UpdateRole")

Haz clic en Crear métrica. Aparece una confirmación.

Crear política de alertas

En la Google Cloud consola, ve a la página Métricas basadas en registros:
Ve a Métricas basadas en registros.

Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Registro.
En la sección Métricas definidas por el usuario, selecciona la métrica que has creado en la sección anterior.
Haz clic en Más y, a continuación, en Crear alerta a partir de la métrica.

Se abrirá el cuadro de diálogo Nueva condición con las opciones de métrica y transformación de datos rellenadas automáticamente.
Haz clic en Siguiente.
1. Revisa los ajustes que se han rellenado automáticamente. Puede que quieras modificar el valor del umbral.
2. Haz clic en Nombre de la condición y escribe el nombre de la condición.
Haz clic en Siguiente.
Para añadir notificaciones a tu política de alertas, haz clic en Canales de notificación. En el cuadro de diálogo, selecciona uno o más canales de notificación y, luego, haz clic en Aceptar.

Para recibir notificaciones cuando se abran y se cierren incidentes, marca la opción Notificar cuando se cierre un incidente. De forma predeterminada, las notificaciones solo se envían cuando se abren incidentes.
Opcional: Actualiza la duración del cierre automático de incidentes. Este campo determina cuándo cierra Monitoring los incidentes si no hay datos de métricas.
Opcional: Haz clic en Documentación y añade la información que quieras incluir en las notificaciones.
Haz clic en Nombre de la alerta y escribe el que quieras asignar a la política de alertas.
Haz clic enCreate Policy (Crear política).

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Dataproc CMEK disabled`

Nombre de la categoría en la API: DATAPROC_CMEK_DISABLED

Se ha creado un clúster de Dataproc sin una CMEK de configuración de cifrado. Con las CMEK, las claves que creas y gestionas en Cloud Key Management Service cifran las claves que usa Google Cloud para cifrar tus datos, lo que te da más control sobre el acceso a tus datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Clúster de Dataproc de la Google Cloud consola.

Ir a clústeres de Dataproc
Selecciona el proyecto y haz clic en Crear clúster.
En la sección Gestionar la seguridad, haz clic en Encriptado y, luego, selecciona Clave gestionada por el cliente.
Selecciona una clave gestionada por el cliente de la lista.

Si no tienes una clave gestionada por el cliente, debes crear una para usarla. Para obtener más información, consulta el artículo Claves de cifrado gestionadas por el cliente.
Comprueba que la clave de KMS seleccionada tiene asignado el rol Encargado del encriptado y desencriptado de la clave criptográfica Cloud KMS a la cuenta de servicio del clúster de Dataproc ("serviceAccount:service-project_number@compute-system.iam.gserviceaccount.com").
Una vez creado el clúster, migra todas las cargas de trabajo del clúster antiguo al nuevo.
Ve a clústeres de Dataproc y selecciona tu proyecto.
Selecciona el clúster antiguo y haz clic en Eliminar clúster.
Repite todos los pasos anteriores con los demás clústeres de Dataproc del proyecto seleccionado.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Dataproc image outdated`

Nombre de la categoría en la API: DATAPROC_IMAGE_OUTDATED

Se ha creado un clúster de Dataproc con una versión de imagen de Dataproc afectada por las vulnerabilidades de seguridad de la utilidad Apache Log4j 2 (CVE-2021-44228 y CVE-2021-45046).

Este detector encuentra vulnerabilidades comprobando si el campo softwareConfig.imageVersion de la propiedad config de un Cluster tiene alguna de las siguientes versiones afectadas:

Versiones de imagen anteriores a la 1.3.95.
Versiones secundarias anteriores a 1.4.77, 1.5.53 y 2.0.27.

El número de versión de una imagen de Dataproc personalizada se puede anular manualmente. Veamos los siguientes casos:

Se puede modificar la versión de una imagen personalizada afectada para que parezca que no lo está. En este caso, este detector no emite ningún resultado.
Se puede sustituir la versión de una imagen personalizada no afectada por una que se sepa que tiene la vulnerabilidad. En este caso, el detector emite un falso positivo. Para suprimir estos falsos positivos, puedes silenciarlos.

Para solucionar este problema, vuelve a crear y actualizar el clúster afectado.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Dataset CMEK disabled`

Nombre de la categoría en la API: DATASET_CMEK_DISABLED

Un conjunto de datos de BigQuery no está configurado para usar una clave de cifrado gestionada por el cliente (CMEK) predeterminada.

Para solucionar este problema, siga estos pasos:

No puedes cambiar una tabla de la encriptación predeterminada a la encriptación con CMEK. Para definir una clave CMEK predeterminada con la que encriptar todas las tablas nuevas del conjunto de datos, sigue las instrucciones para definir una clave predeterminada para un conjunto de datos.

Al definir una clave predeterminada, las tablas del conjunto de datos no se vuelven a encriptar retroactivamente con una clave nueva. Para usar CMEK en datos ya existentes, haz lo siguiente:

Crea un conjunto de datos.
Define una clave CMEK predeterminada en el conjunto de datos que has creado.
Para copiar tablas en tu conjunto de datos con CMEK habilitada, sigue las instrucciones para copiar una tabla.
Una vez que haya copiado los datos correctamente, elimine los conjuntos de datos originales.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Default network`

Nombre de la categoría en la API: DEFAULT_NETWORK

La red predeterminada existe en un proyecto.

Las redes predeterminadas han creado automáticamente reglas de cortafuegos y configuraciones de red que pueden no ser seguras. Para obtener más información, consulta Red predeterminada.

Para solucionar este problema, siga estos pasos:

Ve a la página Redes de VPC de la consola de Google Cloud .

Ir a redes de VPC
En la lista de redes, haz clic en el nombre de la predeterminada.
En la página Detalles de la red de VPC, haz clic en Eliminar red de VPC.
Para crear una red con reglas de cortafuegos personalizadas, consulta cómo crear redes.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Default service account used`

Nombre de la categoría en la API: DEFAULT_SERVICE_ACCOUNT_USED

Una instancia de Compute Engine está configurada para usar la cuenta de servicio predeterminada.

La cuenta de servicio predeterminada de Compute Engine tiene el rol Editor en el proyecto, lo que le da acceso de lectura y escritura a la mayoría de los servicios de Google Cloud . No la uses si quieres evitar la apropiación de privilegios y el acceso no autorizado. En su lugar, crea otra cuenta de servicio y asígnale únicamente los permisos que requiera tu instancia. Consulta la página sobre el control de acceso para obtener información acerca de los roles y los permisos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de VM de la Google Cloud consola.

Ir a instancias de VM
Selecciona la instancia relacionada con el resultado de Security Health Analytics.
En la página Detalles de la instancia que se carga, haz clic en Detener.
Cuando la instancia se detenga, haz clic en Editar.
En la sección Cuenta de servicio, selecciona una que no sea la predeterminada de Compute Engine. Puede que primero debas crear otra cuenta de servicio. Consulta la página sobre el control de acceso para obtener información acerca de los roles y los permisos de gestión de identidades y accesos.
Haz clic en Guardar. La nueva configuración aparece en la página Detalles de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Disk CMEK disabled`

Nombre de la categoría en la API: DISK_CMEK_DISABLED

Los discos de esta VM no están cifrados con claves de cifrado gestionadas por el cliente (CMEK).

Con las CMEK, las claves que creas y gestionas en Cloud KMS cifran las claves que usa Google Cloud para cifrar tus datos, lo que te permite controlar mejor el acceso a tus datos. Para obtener más información, consulta Proteger recursos con claves de Cloud KMS.

Para solucionar este problema, siga estos pasos:

Ve a la página Discos de Compute Engine de la consola deGoogle Cloud .

Ir a los discos de Compute Engine
En la lista de discos, haz clic en el nombre del disco indicado en el resultado.
En la página Gestionar disco, haz clic en Eliminar.
Para crear un disco con la clave CMEK habilitada, consulta Cifrar un disco persistente nuevo con tus propias claves. Las CMEK generan costes adicionales relacionados con Cloud KMS.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Disk CSEK disabled`

Nombre de la categoría en la API: DISK_CSEK_DISABLED

Los discos de esta VM no están encriptados con claves de encriptado proporcionadas por el cliente (CSEK). Los discos de VMs críticas deben encriptarse con CSEK.

Si proporcionas tus propias claves de encriptado, Compute Engine las usará para proteger las claves generadas por Google, que se usan para encriptar y desencriptar tus datos. Para obtener más información, consulta Claves de cifrado proporcionadas por el cliente. La CSEK conlleva costes adicionales relacionados con Cloud KMS.

Para solucionar este problema, siga estos pasos:

Eliminar y crear un disco

Con tu propia clave solo puedes encriptar discos persistentes nuevos. Los discos persistentes anteriores no se pueden encriptar con tu clave.

Ve a la página Discos de Compute Engine de la consola deGoogle Cloud .

Ir a los discos de Compute Engine
En la lista de discos, haz clic en el nombre del disco indicado en el resultado.
En la página Gestionar disco, haz clic en Eliminar.
Para crear un disco con la CSEK habilitada, consulta Encriptar discos con claves de cifrado proporcionadas por el cliente.
Completa los pasos restantes para habilitar el detector.

Habilitar el detector

Ve a la página Recursos de Security Command Center en la consola deGoogle Cloud .

Ir a Recursos
En la sección Tipo de recurso del panel Filtros rápidos, selecciona compute.Disk.

Si no ves compute.Disk, haz clic en Ver más, introduce Disk en el campo de búsqueda y, a continuación, haz clic en Aplicar.

El panel Resultados se actualiza para mostrar solo las instancias del tipo de recurso compute.Disk.
En la columna Nombre visible, seleccione la casilla situada junto al nombre del disco que quiera usar con CSEK y, a continuación, haga clic en Definir marcas de seguridad.
En el cuadro de diálogo, haz clic en Añadir marca.
En el campo clave, introduce enforce_customer_supplied_disk_encryption_keys y, en el campo valor, introduce true.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`DNS logging disabled`

Nombre de la categoría en la API: DNS_LOGGING_DISABLED

Monitorizar los registros de Cloud DNS proporciona visibilidad sobre los nombres de DNS que solicitan los clientes de la red de VPC. Estos registros se pueden monitorizar en busca de nombres de dominio anómalos y evaluar conforme a la inteligencia de amenazas. Recomendamos habilitar el registro de DNS en las redes de VPC.

En función de la cantidad de información, los costes de registro de Cloud DNS pueden ser significativos. Para conocer el uso que haces del servicio y su coste, consulta la página Precios de Google Cloud Observability: Cloud Logging.

Para solucionar este problema, siga estos pasos:

Ve a la página Redes de VPC de la consola de Google Cloud. Google Cloud

Ir a redes de VPC
En la lista de redes, haz clic en el nombre de la red de VPC.
Crea una política de servidor (si no existe) o edita una que ya tengas:
- Si la red no tiene ninguna política de servidor DNS, sigue estos pasos:
  1. Haz clic en Editar.
  2. En el campo Política de servidor DNS, haz clic en Crear política de servidor.
  3. Escribe el nombre de la nueva política de servidor.
  4. En Registros, selecciona Habilitar.
  5. Haz clic en Guardar.
- Si la red tiene una política de servidor DNS, sigue estos pasos:
  1. En el campo Política de servidor DNS, haz clic en el nombre de la política de DNS.
  2. Haz clic en Editar política.
  3. En Registros, selecciona Habilitar.
  4. Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`DNSSEC disabled`

Nombre de la categoría en la API: DNSSEC_DISABLED

Las extensiones de seguridad del sistema de nombres de dominio (DNSSEC) están inhabilitadas en las zonas de Cloud DNS.

DNSSEC valida las respuestas de DNS y mitiga riesgos, como la interceptación de DNS y los ataques de intermediación, firmando criptográficamente los registros DNS. Deberías habilitar DNSSEC. Para obtener más información, consulta la descripción general de las extensiones de seguridad de DNS (DNSSEC).

Para solucionar este problema, siga estos pasos:

Ve a la página Cloud DNS de la Google Cloud consola.

Ir a redes de Cloud DNS
Busca la fila con la zona DNS indicada en el hallazgo.
Haz clic en el ajuste DNSSEC de la fila y, a continuación, en DNSSEC, selecciona Activado.
Lee el cuadro de diálogo que aparece. Si estás de acuerdo, haz clic en Habilitar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Effectively Anonymous Users Granted GKE Cluster Access`

Nombre de la categoría en la API: GKE_PRIVILEGE_ESCALATION_DEFAULT_USERS_GROUPS

Alguien ha creado un enlace RBAC que hace referencia a uno de los siguientes usuarios o grupos:

system:anonymous
system:authenticated
system:unauthenticated

Estos usuarios y grupos son anónimos y no deben usarse en RoleBindings ni ClusterRoleBindings. Para obtener más información, consulta el artículo Evitar roles y grupos predeterminados.

Para solucionar este problema, sigue estos pasos en los recursos afectados:

Abre el manifiesto de cada ClusterRoleBinding o RoleBinding afectado.
Asigna a los siguientes campos restringidos uno de los valores permitidos.

Campos restringidos

subjects[*].name

Valores permitidos

Cualquier grupo, usuario o cuenta de servicio que no incluya system:anonymous, system:authenticated ni system:unauthenticated.

`Egress deny rule not set`

Nombre de la categoría en la API: EGRESS_DENY_RULE_NOT_SET

No se ha definido una regla de denegación de salida en un cortafuegos.

Un cortafuegos que rechace todo el tráfico de red de salida impide que se establezcan conexiones de red de salida no deseadas, excepto las que autoricen expresamente otros cortafuegos. Para obtener más información, consulta Casos de salida.

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ve a Cortafuegos.
Haz clic en Crear regla de cortafuegos.
Asigna un nombre al cortafuegos y, si quieres, una descripción.
En Dirección del tráfico, selecciona Salida.
En Acción tras coincidencia, selecciona Denegar.
En el menú desplegable Destinos, elige Todas las instancias de la red.
En el menú desplegable Filtrar por destino, selecciona Intervalos de IP y, a continuación, escribe 0.0.0.0/0 en el cuadro Intervalos de IP de destino.
En Protocolos y puertos, selecciona Rechazar todos.
Haz clic en Inhabilitar regla y, en Implementación obligatoria, selecciona Habilitada.
Haz clic en Crear.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Essential contacts not configured`

Nombre de la categoría en la API: ESSENTIAL_CONTACTS_NOT_CONFIGURED

Tu organización no ha designado a ninguna persona ni grupo para recibir notificaciones de Google Cloud sobre eventos importantes, como ataques, vulnerabilidades e incidentes de datos, en tu organización Google Cloud . Te recomendamos que designes como contacto esencial a una o varias personas o grupos de tu organización.

Para solucionar este problema, siga estos pasos:

Ve a la página Contactos esenciales de la consola de Google Cloud Google Cloud.

Ir a Contactos esenciales
Comprueba que la organización aparece en el selector de recursos de la parte superior de la página. El selector de recursos te indica de qué proyecto, carpeta u organización estás gestionando contactos.
Haz clic en +Añadir contacto. Se abrirá el panel Añadir un contacto.
En los campos Correo y Confirmar correo, escribe la dirección de correo del contacto.
En la sección Categorías de notificaciones, selecciona los tipos de notificaciones que quieres que reciba el contacto. Asegúrate de que se hayan configurado las direcciones de correo adecuadas en cada una de las categorías de notificación siguientes:
1. Legal
2. Seguridad
3. Suspensión
4. Recursos técnicos
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Firewall not monitored`

Nombre de la categoría en la API: FIREWALL_NOT_MONITORED

Las métricas de registro y las alertas no están configuradas para monitorizar los cambios en las reglas de cortafuegos de redes de VPC.

Monitorizar los eventos de creación y actualización de reglas de cortafuegos te ofrece información valiosa sobre los cambios en el acceso a la red y te permite detectar actividad sospechosa rápidamente. Para obtener más información, consulta la información general sobre las métricas basadas en registros.

Para solucionar este problema, siga estos pasos:

Crear métrica

Ve a la página Métricas basadas en registros de la consola de Google Cloud .

Ir a Métricas basadas en registros
Haz clic en Crear métrica.
En Tipo de métrica, selecciona Contador.
En Detalles:
1. Especifica un nombre para la métrica de registro.
2. Añade una descripción.
3. Asigna a Unidades el valor 1.

En Selección de filtro, copia el texto siguiente y pégalo en el cuadro Crear filtro en lugar del texto que haya, si es preciso:

  resource.type="gce_firewall_rule"
  AND (protoPayload.methodName:"compute.firewalls.insert"
  OR protoPayload.methodName:"compute.firewalls.patch"
  OR protoPayload.methodName:"compute.firewalls.delete")

Haz clic en Crear métrica. Aparece una confirmación.

Crear política de alertas

En la Google Cloud consola, ve a la página Métricas basadas en registros:
Ve a Métricas basadas en registros.

Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Registro.
En la sección Métricas definidas por el usuario, selecciona la métrica que has creado en la sección anterior.
Haz clic en Más y, a continuación, en Crear alerta a partir de la métrica.

Se abrirá el cuadro de diálogo Nueva condición con las opciones de métrica y transformación de datos rellenadas automáticamente.
Haz clic en Siguiente.
1. Revisa los ajustes que se han rellenado automáticamente. Puede que quieras modificar el valor del umbral.
2. Haz clic en Nombre de la condición y escribe el nombre de la condición.
Haz clic en Siguiente.
Para añadir notificaciones a tu política de alertas, haz clic en Canales de notificación. En el cuadro de diálogo, selecciona uno o más canales de notificación y, luego, haz clic en Aceptar.

Para recibir notificaciones cuando se abran y se cierren incidentes, marca la opción Notificar cuando se cierre un incidente. De forma predeterminada, las notificaciones solo se envían cuando se abren incidentes.
Opcional: Actualiza la duración del cierre automático de incidentes. Este campo determina cuándo cierra Monitoring los incidentes si no hay datos de métricas.
Opcional: Haz clic en Documentación y añade la información que quieras incluir en las notificaciones.
Haz clic en Nombre de la alerta y escribe el que quieras asignar a la política de alertas.
Haz clic enCreate Policy (Crear política).

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Firewall rule logging disabled`

Nombre de la categoría en la API: FIREWALL_RULE_LOGGING_DISABLED

El registro de reglas de cortafuegos está inhabilitado.

El almacenamiento de registros de reglas de cortafuegos te permite auditar, verificar y analizar los efectos de estas. Se trata de una función que puede servir para auditar el acceso a la red o generar alertas tempranas si la red se usa de una forma no aprobada. El coste de los registros puede ser considerable. Para obtener más información sobre el almacenamiento de registros de reglas de cortafuegos y su coste, consulta el artículo Utilizar el almacenamiento de registros de reglas de cortafuegos.

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla que quiera.
Haz clic en Editar.
En Registros, selecciona Activado.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Flow logs disabled`

Nombre de la categoría en la API: FLOW_LOGS_DISABLED

Hay una subred de VPC que tiene inhabilitados los registros de flujo.

Registros de flujo de VPC guarda una muestra de los flujos de red enviados y recibidos en las instancias de VM. Estos registros sirven para monitorizar la red, realizar análisis forenses, hacer análisis de seguridad en tiempo real y optimizar el gasto. Para obtener más información sobre los registros de flujo y su coste, consulta el artículo Usar registros de flujo de VPC.

Para solucionar este problema, siga estos pasos:

Ve a la página Redes de VPC de la consola de Google Cloud.Google Cloud

Ir a redes de VPC
En la lista de redes, haz clic en el nombre de la red que quieras.
En la página Detalles de la red de VPC, haz clic en la pestaña Subredes.
En la lista de subredes, haga clic en el nombre de la subred indicada en el resultado.
En la página Detalles de la subred, haga clic en Editar.
En Registros de flujo, selecciona Activado.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Flow logs settings not recommended`

Nombre de la categoría en la API: VPC_FLOW_LOGS_SETTINGS_NOT_RECOMMENDED

En la configuración de una subred de una red de VPC, el servicio Registros de flujo de VPC está desactivado o no está configurado conforme a las recomendaciones del CIS Benchmark 1.3. Registros de flujo de VPC guarda una muestra de los flujos de red enviados y recibidos en instancias de VM que sirven para detectar amenazas.

Para obtener más información sobre los registros de flujo de VPC y su coste, consulta el artículo Usar registros de flujo de VPC.

Para solucionar este problema, siga estos pasos:

Ve a la página Redes de VPC de la consola de Google Cloud.Google Cloud

Ir a redes de VPC
En la lista de redes, haz clic en el nombre de la red.
En la página Detalles de la red de VPC, haz clic en la pestaña Subredes.
En la lista de subredes, haga clic en el nombre de la subred indicada en el resultado.
En la página Detalles de la subred, haga clic en Editar.
En Registros de flujo, selecciona Activado.
1. Si quieres, modifica la configuración de los registros haciendo clic en el botón Configurar registros para que se muestre la pestaña. Los estándares CIS Benchmark recomiendan los siguientes ajustes:
  1. Asigna a Intervalo de agregación el valor 5 S.
  2. En la casilla Otros campos, marca la opción Incluir metadatos.
  3. Asigna a Frecuencia de muestreo el valor 100%.
  4. Haz clic en el botón GUARDAR.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Full API access`

Nombre de la categoría en la API: FULL_API_ACCESS

Una instancia de Compute Engine está configurada para usar la cuenta de servicio predeterminada con acceso completo a todas las APIs. Google Cloud

Una instancia configurada con la cuenta de servicio predeterminada y el permiso de acceso a la API Permitir el acceso completo a todas las APIs de Cloud podría permitir que los usuarios realicen operaciones o llamadas a las APIs aunque no tengan permisos de gestión de identidades y accesos para ello. Para obtener más información, consulta el artículo sobre la cuenta de servicio predeterminada de Compute Engine.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de VM de la Google Cloud consola.

Ir a instancias de VM
En la lista de instancias, haz clic en el nombre de la instancia del hallazgo.
Si la instancia está en ejecución, haz clic en Detener.
Cuando la instancia se detenga, haz clic en Editar.
En la sección Seguridad y acceso, en Cuentas de servicio, selecciona Cuenta de servicio predeterminada de Compute Engine.
En Permisos de acceso, selecciona Permitir acceso predeterminado o Definir acceso para cada API. De esta forma, se limitan las APIs a las que puede acceder cualquier proceso o carga de trabajo que utilice la cuenta de servicio de VM predeterminada.
Si has seleccionado Definir acceso para cada API, haz lo siguiente:
- Inhabilita Cloud Platform seleccionando Ninguno.
- Habilita las APIs específicas a las que debe acceder la cuenta de servicio de la VM predeterminada.
Haz clic en Guardar.
Haz clic en Iniciar para iniciar la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`HTTP load balancer`

Nombre de la categoría en la API: HTTP_LOAD_BALANCER

Una instancia de Compute Engine usa un balanceador de carga configurado para usar un proxy HTTP de destino en lugar de un proxy HTTPS de destino.

Para proteger la integridad de tus datos y evitar que posibles intrusos manipulen tus comunicaciones, configura tus balanceadores de carga HTTP(S) para que solo se permita el tráfico HTTPS. Para obtener más información, consulta el resumen del balanceo de carga HTTP(S) externo.

Para solucionar este problema, siga estos pasos:

Ve a la página Proxies de destino de la consola de Google Cloud .

Ir a Proxies de destino
En la lista de proxies de destino, haga clic en el nombre del proxy de destino en el resultado.
Haz clic en el enlace de la sección Mapa de URLs.
Haz clic en Editar.
Haz clic en Configuración de frontend.
Elimina todas las configuraciones de IP de frontend y puerto que permitan el tráfico HTTP y crea otras que permitan el tráfico HTTPS.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Instance OS login disabled`

Nombre de la categoría en la API: INSTANCE_OS_LOGIN_DISABLED

OS Login está inhabilitado en esta instancia de Compute Engine.

OS Login permite gestionar claves SSH de manera centralizada mediante la gestión de identidades y accesos, e inhabilita la configuración basada en metadatos de esas claves en todas las instancias de un proyecto. Consulta cómo configurar OS Login.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de VM de la Google Cloud consola.

Ir a instancias de VM
En la lista de instancias, haz clic en el nombre de la instancia del hallazgo.
En la página Detalles de la instancia que se carga, haz clic en Detener.
Cuando la instancia se detenga, haz clic en Editar.
En la sección Metadatos personalizados, comprueba que el elemento con la clave enable-oslogin tiene el valor TRUE.
Haz clic en Guardar.
Haz clic en Iniciar para iniciar la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Integrity monitoring disabled`

Nombre de la categoría en la API: INTEGRITY_MONITORING_DISABLED

La monitorización de integridad está inhabilitada en un clúster de GKE.

La monitorización de integridad te permite supervisar y verificar la integridad del arranque del entorno de ejecución de los nodos blindados mediante Monitoring. Así puedes responder a los errores de integridad y evitar que los nodos vulnerados se desplieguen en el clúster.

Para solucionar este problema, siga estos pasos:

Una vez aprovisionado un nodo, no se puede actualizar para habilitar la monitorización de la integridad. Debes crear otro grupo de nodos con la monitorización de integridad habilitada.

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
Haga clic en el nombre del clúster en el resultado.
Haz clic en Add Node Pool (Añadir grupo de nodos).
En la pestaña Seguridad, comprueba que esté marcada la opción Habilitar monitorización de integridad.
Haz clic en Crear.
Para migrar tus cargas de trabajo de los grupos de nodos no conformes a los nuevos, consulta el artículo Migrar cargas de trabajo a diferentes tipos de máquinas.
Después de trasladar tus cargas de trabajo, elimina el grupo de nodos original no conforme.
1. En el menú Grupos de nodos de la página Clúster de Kubernetes, haz clic en el nombre del grupo que quieres eliminar.
2. Haz clic en Eliminar grupo de nodos.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Intranode visibility disabled`

Nombre de la categoría en la API: INTRANODE_VISIBILITY_DISABLED

La visibilidad intranodo está inhabilitada en un clúster de GKE.

Si habilitas la visibilidad intranodo, el tejido de las redes puede ver el tráfico intranodo entre pods. Con esta función, puedes usar el almacenamiento de registros del flujo u otras funciones de VPC para monitorizar o controlar el tráfico intranodo. Para obtener registros, debes habilitar los registros de flujo de VPC en la subred seleccionada. Para obtener más información, consulta el artículo sobre cómo usar los registros de flujo de VPC.

Para solucionar este problema, siga estos pasos:

Una vez aprovisionado un nodo, no se puede actualizar para habilitar la monitorización de la integridad. Debes crear otro grupo de nodos con la monitorización de integridad habilitada.

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
En la sección Redes, haz clic en Editar visibilidad intranodo en la fila Visibilidad intranodo.

Si la configuración del clúster ha cambiado recientemente, puede que el botón Editar esté inhabilitado. Si no puedes modificar la configuración del clúster, espera unos minutos y vuelve a intentarlo.
En el cuadro de diálogo, selecciona Habilitar visibilidad intranodo.
Haz clic en Guardar cambios.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`IP alias disabled`

Nombre de la categoría en la API: IP_ALIAS_DISABLED

Se ha creado un clúster de GKE con los intervalos de IP de alias inhabilitados.

Al habilitar intervalos de IP de alias, los clústeres de GKE asignarán direcciones IP de un bloque CIDR conocido para tener más escalabilidad e interactuar mejor con los productos y las entidades de Google Cloud . Para obtener más información, consulta el artículo Descripción general de los intervalos de IPs alias.

Para solucionar este problema, siga estos pasos:

No puedes migrar un clúster que ya tengas para usar IPs de alias. Para crear un clúster que tenga habilitadas las IPs de alias, sigue estos pasos:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
Haz clic en Crear.
En el panel de navegación, ve a Clúster y haz clic en Redes.
En Opciones de red avanzadas, selecciona Habilitar el enrutamiento del tráfico nativo de VPC (usa IP de alias).
Haz clic en Crear.

Nota: Los clústeres no se pueden modificar mientras se están reconfigurando.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`IP forwarding enabled`

Nombre de la categoría en la API: IP_FORWARDING_ENABLED

El reenvío de IP está habilitado en las instancias de Compute Engine.

Para evitar que se pierdan datos o se revele información, inhabilita el reenvío de las IPs de los paquetes de datos en las VMs.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de VM de la Google Cloud consola.

Ir a instancias de VM
En la lista de instancias, marca la casilla situada junto al nombre de la instancia en la detección.
Haz clic en Eliminar.
Selecciona Crear instancia para crear una instancia que sustituya a la que has eliminado.
Para asegurarte de que Reenvío de IP esté inhabilitado, haz clic en Gestión, discos, redes y claves SSH y, a continuación, en Redes.
En Interfaces de red, haz clic en Editar.
En Reenvío de IP, en el menú desplegable, asegúrate de que esté seleccionada la opción Desactivado.
Especifique los parámetros de instancia que necesite y haga clic en Crear. Para obtener más información, consulta Crear e iniciar una instancia de máquina virtual.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`KMS key not rotated`

Nombre de la categoría en la API: KMS_KEY_NOT_ROTATED

La rotación no está configurada en una clave de cifrado de Cloud KMS.

Rotar tus claves de encriptado de forma periódica te ofrece protección en caso de que se vulnere alguna clave y limita el número de mensajes encriptados disponibles para el criptoanálisis de una versión de clave concreta. Para obtener más información, consulta Rotación de claves.

Para solucionar este problema, siga estos pasos:

Ve a la página Claves de Cloud KMS de la consola de Google Cloud .

Ir a las claves de Cloud KMS
Haga clic en el nombre del conjunto de claves indicado en el resultado.
Haga clic en el nombre de la clave indicada en el resultado.
Haz clic en Editar periodo de rotación.
Establece el periodo de rotación en 90 días como máximo.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`KMS project has owner`

Nombre de la categoría en la API: KMS_PROJECT_HAS_OWNER

Un usuario tiene permisos roles/Owner en un proyecto con claves criptográficas. Para obtener más información, consulta Permisos y roles.

Para solucionar este problema, siga estos pasos:

Ve a la página Gestión de identidades y accesos de la Google Cloud consola.

Ir a la página de gestión de identidades y accesos
Si es necesario, selecciona el proyecto en el resultado.
En cada principal al que se le haya asignado el rol Propietario:
1. Haz clic en Editar.
2. En el panel Editar permisos, junto al rol Propietario, haz clic en Eliminar.
3. Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`KMS public key`

Nombre de la categoría en la API: KMS_PUBLIC_KEY

Una CryptoKey o un Key Ring de Cloud KMS son públicos y cualquier usuario de Internet puede acceder a ellos. Para obtener más información, consulta Usar IAM con Cloud KMS.

Para solucionar este problema, si está relacionado con una Cryptokey, sigue estos pasos:

Ve a la página Claves criptográficas de la consola de Google Cloud .

Claves criptográficas
En Nombre, selecciona el conjunto de claves que contiene la clave criptográfica relacionada con el hallazgo de Security Health Analytics.
En la página Detalles del conjunto de claves que se carga, marque la casilla situada junto a la clave criptográfica.
Si no ves PANEL DE INFORMACIÓN, haz clic en el botón MOSTRAR PANEL DE INFORMACIÓN.
Usa el cuadro de filtro que precede a Rol o principal para buscar los principales allUsers y allAuthenticatedUsers y, a continuación, haz clic en Eliminar para quitar el acceso a estos principales.

Para solucionar este problema, si está relacionado con un conjunto de claves, sigue estos pasos:

Ve a la página Claves criptográficas de la consola de Google Cloud .

Claves criptográficas
Busca la fila del conjunto de claves en el hallazgo y marca su casilla.
Si no ves PANEL DE INFORMACIÓN, haz clic en el botón MOSTRAR PANEL DE INFORMACIÓN.
Usa el cuadro de filtro que precede a Rol o principal para buscar los principales allUsers y allAuthenticatedUsers y, a continuación, haz clic en Eliminar para quitar el acceso a estos principales.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`KMS role separation`

Nombre de la categoría en la API: KMS_ROLE_SEPARATION

Este hallazgo no está disponible para las activaciones a nivel de proyecto.

Hay uno o varios principales a los que se les han asignado varios permisos de Cloud KMS. Recomendamos que ninguna cuenta tenga el rol Administrador de Cloud KMS si ya tiene otros permisos de Cloud KMS. Para obtener más información, consulta Permisos y roles.

Para solucionar este problema, siga estos pasos:

Ve a la página Gestión de identidades y accesos de la Google Cloud consola.

Ir a IAM
En cada principal que se indique en la detección, haga lo siguiente:
1. Comprueba si el rol se ha heredado de una carpeta o de un recurso de la organización. Para ello, fíjate en la columna Herencia. Si la columna contiene un enlace a un recurso superior, haz clic en él para ir a la página de gestión de identidades y accesos de ese recurso.
2. Haz clic en Editar junto a un principal.
3. Para quitar los permisos, haz clic en Eliminar junto a Administrador de Cloud KMS. Si quieres quitarle todos los permisos al principal, haz clic en Eliminar junto a los demás.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Legacy authorization enabled`

Nombre de la categoría en la API: LEGACY_AUTHORIZATION_ENABLED

La autorización antigua está habilitada en los clústeres de GKE.

En Kubernetes, el control de acceso basado en roles (RBAC) te permite definir roles con reglas que contienen un conjunto de permisos, así como otorgar permisos a nivel de clúster y de espacio de nombres. Esta función proporciona una mayor seguridad, dado que los usuarios solo tienen acceso a determinados recursos. Te recomendamos que inhabilites el antiguo control de acceso basado en atributos (ABAC).

Para solucionar este problema, siga estos pasos:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
Seleccione el clúster que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.

Si la configuración del clúster ha cambiado recientemente, puede que el botón Editar esté inhabilitado. Si no puedes modificar la configuración del clúster, espera unos minutos y vuelve a intentarlo.
En la lista desplegable Autorización antigua, selecciona Inhabilitada.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Legacy metadata enabled`

Nombre de la categoría en la API: LEGACY_METADATA_ENABLED

Los metadatos antiguos están habilitados en los clústeres de GKE.

El servidor de metadatos de la instancia de Compute Engine expone los endpoints /0.1/ y /v1beta1/ antiguos, que no implementan obligatoriamente encabezados de consultas de metadatos. Se trata de una función de las APIs /v1/ que dificulta que los posibles atacantes obtengan metadatos de la instancia. A menos que sea necesario, te recomendamos que inhabilites estas APIs antiguas /0.1/ y /v1beta1/.

Para obtener más información, consulta el artículo sobre cómo inhabilitar y cambiar de las APIs de metadatos antiguos.

Para solucionar este problema, siga estos pasos:

Solo puedes inhabilitar APIs de metadatos antiguas cuando creas un clúster o añades un grupo de nodos a uno de tus clústeres. Para actualizar un clúster y inhabilitar las APIs de metadatos antiguas, consulta Migrar cargas de trabajo a diferentes tipos de máquinas.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Legacy network`

Nombre de la categoría en la API: LEGACY_NETWORK

Hay una red antigua en un proyecto.

No se recomienda usar redes antiguas porque no admiten muchas de las nuevas funciones de seguridad. Google Cloud En su lugar, utiliza redes de VPC. Para obtener más información, consulta el artículo sobre redes antiguas.

Para solucionar este problema, siga estos pasos:

Ve a la página Redes de VPC de la consola de Google Cloud.Google Cloud

Ir a redes de VPC
Para crear una red distinta de las antiguas, haz clic en Crear red.
Vuelve a la página Redes de VPC.
En la lista de redes, haz clic en legacy_network.
En la página Detalles de la red de VPC, haz clic en Eliminar red de VPC.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Load balancer logging disabled`

Nombre de la categoría en la API: LOAD_BALANCER_LOGGING_DISABLED

Está inhabilitado el almacenamiento de registros del servicio de backend de un balanceador de carga.

Si habilitas el registro de un balanceador de carga, puedes ver el tráfico de red HTTP(S) de tus aplicaciones web. Para obtener más información, consulta Balanceador de carga.

Para solucionar este problema, siga estos pasos:

Ve a la página Balanceo de carga de Cloud en la consola deGoogle Cloud .

Ir a Cloud Load Balancing
Haz clic en el nombre de tu balanceador de carga.
Haz clic en Editar.
Haz clic en Configuración de backend.
En la página Configuración de backend, haz clic en Editar.
En la sección Almacenamiento de registros, selecciona Activar el almacenamiento de registros y elige la frecuencia de muestreo óptima para tu proyecto.
Para terminar de editar el servicio de backend, haz clic en Actualizar.
Para terminar de editar el balanceador de carga, haz clic en Actualizar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Locked retention policy not set`

Nombre de la categoría en la API: LOCKED_RETENTION_POLICY_NOT_SET

No se ha definido una política de retención bloqueada para los registros.

Si la política de retención está bloqueada, se impide que los registros se sobrescriban y que el contenedor de registros se elimine. Para obtener más información, consulta Bucket Lock.

Para solucionar este problema, siga estos pasos:

Ve a la página Navegador de almacenamiento de la Google Cloud consola.

Ir al navegador de almacenamiento
Selecciona el segmento que aparece en el resultado de Security Health Analytics.
En la página Detalles del segmento, haga clic en la pestaña Retención.
Si no se ha definido ninguna política de retención, haga clic en Definir política de retención.
Introduce un periodo de retención.
Haz clic en Guardar. La política de conservación se muestra en la pestaña Conservación.
Haz clic en Bloquear para asegurarte de que el periodo de conservación no se acorte ni se elimine.
Precaución: Bloquear una política de retención es una acción irreversible que solo se puede deshacer eliminando todo el segmento. Para obtener más información, consulta el artículo sobre Bucket Lock.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Log not exported`

Nombre de la categoría en la API: LOG_NOT_EXPORTED

Un recurso no tiene configurado un sumidero de registros adecuado.

Cloud Logging te permite identificar rápidamente la causa principal de los problemas que surgen en los sistemas y las aplicaciones. No obstante, la mayoría de los registros solo se conservan durante 30 días de forma predeterminada. Exporta copias de todas las entradas de registro para ampliar el periodo de almacenamiento. Para obtener más información, consulta el artículo Descripción general de las exportaciones de registros.

Para solucionar este problema, siga estos pasos:

Ve a la página Enrutador de registros de la consola de Google Cloud Google Cloud.

Ir al enrutador de registros
Haz clic en Crear sumidero.
Para exportar todos los registros, deja vacíos ambos filtros.
Haz clic en Crear sumidero.
Nota: Si sigues estas instrucciones, creas un sumidero a nivel de proyecto. Los sumideros también se pueden crear a nivel de carpeta o de organización. Para obtener más información, consulta el artículo sobre cómo exportar registros con la consola Google Cloud .

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Master authorized networks disabled`

Nombre de la categoría en la API: MASTER_AUTHORIZED_NETWORKS_DISABLED

Las redes autorizadas del plano de control no están habilitadas en los clústeres de GKE.

Las redes autorizadas del plano de control refuerzan la seguridad del clúster de contenedores bloqueando el acceso de las direcciones IP especificadas al plano de control del clúster. Para obtener más información, consulta Añadir redes autorizadas para acceder al plano de control.

Para solucionar este problema, siga estos pasos:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
Seleccione el clúster que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.

Si la configuración del clúster ha cambiado recientemente, puede que el botón Editar esté inhabilitado. Si no puedes modificar la configuración del clúster, espera unos minutos y vuelve a intentarlo.
En la lista desplegable Redes autorizadas del plano de control, selecciona Habilitadas.
Haz clic en Añadir red autorizada.
Especifica las redes autorizadas que quieras usar.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`MFA not enforced`

Nombre de la categoría en la API: MFA_NOT_ENFORCED

Este hallazgo no está disponible para las activaciones a nivel de proyecto.

La autenticación multifactor, en particular la verificación en dos pasos, está inhabilitada para algunos usuarios de tu organización.

La autenticación multifactor se usa para proteger las cuentas frente a accesos no autorizados y es la herramienta más importante para proteger tu organización frente a la vulneración de credenciales de inicio de sesión. Para obtener más información, consulta el artículo Proteger una empresa mediante la verificación en dos pasos.

Para solucionar este problema, siga estos pasos:

Ve a la página Consola de administración en la Google Cloud consola.

Ir a la consola de administración
Selecciona que la verificación en dos pasos sea obligatoria para todas las unidades organizativas.

Suprimir resultados de este tipo

Para suprimir los resultados de este tipo, define una regla de silencio que los silencie automáticamente en el futuro. Para obtener más información, consulta Silenciar resultados en Security Command Center.

Aunque no es la forma recomendada de suprimir resultados, también puedes añadir marcas de seguridad específicas a los recursos para que los detectores de Security Health Analytics no creen resultados de seguridad para esos recursos.

Para evitar que se active de nuevo, añade la marca de seguridad allow_mfa_not_enforced con el valor true al recurso.
Para ignorar posibles infracciones en unidades organizativas específicas, añade la marca de seguridad excluded_orgunits al recurso con una lista separada por comas de las rutas de las unidades organizativas en el campo value. Por ejemplo, excluded_orgunits:/people/vendors/vendorA,/people/contractors/contractorA.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Network not monitored`

Nombre de la categoría en la API: NETWORK_NOT_MONITORED

No se han configurado métricas de registro ni alertas para monitorizar los cambios en la red de VPC.

Para detectar las modificaciones incorrectas o no autorizadas en la configuración de la red, monitoriza los cambios en la red de VPC. Para obtener más información, consulta el artículo Información general sobre las métricas basadas en registros.

Para solucionar este problema, siga estos pasos:

Crear métrica

Ve a la página Métricas basadas en registros de la consola de Google Cloud .

Ir a Métricas basadas en registros
Haz clic en Crear métrica.
En Tipo de métrica, selecciona Contador.
En Detalles:
1. Especifica un nombre para la métrica de registro.
2. Añade una descripción.
3. Asigna a Unidades el valor 1.

En Selección de filtro, copia el texto siguiente y pégalo en el cuadro Crear filtro en lugar del texto que haya, si es preciso:

  resource.type="gce_network"
  AND (protoPayload.methodName:"compute.networks.insert"
  OR protoPayload.methodName:"compute.networks.patch"
  OR protoPayload.methodName:"compute.networks.delete"
  OR protoPayload.methodName:"compute.networks.removePeering"
  OR protoPayload.methodName:"compute.networks.addPeering")

Haz clic en Crear métrica. Aparece una confirmación.

Crear política de alertas

En la Google Cloud consola, ve a la página Métricas basadas en registros:
Ve a Métricas basadas en registros.

Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Registro.
En la sección Métricas definidas por el usuario, selecciona la métrica que has creado en la sección anterior.
Haz clic en Más y, a continuación, en Crear alerta a partir de la métrica.

Se abrirá el cuadro de diálogo Nueva condición con las opciones de métrica y transformación de datos rellenadas automáticamente.
Haz clic en Siguiente.
1. Revisa los ajustes que se han rellenado automáticamente. Puede que quieras modificar el valor del umbral.
2. Haz clic en Nombre de la condición y escribe el nombre de la condición.
Haz clic en Siguiente.
Para añadir notificaciones a tu política de alertas, haz clic en Canales de notificación. En el cuadro de diálogo, selecciona uno o más canales de notificación y, luego, haz clic en Aceptar.

Para recibir notificaciones cuando se abran y se cierren incidentes, marca la opción Notificar cuando se cierre un incidente. De forma predeterminada, las notificaciones solo se envían cuando se abren incidentes.
Opcional: Actualiza la duración del cierre automático de incidentes. Este campo determina cuándo cierra Monitoring los incidentes si no hay datos de métricas.
Opcional: Haz clic en Documentación y añade la información que quieras incluir en las notificaciones.
Haz clic en Nombre de la alerta y escribe el que quieras asignar a la política de alertas.
Haz clic enCreate Policy (Crear política).

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Network policy disabled`

Nombre de la categoría en la API: NETWORK_POLICY_DISABLED

La política de red está inhabilitada en los clústeres de GKE.

De forma predeterminada, la comunicación entre los pods es de tipo abierto. Las comunicaciones abiertas permiten a los pods conectarse directamente en todos los nodos, con o sin traducción de direcciones de red. Un recurso NetworkPolicy es como un cortafuegos a nivel de pod que restringe las conexiones entre pods, a menos que el recurso NetworkPolicy permita explícitamente la conexión. Consulta cómo definir una política de red.

Para solucionar este problema, siga estos pasos:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
Haga clic en el nombre del clúster que aparece en el resultado de Security Health Analytics.
En Redes, en la fila Política de red de Calico Kubernetes, haz clic en Editar.

Si la configuración del clúster ha cambiado recientemente, puede que el botón Editar esté inhabilitado. Si no puedes modificar la configuración del clúster, espera unos minutos y vuelve a intentarlo.
En el cuadro de diálogo, selecciona Habilitar política de red de Calico Kubernetes para el plano de control y Habilitar política de red de Calico Kubernetes para los nodos.
Haz clic en Guardar cambios.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Nodepool boot CMEK disabled`

Nombre de la categoría en la API: NODEPOOL_BOOT_CMEK_DISABLED

Los discos de arranque de este grupo de nodos no están cifrados con claves de cifrado gestionadas por el cliente (CMEK). CMEK permite al usuario configurar las claves de cifrado predeterminadas de los discos de arranque de los grupos de nodos.

Para solucionar este problema, siga estos pasos:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
En la lista de clústeres, haz clic en el nombre del clúster de la detección.
Haz clic en la pestaña Nodos.
En cada grupo de nodos default-pool, haz clic en Eliminar.
Cuando se te pida que confirmes la acción, haz clic en Eliminar.
Para crear grupos de nodos con CMEK, consulta Usar claves de cifrado gestionadas por el cliente (CMEK). Las CMEK generan costes adicionales relacionados con Cloud KMS.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Nodepool secure boot disabled`

Nombre de la categoría en la API: NODEPOOL_SECURE_BOOT_DISABLED

El arranque seguro está inhabilitado en un clúster de GKE.

Habilita el arranque seguro en los nodos de GKE blindados para verificar las firmas digitales de los componentes de arranque de los nodos. Para obtener más información, consulta Arranque seguro.

Para solucionar este problema, siga estos pasos:

Una vez aprovisionado un grupo de nodos, no se puede actualizar para habilitar el arranque seguro. Debes crear otro grupo de nodos con el arranque seguro habilitado.

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
Haga clic en el nombre del clúster en el resultado.
Haz clic en Add Node Pool (Añadir grupo de nodos).
En el menú Grupos de nodos, haz lo siguiente:
1. Haz clic en el nombre del nuevo grupo de nodos para que se muestre la pestaña.
2. Selecciona Seguridad y, luego, en Opciones blindadas, marca Habilitar arranque seguro.
3. Haz clic en Crear.
4. Para migrar tus cargas de trabajo de los grupos de nodos no conformes a los nuevos, consulta el artículo Migrar cargas de trabajo a diferentes tipos de máquinas.
5. Después de trasladar tus cargas de trabajo, elimina el grupo de nodos original no conforme.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Non org IAM member`

Nombre de la categoría en la API: NON_ORG_IAM_MEMBER

Un usuario ajeno a tu organización o proyecto tiene permisos de gestión de identidades y accesos en un proyecto o una organización. Más información sobre los permisos de gestión de identidades y accesos

Para solucionar este problema, siga estos pasos:

Ve a la página Gestión de identidades y accesos de la Google Cloud consola.

Ir a IAM
Marca la casilla situada junto a los usuarios ajenos a tu organización o proyecto.
Haz clic en Quitar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Object versioning disabled`

Nombre de la categoría en la API: OBJECT_VERSIONING_DISABLED

La gestión de versiones de objetos no está habilitada en un segmento de almacenamiento en el que se han configurado receptores.

Cloud Storage ofrece la función de gestión de versiones de objetos para que se puedan obtener objetos eliminados o sobrescritos. Habilita el control de versiones de objetos para proteger tus datos de Cloud Storage en caso de que se sobrescriban o se eliminen por accidente. Consulte cómo habilitar la gestión de versiones de objetos.

Para solucionar este problema, usa la marca --versioning en un comando gcloud storage buckets update con el valor adecuado:

    gcloud storage buckets update gs://finding.assetDisplayName --versioning

Sustituye finding.assetDisplayName por el nombre del segmento correspondiente.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open Cassandra port`

Nombre de la categoría en la API: OPEN_CASSANDRA_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos de Cassandra podrían dejar expuestos tus servicios de Cassandra a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio de Cassandra son:

TCP - 7000, 7001, 7199, 8888, 9042, 9160, 61620, 61621

Esta detección se genera para las reglas de cortafuegos vulnerables, aunque las inhabilite intencionadamente. Las detecciones activas de reglas de cortafuegos inhabilitadas te alertan de configuraciones no seguras que permitirán tráfico no deseado si se habilitan.

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open ciscosecure websm port`

Nombre de la categoría en la API: OPEN_CISCOSECURE_WEBSM_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos de Cisco Secure/WebSM podrían dejar expuestos tus servicios de Cisco Secure/WebSM a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio de CiscoSecure y WebSM son los siguientes:

TCP - 9090

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open directory services port`

Nombre de la categoría en la API: OPEN_DIRECTORY_SERVICES_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos de directorio podrían dejar expuestos tus servicios de directorio a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio de Directory son:

TCP - 445
UDP - 445

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open DNS port`

Nombre de la categoría en la API: OPEN_DNS_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos DNS podrían dejar expuestos tus servicios DNS a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de los servicios de DNS son:

TCP - 53
UDP - 53

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open Elasticsearch port`

Nombre de la categoría en la API: OPEN_ELASTICSEARCH_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos de Elasticsearch podrían dejar expuestos tus servicios de Elasticsearch a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio de Elasticsearch son:

TCP - 9200, 9300

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open firewall`

Nombre de la categoría en la API: OPEN_FIREWALL

Las reglas de cortafuegos que permiten conexiones desde todas las direcciones IP, como 0.0.0.0/0, o desde todos los puertos pueden dejar los recursos expuestos de forma innecesaria a ataques procedentes de fuentes no deseadas. Elimina estas reglas o limítalas de forma explícita a los intervalos de IPs de origen o puertos que te interesan. Por ejemplo, en las aplicaciones que se van a hacer públicas, considera la posibilidad de restringir los puertos permitidos a los que necesite la aplicación, como el 80 y el 443. Si tu aplicación necesita permitir conexiones desde todas las direcciones IP o puertos, considera la posibilidad de añadir el recurso a una lista de permitidos. Más información sobre cómo actualizar reglas de cortafuegos

Para solucionar este problema, siga estos pasos:

Ve a la página Reglas de cortafuegos de la Google Cloud consola.

Ir a reglas de cortafuegos
Haga clic en la regla de firewall que se indica en el resultado de Security Health Analytics y, a continuación, haga clic en Editar.
En Intervalos de IP de origen, edita los valores de IP para restringir el intervalo de IPs que se admiten.
En Protocolos y puertos, selecciona Protocolos y puertos especificados, selecciona los protocolos permitidos e introduce los puertos que se pueden usar.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open FTP port`

Nombre de la categoría en la API: OPEN_FTP_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos FTP podrían dejar expuestos tus servicios FTP a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de los servicios de FTP son:

TCP - 21

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open group IAM member`

Nombre de la categoría en la API: OPEN_GROUP_IAM_MEMBER

Una o varias cuentas principales que tienen acceso a una organización, un proyecto o una carpeta son cuentas de Grupos de Google a las que se puede unir sin aprobación.

Los clientes deGoogle Cloud pueden usar Grupos de Google para gestionar los roles y los permisos de los miembros de sus organizaciones, o bien aplicar políticas de acceso a colecciones de usuarios. En lugar de asignar roles directamente a los miembros, los administradores pueden asignar roles y permisos a grupos de Google y, a continuación, añadir miembros a grupos específicos. Los miembros de un grupo heredan todos los roles y permisos del grupo, lo que les permite acceder a recursos y servicios específicos.

Si se usa una cuenta de Grupos de Google abierta como entidad principal en un enlace de gestión de identidades y accesos, cualquier persona puede heredar el rol asociado simplemente uniéndose al grupo de forma directa o indirecta (a través de un subgrupo). Te recomendamos que revoques los roles de los grupos abiertos o que restrinjas el acceso a esos grupos.

Para solucionar este problema, siga uno de los procedimientos que se indican a continuación.

Quitar el grupo de la política de gestión de identidades y accesos

Ve a la página Gestión de identidades y accesos de la Google Cloud consola.

Gestión de identidades y accesos de Go
Si es necesario, selecciona el proyecto, la carpeta o la organización en el resultado.
Revoca el rol de cada grupo abierto identificado en el resultado.

Restringir el acceso a los grupos abiertos

Inicia sesión en Grupos de Google.
Actualiza la configuración de cada grupo abierto y de sus subgrupos para especificar quién puede unirse al grupo y quién debe aprobarlos.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open HTTP port`

Nombre de la categoría en la API: OPEN_HTTP_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos HTTP podrían dejar expuestos tus servicios HTTP a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio HTTP son:

TCP - 80

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open LDAP port`

Nombre de la categoría en la API: OPEN_LDAP_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos LDAP podrían dejar expuestos tus servicios LDAP a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio LDAP son los siguientes:

TCP - 389, 636
UDP - 389

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open Memcached port`

Nombre de la categoría en la API: OPEN_MEMCACHED_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos de Memcached podrían dejar expuestos tus servicios de Memcached a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio de Memcached son:

TCP - 11211, 11214, 11215
UDP - 11211, 11214, 11215

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open MongoDB port`

Nombre de la categoría en la API: OPEN_MONGODB_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos de MongoDB podrían dejar expuestos tus servicios de MongoDB a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio de MongoDB son:

TCP - 27017, 27018, 27019

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open MySQL port`

Nombre de la categoría en la API: OPEN_MYSQL_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos de MySQL podrían dejar expuestos tus servicios de MySQL a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio de MySQL son:

TCP - 3306

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open NetBIOS port`

Nombre de la categoría en la API: `OPEN_NETBIOS_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos NetBIOS podrían dejar expuestos tus servicios NetBIOS a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio de NetBIOS son:

TCP - 137, 138, 139
UDP - 137, 138, 139

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open OracleDB port`

Nombre de la categoría en la API: OPEN_ORACLEDB_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos de OracleDB podrían dejar expuestos tus servicios de OracleDB a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de los servicios de OracleDB son:

TCP - 1521, 2483, 2484
UDP - 2483, 2484

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open POP3 port`

Nombre de la categoría en la API: OPEN_POP3_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos POP3 podrían dejar expuestos tus servicios POP3 a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio POP3 son:

TCP - 110

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open PostgreSQL port`

Nombre de la categoría en la API: OPEN_POSTGRESQL_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos de PostgreSQL podrían dejar expuestos tus servicios de PostgreSQL a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio de PostgreSQL son los siguientes:

TCP - 5432
UDP - 5432

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open RDP port`

Nombre de la categoría en la API: OPEN_RDP_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos RDP podrían dejar expuestos tus servicios RDP a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio RDP son:

TCP - 3389
UDP - 3389

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open Redis port`

Nombre de la categoría en la API: OPEN_REDIS_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos de Redis podrían dejar expuestos tus servicios de Redis a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio de Redis son:

TCP - 6379

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open SMTP port`

Nombre de la categoría en la API: OPEN_SMTP_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos SMTP podrían dejar expuestos tus servicios SMTP a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio SMTP son:

TCP - 25

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open SSH port`

Nombre de la categoría en la API: OPEN_SSH_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos SSH podrían dejar expuestos tus servicios SSH a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio SSH son:

SCTP - 22
TCP - 22

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Open Telnet port`

Nombre de la categoría en la API: OPEN_TELNET_PORT

Las reglas de cortafuegos que permiten que cualquier dirección IP se conecte a los puertos Telnet podrían dejar expuestos tus servicios Telnet a los atacantes. Para obtener más información, consulta la descripción general de las reglas de cortafuegos de VPC.

Los puertos de servicio Telnet son:

TCP - 23

Para solucionar este problema, siga estos pasos:

Ve a la página Cortafuegos de la Google Cloud consola.

Ir a Cortafuegos
En la lista de reglas de cortafuegos, haga clic en el nombre de la regla de cortafuegos en la detección.
Haz clic en Editar.
En Intervalos de IP de origen, elimina 0.0.0.0/0.
Añade las direcciones IP o los intervalos de IP concretos a los que quieres permitir la conexión a la instancia.
Añade los protocolos y puertos concretos que quieres abrir en tu instancia.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Org policy Confidential VM policy`

Nombre de la categoría en la API: ORG_POLICY_CONFIDENTIAL_VM_POLICY

Un recurso de Compute Engine no cumple la política de la organización constraints/compute.restrictNonConfidentialComputing. Para obtener más información sobre esta restricción de política de organización, consulte Aplicar restricciones de políticas de organización.

Tu organización exige que esta VM tenga habilitado el servicio de VMs confidenciales. Las VMs que no tengan habilitado este servicio no usarán el encriptado de memoria en tiempo de ejecución, de modo que quedarán expuestas a ataques de memoria en tiempo de ejecución.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de VM de la Google Cloud consola.

Ir a instancias de VM
En la lista de instancias, haz clic en el nombre de la instancia del hallazgo.
Si la VM no exige el servicio de VMs confidenciales, muévela a otra carpeta o a otro proyecto.
Si la VM requiere VMs confidenciales, haz clic en Eliminar.
Para crear una instancia con Confidential VMs habilitado, consulta la guía de inicio rápido para crear una instancia de Confidential VMs.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Org policy location restriction`

Nombre de la categoría en la API: ORG_POLICY_LOCATION_RESTRICTION

La restricción gcp.resourceLocations de la política de la organización te permite restringir la creación de recursos nuevos a las regiones de Cloud que selecciones. Para obtener más información, consulta Restringir ubicaciones de recursos.

Para solucionar este problema, siga estos pasos:

El detector ORG_POLICY_LOCATION_RESTRICTION abarca muchos tipos de recursos y las instrucciones de corrección son diferentes para cada recurso. El enfoque general para corregir las infracciones de ubicación incluye lo siguiente:

Copia, mueve o crea una copia de seguridad del recurso fuera de la región o de sus datos en un recurso que esté en la región. Consulta la documentación de cada servicio para obtener instrucciones sobre cómo mover recursos.
Elimina el recurso original de fuera de la región o sus datos.

Este enfoque no es posible para todos los tipos de recursos. Para obtener más información, consulta las recomendaciones personalizadas que se proporcionan en la detección.

Consideraciones adicionales

Cuando corrija este problema, tenga en cuenta lo siguiente.

Recursos gestionados

En ocasiones, los ciclos de vida de los recursos se gestionan y controlan mediante otros recursos. Por ejemplo, un grupo de instancias gestionado de Compute Engine crea y destruye instancias de Compute Engine de acuerdo con la política de autoescalado del grupo de instancias. Si los recursos gestionados y los recursos de gestión están incluidos en el ámbito de la aplicación de la ubicación, es posible que se marquen como infractores de la política de la organización. Para garantizar la estabilidad operativa, las correcciones de los resultados de los recursos gestionados deben realizarse en el recurso de gestión.

Recursos en uso

Algunos recursos se utilizan en otros recursos. Por ejemplo, un disco de Compute Engine conectado a una instancia de Compute Engine en ejecución se considera en uso por la instancia. Si el recurso en uso infringe la política de organización de la ubicación, debes asegurarte de que no esté en uso antes de solucionar la infracción de la ubicación.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`OS login disabled`

Nombre de la categoría en la API: OS_LOGIN_DISABLED

OS Login está inhabilitado en las instancias de Compute Engine de este proyecto.

Para solucionar este problema, siga estos pasos:

Ve a la página Metadatos de la Google Cloud consola.

Ir a Metadatos
Haz clic en Editar y, después, en Añadir elemento.
Añade un elemento que tenga la clave enable-oslogin y el valor VERDADERO.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Over privileged account`

Nombre de la categoría en la API: OVER_PRIVILEGED_ACCOUNT

Un nodo de GKE está usando el nodo del servicio predeterminado de Compute Engine, que proporciona acceso general de forma predeterminada y puede que tenga demasiados privilegios para ejecutar tu clúster de GKE.

Para solucionar este problema, siga estos pasos:

Sigue las instrucciones para usar cuentas de servicio de Google con el número mínimo de privilegios necesarios.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Over privileged scopes`

Nombre de la categoría en la API: OVER_PRIVILEGED_SCOPES

Una cuenta de servicio de nodo tiene permisos de acceso amplios.

Los permisos de acceso son el método antiguo de especificar los permisos de tu instancia. Para reducir la posibilidad de que se produzca una apropiación de privilegios durante un ataque, crea y usa una cuenta de servicio con el número mínimo de privilegios necesarios para ejecutar tu clúster de GKE.

Para solucionar este problema, sigue las instrucciones para usar cuentas de servicio de Google con el número mínimo de privilegios necesarios.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Over privileged service account user`

Nombre de la categoría en la API: OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

Un usuario tiene los roles iam.serviceAccountUser o iam.serviceAccountTokenCreator a nivel de proyecto, carpeta u organización, en lugar de tenerlos en una cuenta de servicio específica.

Si asignas esos roles a un usuario en un proyecto, una carpeta o una organización, le das acceso a todas las cuentas de servicio que ya hay y que se creen en ese ámbito. Esta situación puede provocar una apropiación de privilegios no deseada. Para obtener más información, consulta Permisos de cuentas de servicio.

Para solucionar este problema, siga estos pasos:

Ve a la página Gestión de identidades y accesos de la Google Cloud consola.

Ir a la página de gestión de identidades y accesos
Si es necesario, selecciona el proyecto, la carpeta o la organización en el resultado.
En cada principal asignado roles/iam.serviceAccountUser o roles/iam.serviceAccountTokenCreator, haz lo siguiente:
1. Haz clic en Editar.
2. En el panel Editar permisos, junto a los roles, haz clic en Eliminar.
3. Haz clic en Guardar.
Sigue esta guía para asignar a usuarios concretos permiso para actuar en nombre de una sola cuenta de servicio. Sigue los pasos con cada una de las cuentas de servicio en nombre de las cuales quieres dejar que actúen los usuarios.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Owner not monitored`

Nombre de la categoría en la API: OWNER_NOT_MONITORED

Las métricas de registro y las alertas no están configuradas para monitorizar las asignaciones o los cambios de la propiedad del proyecto.

El rol Propietario de IAM tiene el nivel de privilegios más alto en los proyectos. Para proteger tus recursos, configura alertas que te envíen notificaciones cuando se añadan o eliminen propietarios. Para obtener más información, consulta el artículo Información general sobre las métricas basadas en registros.

Para solucionar este problema, siga estos pasos:

Crear métrica

Ve a la página Métricas basadas en registros de la consola de Google Cloud .

Ir a Métricas basadas en registros
Haz clic en Crear métrica.
En Tipo de métrica, selecciona Contador.
En Detalles:
1. Especifica un nombre para la métrica de registro.
2. Añade una descripción.
3. Asigna a Unidades el valor 1.

En Selección de filtro, copia el texto siguiente y pégalo en el cuadro Crear filtro en lugar del texto que haya, si es preciso:

  (protoPayload.serviceName="cloudresourcemanager.googleapis.com")
  AND (ProjectOwnership OR projectOwnerInvitee)
  OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="REMOVE"
  AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
  OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="ADD"
  AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")

Haz clic en Crear métrica. Aparece una confirmación.

Crear política de alertas

En la Google Cloud consola, ve a la página Métricas basadas en registros:
Ve a Métricas basadas en registros.

Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Registro.
En la sección Métricas definidas por el usuario, selecciona la métrica que has creado en la sección anterior.
Haz clic en Más y, a continuación, en Crear alerta a partir de la métrica.

Se abrirá el cuadro de diálogo Nueva condición con las opciones de métrica y transformación de datos rellenadas automáticamente.
Haz clic en Siguiente.
1. Revisa los ajustes que se han rellenado automáticamente. Puede que quieras modificar el valor del umbral.
2. Haz clic en Nombre de la condición y escribe el nombre de la condición.
Haz clic en Siguiente.
Para añadir notificaciones a tu política de alertas, haz clic en Canales de notificación. En el cuadro de diálogo, selecciona uno o más canales de notificación y, luego, haz clic en Aceptar.

Para recibir notificaciones cuando se abran y se cierren incidentes, marca la opción Notificar cuando se cierre un incidente. De forma predeterminada, las notificaciones solo se envían cuando se abren incidentes.
Opcional: Actualiza la duración del cierre automático de incidentes. Este campo determina cuándo cierra Monitoring los incidentes si no hay datos de métricas.
Opcional: Haz clic en Documentación y añade la información que quieras incluir en las notificaciones.
Haz clic en Nombre de la alerta y escribe el que quieras asignar a la política de alertas.
Haz clic enCreate Policy (Crear política).

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Pod security policy disabled`

Nombre de la categoría en la API: POD_SECURITY_POLICY_DISABLED

PodSecurityPolicy está inhabilitado en un clúster de GKE.

Un PodSecurityPolicy es un recurso controlador de admisión que valida las solicitudes para crear y actualizar pods en un clúster. Los clústeres no aceptarán pods que no cumplan las condiciones definidas en PodSecurityPolicy.

Para solucionar este problema, define y autoriza PodSecurityPolicies, y habilita el controlador PodSecurityPolicy. Para obtener instrucciones, consulta Usar PodSecurityPolicies.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Primitive roles used`

Nombre de la categoría en la API: PRIMITIVE_ROLES_USED

Un usuario tiene uno de los siguientes roles básicos de gestión de identidades y accesos: roles/owner, roles/editor o roles/viewer. Estos roles son demasiado permisivos y no se deben usar. En su lugar, deben asignarse solo por proyecto.

Para obtener más información, consulta el artículo sobre la descripción de los roles.

Para solucionar este problema, siga estos pasos:

Ve a la página de la política de gestión de identidades y accesos en la Google Cloud consola.

Ir a la política de gestión de identidades y accesos
En el caso de cada usuario al que se le haya asignado un rol primitivo, es conveniente que uses roles más granulares.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Private cluster disabled`

Nombre de la categoría en la API: PRIVATE_CLUSTER_DISABLED

Un clúster de GKE tiene inhabilitado el clúster privado.

Los clústeres privados solo permiten que los nodos tengan direcciones IP privadas Esta función limita el acceso de salida a Internet de los nodos. Si los nodos del clúster no tienen una dirección IP pública, no se pueden ver ni descubrir en la red pública de Internet. Puedes dirigir el tráfico hacia ellos con un balanceador de carga interno. Para obtener más información, consulta Clústeres privados.

No puedes hacer privado un clúster que ya existe. Para solucionar este problema, cree un clúster privado:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
Haz clic en Crear clúster.
En el menú de navegación, vaya a Clúster y seleccione Redes.
Selecciona el botón de radio Clúster privado.
En Opciones de red avanzadas, selecciona la casilla Habilitar el enrutamiento del tráfico nativo de VPC (usa IP de alias).
Haz clic en Crear.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Private Google access disabled`

Nombre de la categoría en la API: PRIVATE_GOOGLE_ACCESS_DISABLED

Hay subredes privadas sin acceso a las APIs públicas de Google.

Acceso privado de Google permite que las instancias de VM que solo tienen direcciones IP internas (privadas) lleguen a las direcciones IP públicas de las APIs y los servicios de Google.

Para obtener más información, consulta el artículo sobre cómo configurar Acceso privado de Google.

Para solucionar este problema, siga estos pasos:

Ve a la página Redes de VPC de la consola de Google Cloud.Google Cloud

Ir a redes de VPC
En la lista de redes, haz clic en el nombre de la red que quieras.
En la página Detalles de la red de VPC, haz clic en la pestaña Subredes.
En la lista de subredes, haz clic en el nombre de la subred asociada al clúster de Kubernetes de la detección.
En la página Detalles de la subred, haga clic en Editar.
En Acceso privado de Google, selecciona Activado.
Haz clic en Guardar.
Para quitar las IPs públicas (externas) de las instancias de VM cuyo tráfico externo se dirija únicamente a las APIs de Google, consulta el artículo Anular la asignación de una dirección IP externa estática.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Public bucket ACL`

Nombre de la categoría en la API: PUBLIC_BUCKET_ACL

Un segmento es público y cualquier usuario de Internet puede acceder a él.

Para obtener más información, consulta la descripción general del control de acceso.

Para solucionar este problema, siga estos pasos:

Ve a la página Navegador de almacenamiento de la Google Cloud consola.

Ir al navegador de almacenamiento
Selecciona el segmento que aparece en el resultado de Security Health Analytics.
En la página Detalles del segmento, haga clic en la pestaña Permisos.
Junto a Ver por, haz clic en Roles.
En el cuadro Filtrar, busca allUsers y allAuthenticatedUsers.
Haz clic en Eliminar para quitar todos los permisos de gestión de identidades y accesos que se hayan concedido a allUsers y a allAuthenticatedUsers.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Public Compute image`

Nombre de la categoría en la API: PUBLIC_COMPUTE_IMAGE

Una imagen de Compute Engine es pública y cualquier usuario de Internet puede acceder a ella. allUsers representa a cualquier usuario de Internet y allAuthenticatedUsers, a cualquier usuario que se autentique con una cuenta de Google. Ninguno de ellos se limita a usuarios de la organización.

Las imágenes de Compute Engine pueden contener información sensible, como claves de cifrado o software con licencia. Tal información sensible no debe ser de acceso público. Si quieres que esta imagen de Compute Engine sea pública, asegúrate de que no contenga ninguna información sensible.

Para obtener más información, consulta la descripción general del control de acceso.

Para solucionar este problema, siga estos pasos:

Ve a la página de imágenes de Compute Engine en laGoogle Cloud consola.

Ir a las imágenes de Compute Engine
Selecciona la casilla situada junto a la imagen public-image y, a continuación, haz clic en Mostrar panel de información.
En el cuadro Filtrar, busca los principales allUsers y allAuthenticatedUsers.
Despliega el rol del que quieras quitar usuarios.
Haz clic en Eliminar para quitar un usuario de ese rol.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Public dataset`

Nombre de la categoría en la API: PUBLIC_DATASET

Un conjunto de datos de BigQuery es público y accesible para cualquier persona que tenga conexión a Internet. El principal de gestión de identidades y accesos allUsers representa a cualquier usuario de Internet, y allAuthenticatedUsers, a cualquier usuario que haya iniciado sesión en un servicio de Google. Ninguno de ellos se limita a usuarios de la empresa.

Para obtener más información, consulta la sección Controlar el acceso a los conjuntos de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Explorador de BigQuery en la consola de Google Cloud .

Ir al conjunto de datos de BigQuery
En la lista de conjuntos de datos, haga clic en el nombre del conjunto de datos que se identifica en la detección. Se abrirá el panel Información del conjunto de datos.
Cerca de la parte superior del panel Información del conjunto de datos, haz clic en COMPARTIR.
En el menú desplegable, haz clic en Permisos.
En el panel Permisos del conjunto de datos, introduce allUsers y allAuthenticatedUsers, y quítales el acceso a estos principales.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Public IP address`

Nombre de la categoría en la API: PUBLIC_IP_ADDRESS

Una instancia de Compute Engine tiene una dirección IP pública.

Para reducir la superficie de ataque de tu organización, no asignes direcciones IP públicas a las VMs. Las instancias detenidas se pueden marcar con el resultado de IP pública si, por ejemplo, las interfaces de red están configuradas para asignar una IP pública efímera al inicio. Comprueba que las configuraciones de red de las instancias detenidas no incluyen el acceso externo.

Para obtener más información, consulta el artículo sobre cómo conectarse de forma segura a instancias de VM.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de VM de la Google Cloud consola.

Ve a Instancias de VM.
En la lista de instancias, marca la casilla situada junto al nombre de la instancia en la detección.
Haz clic en Editar.
En cada interfaz, ve a Interfaces de red, haz clic en Editar y elige Ninguna en IP externa.
Haz clic en Hecho y, a continuación, en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Public log bucket`

Nombre de la categoría en la API: PUBLIC_LOG_BUCKET

Este hallazgo no está disponible para las activaciones a nivel de proyecto.

Un segmento de almacenamiento es público y se usa como receptor de registros, lo que significa que cualquier usuario de Internet puede acceder a los registros almacenados en este segmento. allUsers representa a cualquier usuario de Internet y allAuthenticatedUsers, a cualquier usuario que haya iniciado sesión en un servicio de Google. Ninguno de ellos se limita a los usuarios de la organización.

Para obtener más información, consulta la descripción general del control de acceso.

Para solucionar este problema, siga estos pasos:

Ve a la página Navegador de Cloud Storage de la consola deGoogle Cloud .

Ve al navegador de Cloud Storage.
En la lista de segmentos, haga clic en el nombre del segmento indicado en la detección.
Haz clic en la pestaña Permisos.
Elimina allUsers y allAuthenticatedUsers de la lista de principales.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Public SQL instance`

Nombre de la categoría en la API: PUBLIC_SQL_INSTANCE

Tu instancia de SQL incluye 0.0.0.0/0 como red permitida. Esto significa que cualquier cliente IPv4 puede traspasar el cortafuegos de la red y tratar de iniciar sesión en la instancia, incluidos los clientes que no quieres permitir. Aun así, los clientes necesitan credenciales válidas para iniciar sesión en la instancia.

Para obtener más información, consulta Autorizar con redes autorizadas.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de la Google Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En el panel de navegación, haz clic en Conexiones.
En Redes autorizadas, elimina 0.0.0.0/0 y añade las direcciones IP o los intervalos de direcciones IP concretos que quieras que puedan conectarse a la instancia.
Haz clic en Hecho y, a continuación, en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Pubsub CMEK disabled`

Nombre de la categoría en la API: PUBSUB_CMEK_DISABLED

Un tema de Pub/Sub no está cifrado con claves de cifrado gestionadas por el cliente (CMEK).

Con las CMEK, las claves que creas y gestionas en Cloud KMS cifran las claves que usa Google para cifrar tus datos, lo que te da más control sobre el acceso a tus datos.

Para solucionar este problema, elimina el tema y crea uno nuevo:

Ve a la página Temas de Pub/Sub en la Google Cloud consola.

Ir a Temas
Si es necesario, selecciona el proyecto que contiene el tema de Pub/Sub.
Marca la casilla situada junto al tema que aparece en el resultado y, a continuación, haz clic en Eliminar.
Para crear un tema de Pub/Sub con CMEK habilitado, consulta Usar claves de cifrado gestionadas por el cliente. Las CMEK generan costes adicionales relacionados con Cloud KMS.
Publica resultados u otros datos en el tema de Pub/Sub habilitado con CMEK.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Route not monitored`

Nombre de la categoría en la API: ROUTE_NOT_MONITORED

No se han configurado métricas de registro ni alertas para monitorizar los cambios en las rutas de redes de VPC.

LasGoogle Cloud rutas son destinos y saltos que definen la ruta que sigue el tráfico de red desde una instancia de VM hasta una IP de destino. Si monitorizas los cambios que se hacen en las tablas de las rutas, puedes asegurarte de que todo el tráfico de VPC discurra por una ruta prevista.

Para obtener más información, consulta el artículo Información general sobre las métricas basadas en registros.

Para solucionar este problema, siga estos pasos:

Crear métrica

Ve a la página Métricas basadas en registros de la consola de Google Cloud .

Ir a Métricas basadas en registros
Haz clic en Crear métrica.
En Tipo de métrica, selecciona Contador.
En Detalles:
1. Especifica un nombre para la métrica de registro.
2. Añade una descripción.
3. Asigna a Unidades el valor 1.

En Selección de filtro, copia el texto siguiente y pégalo en el cuadro Crear filtro en lugar del texto que haya, si es preciso:

  resource.type="gce_route"
  AND (protoPayload.methodName:"compute.routes.delete"
  OR protoPayload.methodName:"compute.routes.insert")

Haz clic en Crear métrica. Aparece una confirmación.

Crear política de alertas

En la Google Cloud consola, ve a la página Métricas basadas en registros:
Ve a Métricas basadas en registros.

Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Registro.
En la sección Métricas definidas por el usuario, selecciona la métrica que has creado en la sección anterior.
Haz clic en Más y, a continuación, en Crear alerta a partir de la métrica.

Se abrirá el cuadro de diálogo Nueva condición con las opciones de métrica y transformación de datos rellenadas automáticamente.
Haz clic en Siguiente.
1. Revisa los ajustes que se han rellenado automáticamente. Puede que quieras modificar el valor del umbral.
2. Haz clic en Nombre de la condición y escribe el nombre de la condición.
Haz clic en Siguiente.
Para añadir notificaciones a tu política de alertas, haz clic en Canales de notificación. En el cuadro de diálogo, selecciona uno o más canales de notificación y, luego, haz clic en Aceptar.

Para recibir notificaciones cuando se abran y se cierren incidentes, marca la opción Notificar cuando se cierre un incidente. De forma predeterminada, las notificaciones solo se envían cuando se abren incidentes.
Opcional: Actualiza la duración del cierre automático de incidentes. Este campo determina cuándo cierra Monitoring los incidentes si no hay datos de métricas.
Opcional: Haz clic en Documentación y añade la información que quieras incluir en las notificaciones.
Haz clic en Nombre de la alerta y escribe el que quieras asignar a la política de alertas.
Haz clic enCreate Policy (Crear política).

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Redis role used on org`

Nombre de la categoría en la API: REDIS_ROLE_USED_ON_ORG

Este hallazgo no está disponible para las activaciones a nivel de proyecto.

Se asigna un rol de gestión de identidades y accesos de Redis a nivel de organización o de carpeta.

Los siguientes roles de gestión de identidades y accesos de Redis deben asignarse únicamente a nivel de proyecto, no a nivel de organización ni de carpeta:

roles/redis.admin
roles/redis.viewer
roles/redis.editor

Para obtener más información, consulta Control de acceso y permisos.

Para solucionar este problema, siga estos pasos:

Ve a la página de la política de gestión de identidades y accesos en la Google Cloud consola.

Ir a la política de gestión de identidades y accesos
Quita los roles de gestión de identidades y accesos de Redis indicados en la detección y añádelos a los proyectos que corresponda.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Release channel disabled`

Nombre de la categoría en la API: RELEASE_CHANNEL_DISABLED

Un clúster de GKE no está suscrito a un canal de lanzamiento.

Suscríbete a un canal de lanzamiento para automatizar las actualizaciones de versiones del clúster de GKE. Además, las funciones reducen la complejidad de la gestión de versiones al número de funciones y al nivel de estabilidad necesarios. Para obtener más información, consulta Canales de lanzamiento.

Para solucionar este problema, siga estos pasos:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
En la sección Información básica de los clústeres, haz clic en Actualizar versión principal del clúster en la fila Canal de lanzamiento.

Si la configuración del clúster ha cambiado recientemente, puede que el botón Editar esté inhabilitado. Si no puedes modificar la configuración del clúster, espera unos minutos y vuelve a intentarlo.
En el cuadro de diálogo, selecciona Canal de lanzamiento y elige el canal al que quieres suscribirte.

Si la versión del plano de control de tu clúster no se puede actualizar con un canal de lanzamiento, es posible que ese canal esté inhabilitado como opción.
Haz clic en Guardar cambios.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`RSASHA1 for signing`

Nombre de la categoría en la API: RSASHA1_FOR_SIGNING

RSA-SHA1 se usa para la firma de claves en zonas de Cloud DNS. Se debe usar un algoritmo seguro para la firma de claves.

Para solucionar este problema, sustituye el algoritmo por uno recomendado siguiendo la guía Usar opciones de firma avanzadas.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Service account key not rotated`

Nombre de la categoría en la API: SERVICE_ACCOUNT_KEY_NOT_ROTATED

Este hallazgo no está disponible para las activaciones a nivel de proyecto.

Una clave de cuenta de servicio gestionada por el usuario no se ha rotado en más de 90 días.

En general, las claves de cuentas de servicio gestionadas por el usuario deben rotarse al menos cada 90 días para que no se pueda acceder a los datos con claves antiguas que puedan haberse perdido, vulnerado o robado. Para obtener más información, consulta el artículo Rotar las claves de cuentas de servicio para reducir el riesgo de seguridad que provocan las claves filtradas.

Si has generado tú mismo el par de claves pública y privada, has almacenado la clave privada en un módulo de seguridad de hardware (HSM) y has subido la clave pública a Google, puede que no tengas que rotar la clave cada 90 días. En su lugar, puedes rotar la clave si crees que se ha podido vulnerar.

Para solucionar este problema, siga estos pasos:

Ve a la página Cuentas de servicio de la Google Cloud consola.

Ir a Cuentas de servicio
Si es necesario, selecciona el proyecto indicado en el resultado.
En la lista de cuentas de servicio, busca la cuenta de servicio que se indica en el resultado.
Haz clic en la pestaña Claves y, a continuación, busca la clave que quieras inhabilitar.
Para inhabilitar la clave, siga las instrucciones que se indican en el artículo Inhabilitar una clave de cuenta de servicio.
Opcional: Cuando te asegures de que la clave ya no se usa, elimina la clave de la cuenta de servicio.
Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Service account role separation`

Nombre de la categoría en la API: SERVICE_ACCOUNT_ROLE_SEPARATION

Este hallazgo no está disponible para las activaciones a nivel de proyecto.

Hay uno o varios principales de tu organización que tienen asignados varios permisos de cuenta de servicio. Ninguna cuenta debe tener el rol Administrador de cuentas de servicio si ya dispone de otros permisos de cuenta de servicio. Para obtener información sobre las cuentas de servicio y los roles disponibles, consulta el artículo Cuentas de servicio.

Para solucionar este problema, siga estos pasos:

Ve a la página Gestión de identidades y accesos de la Google Cloud consola.

Ir a IAM
En cada principal que se indique en la detección, haga lo siguiente:
1. Comprueba si el rol se ha heredado de una carpeta o de un recurso de la organización. Para ello, fíjate en la columna Herencia. Si la columna contiene un enlace a un recurso superior, haz clic en él para ir a la página de gestión de identidades y accesos de ese recurso.
2. Haz clic en Editar junto a un principal.
3. Para quitar permisos, haz clic en Eliminar junto a Administrador de cuentas de servicio. Si quieres quitar todos los permisos de cuentas de servicio, haz clic en Eliminar junto a los demás.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Shielded VM disabled`

Nombre de la categoría en la API: SHIELDED_VM_DISABLED

VM blindada está inhabilitada en esta instancia de Compute Engine.

Las VMs blindadas son máquinas virtuales (VMs) de Google Cloud endurecidas con un conjunto de controles de seguridad que te permiten defenderte de rootkits y bootkits. Las VMs blindadas ayudan a asegurar que el bootloader y el firmware estén firmados y verificados. Consulta más información sobre VMs blindadas.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de VM de la Google Cloud consola.

Ir a instancias de VM
Selecciona la instancia relacionada con el resultado de Security Health Analytics.
En la página Detalles de la instancia que se carga, haz clic en Detener.
Cuando la instancia se detenga, haz clic en Editar.
En la sección VM blindada, activa las opciones Activa el vTPM y Activa la monitorización de integridad para habilitar el uso de VMs blindadas.
Si no usas controladores personalizados ni sin firma, también puedes habilitar el arranque seguro.
Haz clic en Guardar. La nueva configuración aparece en la página Detalles de la instancia.
Haz clic en Iniciar para iniciar la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL CMEK disabled`

Nombre de la categoría en la API: SQL_CMEK_DISABLED

Una instancia de base de datos SQL no usa claves de cifrado gestionadas por el cliente (CMEK).

Con las CMEK, las claves que creas y gestionas en Cloud KMS cifran las claves que usa Google para cifrar tus datos, lo que te da más control sobre el acceso a tus datos. Para obtener más información, consulta las descripciones generales de CMEK de tu producto: Cloud SQL para MySQL, Cloud SQL para PostgreSQL o Cloud SQL para SQL Server. Las CMEK conllevan costes adicionales relacionados con Cloud KMS.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Eliminar.
Para crear una instancia con CMEK habilitada, sigue las instrucciones para configurar CMEK en tu producto:

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL contained database authentication`

Nombre de la categoría en la API: SQL_CONTAINED_DATABASE_AUTHENTICATION

Una instancia de base de datos de Cloud SQL para SQL Server no tiene la marca de base de datos autenticación de base de datos contenida con el valor Off.

La marca contained database authentication controla si puedes crear o montar bases de datos en contenedores en el motor de base de datos. Las bases de datos en contenedores incluyen todos los ajustes y metadatos necesarios para definirlas, y no tienen dependencias de configuración de la instancia del motor de base de datos donde se instalan.

No se recomienda habilitar esta marca por los siguientes motivos:

Los usuarios pueden conectarse a la base de datos sin autenticarse a nivel de motor de base de datos.
Cuando esas bases de datos se aíslan del motor de base de datos, es posible moverlas a otra instancia de SQL Server.

Las bases de datos en contenedores afrontan amenazas únicas que los administradores del motor de base de datos de SQL Server deben analizar y mitigar. La mayoría de las amenazas surgen con el proceso de autenticación USUARIO CON CONTRASEÑA, que traslada el límite de la autenticación del nivel del motor de base de datos al nivel de la base de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos contained database authentication el valor Off.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL cross DB ownership chaining`

Nombre de la categoría en la API: SQL_CROSS_DB_OWNERSHIP_CHAINING

Una instancia de base de datos de Cloud SQL para SQL Server no tiene la marca de base de datos cross db ownership chaining con el valor Off.

La marca cross db ownership chaining te permite controlar el encadenamiento de propiedad entre bases de datos a nivel de base de datos o permitir ese encadenamiento en todas las instrucciones de bases de datos.

No se recomienda habilitar esta marca a menos que todas las bases de datos alojadas en la instancia de SQL Server participen en el encadenamiento de propiedad entre bases de datos y seas consciente de lo que implica este ajuste para la seguridad.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos cross db ownership chaining el valor Off.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL external scripts enabled`

Nombre de la categoría en la API: SQL_EXTERNAL_SCRIPTS_ENABLED

Una instancia de base de datos de Cloud SQL para SQL Server no tiene la marca de base de datos external scripts enabled con el valor Off.

Cuando este ajuste está activado, permite que se ejecuten secuencias de comandos con determinadas extensiones de lenguaje remoto. Como esta función puede perjudicar la seguridad del sistema, se recomienda inhabilitarla.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos external scripts enabled el valor Off.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL instance not monitored`

Nombre de la categoría en la API: SQL_INSTANCE_NOT_MONITORED

Este hallazgo no está disponible para las activaciones a nivel de proyecto.

Las métricas de registro y las alertas no están configuradas para monitorizar los cambios en la configuración de la instancia de Cloud SQL.

Configurar las opciones de la instancia de SQL de forma errónea puede ocasionar riesgos de seguridad. Si inhabilitas las opciones de copia de seguridad automática y alta disponibilidad, podría verse afectada la continuidad de la actividad empresarial. Además, si no restringes las redes autorizadas, podría aumentar la exposición a redes que no son de confianza. Monitorizar los cambios realizados en la configuración de la instancia de SQL te permite detectar y corregir las configuraciones erróneas en menos tiempo.

Para obtener más información, consulta el artículo Información general sobre las métricas basadas en registros.

Para solucionar este problema, siga estos pasos:

Crear métrica

Ve a la página Métricas basadas en registros de la consola de Google Cloud .

Ir a Métricas basadas en registros
Haz clic en Crear métrica.
En Tipo de métrica, selecciona Contador.
En Detalles:
1. Especifica un nombre para la métrica de registro.
2. Añade una descripción.
3. Asigna a Unidades el valor 1.

En Selección de filtro, copia el texto siguiente y pégalo en el cuadro Crear filtro en lugar del texto que haya, si es preciso:

  protoPayload.methodName="cloudsql.instances.update"
  OR protoPayload.methodName="cloudsql.instances.create"
  OR protoPayload.methodName="cloudsql.instances.delete"

Haz clic en Crear métrica. Aparece una confirmación.

Crear política de alertas

En la Google Cloud consola, ve a la página Métricas basadas en registros:
Ve a Métricas basadas en registros.

Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuya sección sea Registro.
En la sección Métricas definidas por el usuario, selecciona la métrica que has creado en la sección anterior.
Haz clic en Más y, a continuación, en Crear alerta a partir de la métrica.

Se abrirá el cuadro de diálogo Nueva condición con las opciones de métrica y transformación de datos rellenadas automáticamente.
Haz clic en Siguiente.
1. Revisa los ajustes que se han rellenado automáticamente. Puede que quieras modificar el valor del umbral.
2. Haz clic en Nombre de la condición y escribe el nombre de la condición.
Haz clic en Siguiente.
Para añadir notificaciones a tu política de alertas, haz clic en Canales de notificación. En el cuadro de diálogo, selecciona uno o más canales de notificación y, luego, haz clic en Aceptar.

Para recibir notificaciones cuando se abran y se cierren incidentes, marca la opción Notificar cuando se cierre un incidente. De forma predeterminada, las notificaciones solo se envían cuando se abren incidentes.
Opcional: Actualiza la duración del cierre automático de incidentes. Este campo determina cuándo cierra Monitoring los incidentes si no hay datos de métricas.
Opcional: Haz clic en Documentación y añade la información que quieras incluir en las notificaciones.
Haz clic en Nombre de la alerta y escribe el que quieras asignar a la política de alertas.
Haz clic enCreate Policy (Crear política).

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL local infile`

Nombre de la categoría en la API: SQL_LOCAL_INFILE

Una instancia de base de datos de Cloud SQL para MySQL no tiene la marca de base de datos local_infile con el valor Off. Debido a los problemas de seguridad asociados a la marca local_infile, debe inhabilitarse. Para obtener más información, consulta el artículo sobre cómo configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos local_infile el valor Off.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log checkpoints disabled`

Nombre de la categoría en la API: SQL_LOG_CHECKPOINTS_DISABLED

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_checkpoints definida como On.

Si habilitas log_checkpoints, los puntos de control y de reinicio se anotan en el registro del servidor. En los mensajes del registro se incluyen algunas estadísticas, como el número de búferes escritos y el tiempo que se ha tardado en escribirlos.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_checkpoints el valor On.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log connections disabled`

Nombre de la categoría en la API: SQL_LOG_CONNECTIONS_DISABLED

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_connections definida en On.

Si habilitas el ajuste log_connections, se registran los intentos de conexión al servidor junto con la correcta autenticación de los clientes. Estos registros pueden resultar útiles para solucionar problemas y confirmar si hay intentos inusuales de conexión al servidor.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_connections el valor On.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log disconnections disabled`

Nombre de la categoría en la API: SQL_LOG_DISCONNECTIONS_DISABLED

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_disconnections definida en On.

Si habilitas el ajuste log_disconnections, se crean entradas de registro al final de cada sesión. Estos registros resultan útiles para solucionar problemas y confirmar si se detecta actividad inusual durante un periodo. Para obtener más información, consulta Configurar marcas de base de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_disconnections el valor On.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log duration disabled`

Nombre de la categoría en la API: SQL_LOG_DURATION_DISABLED

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_duration definida como On.

Cuando log_duration está habilitado, este ajuste registra la hora de ejecución y la duración de todas las instrucciones completadas. Monitorizar cuánto tiempo tardan en ejecutarse las consultas puede ser crucial para identificar las lentas y para solucionar problemas de bases de datos.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_duration el valor On.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log error verbosity`

Nombre de la categoría en la API: SQL_LOG_ERROR_VERBOSITY

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_error_verbosity definida en default o verbose.

La marca log_error_verbosity controla la cantidad de detalles que incluyen los mensajes registrados. A mayor verbosidad, más detalles se registran en los mensajes. Recomendamos asignar a esta marca los valores default o verbose.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_error_verbosity los valores default o verbose.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log lock waits disabled`

Nombre de la categoría en la API: SQL_LOG_LOCK_WAITS_DISABLED

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_lock_waits definida como On.

Si habilitas el ajuste log_lock_waits, se crean entradas de registro cuando las sesiones tardan más tiempo del especificado en deadlock_timeout en obtener un bloqueo. Estos registros resultan útiles para determinar si las esperas de los bloqueos perjudican el rendimiento.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_lock_waits el valor On.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log min duration statement enabled`

Nombre de la categoría en la API: SQL_LOG_MIN_DURATION_STATEMENT_ENABLED

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_min_duration_statement definida en -1.

La marca log_min_duration_statement provoca que se registren las declaraciones SQL que se ejecutan durante más tiempo del especificado. Se recomienda inhabilitar este ajuste porque las declaraciones SQL pueden incluir información sensible que no se debe registrar. Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_min_duration_statement el valor -1.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log min error statement`

Nombre de la categoría en la API: SQL_LOG_MIN_ERROR_STATEMENT

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_min_error_statement definida correctamente.

La marca log_min_error_statement controla si las declaraciones SQL que provocan errores se anotan en los registros del servidor. Las declaraciones SQL que tengan la gravedad especificada o una superior se registran con mensajes sobre el error. Cuanto mayor es la gravedad, menos mensajes se registran.

Si no se asigna a log_min_error_statement el valor correcto, puede que algunos mensajes no se clasifiquen como mensajes de error. Si la gravedad es demasiado baja, puede aumentar el número de mensajes y dificultar la localización de los errores reales. Si la gravedad es demasiado alta, pueden no registrarse mensajes sobre errores reales.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_min_error_statement uno de los siguientes valores recomendados, conforme a la política de registro de tu empresa.
- debug5
- debug4
- debug3
- debug2
- debug1
- info
- notice
- warning
- error
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log min error statement severity`

Nombre de la categoría en la API: SQL_LOG_MIN_ERROR_STATEMENT_SEVERITY

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_min_error_statement definida correctamente.

Si no se asigna a log_min_error_statement el valor correcto, puede que algunos mensajes no se clasifiquen como mensajes de error. Si la gravedad es demasiado baja, aumenta el número de mensajes y resulta más difícil localizar los errores reales. Si la gravedad es demasiado alta (demasiado estricta), puede que no se registren mensajes sobre errores reales.

Te recomendamos que asignes a esta marca el valor error o uno más estricto.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_min_error_statement uno de los siguientes valores recomendados, conforme a la política de registro de tu empresa.
- error
- log
- fatal
- panic
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log min messages`

Nombre de la categoría en la API: SQL_LOG_MIN_MESSAGES

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_min_messages establecida en warning como mínimo.

La marca log_min_messages controla qué niveles de mensajes se anotan en los registros del servidor. A mayor gravedad, menos mensajes se registran. Si el umbral es demasiado bajo, los registros pueden aumentar en tamaño y en longitud, lo que dificulta la localización de errores reales.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_min_messages uno de los siguientes valores recomendados, conforme a la política de registro de tu empresa.
- debug5
- debug4
- debug3
- debug2
- debug1
- info
- notice
- warning
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log executor stats enabled`

Nombre de la categoría en la API: SQL_LOG_EXECUTOR_STATS_ENABLED

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_executor_stats definida como Off.

Cuando la marca log_executor_stats está activada, se incluyen las estadísticas de rendimiento del ejecutor en los registros de PostgreSQL de cada consulta. Aunque este ajuste resulta útil para solucionar problemas, también puede aumentar considerablemente el número de registros y la sobrecarga en el rendimiento.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de la Google Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_executor_stats el valor Off.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log hostname enabled`

Nombre de la categoría en la API: `SQL_LOG_HOSTNAME_ENABLED

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_hostname con el valor Off.

Cuando se activa la marca log_hostname, se registra el nombre de host del host de conexión. De forma predeterminada, los mensajes de registro de las conexiones solo muestran la dirección IP. Este ajuste resulta útil para solucionar problemas. No obstante, también puede implicar una sobrecarga en el rendimiento del servidor porque, en cada una de las instrucciones registradas, la resolución de DNS debe convertir la dirección IP en un nombre de host.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de la Google Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_hostname el valor Off.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log parser stats enabled`

Nombre de la categoría en la API: SQL_LOG_PARSER_STATS_ENABLED

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_parser_stats definida como Off.

Cuando se activa la marca log_parser_stats, se incluyen las estadísticas de rendimiento del analizador en los registros de PostgreSQL de cada consulta. Aunque este ajuste resulta útil para solucionar problemas, también puede aumentar considerablemente el número de registros y la sobrecarga en el rendimiento.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de la Google Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_parser_stats el valor Off.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log planner stats enabled`

Nombre de la categoría en la API: SQL_LOG_PLANNER_STATS_ENABLED

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_planner_stats con el valor Off.

Cuando la marca log_planner_stats está activada, se usa un método básico de elaboración de perfiles para registrar las estadísticas de rendimiento del planificador de PostgreSQL. Aunque este ajuste resulta útil para solucionar problemas, también puede aumentar considerablemente el número de registros y la sobrecarga en el rendimiento.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de la Google Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_planner_stats el valor Off.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log statement`

Nombre de la categoría en la API: SQL_LOG_STATEMENT

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_statement definida en ddl.

El valor de esta marca controla qué declaraciones SQL se registran. El registro permite solucionar problemas operativos y hacer análisis forenses. Si a esta marca no se le asigna el valor correcto, puede que se omita información pertinente o que quede oculta entre demasiados mensajes. Se recomienda el valor ddl (todas las instrucciones de definición de datos), a menos que se especifique otro en la política de registro de tu empresa.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de la Google Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_statement el valor ddl.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log statement stats enabled`

Nombre de la categoría en la API: SQL_LOG_STATEMENT_STATS_ENABLED

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_statement_stats definida como Off.

Cuando se activa la marca log_statement_stats, se incluyen las estadísticas de rendimiento de extremo a extremo en los registros de PostgreSQL de cada consulta. Aunque este ajuste resulta útil para solucionar problemas, también puede aumentar considerablemente el número de registros y la sobrecarga en el rendimiento.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de la Google Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_statement_stats el valor Off.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL log temp files`

Nombre de la categoría en la API: SQL_LOG_TEMP_FILES

Una instancia de base de datos de Cloud SQL para PostgreSQL no tiene la marca de base de datos log_temp_files establecida en 0.

Se pueden crear archivos temporales para las ordenaciones, los hashes y los resultados temporales de las consultas. Si asignas a la marca log_temp_files el valor 0, se registra la información de todos los archivos temporales. Registrar todos los archivos temporales resulta útil para identificar posibles problemas de rendimiento. Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de la Google Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a la marca de base de datos log_temp_files el valor 0.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL no root password`

Nombre de la categoría en la API: SQL_NO_ROOT_PASSWORD

Una instancia de base de datos MySQL no tiene una contraseña definida para la cuenta raíz. Debes añadir una contraseña a la instancia de base de datos MySQL. Para obtener más información, consulta Usuarios de MySQL.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
En la página Detalles de la instancia que se carga, selecciona la pestaña Usuarios.
Junto al usuario root, haz clic en Más y, a continuación, selecciona Cambiar contraseña.
Introduce una nueva contraseña segura y haz clic en Aceptar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL public IP`

Nombre de la categoría en la API: SQL_PUBLIC_IP

Una base de datos de Cloud SQL tiene una dirección IP pública.

Para reducir la superficie de ataque de tu organización, las bases de datos de Cloud SQL no deben tener direcciones IP públicas. Las direcciones IP privadas refuerzan la seguridad de redes y reducen la latencia de tu aplicación.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de la Google Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
En el menú de la izquierda, haz clic en Conexiones.
Haz clic en la pestaña Redes y desmarca la casilla IP pública.
Si la instancia no está configurada todavía para usar una IP privada, consulta Configurar una IP privada para una instancia ya creada.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL remote access enabled`

Nombre de la categoría en la API: SQL_REMOTE_ACCESS_ENABLED

Una instancia de base de datos de Cloud SQL para SQL Server no tiene la marca de base de datos remote access definida como Off.

Cuando este ajuste está activado, otorga permiso para ejecutar procedimientos almacenados de forma local desde servidores remotos o procedimientos almacenados de forma remota desde el servidor local. Esta función permite lanzar ataques de denegación de servicio (DoS) en servidores remotos descargando el procesamiento de las consultas en un objetivo. Para evitar abusos, te recomendamos que inhabilite este ajuste.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas, asigna a remote access el valor Off.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL skip show database disabled`

Nombre de la categoría en la API: SQL_SKIP_SHOW_DATABASE_DISABLED

Una instancia de base de datos de Cloud SQL para MySQL no tiene la marca de base de datos skip_show_database con el valor On.

Cuando esta marca está activada, impide que los usuarios empleen la instrucción SHOW DATABASES si no tienen el privilegio SHOW DATABASES. Con este ajuste, los usuarios que no tengan permiso explícito no pueden ver bases de datos pertenecientes a otros usuarios. Te recomendamos que habilites esta marca.

Para obtener más información, consulta el artículo sobre cómo configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Flags, asigna a skip_show_database el valor On.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL trace flag 3625`

Nombre de la categoría en la API: SQL_TRACE_FLAG_3625

Una instancia de base de datos de Cloud SQL para SQL Server no tiene la marca de base de datos 3625 (trace flag) con el valor On.

Esta marca limita la cantidad de información que se devuelve a los usuarios que no son miembros del rol de servidor fijo sysadmin. Para ello, se enmascaran los parámetros de algunos mensajes de error con asteriscos (******). Para evitar que se revele información sensible, recomendamos habilitar esta marca.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, asigna a 3625 el valor On.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL user connections configured`

Nombre de la categoría en la API: SQL_USER_CONNECTIONS_CONFIGURED

Una instancia de base de datos de Cloud SQL para SQL Server tiene configurada la marca de base de datos user connections.

La opción user connections especifica el número máximo de conexiones de usuario simultáneas que se permite en una instancia de SQL Server. Como es una opción dinámica, se configura sola. Es decir, SQL Server ajusta automáticamente el número máximo de conexiones de usuarios según sea necesario, hasta el valor máximo permitido. El valor predeterminado es 0, lo que significa que se permiten hasta 32.767 conexiones de usuarios. Por ese motivo, no se recomienda configurar la marca de base de datos user connections.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, junto a user connections, haz clic en Eliminar.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL user options configured`

Nombre de la categoría en la API: SQL_USER_OPTIONS_CONFIGURED

Una instancia de base de datos de Cloud SQL para SQL Server tiene configurada la marca de base de datos user options.

Este ajuste prevalece sobre los valores predeterminados globales de las opciones SET de todos los usuarios. Como los usuarios y las aplicaciones pueden dar por sentado que se están utilizando las opciones SET predeterminadas de la base de datos, definir esta marca puede provocar resultados inesperados. Por ese motivo, no recomendamos configurar la marca de base de datos user options.

Para obtener más información, consulta Configurar marcas de bases de datos.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de laGoogle Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.
En la sección Marcas de bases de datos, junto a user options, haz clic en Eliminar.
Haz clic en Guardar. La nueva configuración aparece en la página Resumen de la instancia.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SQL weak root password`

Nombre de la categoría en la API: SQL_WEAK_ROOT_PASSWORD

La cuenta raíz de una instancia de base de datos MySQL tiene una contraseña poco segura. Debes definir una contraseña segura para la instancia. Para obtener más información, consulta la sección sobre usuarios de MySQL.

Para solucionar este problema, siga estos pasos:

Ve a la página Instancias de Cloud SQL de la Google Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
En la página Detalles de la instancia que se carga, selecciona la pestaña Usuarios.
Junto al usuario root, haz clic en Más y, a continuación, selecciona Cambiar contraseña.
Introduce una nueva contraseña segura y haz clic en Aceptar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`SSL not enforced`

Nombre de la categoría en la API: SSL_NOT_ENFORCED

Una instancia de base de datos de Cloud SQL no requiere que todas las conexiones entrantes utilicen SSL.

Para que no se filtren datos sensibles en tránsito a través de comunicaciones sin encriptar, las conexiones entrantes a tu instancia de base de datos SQL deben usar SSL. Consulta más información sobre cómo configurar SSL/TLS.

Para solucionar este problema, permite solo las conexiones SSL en tus instancias de SQL:

Ve a la página Instancias de Cloud SQL de la Google Cloud consola.

Ir a Instancias de Cloud SQL
Selecciona la instancia que aparece en el resultado de Security Health Analytics.
En la pestaña Conexiones, haz clic en Permitir solo conexiones SSL o en Exigir certificados de cliente de confianza. Para obtener más información, consulta cómo implementar obligatoriamente el encriptado SSL/TLS.
Si has elegido Requerir certificados de cliente de confianza, crea un certificado de cliente. Para obtener más información, consulta Crear un certificado de cliente.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Too many KMS users`

Nombre de la categoría en la API: TOO_MANY_KMS_USERS

Limita a tres el número de usuarios principales que pueden usar claves criptográficas. Los siguientes roles predefinidos otorgan permisos para encriptar, desencriptar o firmar datos con claves criptográficas:

roles/owner
roles/cloudkms.cryptoKeyEncrypterDecrypter
roles/cloudkms.cryptoKeyEncrypter
roles/cloudkms.cryptoKeyDecrypter
roles/cloudkms.signer
roles/cloudkms.signerVerifier

Para obtener más información, consulta Permisos y roles.

Para solucionar este problema, siga estos pasos:

Ve a la página Claves de Cloud KMS de la consola de Google Cloud .

Ve a Claves de Cloud KMS.
Haga clic en el nombre del conjunto de claves indicado en el resultado.
Haga clic en el nombre de la clave indicada en el resultado.
Selecciona la casilla situada junto a la versión principal y, a continuación, haz clic en Mostrar panel de información.
Reduce el número de principales que tienen permisos para cifrar, descifrar o firmar datos a tres o menos. Para revocar los permisos, haz clic en Eliminar junto a cada principal.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Unconfirmed AppArmor profile`

Nombre de la categoría en la API: GKE_APP_ARMOR

Un contenedor se puede configurar explícitamente para que AppArmor no lo limite. De esta forma, se asegura de que no se aplique ningún perfil de AppArmor al contenedor y, por lo tanto, no esté limitado por un perfil. El control de seguridad preventivo inhabilitado aumenta el riesgo de que se eluda el contenedor.

Para solucionar este problema, siga estos pasos en las cargas de trabajo afectadas:

Abre el manifiesto de cada carga de trabajo afectada.
Asigna a los siguientes campos restringidos uno de los valores permitidos.

Campos restringidos

metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]

Valores permitidos

falso

`User managed service account key`

Nombre de la categoría en la API: USER_MANAGED_SERVICE_ACCOUNT_KEY

Un usuario gestiona una clave de cuenta de servicio. Las claves de las cuentas de servicio suponen un riesgo para la seguridad si no se gestionan adecuadamente. Siempre que sea posible, deberías elegir una alternativa más segura a las claves de cuentas de servicio. Si debes autenticarte con una clave de cuenta de servicio, eres responsable de la seguridad de la clave privada y de otras operaciones descritas en las prácticas recomendadas para gestionar las claves de cuentas de servicio. Si no puedes crear una clave de cuenta de servicio, es posible que la creación de claves de cuenta de servicio esté inhabilitada en tu organización. Para obtener más información, consulta el artículo sobre gestionar recursos de organización seguros de forma predeterminada.

Si has obtenido la clave de cuenta de servicio de una fuente externa, debes validarla antes de usarla. Para obtener más información, consulta los requisitos de seguridad de las credenciales de fuentes externas.

Para solucionar este problema, siga estos pasos:

Ve a la página Cuentas de servicio de la Google Cloud consola.

Ir a Cuentas de servicio
Si es necesario, selecciona el proyecto indicado en el resultado.
Elimina las claves de cuenta de servicio gestionadas por el usuario que se indican en la detección si ninguna aplicación las utiliza.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Weak SSL policy`

Nombre de la categoría en la API: WEAK_SSL_POLICY

Una instancia de Compute Engine tiene una política de SSL débil o usa la política de SSL predeterminada de Google Cloudcon una versión de TLS anterior a la 1.2.

Los balanceadores de carga de proxies HTTPS y SSL usan políticas de SSL para determinar el protocolo y los paquetes de encriptado que se emplean en las conexiones TLS establecidas entre los usuarios e Internet. Estas conexiones encriptan los datos sensibles para impedir que accedan a ellos espías maliciosos. Las políticas de SSL débiles permiten que los clientes que usan versiones de TLS obsoletas se conecten con un protocolo o paquete de encriptado menos seguro. Para ver una lista de los paquetes de cifrado recomendados y obsoletos, visita la página de parámetros de TLS de iana.org.

Los pasos para solucionar este problema varían en función de si se ha producido por el uso de una política de SSL predeterminada Google Cloud o de una política de SSL que permite un paquete de cifrado débil o una versión mínima de TLS anterior a la 1.2. Sigue el procedimiento que corresponda al activador de la detección.

Corrección de la política de SSL predeterminada Google Cloud

Ve a la página Proxies de destino de la consola de Google Cloud .

Ir a Proxies de destino
Busca el proxy de destino indicado en el resultado y anota las reglas de reenvío que aparecen en la columna Usado por.
Para crear una política de SSL, consulta Usar políticas de SSL. La política debe tener una versión mínima de TLS de 1.2 y un perfil Moderno o Restringido.
Para usar un perfil Personalizado , asegúrate de que los siguientes paquetes de cifrado estén inhabilitados:
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
Aplica la política de SSL a cada una de las reglas de reenvío que has anotado.

Se ha permitido la corrección de un paquete de cifrado débil o una versión de TLS anterior

En la Google Cloud consola, ve a la página Políticas de SSL .

Ir a políticas de SSL
Busca el balanceador de carga indicado en la columna Usado por.
Haz clic debajo del nombre de la política.
Haz clic en Editar.
Cambia Versión mínima de TLS a TLS 1.2 y Perfil a Moderno o Restringido.
Para usar un perfil Personalizado, asegúrate de que los siguientes paquetes de cifrado estén inhabilitados:
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Web UI enabled`

Nombre de la categoría en la API: WEB_UI_ENABLED

La interfaz web (panel de control) de GKE está habilitada.

La interfaz web de Kubernetes está respaldada por cuentas de servicio de Kubernetes con muchos privilegios. Si se vulnera, la cuenta de servicio se puede usar de forma inadecuada. Si ya usas la Google Cloud consola, la interfaz web de Kubernetes amplía innecesariamente tu superficie de ataque. Consulta información sobre cómo inhabilitar la interfaz web de Kubernetes.

Para solucionar este problema, inhabilita la interfaz web de Kubernetes:

Ve a la página Clústeres de Kubernetes de la consola de Google Cloud .

Ir a clústeres de Kubernetes
Haga clic en el nombre del clúster que aparece en el resultado de Security Health Analytics.
Haz clic en Editar.

Si la configuración del clúster ha cambiado recientemente, puede que el botón Editar esté inhabilitado. Si no puedes modificar la configuración del clúster, espera unos minutos y vuelve a intentarlo.
Haz clic en Complementos. La sección se expande para mostrar los complementos disponibles.
En la lista desplegable del panel de Kubernetes, selecciona Inhabilitado.
Haz clic en Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Workload Identity disabled`

Nombre de la categoría en la API: WORKLOAD_IDENTITY_DISABLED

Workload Identity está inhabilitado en un clúster de GKE.

Se recomienda usar Workload Identity para acceder a los Google Cloud servicios desde GKE, ya que ofrece funcionalidades de gestión y propiedades de seguridad mejoradas. Al habilitar esta función, se protegen algunos metadatos del sistema potencialmente sensibles frente a las cargas de trabajo de los usuarios que se ejecutan en tu clúster. Consulta información sobre el encubrimiento de metadatos.

Para solucionar este problema, sigue la guía para habilitar Workload Identity en un clúster.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

Corregir errores de configuración de AWS

`AWS Cloud Shell Full Access Restricted`

Nombre de la categoría en la API: ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED

AWS CloudShell es una forma cómoda de ejecutar comandos de la CLI en los servicios de AWS. Una política de IAM gestionada ("AWSCloudShellFullAccess") proporciona acceso completo a CloudShell, lo que permite cargar y descargar archivos entre el sistema local de un usuario y el entorno de CloudShell. En el entorno de Cloud Shell, los usuarios tienen permisos de sudo y pueden acceder a Internet. Por lo tanto, es posible instalar software de transferencia de archivos (por ejemplo) y mover datos de Cloud Shell a servidores de Internet externos.

Recomendación: Comprueba que el acceso a AWSCloudShellFullAccess esté restringido

Para solucionar este problema, siga estos pasos:

Consola de AWS

Abre la consola de IAM en https://console.aws.amazon.com/iam/.
En el panel de la izquierda, selecciona Políticas.
Busca y selecciona AWSCloudShellFullAccess
En la pestaña Entidades asociadas, marque la casilla de cada elemento y seleccione Desasociar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Access Keys Rotated Every 90 Days or Less`

Nombre de la categoría en la API: ACCESS_KEYS_ROTATED_90_DAYS_LESS

Las claves de acceso constan de un ID de clave de acceso y una clave de acceso secreta, que se usan para firmar las solicitudes programáticas que envías a AWS. Los usuarios de AWS necesitan sus propias claves de acceso para hacer llamadas programáticas a AWS desde la interfaz de línea de comandos de AWS (CLI de AWS), Tools for Windows PowerShell, los SDKs de AWS o llamadas HTTP directas mediante las APIs de los servicios de AWS. Se recomienda que todas las claves de acceso se roten periódicamente.

Recomendación: Asegúrate de que las claves de acceso se roten cada 90 días o menos

Para solucionar este problema, siga estos pasos:

Consola de AWS

Ve a la consola de administración (https://console.aws.amazon.com/iam).
Haz clic en Users.
Haz clic en Security Credentials.
Como administrador
- Haz clic en Make Inactive para ver las claves que no se han rotado en 90 días.
Como usuario de IAM
- Haz clic en Make Inactive o Delete para ver las claves que no se han rotado o usado en los últimos 90 días.
Haz clic en Create Access Key.
Actualizar la llamada programática con las nuevas credenciales de clave de acceso

CLI de AWS

Mientras la primera clave de acceso siga activa, crea una segunda clave de acceso, que estará activa de forma predeterminada. Ejecuta el siguiente comando:

aws iam create-access-key

En este punto, el usuario tiene dos claves de acceso activas.

Actualiza todas las aplicaciones y herramientas para que usen la nueva clave de acceso.
Determina si la primera clave de acceso sigue en uso con este comando:

aws iam get-access-key-last-used

Una opción es esperar varios días y, a continuación, comprobar si se ha usado la clave de acceso antigua antes de continuar.

Aunque en el paso 3 se indique que no se usa la clave antigua, te recomendamos que no elimines la primera clave de acceso inmediatamente. En su lugar, cambia el estado de la primera clave de acceso a Inactivo con este comando:

aws iam update-access-key

Usa solo la nueva clave de acceso para confirmar que tus aplicaciones funcionan. Las aplicaciones y herramientas que sigan usando la clave de acceso original dejarán de funcionar en ese momento porque ya no tendrán acceso a los recursos de AWS. Si encuentras una aplicación o herramienta de este tipo, puedes volver a activar la primera llave de acceso. Después, vuelve al paso 2 y actualiza esta aplicación para usar la nueva clave.
Después de esperar un tiempo para asegurarte de que se han actualizado todas las aplicaciones y herramientas, puedes eliminar la primera clave de acceso con este comando:

aws iam delete-access-key

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`All Expired Ssl Tls Certificates Stored Aws Iam Removed`

Nombre de la categoría en la API: ALL_EXPIRED_SSL_TLS_CERTIFICATES_STORED_AWS_IAM_REMOVED

Para habilitar las conexiones HTTPS a tu sitio web o aplicación en AWS, necesitas un certificado de servidor SSL/TLS. Puedes usar ACM o IAM para almacenar e implementar certificados de servidor.
Usa IAM como gestor de certificados solo cuando tengas que admitir conexiones HTTPS en una región que no sea compatible con ACM. IAM cifra de forma segura tus claves privadas y almacena la versión cifrada en el almacenamiento de certificados SSL de IAM. IAM admite la implementación de certificados de servidor en todas las regiones, pero debes obtener el certificado de un proveedor externo para usarlo con AWS. No puedes subir un certificado de ACM a IAM. Además, no puedes gestionar tus certificados desde la consola de gestión de identidades y accesos.

Recomendación: Asegúrate de que se hayan eliminado todos los certificados SSL/TLS caducados almacenados en IAM de AWS

Para solucionar este problema, siga estos pasos:

Consola de AWS

Actualmente, no se pueden eliminar certificados caducados a través de la consola de administración de AWS. Para eliminar los certificados SSL/TLS almacenados en IAM a través de la API de AWS, usa la interfaz de línea de comandos (CLI).

CLI de AWS

Para eliminar un certificado caducado, ejecuta el siguiente comando y sustituye CERTIFICATE_NAME por el nombre del certificado que quieras eliminar:

aws iam delete-server-certificate --server-certificate-name <CERTIFICATE_NAME>

Si el comando anterior se ejecuta correctamente, no devuelve ningún resultado.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Autoscaling Group Elb Healthcheck Required`

Nombre de la categoría en la API: AUTOSCALING_GROUP_ELB_HEALTHCHECK_REQUIRED

Comprueba si los grupos de Auto Scaling asociados a un balanceador de carga usan comprobaciones del estado de Elastic Load Balancing.

De esta forma, el grupo puede determinar el estado de una instancia en función de las pruebas adicionales que proporcione el balanceador de carga. Usar las comprobaciones del estado de Elastic Load Balancing puede ayudar a mantener la disponibilidad de las aplicaciones que usan grupos de escalado automático de EC2.

Recomendación: comprueba que todos los grupos de autoescalado asociados a un balanceador de carga usen comprobaciones del estado

Para solucionar este problema, siga estos pasos:

Consola de AWS

Para habilitar las comprobaciones del estado de Elastic Load Balancing

Abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
En el panel de navegación, en Auto Scaling, elija Auto Scaling Groups.
Selecciona la casilla de tu grupo.
Selecciona Editar.
En Comprobaciones del estado, en Tipo de comprobación del estado, elige ELB.
En Periodo de gracia de comprobación del estado, introduce 300.
En la parte inferior de la página, selecciona Actualizar.

Para obtener más información sobre cómo usar un balanceador de carga con un grupo de escalado automático, consulta la guía de usuario de AWS Auto Scaling.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Auto Minor Version Upgrade Feature Enabled Rds Instances`

Nombre de la categoría en la API: AUTO_MINOR_VERSION_UPGRADE_FEATURE_ENABLED_RDS_INSTANCES

Asegúrate de que las instancias de base de datos de RDS tengan habilitada la marca Auto Minor Version Upgrade para recibir automáticamente las actualizaciones secundarias del motor durante el periodo de mantenimiento especificado. Por lo tanto, las instancias de RDS pueden obtener las nuevas funciones, las correcciones de errores y los parches de seguridad de sus motores de bases de datos.

Recomendación: Asegúrate de que la función de actualización automática de versión secundaria esté habilitada en las instancias de RDS

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de administración de AWS y ve al panel de control de RDS en https://console.aws.amazon.com/rds/.
En el panel de navegación de la izquierda, haz clic en Databases.
Seleccione la instancia de RDS que quiera actualizar.
Haz clic en el botón Modify situado en la parte superior derecha.
En la página Modify DB Instance: <instance identifier>, vaya a la sección Maintenance, seleccione Auto minor version upgrade y haga clic en el botón de radio Yes.
En la parte inferior de la página, haga clic en Continue, marque la opción Aplicar inmediatamente para aplicar los cambios de inmediato o seleccione Apply during the next scheduled maintenance window para evitar cualquier tiempo de inactividad.
Revise los cambios y haga clic en Modify DB Instance. El estado de la instancia debe cambiar de disponible a modificando y volver a disponible. Una vez que la función esté habilitada, el estado de Auto Minor Version Upgrade debería cambiar a Yes.

CLI de AWS

Ejecuta el comando describe-db-instances para enumerar todos los nombres de las instancias de base de datos de RDS disponibles en la región de AWS seleccionada:

aws rds describe-db-instances --region <regionName> --query 'DBInstances[*].DBInstanceIdentifier'

El resultado del comando debe devolver el identificador de cada instancia de base de datos.
Ejecuta el comando modify-db-instance para modificar la configuración de la instancia de RDS seleccionada. Este comando aplicará los cambios inmediatamente. Elimina --apply-immediately para aplicar los cambios durante la próxima ventana de mantenimiento programada y evitar cualquier tiempo de inactividad:

aws rds modify-db-instance --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --auto-minor-version-upgrade --apply-immediately

El resultado del comando debería mostrar los nuevos metadatos de configuración de la instancia de RDS y el valor del parámetro AutoMinorVersionUpgrade.
Ejecuta el comando describe-db-instances para comprobar si la función de actualización automática de versión secundaria se ha habilitado correctamente:

aws rds describe-db-instances --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --query 'DBInstances[*].AutoMinorVersionUpgrade'

El resultado del comando debe devolver el estado actual de la función como true. Esto significa que la función está enabled y que las actualizaciones secundarias del motor se aplicarán a la instancia de RDS seleccionada.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Aws Config Enabled All Regions`

Nombre de la categoría en la API: AWS_CONFIG_ENABLED_ALL_REGIONS

AWS Config es un servicio web que gestiona la configuración de los recursos de AWS admitidos en tu cuenta y te envía archivos de registro. La información registrada incluye el elemento de configuración (recurso de AWS), las relaciones entre elementos de configuración (recursos de AWS) y los cambios de configuración entre recursos. Se recomienda habilitar AWS Config en todas las regiones.

Recomendación: Asegúrate de que AWS Config esté habilitado en todas las regiones

Para solucionar este problema, siga estos pasos:

Consola de AWS

Selecciona la región en la que quieras centrarte en la parte superior derecha de la consola.
Haz clic en Servicios.
Haz clic en Configuración.
Si hay un registrador de Config habilitado en esta región, debe ir a la página Configuración desde el menú de navegación de la izquierda. Si aún no se ha habilitado un registro de configuración en esta región, debes seleccionar "Empezar".
Selecciona "Registrar todos los recursos admitidos en esta región".
Incluir recursos globales (recursos de gestión de identidades y accesos)
Especificar un segmento de S3 en la misma cuenta o en otra cuenta de AWS gestionada
Crea un tema de SNS en la misma cuenta de AWS u otra cuenta de AWS gestionada.

CLI de AWS

Asegúrate de que haya un bucket de S3, un tema de SNS y un rol de gestión de identidades y accesos adecuados según los requisitos del servicio AWS Config.
Ejecuta este comando para crear un nuevo registrador de configuración:

aws configservice put-configuration-recorder --configuration-recorder name=default,roleARN=arn:aws:iam::012345678912:role/myConfigRole --recording-group allSupported=true,includeGlobalResourceTypes=true

Crea un archivo de configuración de canal de distribución local que especifique los atributos del canal, rellenado con los requisitos previos configurados anteriormente:

{
 "name": "default",
 "s3BucketName": "my-config-bucket",
 "snsTopicARN": "arn:aws:sns:us-east-1:012345678912:my-config-notice",
 "configSnapshotDeliveryProperties": {
 "deliveryFrequency": "Twelve_Hours"
 }
}

Ejecuta este comando para crear un canal de distribución. Para ello, haz referencia al archivo de configuración JSON que has creado en el paso anterior:

aws configservice put-delivery-channel --delivery-channel file://deliveryChannel.json

Inicia el registro de configuración ejecutando el siguiente comando:

aws configservice start-configuration-recorder --configuration-recorder-name default

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Aws Security Hub Enabled`

Nombre de la categoría en la API: AWS_SECURITY_HUB_ENABLED

Security Hub recoge datos de seguridad de todas las cuentas y servicios de AWS, así como de productos de partners externos compatibles, y le ayuda a analizar sus tendencias de seguridad e identificar los problemas de seguridad de mayor prioridad. Cuando habilitas Security Hub, empieza a consumir, agregar, organizar y priorizar las detecciones de los servicios de AWS que hayas habilitado, como Amazon GuardDuty, Amazon Inspector y Amazon Macie. También puedes habilitar integraciones con productos de seguridad de partners de AWS.

Recomendación: Asegúrate de que AWS Security Hub esté habilitado

Para solucionar este problema, siga estos pasos:

Consola de AWS

Usa las credenciales de la identidad de gestión de identidades y accesos para iniciar sesión en la consola de Security Hub.
Cuando abras la consola de Security Hub por primera vez, elige Habilitar AWS Security Hub.
En la página de bienvenida, la lista Estándares de seguridad muestra los estándares de seguridad que admite Security Hub.
Elige Habilitar Security Hub.

CLI de AWS

Ejecuta el comando enable-security-hub. Para habilitar los estándares predeterminados, incluye --enable-default-standards.

aws securityhub enable-security-hub --enable-default-standards

Para habilitar el centro de seguridad sin los estándares predeterminados, incluye --no-enable-default-standards.

aws securityhub enable-security-hub --no-enable-default-standards

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Cloudtrail Logs Encrypted Rest Using Kms Cmks`

Nombre de la categoría en la API: CLOUDTRAIL_LOGS_ENCRYPTED_REST_USING_KMS_CMKS

AWS CloudTrail es un servicio web que registra las llamadas a las APIs de AWS de una cuenta y pone esos registros a disposición de los usuarios y los recursos de acuerdo con las políticas de IAM. AWS Key Management Service (KMS) es un servicio gestionado que ayuda a crear y controlar las claves de cifrado que se usan para cifrar los datos de las cuentas. Además, usa módulos de seguridad de hardware (HSM) para proteger la seguridad de las claves de cifrado. Los registros de CloudTrail se pueden configurar para que utilicen el cifrado del lado del servidor (SSE) y las claves maestras creadas por el cliente (CMK) de KMS para proteger aún más los registros de CloudTrail. Se recomienda configurar CloudTrail para que use SSE-KMS.

Recomendación: Asegúrate de que los registros de CloudTrail estén encriptados en reposo con CMKs de KMS

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de administración de AWS y abre la consola de CloudTrail en https://console.aws.amazon.com/cloudtrail.
En el panel de navegación de la izquierda, selecciona Trails .
Haz clic en un recorrido.
En la sección S3, haz clic en el botón de edición (icono de lápiz).
Haz clic en Advanced.
Selecciona una CMK del menú desplegable KMS key Id
. - Nota: Asegúrate de que la CMK esté en la misma región que el segmento de S3.
- Nota: Tendrás que aplicar una política de claves de KMS a la CMK seleccionada para que CloudTrail como servicio pueda cifrar y descifrar archivos de registro con la CMK proporcionada. En este enlace se indican los pasos para editar la política de claves de CMK seleccionada.
Haz clic en Save.
Verá un mensaje de notificación en el que se indica que debe tener permisos de descifrado en la clave de KMS especificada para descifrar los archivos de registro.
Haz clic en Yes.

CLI de AWS

aws cloudtrail update-trail --name <trail_name> --kms-id <cloudtrail_kms_key>
aws kms put-key-policy --key-id <cloudtrail_kms_key> --policy <cloudtrail_kms_key_policy>

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Cloudtrail Log File Validation Enabled`

Nombre de la categoría en la API: CLOUDTRAIL_LOG_FILE_VALIDATION_ENABLED

La validación de archivos de registro de CloudTrail crea un archivo de resumen firmado digitalmente que contiene un hash de cada registro que CloudTrail escribe en S3. Estos archivos de resumen se pueden usar para determinar si un archivo de registro se ha modificado, eliminado o no se ha modificado después de que CloudTrail haya entregado el registro. Se recomienda habilitar la validación de archivos en todos los CloudTrails.

Recomendación: Asegúrate de que la validación de archivos de registro de CloudTrail esté habilitada

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/cloudtrail.
En el panel de navegación de la izquierda, haz clic en Trails.
Hacer clic en el rastro del objetivo
En la sección General details, haz clic en edit.
En la sección Advanced settings
Marca la casilla situada debajo de Log file validation
Haz clic en Save changes.

CLI de AWS

aws cloudtrail update-trail --name <trail_name> --enable-log-file-validation

Ten en cuenta que puedes validar periódicamente los registros mediante estos resúmenes ejecutando el siguiente comando:

aws cloudtrail validate-logs --trail-arn <trail_arn> --start-time <start_time> --end-time <end_time>

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Cloudtrail Trails Integrated Cloudwatch Logs`

Nombre de la categoría en la API: CLOUDTRAIL_TRAILS_INTEGRATED_CLOUDWATCH_LOGS

AWS CloudTrail es un servicio web que registra las llamadas a las APIs de AWS realizadas en una cuenta de AWS determinada. La información registrada incluye la identidad de la persona que llama a la API, la hora de la llamada, la dirección IP de origen de la persona que llama a la API, los parámetros de la solicitud y los elementos de respuesta devueltos por el servicio de AWS. CloudTrail usa Amazon S3 para almacenar y entregar archivos de registro, por lo que los archivos de registro se almacenan de forma duradera. Además de capturar registros de CloudTrail en un bucket de S3 especificado para analizarlos a largo plazo, se pueden analizar en tiempo real configurando CloudTrail para que envíe registros a CloudWatch Logs. En el caso de un registro que esté habilitado en todas las regiones de una cuenta, CloudTrail envía archivos de registro de todas esas regiones a un grupo de registros de CloudWatch Logs. Se recomienda enviar los registros de CloudTrail a CloudWatch Logs.

Nota: El objetivo de esta recomendación es asegurarse de que se registra, monitoriza y se emiten las alertas adecuadas sobre la actividad de la cuenta de AWS. CloudWatch Logs es una forma nativa de hacerlo con los servicios de AWS, pero no impide el uso de una solución alternativa.

Recomendación: Asegúrate de que los registros de CloudTrail estén integrados con CloudWatch Logs

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de CloudTrail en https://console.aws.amazon.com/cloudtrail/.
Selecciona el Trail que quieras actualizar.
Desplázate hacia abajo hasta CloudWatch Logs.
Haz clic en Edit.
En CloudWatch Logs, marca la casilla Enabled.
En Log Group, elige un grupo de registro nuevo o selecciona uno que ya tengas.
Edita el Log group name para que coincida con CloudTrail o elige el grupo de CloudWatch que ya tengas.
En IAM Role, elige una nueva o selecciona una que ya tengas.
Edita el Role name para que coincida con CloudTrail o elige el rol de IAM que ya tengas.
Haz clic en `Guardar cambios`.

CLI de AWS

aws cloudtrail update-trail --name <trail_name> --cloudwatch-logs-log-group-arn <cloudtrail_log_group_arn> --cloudwatch-logs-role-arn <cloudtrail_cloudwatchLogs_role_arn>

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Cloudwatch Alarm Action Check`

Nombre de la categoría en la API: CLOUDWATCH_ALARM_ACTION_CHECK

Comprueba si Amazon CloudWatch tiene acciones definidas cuando una alarma pasa de un estado a otro: "OK", "ALARM" e "INSUFFICIENT_DATA".

Configurar acciones para el estado ALARMA en las alarmas de Amazon CloudWatch es muy importante para activar una respuesta inmediata cuando las métricas monitorizadas superen los umbrales.
Asegura una resolución rápida de los problemas, reduce el tiempo de inactividad y permite la corrección automatizada, lo que mantiene el buen estado del sistema y evita las interrupciones.

Las alarmas tienen al menos una acción.
Las alarmas tienen al menos una acción cuando pasan al estado "INSUFFICIENT_DATA" desde cualquier otro estado.
(Opcional) Las alarmas tienen al menos una acción cuando pasan a un estado "OK" desde cualquier otro estado.

Recomendación: comprueba si las alarmas de CloudWatch tienen al menos una acción de alarma, una acción INSUFFICIENT_DATA o una acción OK habilitada.

Para solucionar este problema, siga estos pasos:

Consola de AWS

Para configurar acciones ALARM en tus alarmas de Amazon CloudWatch, haz lo siguiente.

Abre la consola de Amazon CloudWatch en https://console.aws.amazon.com/cloudwatch/.
En el panel de navegación, en "Alarmas", selecciona "Todas las alarmas".
Elige la alarma de Amazon CloudWatch que quieras modificar, selecciona "Actions" (Acciones) y, a continuación, "Edit" (Editar).
En la parte izquierda, elige "Paso 2: configurar acciones opcionales".
En "Activador de estado de alarma", selecciona la opción "En alarma" para configurar una acción basada en ALARMA.
Para enviar una notificación a un tema de SNS recién creado, selecciona "Crear tema".
En el cuadro "Create new topic..." (Crear tema), especifica un nombre de tema de SNS único.
En el cuadro "Endpoints de correo que recibirán la notificación…", especifica una o varias direcciones de correo.
A continuación, selecciona "Crear tema" para crear el tema de Amazon SNS necesario.
Abajo a la derecha, selecciona "Siguiente", "Siguiente" y elige "Actualizar alarma" para aplicar los cambios.
Abre tu cliente de correo y, en el correo de notificaciones de AWS, haz clic en el enlace para confirmar tu suscripción al tema de SNS en cuestión.
Repite los pasos del 4 al 11 y, en el paso 5, elige "Aceptar" y "Datos insuficientes" en "Activador de estado de alarma" para configurar las acciones de esos dos estados.
Repite el proceso con todas las demás alarmas de CloudWatch de la misma región de AWS.
Repite el proceso con todas las demás alarmas de CloudWatch en todas las demás regiones de AWS.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Cloudwatch Log Group Encrypted`

Nombre de la categoría en la API: CLOUDWATCH_LOG_GROUP_ENCRYPTED

Esta comprobación asegura que los registros de CloudWatch estén configurados con KMS.

Los datos de los grupos de registros siempre están cifrados en CloudWatch Logs. De forma predeterminada, CloudWatch Logs utiliza el cifrado del lado del servidor para los datos de registro en reposo. También puedes usar AWS Key Management Service para este cifrado. En ese caso, el cifrado se realiza con una clave de KMS de AWS. El cifrado con AWS KMS se habilita a nivel de grupo de registros asociando una clave de KMS a un grupo de registros, ya sea al crear el grupo de registros o después de que ya exista.

Recomendación: comprueba que todos los grupos de registros de Amazon CloudWatch Logs estén encriptados con KMS

Para obtener más información, consulta Encrypt log data in CloudWatch Logs using AWS Key Management Service (Encriptar datos de registro en CloudWatch Logs con AWS Key Management Service) en la guía del usuario de Amazon CloudWatch.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`CloudTrail CloudWatch Logs Enabled`

Nombre de la categoría en la API: CLOUD_TRAIL_CLOUD_WATCH_LOGS_ENABLED

Este control comprueba si los registros de CloudTrail están configurados para enviar registros a CloudWatch Logs. El control falla si la propiedad CloudWatchLogsLogGroupArn del registro está vacía.

CloudTrail registra las llamadas a las APIs de AWS que se realizan en una cuenta determinada. La información registrada incluye lo siguiente:

La identidad de la persona que llama a la API
La hora de la llamada a la API
Dirección IP de origen de la persona que llama a la API.
Los parámetros de solicitud
Los elementos de respuesta devueltos por el servicio de AWS

CloudTrail usa Amazon S3 para almacenar y entregar archivos de registro. Puede capturar registros de CloudTrail en un bucket de S3 específico para analizarlos a largo plazo. Para realizar análisis en tiempo real, puede configurar CloudTrail para que envíe registros a CloudWatch Logs.

En el caso de un registro habilitado en todas las regiones de una cuenta, CloudTrail envía archivos de registro de todas esas regiones a un grupo de registros de CloudWatch Logs.

Security Hub recomienda que envíe los registros de CloudTrail a CloudWatch Logs. Ten en cuenta que esta recomendación tiene como objetivo asegurar que la actividad de la cuenta se registre, se monitorice y se alerte de forma adecuada. Puede usar CloudWatch Logs para configurarlo con sus servicios de AWS. Esta recomendación no impide el uso de otra solución.

El envío de registros de CloudTrail a CloudWatch Logs facilita el registro de actividad en tiempo real e histórico en función del usuario, la API, el recurso y la dirección IP. Puedes usar este método para configurar alarmas y notificaciones de actividad anómala o sensible en la cuenta.

Recomendación: comprueba que todos los registros de CloudTrail estén configurados para enviar registros a AWS CloudWatch

Para integrar CloudTrail con CloudWatch Logs, consulta Sending events to CloudWatch Logs (Enviar eventos a CloudWatch Logs) en la guía del usuario de AWS CloudTrail.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`No AWS Credentials in CodeBuild Project Environment Variables`

Nombre de la categoría en la API: CODEBUILD_PROJECT_ENVVAR_AWSCRED_CHECK

Comprueba si el proyecto contiene las variables de entorno AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY.

Las credenciales de autenticación AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY nunca deben almacenarse en texto sin cifrar, ya que esto podría provocar una exposición de datos no intencionada y un acceso no autorizado.

Recomendación: comprueba que el texto de todos los proyectos que contienen las variables de entorno AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY no sea texto sin formato

Para eliminar variables de entorno de un proyecto de CodeBuild, consulta Cambiar la configuración de un proyecto de compilación en AWS CodeBuild en la guía del usuario de AWS CodeBuild. Asegúrate de que no haya nada seleccionado en Variables de entorno.

Puede almacenar variables de entorno con valores sensibles en AWS Systems Manager Parameter Store o AWS Secrets Manager y, a continuación, recuperarlas de su archivo de especificación de compilación. Para obtener instrucciones, consulte el recuadro con la etiqueta "Importante" de la sección "Entorno" de la guía del usuario de AWS CodeBuild.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Codebuild Project Source Repo Url Check`

Nombre de la categoría en la API: CODEBUILD_PROJECT_SOURCE_REPO_URL_CHECK

Comprueba si la URL del repositorio de origen de Bitbucket de un proyecto de AWS CodeBuild contiene tokens de acceso personal o un nombre de usuario y una contraseña. El control falla si la URL del repositorio de origen de Bitbucket contiene tokens de acceso personal o un nombre de usuario y una contraseña.

Las credenciales de inicio de sesión no deben almacenarse ni transmitirse como texto sin cifrar, ni aparecer en la URL del repositorio de origen. En lugar de usar tokens de acceso personal o credenciales de inicio de sesión, debes acceder a tu proveedor de origen en CodeBuild y cambiar la URL del repositorio de origen para que solo contenga la ruta a la ubicación del repositorio de Bitbucket. Si usas tokens de acceso personal o credenciales de inicio de sesión, se podrían exponer datos de forma accidental o se podría obtener acceso no autorizado.

Recomendación: comprueba que todos los proyectos que tengan GitHub o Bitbucket como origen usen OAuth

Puedes actualizar tu proyecto de CodeBuild para usar OAuth.

Para eliminar la autenticación básica o el token de acceso personal (GitHub) de la fuente del proyecto de CodeBuild

Abre la consola de CodeBuild en https://console.aws.amazon.com/codebuild/.
Elige el proyecto de compilación que contenga tokens de acceso personal o un nombre de usuario y una contraseña.
En Editar, elige Fuente.
Elige Desconectar de GitHub o Bitbucket.
Elige Conectar mediante OAuth y, a continuación, Conectar a GitHub o Conectar a Bitbucket.
Cuando se te solicite, elige la opción de autorización que corresponda.
Vuelve a configurar la URL del repositorio y los ajustes de configuración adicionales según sea necesario.
Elige Actualizar fuente.

Para obtener más información, consulta los ejemplos basados en casos prácticos de CodeBuild en la guía del usuario de AWS CodeBuild.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Credentials Unused 45 Days Greater Disabled`

Nombre de la categoría en la API: CREDENTIALS_UNUSED_45_DAYS_GREATER_DISABLED

Los usuarios de AWS IAM pueden acceder a los recursos de AWS mediante diferentes tipos de credenciales, como contraseñas o claves de acceso. Se recomienda desactivar o eliminar todas las credenciales que no se hayan usado durante 45 días o más.

Recomendación: Asegúrate de que las credenciales que no se hayan usado durante 45 días o más estén inhabilitadas

Para solucionar este problema, siga estos pasos:

Consola de AWS

Sigue estos pasos para gestionar la contraseña no utilizada (acceso a la consola de usuario de IAM):

Inicia sesión en la consola de administración de AWS:
Haz clic en Services.
Haz clic en IAM.
Haz clic en Users.
Haz clic en Security Credentials.
Seleccionar usuarios cuyo Console last sign-in sea superior a 45 días
Haz clic en Security credentials.
En la sección Sign-in credentials, Console password haz clic en Manage.
En Acceso a la consola, selecciona Disable
. 10. Haz clic en Apply.

Para desactivar las claves de acceso, haz lo siguiente:

Inicia sesión en la consola de administración de AWS:
Haz clic en Services.
Haz clic en IAM.
Haz clic en Users.
Haz clic en Security Credentials.
Selecciona las claves de acceso que tengan más de 45 días y que se hayan usado.
- Haz clic en Make Inactive.
Selecciona las claves de acceso que tengan más de 45 días y que no se hayan usado.
- Haz clic en la X para Delete

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Default Security Group Vpc Restricts All Traffic`

Nombre de la categoría en la API: DEFAULT_SECURITY_GROUP_VPC_RESTRICTS_ALL_TRAFFIC

Una VPC incluye un grupo de seguridad predeterminado cuya configuración inicial deniega todo el tráfico entrante, permite todo el tráfico saliente y permite todo el tráfico entre las instancias asignadas al grupo de seguridad. Si no especifica un grupo de seguridad al lanzar una instancia, esta se asignará automáticamente a este grupo de seguridad predeterminado. Los grupos de seguridad proporcionan un filtrado con estado del tráfico de red de entrada y salida a los recursos de AWS. Se recomienda que el grupo de seguridad predeterminado restrinja todo el tráfico.

El grupo de seguridad predeterminado de cada VPC de cada región debe actualizarse para cumplir este requisito. Las VPCs que se creen automáticamente contendrán un grupo de seguridad predeterminado que deberá corregirse para cumplir esta recomendación.

NOTA: Al implementar esta recomendación, el registro de flujo de VPC es muy útil para determinar el acceso al puerto con los mínimos privilegios que necesitan los sistemas para funcionar correctamente, ya que puede registrar todas las aceptaciones y rechazos de paquetes que se produzcan en los grupos de seguridad actuales. De esta forma, se reduce considerablemente el principal obstáculo para la ingeniería de mínimos accesos: descubrir los puertos mínimos que necesitan los sistemas del entorno. Aunque no se adopte la recomendación de registro de flujo de VPC de esta comparativa como medida de seguridad permanente, se debe usar durante cualquier periodo de descubrimiento y de ingeniería para los grupos de seguridad con los privilegios mínimos.

Recomendación: Asegúrate de que el grupo de seguridad predeterminado de cada VPC restrinja todo el tráfico

Miembros del grupo de seguridad

Para implementar el estado prescrito, haz lo siguiente:

Identificar los recursos de AWS que se encuentran en el grupo de seguridad predeterminado
Crea un conjunto de grupos de seguridad con el mínimo privilegio para esos recursos.
Coloca los recursos en esos grupos de seguridad
Elimina los recursos indicados en el paso 1 del grupo de seguridad predeterminado.

Estado del grupo de seguridad

Inicia sesión en la consola de administración de AWS en https://console.aws.amazon.com/vpc/home.
Repite los pasos siguientes con todas las VPCs, incluida la VPC predeterminada de cada región de AWS:
En el panel de la izquierda, haz clic en Security Groups.
Sigue estos pasos para cada grupo de seguridad predeterminado:
Selecciona el grupo de seguridad default.
Haz clic en la pestaña Inbound Rules.
Quitar las reglas de entrada
Haz clic en la pestaña Outbound Rules.
Quita las reglas de salida

Recomendado:

Los grupos de gestión de identidades y accesos te permiten editar el campo "name". Después de corregir las reglas de los grupos predeterminados de todas las VPCs de todas las regiones, edita este campo para añadir un texto similar a "NO USAR. NO AÑADIR REGLAS"

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Dms Replication Not Public`

Nombre de la categoría en la API: DMS_REPLICATION_NOT_PUBLIC

Comprueba si las instancias de replicación de AWS DMS son públicas. Para ello, examina el valor del campo PubliclyAccessible.

Una instancia de réplica privada tiene una dirección IP privada a la que no puedes acceder fuera de la red de réplica. Una instancia de replicación debe tener una dirección IP privada cuando las bases de datos de origen y de destino estén en la misma red. La red también debe estar conectada a la VPC de la instancia de replicación mediante una VPN, AWS Direct Connect o el emparejamiento de VPCs. Para obtener más información sobre las instancias de replicación públicas y privadas, consulta Instancias de replicación públicas y privadas en la guía del usuario de AWS Database Migration Service.

También debes asegurarte de que solo los usuarios autorizados tengan acceso a la configuración de tu instancia de AWS DMS. Para ello, restringe los permisos de gestión de identidades y accesos de los usuarios para modificar los ajustes y los recursos de AWS DMS.

Recomendación: comprueba si las instancias de replicación de AWS Database Migration Service son públicas

No puedes cambiar la configuración de acceso público de una instancia de replicación de DMS después de crearla. Para cambiar el ajuste de acceso público, elimina la instancia actual y vuelve a crearla. No selecciones la opción Accesible públicamente.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Do Setup Access Keys During Initial User Setup All Iam Users Console`

Nombre de la categoría en la API: DO_SETUP_ACCESS_KEYS_DURING_INITIAL_USER_SETUP_ALL_IAM_USERS_CONSOLE

La consola de AWS no tiene ninguna casilla marcada de forma predeterminada al crear un usuario de IAM. Al crear las credenciales de usuario de IAM, debe determinar el tipo de acceso que necesitan.

Acceso programático: es posible que el usuario de IAM necesite hacer llamadas a la API, usar la CLI de AWS o usar las herramientas de Windows PowerShell. En ese caso, crea una clave de acceso (un ID de clave de acceso y una clave de acceso secreta) para ese usuario.

Acceso a la consola de administración de AWS: si el usuario necesita acceder a la consola de administración de AWS, crea una contraseña para él.

Recomendación: No configures las claves de acceso durante la configuración inicial de todos los usuarios de IAM que tengan una contraseña de consola

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de administración de AWS:
Haz clic en Services.
Haz clic en IAM.
Haz clic en Users.
Haz clic en Security Credentials.
Como administrador
- Haga clic en la X (Delete) de las claves que se crearon al mismo tiempo que el perfil de usuario, pero que no se han usado.
Como usuario de IAM
- Haz clic en la X (Delete) de las claves que se crearon al mismo tiempo que el perfil de usuario, pero que no se han usado.

CLI de AWS

aws iam delete-access-key --access-key-id <access-key-id-listed> --user-name <users-name>

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Dynamodb Autoscaling Enabled`

Nombre de la categoría en la API: DYNAMODB_AUTOSCALING_ENABLED

Comprueba si una tabla de Amazon DynamoDB puede escalar su capacidad de lectura y escritura según sea necesario. Este control se supera si la tabla usa el modo de capacidad bajo demanda o el modo aprovisionado con el autoescalado configurado. Al escalar la capacidad en función de la demanda, se evitan las excepciones de limitación, lo que ayuda a mantener la disponibilidad de las aplicaciones.

Las tablas de DynamoDB en modo de capacidad bajo demanda solo están limitadas por las cuotas de tabla predeterminadas de rendimiento de DynamoDB. Para aumentar estas cuotas, puede registrar una incidencia a través del equipo de Asistencia de AWS.

Las tablas de DynamoDB en modo aprovisionado con escalado automático ajustan la capacidad de procesamiento aprovisionada de forma dinámica en respuesta a los patrones de tráfico. Para obtener más información sobre la limitación de solicitudes de DynamoDB, consulta Limitación de solicitudes y capacidad de ráfaga en la guía para desarrolladores de Amazon DynamoDB.

Recomendación: Las tablas de DynamoDB deberían escalar automáticamente la capacidad según la demanda

Para obtener instrucciones detalladas sobre cómo habilitar el escalado automático de DynamoDB en tablas existentes en modo de capacidad, consulta Habilitar el escalado automático de DynamoDB en tablas existentes en la guía para desarrolladores de Amazon DynamoDB.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Dynamodb In Backup Plan`

Nombre de la categoría en la API: DYNAMODB_IN_BACKUP_PLAN

Este control evalúa si una tabla de DynamoDB está cubierta por un plan de copia de seguridad. El control falla si una tabla de DynamoDB no está cubierta por un plan de copia de seguridad. Este control solo evalúa las tablas de DynamoDB que están en estado ACTIVE.

Las copias de seguridad te ayudan a recuperarte más rápido de un incidente de seguridad. También refuerzan la resiliencia de tus sistemas. Incluir tablas de DynamoDB en un plan de copias de seguridad te ayuda a proteger tus datos frente a pérdidas o eliminaciones accidentales.

Recomendación: Las tablas de DynamoDB deben estar cubiertas por un plan de copia de seguridad

Para añadir una tabla de DynamoDB a un plan de copia de seguridad de AWS Backup, consulta Asignar recursos a un plan de copia de seguridad en la Guía para desarrolladores de AWS Backup.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Dynamodb Pitr Enabled`

Nombre de la categoría en la API: DYNAMODB_PITR_ENABLED

La recuperación a un momento dado (PITR) es uno de los mecanismos disponibles para crear copias de seguridad de las tablas de DynamoDB.

Las copias de seguridad de un momento dado se conservan durante 35 días. Si necesitas un periodo de conservación más largo, consulta el artículo Configurar copias de seguridad programadas para Amazon DynamoDB con AWS Backup en la documentación de AWS.

Recomendación: comprueba que la recuperación a un momento dado (PITR) esté habilitada en todas las tablas de AWS DynamoDB

Para solucionar este problema, siga estos pasos:

Terraform

Para configurar la recuperación a un momento dado en las tablas de DynamoDB, define el bloque point_in_time_recovery:

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  point_in_time_recovery {
    enabled = true
  }
}

Consola de AWS

Para habilitar la recuperación a un momento dado de DynamoDB en una tabla

Abre la consola de DynamoDB en https://console.aws.amazon.com/dynamodb/.
Elige la tabla con la que quieras trabajar y, a continuación, selecciona Copias de seguridad.
En la sección Recuperación a un momento dado, en Estado, elige Habilitar.
Vuelve a elegir Habilitar para confirmar el cambio.

CLI de AWS

aws dynamodb update-continuous-backups \
  --table-name "GameScoresOnDemand" \
  --point-in-time-recovery-specification "PointInTimeRecoveryEnabled=true"

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Dynamodb Table Encrypted Kms`

Nombre de la categoría en la API: DYNAMODB_TABLE_ENCRYPTED_KMS

Comprueba si todas las tablas de DynamoDB están cifradas con una clave de KMS gestionada por el cliente (no predeterminada).

Recomendación: comprueba que todas las tablas de DynamoDB estén encriptadas con AWS Key Management Service (KMS)

Para solucionar este problema, siga estos pasos:

Terraform

Para corregir este control, cree una clave de KMS de AWS y úsela para cifrar el recurso de DynamoDB infractor.

resource "aws_kms_key" "dynamodb_encryption" {
  description         = "Used for DynamoDB encryption configuration"
  enable_key_rotation = true
}

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  server_side_encryption {
    enabled     = true
    kms_key_arn = aws_kms_key.dynamodb_encryption.arn
  }
}

Consola de AWS

Supongamos que hay una clave de KMS de AWS disponible para cifrar DynamoDB.

Para cambiar el cifrado de una tabla de DynamoDB a una clave de KMS gestionada y propiedad del cliente.

Abre la consola de DynamoDB en https://console.aws.amazon.com/dynamodb/.
Elige la tabla con la que quieras trabajar y, a continuación, selecciona Configuración adicional.
En Cifrado, elige Gestionar cifrado.
En Cifrado en reposo, elige Almacenado en tu cuenta, de tu propiedad y gestionado por ti.
Selecciona la clave de AWS que quieras usar. Guarda los cambios.

CLI de AWS

aws dynamodb update-table \
  --table-name <value> \
  --sse-specification "Enabled=true,SSEType=KMS,KMSMasterKeyId=<kms_key_arn>"

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Ebs Optimized Instance`

Nombre de la categoría en la API: EBS_OPTIMIZED_INSTANCE

Comprueba si la optimización de EBS está habilitada en las instancias de EC2 que se pueden optimizar para EBS

Recomendación: comprueba que la optimización de EBS esté habilitada en todas las instancias que admiten la optimización de EBS

Para configurar los ajustes de las instancias optimizadas para EBS, consulta Instancias optimizadas para Amazon EBS en la guía del usuario de Amazon EC2.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Ebs Snapshot Public Restorable Check`

Nombre de la categoría en la API: EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK

Comprueba si las capturas de Amazon Elastic Block Store no son públicas. El control falla si cualquier persona puede restaurar las capturas de Amazon EBS.

Las capturas de EBS se usan para crear copias de seguridad de los datos de los volúmenes de EBS en Amazon S3 en un momento concreto. Puedes usar las instantáneas para restaurar estados anteriores de los volúmenes de EBS. Rara vez es aceptable compartir una captura de pantalla con el público. Normalmente, la decisión de compartir una instantánea públicamente se toma por error o sin comprender completamente las implicaciones. Esta comprobación ayuda a asegurarse de que todo el contenido compartido se haya planificado y se haya hecho de forma intencionada.

Recomendación: Las capturas de Amazon EBS no deben poder restaurarse públicamente

Para solucionar este problema, siga estos pasos:

Consola de AWS

Para solucionar este problema, actualice su captura de EBS para que sea privada en lugar de pública.

Para convertir una captura de EBS pública en privada, sigue estos pasos:

Abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
En el panel de navegación, en Elastic Block Store, elija el menú Snapshots (Instantáneas) y, a continuación, elija su instantánea pública.
En Acciones, elige Modificar permisos.
Elige Privado.
(Opcional) Añade los números de cuenta de AWS de las cuentas autorizadas con las que quieras compartir tu instantánea y elige Añadir permiso.
Selecciona Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Ebs Volume Encryption Enabled All Regions`

Nombre de la categoría en la API: EBS_VOLUME_ENCRYPTION_ENABLED_ALL_REGIONS

Elastic Compute Cloud (EC2) admite el cifrado en reposo cuando se usa el servicio Elastic Block Store (EBS). Aunque está inhabilitado de forma predeterminada, se admite la opción de forzar el cifrado al crear volúmenes de EBS.

Recomendación: Asegúrate de que el encriptado de volúmenes de EBS esté habilitado en todas las regiones

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de administración de AWS y abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
En Account attributes, haz clic en EBS encryption.
Haz clic en Manage.
Haz clic en la casilla Enable.
Haz clic en Update EBS encryption.
Repite este proceso con cada región en la que quieras hacer el cambio.

Nota: El cifrado de volúmenes de EBS se configura por región.

CLI de AWS

Ejecutar

aws --region <region> ec2 enable-ebs-encryption-by-default

Comprueba que se muestre "EbsEncryptionByDefault": true.
Repite este proceso en cada región que requiera el cambio.

Nota: El cifrado de volúmenes de EBS se configura por región.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Ec2 Instances In Vpc`

Nombre de la categoría en la API: EC2_INSTANCES_IN_VPC

Amazon VPC ofrece más funciones de seguridad que EC2 Classic. Se recomienda que todos los nodos pertenezcan a una VPC de Amazon.

Recomendación: se asegura de que todas las instancias pertenezcan a una VPC

Para solucionar este problema, siga estos pasos:

Terraform

Si tiene instancias de EC2 Classic definidas en Terraform, puede modificar sus recursos para que formen parte de una VPC. Esta migración dependerá de la arquitectura que mejor se adapte a tus necesidades. A continuación, se muestra un ejemplo sencillo de Terraform que ilustra una instancia EC2 expuesta públicamente en una VPC.

  resource "aws_vpc" "example_vpc" {
    cidr_block = "10.0.0.0/16"
  }

  resource "aws_subnet" "example_public_subnet" {
    vpc_id            = aws_vpc.example_vpc.id
    cidr_block        = "10.0.1.0/24"
    availability_zone = "1a"
  }

  resource "aws_internet_gateway" "example_igw" {
    vpc_id = aws_vpc.example_vpc.id
  }

  resource "aws_key_pair" "example_key" {
    key_name   = "web-instance-key"
    public_key = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD3F6tyPEFEzV0LX3X8BsXdMsQz1x2cEikKDEY0aIj41qgxMCP/iteneqXSIFZBp5vizPvaoIR3Um9xK7PGoW8giupGn+EPuxIA4cDM4vzOqOkiMPhz5XK0whEjkVzTo4+S0puvDZuwIsdiW9mxhJc7tgBNL0cYlWSYVkz4G/fslNfRPW5mYAM49f4fhtxPb5ok4Q2Lg9dPKVHO/Bgeu5woMc7RY0p1ej6D4CKFE6lymSDJpW0YHX/wqE9+cfEauh7xZcG0q9t2ta6F6fmX0agvpFyZo8aFbXeUBr7osSCJNgvavWbM/06niWrOvYX2xwWdhXmXSrbX8ZbabVohBK41 email@example.com"
  }

  resource "aws_security_group" "web_sg" {
    name   = "http and ssh"
    vpc_id = aws_vpc.some_custom_vpc.id

    ingress {
      from_port   = 80
      to_port     = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    ingress {
      from_port   = 22
      to_port     = 22
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    egress {
      from_port   = 0
      to_port     = 0
      protocol    = -1
      cidr_blocks = ["0.0.0.0/0"]
    }
  }

  resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    key_name               = aws_key_pair.example_key.name
    monitoring             = true
    subnet_id              = aws_subnet.example_public_subnet.id
    vpc_security_group_ids = [aws_security_group.web_sg.id]
    metadata_options {
      http_tokens = "required"
    }
  }

Consola de AWS

Para migrar de EC2-Classic a VPC, consulta el artículo Migrar de EC2-Classic a una VPC.

CLI de AWS

En este ejemplo de la CLI de AWS se muestra la misma infraestructura definida con Terraform. Es un ejemplo sencillo de una instancia de EC2 expuesta públicamente en una VPC

Crear VPC

  aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16

Crear subred pública

  aws ec2 create-subnet \
  --availability-zone 1a \
  --cidr-block 10.0.1.0/24 \
  --vpc-id <id_from_create-vpc_command>

Crear una pasarela de Internet

  aws ec2 create-internet-gateway

Asociar una pasarela de Internet a una VPC

  aws ec2 attach-internet-gateway \
  --internet-gateway-id <id_from_create-internet-gateway_command> \
  --vpc-id <id_from_create-vpc_command>

Crear par de claves: se guardará tu clave privada en /.ssh/web-instance-key.pem

  aws ec2 create-key-pair \
  --key-name web-instance-key \
  --query "KeyMaterial" \
  --output text > ~/.ssh/web-instance-key.pem && \
  chmod 400 ~/.ssh/web-instance-key.pem

Crear grupo de seguridad

  aws ec2 create-security-group \
  --group-name "http and ssh" \
  --vpc-id <id_from_create-vpc_command>

Crear reglas de grupo de seguridad: para restringir aún más el acceso, define un CIDR más restringido para SSH en el puerto 22.

  aws ec2 authorize-security-group-ingress \
  --group-id <id_from_create-security-group_command>
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

  aws ec2 authorize-security-group-ingress \
  --group-id <id_from_create-security-group_command>
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0

  aws ec2 authorize-security-group-egress \
  --group-id <id_from_create-security-group_command>
  --protocol -1 \
  --port 0 \
  --cidr 0.0.0.0/0

Crear instancia de EC2

  aws ec2 run-instances \
  --image-id <ami_id> \
  --instance-type <instance_flavor> \
  --metadata-options "HttpEndpoint=enabled,HttpTokens=required" \
  --monitoring true \
  --key-name web-instance-key \
  --subnet-id <id_from_create-subnet_command> \
  --security-group-ids <id_from_create-security-group_command>

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Ec2 Instance No Public Ip`

Nombre de la categoría en la API: EC2_INSTANCE_NO_PUBLIC_IP

Las instancias de EC2 que tienen una dirección IP pública corren un mayor riesgo de sufrir una vulneración. Se recomienda que las instancias EC2 no se configuren con una dirección IP pública.

Recomendación: se asegura de que ninguna instancia tenga una IP pública

Para solucionar este problema, siga estos pasos:

Terraform

Usa el argumento associate_public_ip_address = false con el recurso aws_instance para asegurarte de que las instancias de EC2 se aprovisionen sin una dirección IP pública

resource "aws_instance" "no_public_ip" {
  ...
  associate_public_ip_address = false
}

Consola de AWS

De forma predeterminada, las subredes no predeterminadas tienen el atributo de direccionamiento público IPv4 definido como "false", mientras que las subredes predeterminadas tienen este atributo definido como "true". Una excepción es una subred no predeterminada creada por el asistente de inicio de instancias de Amazon EC2. El asistente asigna el valor "true" al atributo. Puede modificar este atributo mediante la consola de Amazon VPC.

Para modificar el comportamiento de direccionamiento IPv4 público de tu subred

Abre la consola de Amazon VPC en https://console.aws.amazon.com/vpc/.
En el panel de navegación, elige Subredes.
Selecciona tu subred y elige Acciones > Editar ajustes de subred.
Si está marcada, la casilla Habilitar la asignación automática de direcciones IPv4 públicas solicita una dirección IPv4 pública para todas las instancias que se lancen en la subred seleccionada. Marca o desmarca la casilla según sea necesario y, a continuación, selecciona Guardar.

CLI de AWS

El siguiente comando ejecuta una instancia EC2 en una subred predeterminada sin asociarle una dirección IP pública.

aws ec2 run-instances \
--image-id <ami_id> \
--instance-type <instance_flavor> \
--no-associate-public-ip-address \
--key-name MyKeyPair

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Ec2 Managedinstance Association Compliance Status Check`

Nombre de la categoría en la API: EC2_MANAGEDINSTANCE_ASSOCIATION_COMPLIANCE_STATUS_CHECK

Una asociación de State Manager es una configuración que se asigna a las instancias gestionadas. La configuración define el estado que quieres mantener en tus instancias. Por ejemplo, una asociación puede especificar que el software antivirus debe estar instalado y en ejecución en tus instancias, o que determinados puertos deben estar cerrados. Las instancias EC2 que tienen una asociación con AWS Systems Manager están gestionadas por Systems Manager, lo que facilita la aplicación de parches, la corrección de configuraciones erróneas y la respuesta a eventos de seguridad.

Recomendación: comprueba el estado de cumplimiento de la asociación de AWS Systems Manager

Para solucionar este problema, siga estos pasos:

Terraform

En el siguiente ejemplo se muestra cómo crear una instancia de EC2 sencilla, un documento de AWS Systems Manager (SSM) y una asociación entre SSM y la instancia de EC2. Los documentos admitidos son de tipo Command y Policy.

resource "aws_instance" "web" {
  ami           = "<iam_id>"
  instance_type = "<instance_flavor>"
}

resource "aws_ssm_document" "check_ip" {
  name          = "check-ip-config"
  document_type = "Command"

  content = <<DOC
  {
    "schemaVersion": "1.2",
    "description": "Check ip configuration of a Linux instance.",
    "parameters": {

    },
    "runtimeConfig": {
      "aws:runShellScript": {
        "properties": [
          {
            "id": "0.aws:runShellScript",
            "runCommand": ["ifconfig"]
          }
        ]
      }
    }
  }
DOC
}

resource "aws_ssm_association" "check_ip_association" {
  name = aws_ssm_document.check_ip.name

  targets {
    key    = "InstanceIds"
    values = [aws_instance.web.id]
  }
}

Consola de AWS

Para obtener información sobre cómo configurar asociaciones con AWS Systems Manager mediante la consola, consulta el artículo Crear asociaciones de la documentación de AWS Systems Manager.

CLI de AWS

Crear un documento de SSM

aws ssm create-document \
--name <document_name> \
--content  file://path/to-file/document.json \
--document-type "Command"

Crear una asociación de SSM

aws ssm create-association \
--name <association_name> \
--targets "Key=InstanceIds,Values=<instance-id-1>,<instance-id-2>"

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Ec2 Managedinstance Patch Compliance Status Check`

Nombre de la categoría en la API: EC2_MANAGEDINSTANCE_PATCH_COMPLIANCE_STATUS_CHECK

Este control comprueba si el estado de cumplimiento de la asociación de AWS Systems Manager es COMPLIANT o NON_COMPLIANT después de que la asociación se ejecute en una instancia. El control falla si el estado de cumplimiento de la asociación es NON_COMPLIANT.

Después de crear una o varias asociaciones de State Manager, podrá acceder inmediatamente a la información sobre el estado de cumplimiento. Puede ver el estado de cumplimiento en la consola o en respuesta a los comandos de la CLI de AWS o a las acciones de la API de Systems Manager correspondientes. En el caso de las asociaciones, Cumplimiento de la configuración muestra el estado de cumplimiento (Cumple o No cumple). También se muestra el nivel de gravedad asignado a la asociación, como Crítico o Medio.

Para obtener más información sobre el cumplimiento de las asociaciones de State Manager, consulta el artículo Acerca del cumplimiento de las asociaciones de State Manager en la guía del usuario de AWS Systems Manager.

Recomendación: comprueba el estado de cumplimiento de parches de AWS Systems Manager

Una asociación fallida puede deberse a diferentes motivos, como los nombres de los documentos SSM y los destinos. Para solucionar este problema, primero debe identificar e investigar la asociación consultando el historial de asociaciones. Para obtener instrucciones sobre cómo ver el historial de asociaciones, consulta Ver historiales de asociaciones en la Guía del usuario de AWS Systems Manager.

Después de investigar, puedes editar la asociación para corregir el problema identificado. Puedes editar una asociación para especificar un nuevo nombre, una nueva programación, un nuevo nivel de gravedad o nuevos destinos. Después de editar una asociación, AWS Systems Manager crea una nueva versión. Para obtener instrucciones sobre cómo editar una asociación, consulta Editar y crear una nueva versión de una asociación en la guía del usuario de AWS Systems Manager.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Ec2 Metadata Service Allows Imdsv2`

Nombre de la categoría en la API: EC2_METADATA_SERVICE_ALLOWS_IMDSV2

Cuando habilitan el servicio de metadatos en instancias EC2 de AWS, los usuarios pueden usar la versión 1 del servicio de metadatos de instancias (IMDSv1, un método de solicitud/respuesta) o la versión 2 (IMDSv2, un método orientado a sesiones).

Recomendación: Asegúrate de que el servicio de metadatos de EC2 solo permita IMDSv2

Desde la consola:
1. Inicia sesión en la consola de administración de AWS y abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/
2. En el menú Instancias, selecciona Instancias.
3. En cada instancia, seleccione la instancia y, a continuación, elija Acciones > Modificar opciones de metadatos de la instancia.
4. Si el servicio de metadatos de la instancia está habilitado, defina IMDSv2 como obligatorio.

Desde la línea de comandos:

aws ec2 modify-instance-metadata-options --instance-id <instance_id> --http-tokens required

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Ec2 Volume Inuse Check`

Nombre de la categoría en la API: EC2_VOLUME_INUSE_CHECK

Identificar y eliminar volúmenes de Elastic Block Store (EBS) no asociados (sin usar) en su cuenta de AWS para reducir el coste de su factura mensual de AWS. Al eliminar los volúmenes de EBS que no se usen, también se reduce el riesgo de que los datos confidenciales o sensibles salgan de tus instalaciones. Además, este control también comprueba si las instancias de EC2 archivadas están configuradas para eliminar volúmenes al finalizar.

De forma predeterminada, las instancias de EC2 están configuradas para eliminar los datos de los volúmenes de EBS asociados a la instancia y para eliminar el volumen de EBS raíz de la instancia. Sin embargo, los volúmenes de EBS que no sean raíz y que estén conectados a la instancia, ya sea al iniciarse o durante la ejecución, se conservarán después de la finalización de forma predeterminada.

Recomendación: comprueba si los volúmenes de EBS están conectados a instancias de EC2 y configurados para eliminarse cuando finalice la instancia

Para solucionar este problema, siga estos pasos:

Terraform

Para evitar esta situación con Terraform, crea instancias EC2 con bloques EBS insertados. De esta forma, se asegura de que todos los bloques de EBS asociados a la instancia (no solo la raíz) se eliminen cuando finalice la instancia, ya que el valor predeterminado del atributo ebs_block_device.delete_on_termination es true.

resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    ebs_block_device {
      delete_on_termination = true # Default
      device_name           = "/dev/sdh"
    }

Consola de AWS

Para eliminar un volumen de EBS mediante la consola

Abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
En el panel de navegación, selecciona Volúmenes.
Selecciona el volumen que quieras eliminar y elige Acciones > Eliminar volumen.
Nota: Si la opción Eliminar volumen está atenuada, significa que el volumen está conectado a una instancia. Debes separar el volumen de la instancia para poder eliminarlo.
En el cuadro de diálogo de confirmación, elige Eliminar.

CLI de AWS

Este comando de ejemplo elimina un volumen disponible con el ID de volumen vol-049df61146c4d7901. Si el comando se ejecuta correctamente, no se devuelve ningún resultado.

aws ec2 delete-volume --volume-id vol-049df61146c4d7901

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Efs Encrypted Check`

Nombre de la categoría en la API: EFS_ENCRYPTED_CHECK

Amazon EFS admite dos tipos de cifrado para los sistemas de archivos: el cifrado de datos en tránsito y el cifrado en reposo. Esta comprobación verifica que todos los sistemas de archivos de EFS estén configurados con el cifrado en reposo en todas las regiones habilitadas de la cuenta.

Recomendación: comprueba si EFS está configurado para encriptar datos de archivos con KMS

Para solucionar este problema, siga estos pasos:

Terraform

El siguiente fragmento de código se puede usar para crear un EFS cifrado con KMS (nota: el atributo kms_key_id es opcional y se creará una clave si no se proporciona ningún ID de clave de KMS).

resource "aws_efs_file_system" "encrypted-efs" {
  creation_token = "my-kms-encrypted-efs"
  encrypted      = true
  kms_key_id     = "arn:aws:kms:us-west-2:12344375555:key/16393ebd-3348-483f-b162-99b6648azz23"

  tags = {
    Name = "MyProduct"
  }
}

Consola de AWS

Para configurar EFS con cifrado mediante la consola de AWS, consulta Cifrar un sistema de archivos en reposo mediante la consola.

CLI de AWS

Es importante tener en cuenta que, aunque la creación de EFS desde la consola habilita el cifrado en reposo de forma predeterminada, no ocurre lo mismo con los EFS creados mediante la CLI, la API o el SDK. En el siguiente ejemplo se muestra cómo crear un sistema de archivos cifrado en tu infraestructura.

aws efs create-file-system \
--backup \
--encrypted \
--region us-east-1 \

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Efs In Backup Plan`

Nombre de la categoría en la API: EFS_IN_BACKUP_PLAN

Las prácticas recomendadas de Amazon indican que debes configurar copias de seguridad para tus sistemas de archivos elásticos (EFS). De esta forma, se comprueban todos los sistemas de archivos de EFS de todas las regiones habilitadas de tu cuenta de AWS para ver si tienen copias de seguridad habilitadas.

Recomendación: comprueba si los sistemas de archivos de EFS están incluidos en los planes de AWS Backup

Para solucionar este problema, siga estos pasos:

Terraform

Usa el recurso aws_efs_backup_policy para configurar una política de copias de seguridad para los sistemas de archivos de EFS.

resource "aws_efs_file_system" "encrypted-efs" {
  creation_token = "my-encrypted-efs"
  encrypted      = true

  tags = merge({
    Name = "${local.resource_prefix.value}-efs"
    }, {
    git_file             = "terraform/aws/efs.tf"
    git_org              = "your_git_org"
    git_repo             = "your_git_repo"
  })
}

resource "aws_efs_backup_policy" "policy" {
  file_system_id = aws_efs_file_system.encrypted-efs.id

  backup_policy {
    status = "ENABLED"
  }
}

Consola de AWS

Hay dos opciones para crear copias de seguridad de EFS: el servicio AWS Backup y la solución de copia de seguridad de EFS a EFS. Para corregir un EFS sin copia de seguridad mediante la consola, consulta lo siguiente:

CLI de AWS

Hay varias opciones para crear sistemas de archivos EFS conformes mediante la CLI:

Crea un EFS con la copia de seguridad automática habilitada (opción predeterminada para el almacenamiento de una zona y condicional a la disponibilidad de la copia de seguridad en la región de AWS)
Crear un EFS y poner una política de copia de seguridad

Sin embargo, si la corrección debe realizarse en el EFS actual, la mejor opción es crear una política de copias de seguridad y asociarla al EFS que no cumple los requisitos. Necesitarás un comando por cada EFS de tu infraestructura.

arr=( $(aws efs describe-file-systems | jq -r '.FileSystems[].FileSystemId') )
for efs in "${arr[@]}"
do
  aws efs put-backup-policy \
  --file-system-id "${efs}" \
  --backup-policy "Status=ENABLED"
done

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Elb Acm Certificate Required`

Nombre de la categoría en la API: ELB_ACM_CERTIFICATE_REQUIRED

Comprueba si el balanceador de carga clásico usa certificados HTTPS/SSL proporcionados por AWS Certificate Manager (ACM). La comprobación falla si el balanceador de carga clásico configurado con un listener HTTPS o SSL no usa un certificado proporcionado por ACM.

Para crear un certificado, puedes usar ACM o una herramienta que admita los protocolos SSL y TLS, como OpenSSL. Security Hub recomienda que uses ACM para crear o importar certificados para tu balanceador de carga.

ACM se integra con los balanceadores de carga clásicos para que puedas implementar el certificado en tu balanceador de carga. También deberías renovar estos certificados automáticamente.

Recomendación: comprueba que todos los balanceadores de carga clásicos usen certificados SSL proporcionados por AWS Certificate Manager

Para obtener información sobre cómo asociar un certificado SSL/TLS de ACM a un balanceador de carga clásico, consulta el artículo del Centro de conocimientos de AWS ¿Cómo puedo asociar un certificado SSL/TLS de ACM a un balanceador de carga clásico, de aplicaciones o de red?

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Elb Deletion Protection Enabled`

Nombre de la categoría en la API: ELB_DELETION_PROTECTION_ENABLED

Comprueba si un balanceador de carga de aplicación tiene habilitada la protección contra la eliminación. El control falla si no se ha configurado la protección contra la eliminación.

Habilita la protección contra la eliminación para proteger tu balanceador de carga de aplicaciones frente a la eliminación.

Recomendación: La protección contra la eliminación del balanceador de carga de aplicación debe estar habilitada

Para solucionar este problema, siga estos pasos:

Consola de AWS

Para evitar que tu balanceador de carga se elimine por error, puedes habilitar la protección contra la eliminación. De forma predeterminada, la protección contra la eliminación está inhabilitada en el balanceador de carga.

Si habilitas la protección contra la eliminación de tu balanceador de carga, debes inhabilitarla para poder eliminar el balanceador de carga.

Para habilitar la protección frente a la eliminación desde la consola, sigue estos pasos:

Abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
En el panel de navegación, en BALANCEO DE CARGA, elige Balanceadores de carga.
Elige el balanceador de carga.
En la pestaña Descripción, selecciona Editar atributos.
En la página Editar atributos del balanceador de carga, selecciona Habilitar protección contra eliminación y, a continuación, Guardar.
Selecciona Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Elb Logging Enabled`

Nombre de la categoría en la API: ELB_LOGGING_ENABLED

Comprueba si los balanceadores de carga de aplicación y los clásicos tienen el registro habilitado. El control falla si access_logs.s3.enabled es false.

Elastic Load Balancing proporciona registros de acceso que recogen información detallada sobre las solicitudes enviadas a tu balanceador de carga. Cada registro contiene información como la hora en la que se recibió la solicitud, la dirección IP del cliente, las latencias, las rutas de solicitud y las respuestas del servidor. Puede usar estos registros de acceso para analizar patrones de tráfico y solucionar problemas.

Para obtener más información, consulta Registros de acceso de tu balanceador de carga clásico en la guía del usuario de los balanceadores de carga clásicos.

Recomendación: comprueba si los balanceadores de carga de aplicación y los clásicos tienen el registro habilitado

Para solucionar este problema, siga estos pasos:

Consola de AWS

Para solucionar este problema, actualice sus balanceadores de carga para habilitar el registro.

Para habilitar los registros de acceso

Abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
En el panel de navegación, elige Balanceadores de carga.
Elige un balanceador de carga de aplicación o un balanceador de carga clásico.
En Acciones, elija Editar atributos.
En Registros de acceso, elige Habilitar.
Introduce tu ubicación de S3. Esta ubicación puede existir o se puede crear para ti. Si no especifica un prefijo, los registros de acceso se almacenan en la raíz del segmento de S3.
Selecciona Guardar.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Elb Tls Https Listeners Only`

Nombre de la categoría en la API: ELB_TLS_HTTPS_LISTENERS_ONLY

Esta comprobación asegura que todos los balanceadores de carga clásicos estén configurados para usar una comunicación segura.

Un receptor es un proceso que comprueba si hay solicitudes de conexión. Se configura con un protocolo y un puerto para las conexiones de frontend (cliente a balanceador de carga) y un protocolo y un puerto para las conexiones de backend (balanceador de carga a instancia). Para obtener información sobre los puertos, protocolos y configuraciones de escucha compatibles con Elastic Load Balancing, consulta Listeners for your Classic Load Balancer (Procesadores de tu balanceador de carga clásico).

Recomendación: comprueba que todos los balanceadores de carga clásicos estén configurados con procesadores SSL o HTTPS

Para configurar SSL o TLS en balanceadores de carga clásicos, consulta Crear un balanceador de carga HTTPS/SSL con la consola de administración de AWS.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Encrypted Volumes`

Nombre de la categoría en la API: ENCRYPTED_VOLUMES

Comprueba si los volúmenes de EBS que están conectados están cifrados. Para superar esta comprobación, los volúmenes de EBS deben estar en uso y cifrados. Si el volumen de EBS no está conectado, no está sujeto a esta comprobación.

Para añadir una capa de seguridad a tus datos sensibles en los volúmenes de EBS, debes habilitar el cifrado de EBS en reposo. El cifrado de Amazon EBS ofrece una solución de cifrado sencilla para tus recursos de EBS que no requiere que crees, mantengas y protejas tu propia infraestructura de gestión de claves. Usa claves de KMS al crear volúmenes y capturas cifrados.

Para obtener más información sobre el cifrado de Amazon EBS, consulta el artículo sobre el cifrado de Amazon EBS en la guía del usuario de Amazon EC2 para instancias Linux.

Recomendación: Los volúmenes de Amazon EBS conectados deben estar encriptados en reposo

Para solucionar este problema, siga estos pasos:

Consola de AWS

No hay ninguna forma directa de cifrar un volumen o una instantánea que no estén cifrados. Solo puedes cifrar un volumen o una instantánea nuevos cuando los creas.

Si has habilitado el cifrado de forma predeterminada, Amazon EBS cifrará el nuevo volumen o la nueva instantánea con tu clave predeterminada para el cifrado de Amazon EBS. Aunque no hayas habilitado el cifrado de forma predeterminada, puedes hacerlo al crear un volumen o una instantánea concretos. En ambos casos, puede anular la clave predeterminada para el cifrado de Amazon EBS y elegir una clave simétrica gestionada por el cliente.

Para obtener más información, consulta Crear un volumen de Amazon EBS y Copiar una instantánea de Amazon EBS en la guía del usuario de Amazon EC2 para instancias Linux.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Encryption At Rest Enabled Rds Instances`

Nombre de la categoría en la API: ENCRYPTION_AT_REST_ENABLED_RDS_INSTANCES

Las instancias de base de datos cifradas de Amazon RDS usan el algoritmo de cifrado AES-256 estándar del sector para cifrar los datos en el servidor que aloja las instancias de base de datos de Amazon RDS. Una vez que se cifran los datos, Amazon RDS gestiona la autenticación del acceso y el descifrado de los datos de forma transparente y con un impacto mínimo en el rendimiento.

Recomendación: Asegúrate de que el cifrado en reposo esté habilitado en las instancias de RDS

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de gestión de AWS y abre el panel de control de RDS en https://console.aws.amazon.com/rds/.
En el panel de navegación de la izquierda, haz clic en Databases.
Selecciona la instancia de base de datos que quieras cifrar.
Haz clic en el botón Actions situado en la parte superior derecha y selecciona Take Snapshot.
En la página Crear copia, introduzca el nombre de la base de datos de la que quiera crear una copia en el campo Snapshot Name y haga clic en Take Snapshot.
Selecciona la instantánea que acabas de crear, haz clic en el botón Action situado en la parte superior derecha y, en el menú Acción, selecciona Copy snapshot.
En la página Make Copy of DB Snapshot (Crear copia de la instantánea de la base de datos), haz lo siguiente:

En el campo Nuevo identificador de la instantánea de la base de datos, introduzca un nombre para la new snapshot.
Comprueba Copy Tags. La nueva versión debe tener las mismas etiquetas que la versión de origen.
Selecciona Yes en la lista desplegable Enable Encryption para habilitar el cifrado. Puedes usar la clave de cifrado predeterminada de AWS o una clave personalizada de la lista desplegable Clave maestra.

Haz clic en Copy Snapshot para crear una copia cifrada de la captura de la instancia seleccionada.
Selecciona la nueva copia cifrada de la instantánea y haz clic en el botón Action situado en la parte superior derecha. A continuación, selecciona el botón Restore Snapshot en el menú Acción. De esta forma, se restaurará la instantánea cifrada en una nueva instancia de base de datos.
En la página Restore DB Instance (Restaurar instancia de base de datos), escriba un nombre único para la nueva instancia de base de datos en el campo DB Instance Identifier (Identificador de instancia de base de datos).
Revisa los detalles de la configuración de la instancia y haz clic en Restore DB Instance.
Una vez que se haya completado el proceso de aprovisionamiento de la nueva instancia, puede actualizar la configuración de la aplicación para que haga referencia al endpoint de la nueva instancia de base de datos cifrada. Cuando se haya cambiado el endpoint de la base de datos en la aplicación, puede quitar la instancia sin cifrar.

CLI de AWS

Ejecuta el comando describe-db-instances para enumerar todos los nombres de bases de datos de RDS disponibles en la región de AWS seleccionada. El resultado del comando debe devolver el identificador de la instancia de la base de datos.

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

Ejecuta el comando create-db-snapshot para crear una instantánea de la instancia de base de datos seleccionada. El resultado del comando devolverá el new snapshot con el nombre "DB Snapshot Name".

aws rds create-db-snapshot --region <region-name> --db-snapshot-identifier <DB-Snapshot-Name> --db-instance-identifier <DB-Name>

Ahora, ejecuta el comando list-aliases para enumerar los alias de las claves de KMS disponibles en una región específica. El resultado del comando debe devolver cada key alias currently available. Para nuestro proceso de activación del cifrado de RDS, busca el ID de la clave de KMS predeterminada de AWS.

aws kms list-aliases --region <region-name>

Ejecuta el comando copy-db-snapshot con el ID de clave de KMS predeterminado de las instancias de RDS devueltas anteriormente para crear una copia cifrada de la instantánea de la instancia de base de datos. El resultado del comando devolverá el encrypted instance snapshot configuration.

aws rds copy-db-snapshot --region <region-name> --source-db-snapshot-identifier <DB-Snapshot-Name> --target-db-snapshot-identifier <DB-Snapshot-Name-Encrypted> --copy-tags --kms-key-id <KMS-ID-For-RDS>

Ejecuta el comando restore-db-instance-from-db-snapshot para restaurar la instantánea cifrada creada en el paso anterior en una nueva instancia de base de datos. Si la acción se realiza correctamente, el resultado del comando debería devolver la configuración de la nueva instancia de base de datos cifrada.

aws rds restore-db-instance-from-db-snapshot --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --db-snapshot-identifier <DB-Snapshot-Name-Encrypted>

Ejecuta el comando describe-db-instances para enumerar todos los nombres de bases de datos de RDS disponibles en la región de AWS seleccionada. El resultado devolverá el nombre del identificador de la instancia de base de datos. Selecciona el nombre de la base de datos cifrada que acabamos de crear (DB-Name-Encrypted).

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

Vuelve a ejecutar el comando describe-db-instances con el identificador de instancia de RDS que has obtenido antes para determinar si la instancia de base de datos seleccionada está cifrada. El resultado del comando debe devolver el estado del cifrado True.

aws rds describe-db-instances --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --query 'DBInstances[*].StorageEncrypted'

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Encryption Enabled Efs File Systems`

Nombre de la categoría en la API: ENCRYPTION_ENABLED_EFS_FILE_SYSTEMS

Los datos de EFS deben cifrarse en reposo con AWS KMS (Key Management Service).

Recomendación: Asegúrate de que el cifrado esté habilitado en los sistemas de archivos de EFS

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de administración de AWS y ve al panel de control de Elastic File System (EFS).
En el panel de navegación de la izquierda, selecciona File Systems.
Haz clic en el botón Create File System del menú superior del panel de control para iniciar el proceso de configuración del sistema de archivos.
En la página de configuración de Configure file system access, haz lo siguiente.
- Elige la VPC adecuada en la lista desplegable de VPCs.
- En la sección "Create mount targets" (Crear destinos de montaje), selecciona las casillas de todas las zonas de disponibilidad de la VPC seleccionada. Estos serán tus objetivos de montaje.
- Haz clic en Next step para continuar.
Haz lo siguiente en la página Configure optional settings.
- Crea un tags para describir el nuevo sistema de archivos.
- Elige performance mode según tus requisitos.
- Marca la casilla Enable encryption y elige aws/elasticfilesystem en la lista desplegable Seleccionar clave maestra de KMS para habilitar el cifrado del nuevo sistema de archivos con la clave maestra predeterminada proporcionada y gestionada por AWS KMS.
- Haz clic en Next step para continuar.
Revisa los detalles de la configuración del sistema de archivos en la página review and create y, a continuación, haz clic en Create File System para crear tu nuevo sistema de archivos de AWS EFS.
Copia los datos del sistema de archivos EFS antiguo sin cifrar en el sistema de archivos cifrado que acabas de crear.
Elimina el sistema de archivos sin cifrar en cuanto se haya completado la migración de datos al sistema de archivos cifrado que has creado.
Cambia la región de AWS en la barra de navegación y repite todo el proceso para otras regiones de AWS.

Desde la CLI:
1. Ejecuta el comando describe-file-systems para describir la información de configuración disponible para el sistema de archivos seleccionado (sin cifrar). Consulta la sección Auditoría para identificar el recurso adecuado:

aws efs describe-file-systems --region <region> --file-system-id <file-system-id from audit section step 2 output>

El resultado del comando debe devolver la información de configuración solicitada.
Para aprovisionar un nuevo sistema de archivos de AWS EFS, debe generar un identificador único universal (UUID) para crear el token que requiere el comando create-file-system. Para crear el token necesario, puedes usar un UUID generado aleatoriamente desde "https://www.uuidgenerator.net".
Ejecuta el comando create-file-system con el token único creado en el paso anterior.

aws efs create-file-system --region <region> --creation-token <Token (randomly generated UUID from step 3)> --performance-mode generalPurpose --encrypted

La salida del comando debe devolver los metadatos de la nueva configuración del sistema de archivos.
Ejecuta el comando create-mount-target con el ID del sistema de archivos EFS recién creado, que se ha devuelto en el paso anterior, como identificador y el ID de la zona de disponibilidad (AZ) que representará el destino de montaje:

aws efs create-mount-target --region <region> --file-system-id <file-system-id> --subnet-id <subnet-id>

La salida del comando debería devolver los metadatos del nuevo destino de montaje.
Ahora puedes montar tu sistema de archivos desde una instancia EC2.
Copia los datos del sistema de archivos EFS antiguo sin cifrar en el sistema de archivos cifrado que acabas de crear.
Elimina el sistema de archivos sin cifrar en cuanto se haya completado la migración de datos al sistema de archivos cifrado que has creado.

aws efs delete-file-system --region <region> --file-system-id <unencrypted-file-system-id>

Cambia la región de AWS actualizando --region y repite todo el proceso para otras regiones de AWS.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Iam Password Policy`

Nombre de la categoría en la API: IAM_PASSWORD_POLICY

AWS permite aplicar políticas de contraseñas personalizadas en tu cuenta de AWS para especificar los requisitos de complejidad y los periodos de rotación obligatorios de las contraseñas de tus usuarios de IAM. Si no defines una política de contraseñas personalizada, las contraseñas de los usuarios de IAM deben cumplir la política de contraseñas predeterminada de AWS. En las prácticas recomendadas de seguridad de AWS se indican los siguientes requisitos de complejidad de las contraseñas:

Requerir al menos un carácter en mayúscula en la contraseña.
Exige que las contraseñas incluyan al menos un carácter en minúscula.
Requerir al menos un símbolo en las contraseñas.
Requerir al menos un número en las contraseñas.
Exige que las contraseñas tengan una longitud mínima de 14 caracteres.
Requiere al menos 24 contraseñas antes de permitir la reutilización.
Requerir al menos 90 días antes de que caduque la contraseña

Esta opción controla todos los requisitos de la política de contraseñas especificada.

Recomendación: comprueba si la política de contraseñas de la cuenta de los usuarios de IAM cumple los requisitos especificados

Para solucionar este problema, siga estos pasos:

Terraform

resource "aws_iam_account_password_policy" "strict" {
  allow_users_to_change_password = true
  require_uppercase_characters   = true
  require_lowercase_characters   = true
  require_symbols                = true
  require_numbers                = true
  minimum_password_length        = 14
  password_reuse_prevention      = 24
  max_password_age               = 90
}

Consola de AWS

Para crear una política de contraseñas personalizada

Inicia sesión en la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
En el panel de navegación, elija Configuración de la cuenta.
En la sección Política de contraseñas, elige Cambiar política de contraseñas.
Selecciona las opciones que quieras aplicar a tu política de contraseñas y elige Guardar cambios.

Para cambiar una política de contraseñas personalizada

Inicia sesión en la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
En el panel de navegación, elija Configuración de la cuenta.
En la sección Política de contraseñas, elige Cambiar.
Selecciona las opciones que quieras aplicar a tu política de contraseñas y elige Guardar cambios.

CLI de AWS

aws iam update-account-password-policy \
--allow-users-to-change-password \
--require-uppercase-characters \
--require-lowercase-characters \
--require-symbols \
--require-numbers \
--minimum-password-length 14 \
--password-reuse-prevention 24 \
--max-password-age 90

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Iam Password Policy Prevents Password Reuse`

Nombre de la categoría en la API: IAM_PASSWORD_POLICY_PREVENTS_PASSWORD_REUSE

Las políticas de contraseñas de IAM pueden impedir que el mismo usuario reutilice una contraseña determinada. Se recomienda que la política de contraseñas impida que se reutilicen las contraseñas.

Recomendación: Asegúrate de que la política de contraseñas de IAM impida que se reutilicen las contraseñas

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de AWS (con los permisos adecuados para ver la configuración de la cuenta de gestión de identidades y accesos).
Ve a Cuentas de servicio de IAM en la consola de AWS
Haga clic en Configuración de la cuenta en el panel de la izquierda.
Marca la opción "Impedir que se reutilicen contraseñas".
La opción "Número de contraseñas que recordar" está definida en 24

CLI de AWS

 aws iam update-account-password-policy --password-reuse-prevention 24

Nota: Todos los comandos que empiezan por "aws iam update-account-password-policy" se pueden combinar en un solo comando.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Iam Password Policy Requires Minimum Length 14 Greater`

Nombre de la categoría en la API: IAM_PASSWORD_POLICY_REQUIRES_MINIMUM_LENGTH_14_GREATER

Las políticas de contraseñas se usan, en parte, para aplicar los requisitos de complejidad de las contraseñas. Las políticas de contraseñas de IAM se pueden usar para asegurarse de que las contraseñas tengan al menos una longitud determinada. Se recomienda que la política de contraseñas requiera una longitud mínima de 14 caracteres.

Recomendación: Asegúrate de que la política de contraseñas de IAM requiera una longitud mínima de 14 caracteres

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de AWS (con los permisos adecuados para ver la configuración de la cuenta de gestión de identidades y accesos).
Ve a Cuentas de servicio de IAM en la consola de AWS
Haga clic en Configuración de la cuenta en el panel de la izquierda.
Define "Longitud mínima de la contraseña" como 14 o un valor superior.
Haz clic en "Aplicar política de contraseñas".

CLI de AWS

 aws iam update-account-password-policy --minimum-password-length 14

Nota: Todos los comandos que empiezan por "aws iam update-account-password-policy" se pueden combinar en un solo comando.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Iam Policies Allow Full Administrative Privileges Attached`

Nombre de la categoría en la API: IAM_POLICIES_ALLOW_FULL_ADMINISTRATIVE_PRIVILEGES_ATTACHED

Las políticas de IAM son el medio por el que se conceden privilegios a usuarios, grupos o roles. Se recomienda y se considera una práctica de seguridad estándar conceder mínimos accesos, es decir, conceder solo los permisos necesarios para realizar una tarea. Determina qué deben hacer los usuarios y, a continuación, crea políticas para ellos que les permitan realizar solo esas tareas, en lugar de concederles privilegios de administrador completos.

Recomendación: Asegúrate de que no se hayan asociado políticas de IAM que permitan privilegios administrativos completos de "*:*"

Para solucionar este problema, siga estos pasos:

Consola de AWS

Sigue estos pasos para desasociar la política que tiene privilegios administrativos completos:

Inicia sesión en la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
En el panel de navegación, haga clic en Políticas y, a continuación, busque el nombre de la política que ha encontrado en el paso de auditoría.
Selecciona la política que quieras eliminar.
En el menú de acciones de la política, selecciona primero Detach
Seleccionar todos los usuarios, grupos y roles que tengan esta política asociada
Haz clic en Detach Policy.
En el menú de acciones de la política, selecciona Detach.

CLI de AWS

Siga estos pasos para separar la política que tiene privilegios administrativos completos, tal como se indica en el paso de auditoría:

Enumera todos los usuarios, grupos y roles de gestión de identidades y accesos a los que está asociada la política gestionada especificada.

 aws iam list-entities-for-policy --policy-arn <policy_arn>

Desvincula la política de todos los usuarios de gestión de identidades y accesos:

 aws iam detach-user-policy --user-name <iam_user> --policy-arn <policy_arn>

Desasocia la política de todos los grupos de gestión de identidades y accesos:

 aws iam detach-group-policy --group-name <iam_group> --policy-arn <policy_arn>

Desasocia la política de todos los roles de gestión de identidades y accesos:

 aws iam detach-role-policy --role-name <iam_role> --policy-arn <policy_arn>

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Iam Users Receive Permissions Groups`

Nombre de la categoría en la API: IAM_USERS_RECEIVE_PERMISSIONS_GROUPS

Los usuarios de gestión de identidades y accesos obtienen acceso a servicios, funciones y datos a través de políticas de gestión de identidades y accesos. Hay cuatro formas de definir políticas para un usuario: 1) editar la política de usuario directamente (también conocida como política insertada o política de usuario); 2) adjuntar una política directamente a un usuario; 3) añadir el usuario a un grupo de gestión de identidades y accesos que tenga una política adjunta; 4) añadir el usuario a un grupo de gestión de identidades y accesos que tenga una política insertada.

Solo se recomienda la tercera implementación.

Recomendación: Asegúrate de que los usuarios de IAM solo reciban permisos a través de grupos

Sigue estos pasos para crear un grupo de gestión de identidades y accesos y asignarle una política:

Inicia sesión en la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
En el panel de navegación, haga clic en Groups y, a continuación, en Create New Group .
En el cuadro Group Name, escribe el nombre del grupo y haz clic en Next Step .
En la lista de políticas, marca la casilla de cada política que quieras aplicar a todos los miembros del grupo. A continuación, haz clic en Next Step .
Haz clic en Create Group.

Sigue estos pasos para añadir un usuario a un grupo determinado:

Inicia sesión en la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
En el panel de navegación, haz clic en Groups.
Selecciona el grupo al que quieras añadir un usuario
Haz clic en Add Users To Group.
Selecciona los usuarios que quieras añadir al grupo.
Haz clic en Add Users.

Para eliminar una asociación directa entre un usuario y una política, haz lo siguiente:

Inicia sesión en la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
En el panel de navegación de la izquierda, haga clic en Usuarios.
Para cada usuario:
- Selecciona el usuario.
- Haz clic en la pestaña Permissions.
- Despliega Permissions policies
- Haz clic en X en cada política y, a continuación, haz clic en Desvincular o Quitar (en función del tipo de política).

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Iam User Group Membership Check`

Nombre de la categoría en la API: IAM_USER_GROUP_MEMBERSHIP_CHECK

Los usuarios de IAM siempre deben formar parte de un grupo de IAM para cumplir las prácticas recomendadas de seguridad de IAM.

Si añades usuarios a un grupo, podrás compartir políticas entre tipos de usuarios.

Recomendación: comprueba si los usuarios de IAM son miembros de al menos un grupo de IAM

Para solucionar este problema, siga estos pasos:

Terraform

resource "aws_iam_user" "example" {
  name = "test-iam-user"
  path = "/users/dev/"
}

resource "aws_iam_group" "example" {
  name = "Developers"
  path = "/users/dev/"
}

resource "aws_iam_user_group_membership" "example" {
  user   = aws_iam_user.example.name
  groups = [aws_iam_group.example.name]
}

Consola de AWS

Cuando utiliza la consola de administración de AWS para eliminar un usuario de IAM, IAM elimina automáticamente la siguiente información:

El usuario
Las pertenencias a grupos de usuarios, es decir, el usuario se elimina de todos los grupos de usuarios de IAM a los que pertenecía.
Cualquier contraseña asociada al usuario
Cualquier clave de acceso que pertenezca al usuario
Todas las políticas insertadas en el usuario (las políticas que se aplican a un usuario a través de los permisos de un grupo de usuarios no se ven afectadas)

Para eliminar un usuario de IAM, sigue estos pasos:

Inicia sesión en la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
En el panel de navegación, elija Usuarios y, a continuación, marque la casilla situada junto al nombre del usuario que quiera eliminar.
En la parte superior de la página, selecciona Eliminar.
En el cuadro de diálogo de confirmación, introduce el nombre de usuario en el campo de entrada de texto para confirmar la eliminación del usuario.
Elige Eliminar.

Para añadir un usuario a un grupo de usuarios de IAM, sigue estos pasos:

Inicia sesión en la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
En el panel de navegación, elige Grupos de usuarios y, a continuación, el nombre del grupo.
Elige la pestaña Usuarios y, a continuación, Añadir usuarios. Seleccione la casilla situada junto a los usuarios que quiera añadir.
Elige Añadir usuarios.

CLI de AWS

A diferencia de la consola de administración de Amazon Web Services, cuando eliminas un usuario mediante programación, debes eliminar manualmente los elementos asociados al usuario. De lo contrario, la eliminación no se realizará.

Antes de intentar eliminar un usuario, quita los siguientes elementos:

Contraseña ( DeleteLoginProfile )
Claves de acceso ( DeleteAccessKey )
Certificado de firma ( DeleteSigningCertificate )
Clave pública SSH ( DeleteSSHPublicKey )
Credenciales de Git ( DeleteServiceSpecificCredential )
Dispositivo de autenticación multifactor (MFA) ( DeactivateMFADevice , DeleteVirtualMFADevice )
Políticas insertadas ( DeleteUserPolicy )
Políticas gestionadas asociadas ( DetachUserPolicy )
Pertenencias a grupos ( RemoveUserFromGroup )

Para eliminar un usuario, después de eliminar todos los elementos asociados a él, sigue estos pasos:

aws iam delete-user \
  --user-name "test-user"

Para añadir un usuario de gestión de identidades y accesos a un grupo de gestión de identidades y accesos, sigue estos pasos:

aws iam add-user-to-group \
  --group-name "test-group"
  --user-name "test-user"

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Iam User Mfa Enabled`

Nombre de la categoría en la API: IAM_USER_MFA_ENABLED

La autenticación multifactor (MFA) es una práctica recomendada que añade una capa de protección adicional a los nombres de usuario y las contraseñas. Con la MFA, cuando un usuario inicia sesión en la consola de administración de AWS, debe proporcionar un código de autenticación que depende del tiempo y que le proporciona un dispositivo virtual o físico registrado.

Recomendación: comprueba si los usuarios de AWS IAM tienen habilitada la autenticación multifactor (MFA)

Para solucionar este problema, siga estos pasos:

Terraform

En el caso de Terraform, hay varias opciones para solucionar la ausencia de dispositivos MFA. Seguramente ya tengas una estructura lógica para organizar a tus usuarios en grupos y políticas restrictivas.

En el siguiente ejemplo se muestra cómo hacer lo siguiente:

Crear usuarios.
Crea perfiles de inicio de sesión de usuarios con una clave pública PGP.
Crea un grupo y una política de grupo que permitan la autogestión del perfil de gestión de identidades y accesos.
Asigna usuarios al grupo.
Crea dispositivos de MFA virtual para los usuarios.
Proporciona a cada usuario el código QR y la contraseña.

variable "users" {
  type = set(string)
  default = [
    "test@example.com",
    "test2@example.com"
  ]
}

resource "aws_iam_user" "test_users" {
  for_each = toset(var.users)
  name     = each.key
}

resource "aws_iam_user_login_profile" "test_users_profile" {
  for_each                = var.users
  user                    = each.key
  # Key pair created using GnuPG, this is the public key
  pgp_key = file("path/to/gpg_pub_key_base64.pem")
  password_reset_required = true
  lifecycle {
    ignore_changes = [
      password_length,
      password_reset_required,
      pgp_key,
    ]
  }
}

resource "aws_iam_virtual_mfa_device" "test_mfa" {
  for_each                = toset(var.users)
  virtual_mfa_device_name = each.key
}

resource "aws_iam_group" "enforce_mfa_group" {
  name = "EnforceMFAGroup"
}

resource "aws_iam_group_membership" "enforce_mfa_group_membership" {
  name  = "EnforceMFAGroupMembership"
  group = aws_iam_group.enforce_mfa_group.name
  users = [for k in aws_iam_user.test_users : k.name]
}

resource "aws_iam_group_policy" "enforce_mfa_policy" {
  name   = "EnforceMFAGroupPolicy"
  group  = aws_iam_group.enforce_mfa_group.id
  policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
        "Sid": "AllowViewAccountInfo",
        "Effect": "Allow",
        "Action": [
            "iam:GetAccountPasswordPolicy",
            "iam:ListVirtualMFADevices"
        ],
        "Resource": "*"
    },
    {
        "Sid": "AllowManageOwnPasswords",
        "Effect": "Allow",
        "Action": [
            "iam:ChangePassword",
            "iam:GetUser"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnAccessKeys",
        "Effect": "Allow",
        "Action": [
            "iam:CreateAccessKey",
            "iam:DeleteAccessKey",
            "iam:ListAccessKeys",
            "iam:UpdateAccessKey"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnSigningCertificates",
        "Effect": "Allow",
        "Action": [
            "iam:DeleteSigningCertificate",
            "iam:ListSigningCertificates",
            "iam:UpdateSigningCertificate",
            "iam:UploadSigningCertificate"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnSSHPublicKeys",
        "Effect": "Allow",
        "Action": [
            "iam:DeleteSSHPublicKey",
            "iam:GetSSHPublicKey",
            "iam:ListSSHPublicKeys",
            "iam:UpdateSSHPublicKey",
            "iam:UploadSSHPublicKey"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnGitCredentials",
        "Effect": "Allow",
        "Action": [
            "iam:CreateServiceSpecificCredential",
            "iam:DeleteServiceSpecificCredential",
            "iam:ListServiceSpecificCredentials",
            "iam:ResetServiceSpecificCredential",
            "iam:UpdateServiceSpecificCredential"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnVirtualMFADevice",
        "Effect": "Allow",
        "Action": [
            "iam:CreateVirtualMFADevice",
            "iam:DeleteVirtualMFADevice"
        ],
        "Resource": "arn:aws:iam::*:mfa/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnUserMFA",
        "Effect": "Allow",
        "Action": [
            "iam:DeactivateMFADevice",
            "iam:EnableMFADevice",
            "iam:ListMFADevices",
            "iam:ResyncMFADevice"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "DenyAllExceptListedIfNoMFA",
        "Effect": "Deny",
        "NotAction": [
            "iam:CreateVirtualMFADevice",
            "iam:EnableMFADevice",
            "iam:GetUser",
            "iam:ListMFADevices",
            "iam:ListVirtualMFADevices",
            "iam:ResyncMFADevice",
            "sts:GetSessionToken"
        ],
        "Resource": "*",
        "Condition": {
            "BoolIfExists": {
                "aws:MultiFactorAuthPresent": "false"
            }
        }
    }
  ]
}
POLICY
}

output "user_password_map" {
  # Outputs a map in the format {"test@example.com": <PGPEncryptedPassword>, "test2@example.com": <PGPEncryptedPassword>}
  value = { for k, v in aws_iam_user_login_profile.test_users_profile : k => v.password }
}

output "user_qr_map" {
  # Outputs a map in the format {"test@example.com": <QRCode>, "test2@example.com": <QRCode>}
  value = { for k, v in aws_iam_virtual_mfa_device.test_mfa : k => v.qr_code_png }
}

Consola de AWS

Para habilitar la MFA en cualquier cuenta de usuario con acceso a la consola de AWS, consulta el artículo Habilitar un dispositivo de autenticación multifactor (MFA) virtual (consola) en la documentación de AWS.

CLI de AWS

Crear un dispositivo de MFA

aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name "test@example.com" \
  --outfile ./QRCode.png \
  --bootstrap-method QRCodePNG

Habilitar un dispositivo de MFA para un usuario

aws iam enable-mfa-device \
  --user-name "test@example.com" \
  --serial-number "arn:aws:iam::123456976749:mfa/test@example.com" \
  --authentication-code1 123456 \
  --authentication-code2 654321

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Iam User Unused Credentials Check`

Nombre de la categoría en la API: IAM_USER_UNUSED_CREDENTIALS_CHECK

Comprueba si hay contraseñas de IAM o claves de acceso activas que no se hayan usado en los últimos 90 días.

Las prácticas recomendadas indican que debes eliminar, desactivar o rotar todas las credenciales que no se hayan usado durante 90 días o más. De esta forma, se reduce el tiempo que se pueden usar las credenciales asociadas a una cuenta vulnerada o abandonada.

Recomendación: comprueba que todos los usuarios de AWS IAM tengan contraseñas o claves de acceso activas que no se hayan usado en maxCredentialUsageAge días (90 días de forma predeterminada)

Para solucionar este problema, siga estos pasos:

Terraform

Para quitar las claves de acceso caducadas creadas mediante Terraform, elimina el recurso aws_iam_access_key de tu módulo y aplica el cambio.

Para cambiar la contraseña de inicio de sesión de un usuario de IAM, usa -replace al ejecutar terraform apply.

Supongamos que tenemos el siguiente perfil de inicio de sesión de usuario:

resource "aws_iam_user" "example" {
  name          = "test@example.com"
  path          = "/users/"
  force_destroy = true
}

resource "aws_iam_user_login_profile" "example" {
  user    = aws_iam_user.example.name
  pgp_key = "keybase:some_person_that_exists"
}

Ejecuta el siguiente comando para cambiar la contraseña del perfil de inicio de sesión del usuario

terraform apply -replace="aws_iam_user_login_profile.example"

Consola de AWS

Para inhabilitar las credenciales de las cuentas inactivas, sigue estos pasos:

Abre la consola de IAM en https://console.aws.amazon.com/iam/.
Elige Usuarios.
Elige el nombre del usuario cuyas credenciales tengan más de 90 días o se hayan usado por última vez hace más de 90 días.
Elige Credenciales de seguridad.
En cada credencial de inicio de sesión y clave de acceso que no se haya usado en al menos 90 días, elija Inactivar.

Para solicitar una contraseña nueva a los usuarios de la consola en el próximo inicio de sesión, sigue estos pasos:

Abre la consola de IAM en https://console.aws.amazon.com/iam/.
Elige Usuarios.
Elige el nombre del usuario cuyas credenciales tengan más de 90 días o se hayan usado por última vez hace más de 90 días.
Elige Credenciales de seguridad.
En Credenciales de inicio de sesión y contraseña de la consola, elige Gestionar.
Define una contraseña nueva (generada automáticamente o personalizada).
Marca la casilla para requerir el cambio de contraseña.
Elige Aplicar.

CLI de AWS

Para desactivar las claves de acceso

aws iam update-access-key \
  --access-key-id <value> \
  --status "Inactive"

Para eliminar claves de acceso

aws iam delete-access-key \
  --access-key-id <value>

Para cambiar la contraseña de un perfil de inicio de sesión de usuario

aws iam update-login-profile \
  --user-name "test@example.com" \
  --password <temporary_password> \
  --password-reset-required

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Kms Cmk Not Scheduled For Deletion`

Nombre de la categoría en la API: KMS_CMK_NOT_SCHEDULED_FOR_DELETION

Este control comprueba si se ha programado la eliminación de las claves de KMS. El control falla si se ha programado la eliminación de una clave de KMS.

Las claves de KMS no se pueden recuperar una vez eliminadas. Los datos cifrados con una clave de KMS tampoco se pueden recuperar de forma permanente si se elimina la clave de KMS. Si se han cifrado datos significativos con una clave de KMS programada para su eliminación, considera la posibilidad de descifrar los datos o volver a cifrarlos con una nueva clave de KMS, a menos que estés realizando una eliminación criptográfica de forma intencionada.

Cuando se programa la eliminación de una clave de KMS, se aplica un periodo de espera obligatorio para que se pueda cancelar la eliminación si se ha programado por error. El periodo de espera predeterminado es de 30 días, pero se puede reducir a 7 días cuando se programa la eliminación de la clave de KMS. Durante el periodo de espera, se puede cancelar la eliminación programada y la clave de KMS no se eliminará.

Para obtener más información sobre cómo eliminar claves de KMS, consulta el artículo Eliminar claves de KMS de la guía para desarrolladores de AWS Key Management Service.

Recomendación: comprueba que no se haya programado la eliminación de todos los CMKs

Para cancelar la eliminación programada de una clave de KMS, consulta la sección To cancel key deletion under Scheduling and canceling key deletion (console) (Cancelar la eliminación de una clave en Programación y cancelación de la eliminación de claves [consola]) de la guía para desarrolladores de AWS Key Management Service.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Lambda Concurrency Check`

Nombre de la categoría en la API: LAMBDA_CONCURRENCY_CHECK

Comprueba si la función Lambda está configurada con un límite de ejecución simultánea a nivel de función. La regla es NON_COMPLIANT si la función de Lambda no está configurada con un límite de ejecución simultánea a nivel de función.

Recomendación: comprueba si las funciones de Lambda están configuradas con un límite de ejecución simultánea a nivel de función

Para configurar un límite de ejecución simultánea a nivel de función, consulta Configurar la simultaneidad reservada en la documentación de AWS Lambda.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Lambda Dlq Check`

Nombre de la categoría en la API: LAMBDA_DLQ_CHECK

Comprueba si una función Lambda está configurada con una cola de mensajes fallidos. La regla es NON_COMPLIANT si la función de Lambda no está configurada con una cola de mensajes fallidos.

Recomendación: comprueba si las funciones de Lambda están configuradas con una cola de mensajes fallidos

Para actualizar las funciones de Lambda de forma que usen colas de mensajes fallidos, consulta Colas de mensajes fallidos en la documentación de AWS.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Lambda Function Public Access Prohibited`

Nombre de la categoría en la API: LAMBDA_FUNCTION_PUBLIC_ACCESS_PROHIBITED

Las prácticas recomendadas de AWS indican que las funciones de Lambda no deben exponerse públicamente. Esta política comprueba todas las funciones Lambda implementadas en todas las regiones habilitadas de tu cuenta y fallará si están configuradas para permitir el acceso público.

Recomendación: comprueba si la política adjunta a la función Lambda prohíbe el acceso público

Para solucionar este problema, siga estos pasos:

Terraform

En el siguiente ejemplo se muestra cómo usar Terraform para aprovisionar un rol de gestión de identidades y accesos que restrinja el acceso a una función de Lambda y cómo adjuntar ese rol a la función de Lambda.

resource "aws_iam_role" "iam_for_lambda" {
  name = "iam_for_lambda"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

resource "aws_lambda_function" "test_lambda" {
  filename      = "lambda_function_payload.zip"
  function_name = "lambda_function_name"
  role          = aws_iam_role.iam_for_lambda.arn
  handler       = "index.test"

  source_code_hash = filebase64sha256("lambda_function_payload.zip")

  runtime = "nodejs12.x"

}

Consola de AWS

Si una función Lambda no supera este control, significa que la instrucción de la política basada en recursos de la función Lambda permite el acceso público.

Para solucionar el problema, debe actualizar la política para quitar los permisos o añadir la condición AWS:SourceAccount. Solo puedes actualizar la política basada en recursos desde la API de Lambda.

En las siguientes instrucciones se utiliza la consola para revisar la política y la interfaz de línea de comandos de AWS para eliminar los permisos.

Para ver la política basada en recursos de una función Lambda

Abre la consola de AWS Lambda en https://console.aws.amazon.com/lambda/.
En el panel de navegación, elige Funciones.
Elige la función.
Elige Permisos. La política basada en recursos muestra los permisos que se aplican cuando otra cuenta o servicio de AWS intenta acceder a la función.
Examina la política basada en recursos.
Identifica la instrucción de la política que tiene valores en el campo Principal que hacen que la política sea pública. Por ejemplo, permitir "*" o { "AWS": "*" }.

No puedes editar la política desde la consola. Para quitar permisos de la función, usa el comando remove-permission de la CLI de AWS.

Anota el valor del ID de la instrucción (Sid) de la instrucción que quieras quitar.

CLI de AWS

Para usar la CLI y quitar permisos de una función Lambda, ejecuta el comando remove-permission de la siguiente manera.

aws lambda remove-permission \
--function-name <value> \
--statement-id <value>

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Lambda Inside Vpc`

Nombre de la categoría en la API: LAMBDA_INSIDE_VPC

Comprueba si una función Lambda está en una VPC. Es posible que veas resultados fallidos de recursos de Lambda@Edge.

No evalúa la configuración de enrutamiento de la subred de la VPC para determinar la accesibilidad pública.

Recomendación: comprueba si las funciones Lambda existen en una VPC

Para solucionar este problema, siga estos pasos:

Consola de AWS

Para configurar una función que se conecte a subredes privadas de una nube privada virtual (VPC) de tu cuenta, sigue estos pasos:

Abre la consola de AWS Lambda en https://console.aws.amazon.com/lambda/.
Ve a Funciones y selecciona tu función Lambda.
Desplázate hasta Red y, a continuación, selecciona una VPC que cumpla los requisitos de conectividad de la función.
Para ejecutar tus funciones en modo de alta disponibilidad, Security Hub te recomienda que elijas al menos dos subredes.
Elige al menos un grupo de seguridad que cumpla los requisitos de conectividad de la función.
Selecciona Guardar.

Para obtener más información, consulta la sección sobre cómo configurar una función Lambda para acceder a recursos de una VPC en la guía para desarrolladores de AWS Lambda.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Mfa Delete Enabled S3 Buckets`

Nombre de la categoría en la API: MFA_DELETE_ENABLED_S3_BUCKETS

Una vez que la eliminación de MFA esté habilitada en tu bucket de S3 sensible y clasificado, el usuario deberá tener dos formas de autenticación.

Recomendación: Asegúrate de que la eliminación de MFA esté habilitada en los buckets de S3

Sigue los pasos que se indican a continuación para habilitar la eliminación de MFA en un bucket de S3.

Nota:
- No puedes habilitar la eliminación con MFA mediante la consola de administración de AWS. Debes usar la CLI o la API de AWS.
- Debes usar tu cuenta raíz para habilitar la eliminación de MFA en los buckets de S3.

Desde la línea de comandos:

Ejecuta el comando s3api put-bucket-versioning

aws s3api put-bucket-versioning --profile my-root-profile --bucket Bucket_Name --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa “arn:aws:iam::aws_account_id:mfa/root-account-mfa-device passcode”

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Mfa Enabled Root User Account`

Nombre de la categoría en la API: MFA_ENABLED_ROOT_USER_ACCOUNT

La cuenta de usuario "root" es el usuario con más privilegios de una cuenta de AWS. La autenticación multifactor (MFA) añade una capa de protección adicional a un nombre de usuario y una contraseña. Con la MFA habilitada, cuando un usuario inicia sesión en un sitio web de AWS, se le pedirá su nombre de usuario y contraseña, así como un código de autenticación de su dispositivo de MFA de AWS.

Nota: Cuando se usa la MFA virtual en cuentas raíz, se recomienda que el dispositivo utilizado NO sea un dispositivo personal, sino un dispositivo móvil específico (una tablet o un teléfono) que se gestione para que esté cargado y protegido independientemente de cualquier dispositivo personal. ("MFA virtual no personal"). De esta forma, se reducen los riesgos de perder el acceso a la MFA en caso de pérdida o sustitución del dispositivo, o si la persona propietaria del dispositivo ya no trabaja en la empresa.

Recomendación: Asegúrate de que la MFA esté habilitada para la cuenta de usuario raíz

Sigue estos pasos para habilitar la MFA en la cuenta de usuario raíz:

Inicia sesión en la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.

Nota: Para gestionar los dispositivos de MFA de la cuenta de AWS "root", debes usar las credenciales de tu cuenta "root" para iniciar sesión en AWS. No puedes gestionar los dispositivos de MFA de la cuenta raíz con otras credenciales.

Elige Dashboard y , en Security Status , despliega Activate MFA en tu cuenta raíz.
Elegir Activate MFA
En el asistente, elige el dispositivo A virtual MFA y, a continuación, Next Step .
IAM genera y muestra la información de configuración del dispositivo MFA virtual, incluido un gráfico de código QR. El gráfico es una representación de la "clave de configuración secreta" que se puede introducir manualmente en los dispositivos que no admiten códigos QR.
Abre tu aplicación de MFA virtual. Para ver una lista de las aplicaciones que puedes usar para alojar dispositivos de MFA virtual, consulta Aplicaciones de MFA virtual. Si la aplicación de MFA virtual admite varias cuentas (varios dispositivos de MFA virtual), elige la opción para crear una cuenta (un dispositivo de MFA virtual).
Determina si la aplicación de MFA admite códigos QR y, a continuación, haz una de las siguientes acciones:

Usa la aplicación para escanear el código QR. Por ejemplo, puedes elegir el icono de la cámara o una opción similar a Escanear código y, a continuación, usar la cámara del dispositivo para escanear el código.
En el asistente Gestionar dispositivo de MFA, elige Mostrar clave secreta para la configuración manual y, a continuación, escribe la clave de configuración secreta en tu aplicación de MFA.

Cuando hayas terminado, el dispositivo de MFA virtual empezará a generar contraseñas de un solo uso.

En el asistente Gestionar dispositivo de MFA, en el cuadro Código de autenticación 1, escribe la contraseña de un solo uso que aparece en el dispositivo de MFA virtual. Espera hasta 30 segundos a que el dispositivo genere una nueva contraseña de un solo uso. A continuación, escribe la segunda contraseña de un solo uso en el cuadro Código de autenticación 2. Elige Asignar MFA virtual.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Multi Factor Authentication Mfa Enabled All Iam Users Console`

Nombre de la categoría en la API: MULTI_FACTOR_AUTHENTICATION_MFA_ENABLED_ALL_IAM_USERS_CONSOLE

La autenticación multifactor (MFA) añade una capa adicional de garantía de autenticación más allá de las credenciales tradicionales. Si la MFA está habilitada, cuando un usuario inicie sesión en la consola de AWS, se le pedirá su nombre de usuario y contraseña, así como un código de autenticación de su token de MFA físico o virtual. Se recomienda habilitar la MFA en todas las cuentas que tengan una contraseña de consola.

Recomendación: Asegúrate de que la autenticación multifactor (MFA) esté habilitada para todos los usuarios de IAM que tengan una contraseña de consola

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
En el panel de la izquierda, selecciona Users.
En la lista User Name, elige el nombre del usuario al que quieras habilitar la MFA.
Elige la pestaña Security Credentials y, a continuación, Manage MFA Device.
En Manage MFA Device wizard, elige el dispositivo Virtual MFA y, a continuación, Continue.

IAM genera y muestra la información de configuración del dispositivo MFA virtual, incluido un gráfico de código QR. El gráfico es una representación de la "clave de configuración secreta" que se puede introducir manualmente en los dispositivos que no admiten códigos QR.

Abre tu aplicación de MFA virtual. Para ver una lista de las aplicaciones que puedes usar para alojar dispositivos de MFA virtual, consulta Aplicaciones de MFA virtual en https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications. Si la aplicación de MFA virtual admite varias cuentas (varios dispositivos de MFA virtual), elige la opción para crear una cuenta (un dispositivo de MFA virtual).
Determina si la aplicación de MFA admite códigos QR y, a continuación, haz una de las siguientes acciones:

Usa la aplicación para escanear el código QR. Por ejemplo, puedes elegir el icono de la cámara o una opción similar a Escanear código y, a continuación, usar la cámara del dispositivo para escanear el código.
En el asistente Gestionar dispositivo de MFA, elige Mostrar clave secreta para la configuración manual y, a continuación, escribe la clave de configuración secreta en tu aplicación de MFA.

Cuando hayas terminado, el dispositivo de MFA virtual empezará a generar contraseñas de un solo uso.

En Manage MFA Device wizard, en MFA Code 1 box, escribe el one-time password que aparece en el dispositivo de MFA virtual. Espera hasta 30 segundos a que el dispositivo genere una nueva contraseña de un solo uso. A continuación, escribe el segundo one-time password en el MFA Code 2 box.
Haz clic en Assign MFA.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`No Network Acls Allow Ingress 0 0 0 0 Remote Server Administration`

Nombre de la categoría en la API: NO_NETWORK_ACLS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION

La función de lista de control de acceso de red (NACL) proporciona un filtrado sin estado del tráfico de red de entrada y salida a los recursos de AWS. Se recomienda que ninguna ACL de red permita el acceso de entrada sin restricciones a los puertos de administración de servidores remotos, como SSH al puerto 22 y RDP al puerto 3389, mediante los protocolos TCP (6), UDP (17) o ALL (-1).

Recomendación: Asegúrate de que ninguna LCA de red permita la entrada desde 0.0.0.0/0 a los puertos de administración de servidores remotos

Para solucionar este problema, siga estos pasos:

Consola de AWS

Sigue estos pasos:
1. Inicia sesión en la consola de administración de AWS en https://console.aws.amazon.com/vpc/home.
2. En el panel de la izquierda, haz clic en Network ACLs
. 3. Para corregir cada LCA de red, haz lo siguiente:
- Selecciona la LCA de red.
- Haz clic en la pestaña Inbound Rules.
- Haz clic en Edit inbound rules.
- Elige una de estas opciones: A) Actualiza el campo Origen a un intervalo distinto de 0.0.0.0/0 o B) Haz clic en Delete para quitar la regla de entrada infractora.
- Haz clic en Save.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`No Root User Account Access Key Exists`

Nombre de la categoría en la API: NO_ROOT_USER_ACCOUNT_ACCESS_KEY_EXISTS

La cuenta de usuario "root" es el usuario con más privilegios de una cuenta de AWS. Las claves de acceso de AWS proporcionan acceso programático a una cuenta de AWS determinada. Te recomendamos que elimines todas las claves de acceso asociadas a la cuenta de usuario raíz.

Recomendación: Asegúrate de que no haya ninguna clave de acceso de la cuenta de usuario raíz

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de administración de AWS como "root" y abre la consola de IAM en https://console.aws.amazon.com/iam/.
Haz clic en <root_account> en la parte superior derecha y selecciona My Security Credentials en la lista desplegable.
En la pantalla emergente, haz clic en Continue to Security Credentials.
Haz clic en Access Keys (ID de clave de acceso y clave de acceso secreta).
En la columna Status (si hay claves activas).
Haz clic en Delete. Nota: Las llaves eliminadas no se pueden recuperar.

Nota: Aunque una clave se puede inhabilitar, seguirá apareciendo en el comando de la CLI del procedimiento de auditoría, lo que puede provocar que se marque erróneamente como no conforme.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`No Security Groups Allow Ingress 0 0 0 0 Remote Server Administration`

Nombre de la categoría en la API: NO_SECURITY_GROUPS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION

Los grupos de seguridad proporcionan un filtrado con estado del tráfico de red de entrada y salida a los recursos de AWS. Se recomienda que ningún grupo de seguridad permita el acceso de entrada sin restricciones a los puertos de administración de servidores remotos, como SSH al puerto 22 y RDP al puerto 3389, mediante los protocolos TDP (6), UDP (17) o ALL (-1).

Recomendación: Asegúrate de que ningún grupo de seguridad permita la entrada desde 0.0.0.0/0 a los puertos de administración de servidores remotos

Para implementar el estado prescrito, haz lo siguiente:

Inicia sesión en la consola de administración de AWS en https://console.aws.amazon.com/vpc/home.
En el panel de la izquierda, haz clic en Security Groups.
Para cada grupo de seguridad, haz lo siguiente:
Selecciona el grupo de seguridad.
Haz clic en la pestaña Inbound Rules.
Haz clic en el botón Edit inbound rules.
Identificar las reglas que se van a editar o eliminar
A) Actualiza el campo Fuente a un intervalo distinto de 0.0.0.0/0 o B) haz clic en Delete para eliminar la regla de entrada infractora.
Haz clic en Save rules.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`No Security Groups Allow Ingress 0 Remote Server Administration`

Nombre de la categoría en la API: NO_SECURITY_GROUPS_ALLOW_INGRESS_0_REMOTE_SERVER_ADMINISTRATION

Recomendación: Asegúrate de que ningún grupo de seguridad permita la entrada desde ::/0 a los puertos de administración de servidores remotos

Para implementar el estado prescrito, haz lo siguiente:

Inicia sesión en la consola de administración de AWS en https://console.aws.amazon.com/vpc/home.
En el panel de la izquierda, haz clic en Security Groups.
Para cada grupo de seguridad, haz lo siguiente:
Selecciona el grupo de seguridad.
Haz clic en la pestaña Inbound Rules.
Haz clic en el botón Edit inbound rules.
Identificar las reglas que se van a editar o eliminar
A) Actualiza el campo Fuente a un intervalo distinto de ::/0 o B) haz clic en Delete para quitar la regla de entrada infractora.
Haz clic en Save rules.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`One Active Access Key Available Any Single Iam User`

Nombre de la categoría en la API: ONE_ACTIVE_ACCESS_KEY_AVAILABLE_ANY_SINGLE_IAM_USER

Las claves de acceso son credenciales a largo plazo de un usuario de IAM o del usuario raíz de la cuenta de AWS. Puede usar claves de acceso para firmar solicitudes programáticas a la CLI de AWS o a la API de AWS (directamente o mediante el SDK de AWS).

Recomendación: Asegúrate de que solo haya una clave de acceso activa disponible para cada usuario de IAM

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de administración de AWS y ve al panel de control de IAM en https://console.aws.amazon.com/iam/.
En el panel de navegación de la izquierda, selecciona Users.
Haz clic en el nombre del usuario de IAM que quieras examinar.
En la página de configuración de usuario de IAM, selecciona la pestaña Security Credentials.
En la sección Access Keys, elige una clave de acceso que tenga menos de 90 días. Esta debe ser la única clave activa que utilice este usuario de IAM para acceder a los recursos de AWS de forma programática. Prueba tus aplicaciones para asegurarte de que la clave de acceso elegida funciona.
En la misma sección Access Keys, identifique las claves de acceso que no funcionen (excepto la que ha elegido) y desactívelas haciendo clic en el enlace Make Inactive.
Si aparece el cuadro de confirmación Change Key Status, haz clic en Deactivate para desactivar la clave seleccionada.
Repite los pasos del 3 al 7 con cada usuario de gestión de identidades y accesos de tu cuenta de AWS.

CLI de AWS

Con la información de usuario de IAM y de clave de acceso proporcionada en el Audit CLI, elige una clave de acceso que tenga menos de 90 días. Esta debe ser la única clave activa que utilice este usuario de IAM para acceder a los recursos de AWS de forma programática. Prueba tus aplicaciones para asegurarte de que la clave de acceso elegida funciona.
Ejecuta el comando update-access-key que aparece a continuación con el nombre de usuario de IAM y los IDs de las claves de acceso no operativas para desactivar las claves innecesarias. Consulta la sección Auditoría para identificar el ID de clave de acceso innecesario del usuario de IAM seleccionado.

Nota: El comando no devuelve ningún resultado:

aws iam update-access-key --access-key-id <access-key-id> --status Inactive --user-name <user-name>

Para confirmar que el par de claves de acceso seleccionado se ha deactivated correctamente, vuelve a ejecutar el comando de auditoría list-access-keys para ese usuario de IAM:

aws iam list-access-keys --user-name <user-name>

El resultado del comando debe mostrar los metadatos de cada clave de acceso asociada al usuario de gestión de identidades y accesos. Si el par o los pares de claves no operativas Status se definen como Inactive, la clave se ha desactivado correctamente y la configuración de acceso de usuario de IAM ahora cumple esta recomendación.

Repite los pasos del 1 al 3 con cada usuario de gestión de identidades y accesos de tu cuenta de AWS.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Public Access Given Rds Instance`

Nombre de la categoría en la API: PUBLIC_ACCESS_GIVEN_RDS_INSTANCE

Asegúrese de que las instancias de bases de datos de RDS aprovisionadas en su cuenta de AWS restrinjan el acceso no autorizado para minimizar los riesgos de seguridad. Para restringir el acceso a cualquier instancia de base de datos de RDS accesible públicamente, debes inhabilitar la marca de acceso público de la base de datos y actualizar el grupo de seguridad de VPC asociado a la instancia.

Recomendación: Asegúrate de que no se haya dado acceso público a la instancia de RDS

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de administración de AWS y ve al panel de control de RDS en https://console.aws.amazon.com/rds/.
En el panel de navegación, en el panel de control de RDS, haz clic en Databases.
Selecciona la instancia de RDS que quieras actualizar.
En el menú superior del panel de control, haz clic en Modify.
En el panel Modify DB Instance (Modificar instancia de base de datos), en la sección Connectivity, haga clic en Additional connectivity configuration y actualice el valor de Publicly Accessible a Not publicly accessible (No accesible públicamente) para restringir el acceso público. Sigue los pasos que se indican a continuación para actualizar las configuraciones de subred:
- Selecciona la pestaña Connectivity and security y haz clic en el valor del atributo de VPC de la sección Networking.
- Selecciona la pestaña Details del panel inferior del panel de control de VPC y haz clic en el valor del atributo de configuración de la tabla de rutas.
- En la página de detalles de la tabla de rutas, selecciona la pestaña Rutas del panel inferior del panel de control y haz clic en Edit routes.
- En la página Editar rutas, actualiza el destino de la segmentación, que está definido como igw-xxxxx, y haz clic en Save rutas.
En el panel Modificar instancia de base de datos, haga clic en Continue y, en la sección Programación de modificaciones, realice una de las siguientes acciones en función de sus requisitos:
- Seleccione Aplicar durante la próxima ventana de mantenimiento programada para aplicar los cambios automáticamente durante la próxima ventana de mantenimiento programada.
- Selecciona Aplicar inmediatamente para aplicar los cambios al instante. Con esta opción, las modificaciones pendientes se aplicarán de forma asíncrona lo antes posible, independientemente del ajuste de la ventana de mantenimiento de esta instancia de base de datos RDS. Ten en cuenta que también se aplicarán los cambios disponibles en la cola de modificaciones pendientes. Si alguna de las modificaciones pendientes requiere un tiempo de inactividad, elegir esta opción puede provocar un tiempo de inactividad inesperado en la aplicación.
Repite los pasos del 3 al 6 para cada instancia de RDS disponible en la región actual.
Cambia la región de AWS en la barra de navegación para repetir el proceso en otras regiones.

CLI de AWS

Ejecuta el comando describe-db-instances para enumerar todos los identificadores de nombres de bases de datos de RDS disponibles en la región de AWS seleccionada:

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

El resultado del comando debe devolver el identificador de cada instancia de base de datos.
Ejecuta el comando modify-db-instance para modificar la configuración de la instancia de RDS seleccionada. A continuación, usa el siguiente comando para inhabilitar la marca Publicly Accessible en las instancias de RDS seleccionadas. Este comando usa la marca apply-immediately. Si quieres to avoid any downtime --no-apply-immediately flag can be used:

aws rds modify-db-instance --region <region-name> --db-instance-identifier <db-name> --no-publicly-accessible --apply-immediately

El resultado del comando debe mostrar la configuración de PubliclyAccessible en los valores pendientes y se debe aplicar a la hora especificada.
Actualmente, no se puede actualizar el destino de la pasarela de Internet mediante la CLI de AWS. Para actualizar la información sobre la pasarela de Internet, sigue el procedimiento de la consola de AWS.
Repite los pasos del 1 al 5 para cada instancia de RDS aprovisionada en la región actual.
Cambia la región de AWS usando el filtro --region para repetir el proceso en otras regiones.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Rds Enhanced Monitoring Enabled`

Nombre de la categoría en la API: RDS_ENHANCED_MONITORING_ENABLED

La monitorización mejorada proporciona métricas en tiempo real sobre el sistema operativo en el que se ejecuta la instancia de RDS a través de un agente instalado en la instancia.

Para obtener más información, consulta Monitorizar métricas del SO con la monitorización mejorada.

Recomendación: comprueba si la monitorización mejorada está habilitada en todas las instancias de bases de datos de RDS

Para solucionar este problema, siga estos pasos:

Terraform

Para corregir este control, habilita la monitorización mejorada en tus instancias de RDS de la siguiente manera:

Crea un rol de gestión de identidades y accesos para RDS:

resource "aws_iam_role" "rds_logging" {
  name = "CustomRoleForRDSMonitoring"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = "CustomRoleForRDSLogging"
        Principal = {
          Service = "monitoring.rds.amazonaws.com"
        }
      },
    ]
  })
}

Recupera la política gestionada de AWS para la monitorización mejorada de RDS:

data "aws_iam_policy" "rds_logging" {
  name = "AmazonRDSEnhancedMonitoringRole"
}

Adjunta la política al rol:

resource "aws_iam_policy_attachment" "rds_logging" {
  name       = "AttachRdsLogging"
  roles      = [aws_iam_role.rds_logging.name]
  policy_arn = data.aws_iam_policy.rds_logging.arn
}

Define un intervalo de monitorización y un ARN de rol de monitorización para la instancia de RDS infractora para habilitar la monitorización mejorada:

resource "aws_db_instance" "default" {
  identifier           = "test-rds"
  allocated_storage    = 10
  engine               = "mysql"
  engine_version       = "5.7"
  instance_class       = "db.t3.micro"
  db_name              = "mydb"
  username             = "foo"
  password             = "foobarbaz"
  parameter_group_name = "default.mysql5.7"
  skip_final_snapshot  = true
  monitoring_interval  = 60
  monitoring_role_arn  = aws_iam_role.rds_logging.arn
}

Consola de AWS

Puede activar la monitorización mejorada al crear una instancia de base de datos, un clúster de base de datos Multi-AZ o una réplica de lectura, o bien al modificar una instancia de base de datos o un clúster de base de datos Multi-AZ. Si modificas una instancia de base de datos para activar la monitorización mejorada, no es necesario que la reinicies para que el cambio surta efecto.

Puedes activar la monitorización mejorada en la consola de RDS cuando realices una de las siguientes acciones en la página Bases de datos:

Crea una instancia de base de datos o un clúster de base de datos Multi-AZ. Para ello, selecciona Crear base de datos.
Crear una réplica de lectura: elige Acciones y, a continuación, Crear réplica de lectura.
Modificar una instancia de base de datos o un clúster de base de datos Multi-AZ: elige Modificar.

Para activar o desactivar la monitorización mejorada en la consola de RDS

Desplázate hasta Configuración adicional.
En Monitorización, elija Habilitar monitorización mejorada para su instancia de base de datos o réplica de lectura. Para desactivar la monitorización mejorada, selecciona Inhabilitar monitorización mejorada.
Asigna a la propiedad Monitoring Role el rol de IAM que has creado para permitir que Amazon RDS se comunique con Amazon CloudWatch Logs por ti o elige Default para que RDS cree un rol llamado rds-monitoring-role.
Define la propiedad Granularity en el intervalo, en segundos, entre los puntos en los que se recogen las métricas de tu instancia de base de datos o réplica de lectura. La propiedad Granularity puede tener uno de los siguientes valores: 1, 5, 10, 15, 30 o 60. La consola de RDS se actualiza cada 5 segundos como mínimo. Si define la granularidad en 1 segundo en la consola de RDS, las métricas actualizadas solo se mostrarán cada 5 segundos. Puede obtener actualizaciones de métricas de 1 segundo mediante CloudWatch Logs.

CLI de AWS

Crea el rol de gestión de identidades y accesos de RDS:

aws iam create-role \
  --role-name "CustomRoleForRDSMonitoring" \
  --assume-role-policy-document file://rds-assume-role.json

Adjunta la política AmazonRDSEnhancedMonitoringRole al rol:

aws iam attach-role-policy \
  --role-name "CustomRoleForRDSMonitoring"\
  --policy-arn "arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRole"

Modifica la instancia de RDS para habilitar la monitorización mejorada configurando --monitoring-interval y --monitoring-role-arn:

aws rds modify-db-instance \
  --db-instance-identifier "test-rds" \
  --monitoring-interval 30 \
  --monitoring-role-arn "arn:aws:iam::<account_id>:role/CustomRoleForRDSMonitoring"

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Rds Instance Deletion Protection Enabled`

Nombre de la categoría en la API: RDS_INSTANCE_DELETION_PROTECTION_ENABLED

Habilitar la protección contra la eliminación de instancias es una capa adicional de protección contra la eliminación accidental de bases de datos o la eliminación por parte de una entidad no autorizada.

Mientras la protección contra la eliminación esté habilitada, no se podrá eliminar una instancia de base de datos de RDS. Para que una solicitud de eliminación se complete correctamente, la protección contra la eliminación debe estar inhabilitada.

Recomendación: comprueba si todas las instancias de RDS tienen habilitada la protección contra la eliminación

Para solucionar este problema, siga estos pasos:

Terraform

Para corregir este control, asigna el valor true a deletion_protection en el recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  deletion_protection = true
}

Consola de AWS

Para habilitar la protección contra la eliminación en una instancia de base de datos de RDS

Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
En el panel de navegación, elija Bases de datos y, a continuación, la instancia de base de datos que quiera modificar.
Selecciona Modificar.
En Protección frente a la eliminación, elige Habilitar protección frente a la eliminación.
Elige Continuar.
En Programación de modificaciones, elige cuándo aplicar las modificaciones. Las opciones son Aplicar durante la próxima ventana de mantenimiento programada o Aplicar inmediatamente.
Elige Modificar instancia de base de datos.

CLI de AWS

Lo mismo ocurre con la CLI de AWS. Define --deletion-protection como se indica a continuación.

aws rds modify-db-instance \
  --db-instance-identifier = "test-rds" \
  --deletion-protection

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Rds In Backup Plan`

Nombre de la categoría en la API: RDS_IN_BACKUP_PLAN

Esta comprobación evalúa si las instancias de bases de datos de Amazon RDS están cubiertas por un plan de copias de seguridad. Este control falla si una instancia de base de datos de RDS no está cubierta por un plan de copias de seguridad.

AWS Backup es un servicio de copias de seguridad totalmente gestionado que centraliza y automatiza la creación de copias de seguridad de datos en los servicios de AWS. Con AWS Backup, puede crear políticas de copia de seguridad llamadas planes de copia de seguridad. Puede usar estos planes para definir sus requisitos de copia de seguridad, como la frecuencia con la que se deben crear copias de seguridad de sus datos y durante cuánto tiempo se deben conservar esas copias de seguridad. Incluir instancias de bases de datos de RDS en un plan de copias de seguridad te ayuda a proteger tus datos frente a pérdidas o eliminaciones accidentales.

Recomendación: Las instancias de bases de datos de RDS deben estar cubiertas por un plan de copias de seguridad

Para solucionar este problema, siga estos pasos:

Terraform

Para corregir este control, asigna a backup_retention_period un valor superior a 7 en el recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other Configuration ...
  backup_retention_period = 7
}

Consola de AWS

Para habilitar las copias de seguridad automáticas inmediatamente

Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
En el panel de navegación, elija Bases de datos y, a continuación, la instancia de base de datos que quiera modificar.
Elige Modificar para abrir la página Modificar instancia de base de datos.
En Periodo de conservación de copias de seguridad, elige un valor positivo distinto de cero (por ejemplo, 30 días) y, a continuación, selecciona Continuar.
Selecciona la sección Programación de modificaciones y elige cuándo aplicar las modificaciones: puedes elegir Aplicar durante la próxima ventana de mantenimiento programada o Aplicar inmediatamente.
A continuación, en la página de confirmación, elija Modificar instancia de base de datos para guardar los cambios y habilitar las copias de seguridad automáticas.

CLI de AWS

Lo mismo ocurre con la CLI de AWS. Para habilitar las copias de seguridad automáticas, cambia el valor de backup-retention-period a un valor superior a 0 (valor predeterminado).

aws rds modify-db-instance --db-instance-identifier "test-rds" --backup-retention-period 7

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Rds Logging Enabled`

Nombre de la categoría en la API: RDS_LOGGING_ENABLED

Comprueba si los siguientes registros de Amazon RDS están habilitados y se envían a CloudWatch.

Las bases de datos de RDS deben tener habilitados los registros pertinentes. El registro de bases de datos proporciona registros detallados de las solicitudes realizadas a RDS. Los registros de la base de datos pueden ayudar a realizar auditorías de seguridad y de acceso, así como a diagnosticar problemas de disponibilidad.

Recomendación: comprueba si los registros exportados están habilitados en todas las instancias de bases de datos de RDS

Para solucionar este problema, siga estos pasos:

Terraform

resource "aws_db_instance" "example" {
  # ... other configuration for MySQL ...
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
  parameter_group_name            = aws_db_parameter_group.example.name
}

resource "aws_db_parameter_group" "example" {
  name   = "${aws_db_instance.example.dbInstanceIdentifier}-parameter-group"
  family = "mysql5.7"

  parameter {
    name  = "general_log"
    value = 1
  }

  parameter {
    name  = "slow_query_log"
    value = 1
  }

  parameter {
    name  = "log_output"
    value = "FILE"
  }
}

En el caso de MariaDB, crea también un grupo de opciones personalizado y define option_group_name en el recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other configuration for MariaDB ...
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
  parameter_group_name            = aws_db_parameter_group.example.name
  option_group_name               = aws_db_option_group.example.name
}

resource "aws_db_option_group" "example" {
  name                     = "mariadb-option-group-for-logs"
  option_group_description = "MariaDB Option Group for Logs"
  engine_name              = "mariadb"
  option {
    option_name = "MARIADB_AUDIT_PLUGIN"
    option_settings {
      name  = "SERVER_AUDIT_EVENTS"
      value = "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
    }
  }
}

Consola de AWS

Para crear un grupo de parámetros de base de datos personalizado

Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
En el panel de navegación, elija Grupos de parámetros.
Elige Crear grupo de parámetros.
En la lista Familia de grupos de parámetros, elija una familia de grupos de parámetros de la base de datos.
En la lista Type (Tipo), elija DB Parameter Group (Grupo de parámetros de la base de datos).
En Nombre del grupo, escriba el nombre del nuevo grupo de parámetros de la base de datos.
En Descripción, escriba una descripción para el nuevo grupo de parámetros de la base de datos.
Elige Crear.

Para crear un grupo de opciones para el registro de MariaDB mediante la consola

Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
En el panel de navegación, elija Grupos de opciones.
Elige Crear grupo.
En la ventana del grupo de opciones Crear, proporciona lo siguiente:
* Nombre: debe ser único en tu cuenta de AWS. Solo se admiten letras, números y guiones.
* Descripción: se usa únicamente con fines de visualización.
* Motor: selecciona el motor de tu base de datos.
* Versión principal del motor: selecciona la versión principal del motor de tu base de datos.
Elige Crear.
Elige el nombre del grupo de opciones que acabas de crear.
Elige la opción Añadir.
Elige MARIADB_AUDIT_PLUGIN en la lista Nombre de la opción.
Define SERVER_AUDIT_EVENTS como CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML y QUERY_DCL.
Elige la opción Añadir.

Publicar registros de bases de datos de SQL Server, Oracle o PostgreSQL en CloudWatch Logs desde la consola de administración de AWS

Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
En el panel de navegación, elige Bases de datos.
Elige la instancia de base de datos que quieras modificar.
Selecciona Modificar.
En Exportaciones de registros, elija todos los archivos de registro para empezar a publicarlos en CloudWatch Logs.
La exportación de registros solo está disponible para las versiones del motor de base de datos que admiten la publicación en CloudWatch Logs.
Elige Continuar. A continuación, en la página de resumen, elige Modificar instancia de base de datos.

Para aplicar un nuevo grupo de parámetros de base de datos o un grupo de opciones de base de datos a una instancia de base de datos de RDS

Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
En el panel de navegación, elige Bases de datos.
Elige la instancia de base de datos que quieras modificar.
Selecciona Modificar.
En Opciones de base de datos, cambia el grupo de parámetros de la base de datos y el grupo de opciones de la base de datos según sea necesario.
Cuando hayas terminado de hacer los cambios, selecciona Continuar. Consulta el resumen de las modificaciones.
Elige Modificar instancia de base de datos para guardar los cambios.

CLI de AWS

Recupera las familias de buscadores y elige la que coincida con el buscador y la versión de la instancia de base de datos.

aws rds describe-db-engine-versions \
  --query "DBEngineVersions[].DBParameterGroupFamily" \
  --engine "mysql"

Crea un grupo de parámetros según el motor y la versión.

aws rds create-db-parameter-group \
  --db-parameter-group-name "rds-mysql-parameter-group" \
  --db-parameter-group-family "mysql5.7" \
  --description "Example parameter group for logs"

Crea un archivo rds-parameters.json que contenga los parámetros necesarios según el motor de base de datos. En este ejemplo, se usa MySQL 5.7.

[
  {
    "ParameterName": "general_log",
    "ParameterValue": "1",
    "ApplyMethod": "immediate"
  },
  {
    "ParameterName": "slow_query_log",
    "ParameterValue": "1",
    "ApplyMethod": "immediate"
  },
  {
    "ParameterName": "log_output",
    "ParameterValue": "FILE",
    "ApplyMethod": "immediate"
  }
]

Modifica el grupo de parámetros para añadir los parámetros según el motor de la base de datos. En este ejemplo se usa MySQL 5.7.

aws rds modify-db-parameter-group \
  --db-parameter-group-name "rds-mysql-parameter-group" \
  --parameters file://rds-parameters.json

Modifique la instancia de base de datos para asociar el grupo de parámetros.

aws rds modify-db-instance \
  --db-instance-identifier "test-rds" \
  --db-parameter-group-name "rds-mysql-parameter-group"

Además, en MariaDB, crea un grupo de opciones de la siguiente manera.

aws rds create-option-group \
  --option-group-name "rds-mariadb-option-group" \
  --engine-name "mariadb" \
  --major-engine-version "10.6" \
  --option-group-description "Option group for MariaDB logs"

Crea un archivo rds-mariadb-options.json de la siguiente manera.

{
  "OptionName": "MARIADB_AUDIT_PLUGIN",
  "OptionSettings": [
    {
      "Name": "SERVER_AUDIT_EVENTS",
      "Value": "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
    }
  ]
}

Añade la opción al grupo de opciones.

aws rds add-option-to-option-group \
  --option-group-name "rds-mariadb-option-group" \
  --options file://rds-mariadb-options.json

Asocia el grupo de opciones a la instancia de base de datos modificando la instancia de MariaDB.

aws rds modify-db-instance \
  --db-instance-identifier "rds-test-mariadb" \
  --option-group-name "rds-mariadb-option-group"

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Rds Multi Az Support`

Nombre de la categoría en la API: RDS_MULTI_AZ_SUPPORT

Las instancias de bases de datos de RDS deben configurarse para varias zonas de disponibilidad. De esta forma, se garantiza la disponibilidad de los datos almacenados. Las implementaciones multizona de disponibilidad permiten la conmutación por error automática si hay un problema con la disponibilidad de una zona de disponibilidad y durante el mantenimiento periódico de RDS.

Recomendación: comprueba si la alta disponibilidad está habilitada en todas las instancias de bases de datos de RDS

Para solucionar este problema, siga estos pasos:

Terraform

Para corregir este control, asigna el valor true a multi_az en el recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  multi_az                = true
}

Consola de AWS

Para habilitar varias zonas de disponibilidad en una instancia de base de datos

Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
En el panel de navegación, elija Bases de datos y, a continuación, la instancia de base de datos que quiera modificar.
Selecciona Modificar. Aparecerá la página Modificar instancia de base de datos.
En Especificaciones de instancia, selecciona Sí en Despliegue en varias zonas de disponibilidad.
Elige Continuar y, a continuación, consulta el resumen de las modificaciones.
(Opcional) Elige Aplicar inmediatamente para aplicar los cambios inmediatamente. En algunos casos, elegir esta opción puede provocar una interrupción. Para obtener más información, consulta el artículo sobre el uso de la opción Aplicar inmediatamente en la guía del usuario de Amazon RDS.
En la página de confirmación, revisa los cambios. Si son correctos, elige Modificar instancia de base de datos para guardar los cambios.

CLI de AWS

Lo mismo ocurre con la CLI de AWS. Para habilitar la compatibilidad con varias zonas de disponibilidad, proporciona la opción --multi-az.

modify-db-instance
  --db-instance-identifier "test-rds" \
  --multi-az

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Redshift Cluster Configuration Check`

Nombre de la categoría en la API: REDSHIFT_CLUSTER_CONFIGURATION_CHECK

Comprueba los elementos esenciales de un clúster de Redshift: cifrado en reposo, registro y tipo de nodo.

Estos elementos de configuración son importantes para mantener un clúster de Redshift seguro y observable.

Recomendación: comprueba que todos los clústeres de Redshift tengan encriptado en reposo, almacenamiento de registros y tipo de nodo.

Para solucionar este problema, siga estos pasos:

Terraform

resource "aws_kms_key" "redshift_encryption" {
  description         = "Used for Redshift encryption configuration"
  enable_key_rotation = true
}

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  encrypted                           = true
  kms_key_id                          = aws_kms_key.redshift_encryption.id
  logging {
    enable               = true
    log_destination_type = "cloudwatch"
    log_exports          = ["connectionlog", "userlog", "useractivitylog"]
  }
}

Consola de AWS

Para habilitar el registro de auditoría del clúster

Abre la consola de Amazon Redshift en https://console.aws.amazon.com/redshift/.
En el menú de navegación, elija Clústeres y, a continuación, el nombre del clúster que quiera modificar.
Selecciona Propiedades.
Elige Editar y, a continuación, Editar registro de auditoría.
Selecciona Activar en Configurar registro de auditoría, elige CloudWatch en Tipo de exportación de registros (opción recomendada) y selecciona los registros que quieras exportar.

Para usar AWS S3 y gestionar los registros de auditoría de Redshift, consulta Redshift - Registro de auditoría de bases de datos en la documentación de AWS.

Elige Guardar cambios.

Modificar el cifrado de la base de datos en un clúster

Inicia sesión en la consola de administración de AWS y abre la consola de Amazon Redshift en https://console.aws.amazon.com/redshift/.
En el menú de navegación, elija Clústeres y, a continuación, el clúster cuya cifrado quiera modificar.
Selecciona Propiedades.
Elige Editar y, a continuación, Editar cifrado.
Elige el cifrado que quieras usar (KMS o HSM) y proporciona lo siguiente:

En el caso de KMS, la clave que se va a usar.
En el HSM: conexión y certificado de cliente

CLI de AWS

Crear una clave de KMS y obtener su ID

aws kms create-key \
  --description "Key to encrypt Redshift Clusters"

Modificar el clúster

aws redshift modify-cluster \
  --cluster-identifiers "test-redshift-cluster" \
  --encrypted \
  --kms-key-id <value>

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Redshift Cluster Maintenancesettings Check`

Nombre de la categoría en la API: REDSHIFT_CLUSTER_MAINTENANCESETTINGS_CHECK

Las actualizaciones automáticas de la versión principal se realizan según la ventana de mantenimiento

Recomendación: comprueba que todos los clústeres de Redshift tengan habilitada la opción allowVersionUpgrade y que se hayan establecido preferredMaintenanceWindow y automatedSnapshotRetentionPeriod

Para solucionar este problema, siga estos pasos:

Terraform

Esta comprobación cumple todos los valores predeterminados proporcionados por Terraform. Si un clúster de Redshift falla, revisa los requisitos y elimina las anulaciones predeterminadas de los siguientes atributos del recurso aws_redshift_cluster.

resource "aws_redshift_cluster" "example" {

  # ...other configuration ...

  # The following values are compliant and set by default if omitted.
  allow_version_upgrade               = true
  preferred_maintenance_window        = "sat:10:00-sat:10:30"
  automated_snapshot_retention_period = 1
}

Consola de AWS

Cuando se crea un clúster de Redshift a través de la consola de AWS, los valores predeterminados ya cumplen este control.

Para obtener más información, consulta Gestionar clústeres con la consola.

CLI de AWS

Para corregir este control con la CLI de AWS, haz lo siguiente:

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --allow-version-upgrade

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Redshift Cluster Public Access Check`

Nombre de la categoría en la API: REDSHIFT_CLUSTER_PUBLIC_ACCESS_CHECK

El atributo PubliclyAccessible de la configuración del clúster de Amazon Redshift indica si el clúster es de acceso público. Cuando el clúster se configura con PubliclyAccessible definido como true, se trata de una instancia orientada a Internet que tiene un nombre DNS que se puede resolver públicamente, que se resuelve en una dirección IP pública.

Si no se puede acceder públicamente al clúster, se trata de una instancia interna con un nombre de DNS que se resuelve en una dirección IP privada. A menos que quieras que tu clúster sea accesible públicamente, no debes configurarlo con el valor "true" en el campo "PubliclyAccessible".

Recomendación: comprueba si los clústeres de Redshift son de acceso público

Para solucionar este problema, siga estos pasos:

Terraform

Para corregir este control, es necesario modificar el recurso del clúster de Redshift y asignar el valor publicly_accessible a false. El valor predeterminado es true.

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  publicly_accessible = false
}

Consola de AWS

Para inhabilitar el acceso público a un clúster de Amazon Redshift

Abre la consola de Amazon Redshift en https://console.aws.amazon.com/redshift/.
En el menú de navegación, elige Clústeres y, a continuación, el nombre del clúster con el grupo de seguridad que quieras modificar.
Elige Acciones y, a continuación, Modificar ajuste de acceso público.
En Permitir que las instancias y los dispositivos ajenos a la VPC se conecten a tu base de datos a través del endpoint del clúster, elige No.
Elige Confirmar.

CLI de AWS

Usa el comando modify-cluster para definir --no-publicly-accessible.

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --no-publicly-accessible

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Restricted Common Ports`

Nombre de la categoría en la API: RESTRICTED_COMMON_PORTS

Comprueba si el tráfico entrante sin restricciones de los grupos de seguridad es accesible a los puertos especificados que tienen el mayor riesgo. Este control falla si alguna de las reglas de un grupo de seguridad permite el tráfico entrante desde "0.0.0.0/0" o "::/0" para esos puertos.

El acceso sin restricciones (0.0.0.0/0) aumenta las oportunidades de que se produzcan actividades maliciosas, como hackeos, ataques de denegación de servicio y pérdida de datos.

Los grupos de seguridad proporcionan un filtrado con estado del tráfico de red de entrada y salida a los recursos de AWS. Ningún grupo de seguridad debe permitir el acceso de entrada sin restricciones a los siguientes puertos:

20 y 21 (FTP)
22 (SSH)
23 (Telnet)
25 (SMTP)
110 (POP3)
135 (RPC)
143 (IMAP)
445 (CIFS)
1433, 1434 (MSSQL)
3000 (frameworks de desarrollo web de Go, Node.js y Ruby)
3306 (MySQL)
3389 (RDP)
4333 (ahsp)
5000 (frameworks de desarrollo web de Python)
5432 (postgresql)
5500 (fcp-addr-srvr1)
5601 (OpenSearch Dashboards)
8080 (proxy)
8088 (puerto HTTP antiguo)
8888 (puerto HTTP alternativo)
9200 o 9300 (OpenSearch)

Recomendación: Los grupos de seguridad no deben permitir el acceso sin restricciones a puertos de alto riesgo

Para solucionar este problema, siga estos pasos:

Consola de AWS

Para eliminar una regla de un grupo de seguridad, sigue estos pasos:

Abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
En el panel de navegación, selecciona Grupos de seguridad.
Selecciona el grupo de seguridad que quieras actualizar, elige Acciones y, a continuación, Editar reglas de entrada para eliminar una regla de entrada o Editar reglas de salida para eliminar una regla de salida.
Elige el botón Eliminar situado a la derecha de la regla que quieras eliminar.
Elige Vista previa de los cambios y, a continuación, Confirmar.

Para obtener información sobre cómo eliminar reglas de un grupo de seguridad, consulte Configurar reglas de grupos de seguridad en la guía del usuario de Amazon EC2.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Restricted Ssh`

Nombre de la categoría en la API: RESTRICTED_SSH

Los grupos de seguridad proporcionan un filtrado con estado del tráfico de red de entrada y salida a los recursos de AWS.

CIS recomienda que ningún grupo de seguridad permita el acceso de entrada sin restricciones al puerto 22. Al eliminar la conectividad sin restricciones a los servicios de consola remota, como SSH, se reduce la exposición de un servidor a los riesgos.

Recomendación: Los grupos de seguridad no deben permitir la entrada desde 0.0.0.0/0 al puerto 22

Para solucionar este problema, siga estos pasos:

Consola de AWS

Sigue estos pasos para cada grupo de seguridad asociado a una VPC.

Abre la consola de Amazon VPC en https://console.aws.amazon.com/vpc/.

En el panel de la izquierda, elige Grupos de seguridad.
Selecciona un grupo de seguridad.
En la parte inferior de la página, elige la pestaña Reglas de entrada.
Elige Editar reglas.
Identifica la regla que permite el acceso a través del puerto 22 y, a continuación, selecciona la X para quitarla.
Elige Guardar reglas.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Rotation Customer Created Cmks Enabled`

Nombre de la categoría en la API: ROTATION_CUSTOMER_CREATED_CMKS_ENABLED

Comprueba si la rotación automática de claves está habilitada para cada clave y si coincide con el ID de clave de la clave de KMS de AWS creada por el cliente. La regla es NON_COMPLIANT si el rol de grabador de AWS Config de un recurso no tiene el permiso kms:DescribeKey.

Recomendación: Comprueba que la rotación de las CMKs creadas por el cliente esté habilitada

Para habilitar la rotación de claves automatizada en AWS KMS, consulta el artículo Rotación de claves de KMS de AWS en la documentación de AWS.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Rotation Customer Created Symmetric Cmks Enabled`

Nombre de la categoría en la API: ROTATION_CUSTOMER_CREATED_SYMMETRIC_CMKS_ENABLED

AWS Key Management Service (KMS) permite a los clientes rotar la clave de respaldo, que es el material de la clave almacenado en KMS y que está vinculado al ID de la clave maestra del cliente (CMK) creada por el cliente. Es la clave subyacente que se usa para realizar operaciones criptográficas, como el cifrado y el descifrado. Actualmente, la rotación de claves automatizada conserva todas las claves de respaldo anteriores para que el descifrado de los datos cifrados se pueda llevar a cabo de forma transparente. Se recomienda habilitar la rotación de claves de CMK para las claves simétricas. La rotación de claves no se puede habilitar en ninguna CMK asimétrica.

Recomendación: Comprueba que la rotación de las CMKs simétricas creadas por el cliente esté habilitada

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam.
En el panel de navegación de la izquierda, selecciona Customer managed keys .
Selecciona una CMK gestionada por el cliente donde Key spec = SYMMETRIC_DEFAULT
En el panel "Configuración general", abre la pestaña "Rotación de claves".
Marca la casilla "Rota automáticamente esta clave de KMS cada año".

CLI de AWS

Ejecuta el siguiente comando para habilitar la rotación de claves:

 aws kms enable-key-rotation --key-id <kms_key_id>

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Routing Tables Vpc Peering Are Least Access`

Nombre de la categoría en la API: ROUTING_TABLES_VPC_PEERING_ARE_LEAST_ACCESS

Comprueba si las tablas de rutas del emparejamiento de VPCs están configuradas con el principio de mínimos privilegios.

Recomendación: Asegúrate de que las tablas de enrutamiento del emparejamiento de VPCs tengan el nivel de acceso mínimo

Para actualizar las tablas de rutas del emparejamiento entre VPCs, consulta Update your route tables for a VPC peering connection (Actualizar las tablas de rutas de una conexión de emparejamiento entre VPCs) en la guía del usuario de AWS VPC.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`S3 Account Level Public Access Blocks`

Nombre de la categoría en la API: S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS

La función de bloqueo de acceso público de Amazon S3 ofrece ajustes para puntos de acceso, buckets y cuentas que le ayudan a gestionar el acceso público a los recursos de Amazon S3. De forma predeterminada, los nuevos segmentos, puntos de acceso y objetos no permiten el acceso público.

Recomendación: comprueba si la configuración de bloqueo de acceso público de S3 necesaria está definida a nivel de cuenta

Para solucionar este problema, siga estos pasos:

Terraform

La siguiente configuración de recursos de Terraform configura el acceso a S3 a nivel de cuenta.

resource "aws_s3_account_public_access_block" "s3_control" {
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Consola de AWS

Para editar la configuración de bloqueo de acceso público de todos los buckets de S3 de una cuenta de AWS.

Inicia sesión en la consola de administración de AWS y abre la consola de Amazon S3 en https://console.aws.amazon.com/s3/.
Elige la configuración de Bloqueo del acceso público para esta cuenta.
Seleccione Editar para cambiar la configuración de acceso público de todos los contenedores de su cuenta de AWS.
Elige los ajustes que quieras cambiar y, a continuación, selecciona Guardar cambios.
Cuando se te pida que confirmes la acción, escribe "confirm". A continuación, elige Confirmar para guardar los cambios.

CLI de AWS

aws s3control put-public-access-block \
--account-id <value> \
--public-access-block-configuration '{"BlockPublicAcls": true, "BlockPublicPolicy": true, "IgnorePublicAcls": true, "RestrictPublicBuckets": true}'

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`S3 Buckets Configured Block Public Access Bucket And Account Settings`

Nombre de la categoría en la API: S3_BUCKETS_CONFIGURED_BLOCK_PUBLIC_ACCESS_BUCKET_AND_ACCOUNT_SETTINGS

Amazon S3 proporciona Block public access (bucket settings) y Block public access (account settings) para ayudarte a gestionar el acceso público a los recursos de Amazon S3. De forma predeterminada, los buckets y los objetos de S3 se crean con el acceso público inhabilitado. Sin embargo, un principal de AWS IAM con permisos de S3 suficientes puede habilitar el acceso público a nivel de segmento u objeto. Cuando está habilitada, Block public access (bucket settings) impide que un segmento concreto y los objetos que contiene se hagan accesibles públicamente. Del mismo modo, Block public access (account settings) impide que se pueda acceder públicamente a todos los segmentos y objetos que contengan en toda la cuenta.

Recomendación:

Asegúrate de que los buckets de S3 estén configurados con Block public access (bucket settings).

Para solucionar este problema, siga estos pasos:

Consola de AWS

Si el resultado es true en los ajustes de configuración independientes, significa que están configurados en la cuenta.

Inicia sesión en la consola de administración de AWS y abre la consola de Amazon S3 en https://console.aws.amazon.com/s3/.
Elige Bloquear acceso público (configuración de la cuenta).
Seleccione Editar para cambiar la configuración de acceso público de todos los contenedores de su cuenta de AWS.
Elige los ajustes que quieras cambiar y, a continuación, selecciona Guardar. Para obtener más información sobre cada ajuste, coloca el cursor sobre los iconos i.
Cuando se te pida que confirmes la acción, introduce confirm. A continuación, haz clic en Confirmar para guardar los cambios.

CLI de AWS

Para definir la configuración de bloqueo del acceso público de esta cuenta, ejecuta el siguiente comando:

aws s3control put-public-access-block
--public-access-block-configuration BlockPublicAcls=true, IgnorePublicAcls=true, BlockPublicPolicy=true, RestrictPublicBuckets=true
--account-id <value>

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`S3 Bucket Access Logging Enabled Cloudtrail S3 Bucket`

Nombre de la categoría en la API: S3_BUCKET_ACCESS_LOGGING_ENABLED_CLOUDTRAIL_S3_BUCKET

El almacenamiento de registros de acceso al bucket de S3 genera un registro que contiene los registros de acceso de cada solicitud realizada a tu bucket de S3. Un registro de acceso contiene detalles sobre la solicitud, como el tipo de solicitud, los recursos especificados en la solicitud, y la hora y la fecha en las que se procesó la solicitud. Se recomienda habilitar el almacenamiento de registros de acceso al bucket en el bucket de S3 de CloudTrail.

Recomendación:

Asegúrate de que el almacenamiento de registros de acceso al bucket de S3 esté habilitado en el bucket de S3 de CloudTrail

Para solucionar este problema, siga estos pasos:

Consola de AWS

Inicia sesión en la consola de administración de AWS y abre la consola de S3 en https://console.aws.amazon.com/s3.
En Todos los contenedores, haga clic en el contenedor de S3 de destino.
En la parte superior derecha de la consola, haz clic en Propiedades.
En Bucket: <s3\_bucket\_for\_cloudtrail>, haga clic en Logging</s3\_bucket\_for\_cloudtrail>.
Configurar el registro de un contenedor
- Haz clic en la casilla Habilitado
- Selecciona Contenedor de destino en la lista
- Introduce un prefijo de destino
Haz clic en Guardar.

CLI de AWS

Obtén el nombre del bucket de S3 en el que CloudTrail está registrando:

aws cloudtrail describe-trails --region <region-name> --query trailList[*].S3BucketName

Copia y añade el nombre del contenedor de destino en , el prefijo del archivo de registro en y, opcionalmente, una dirección de correo en la siguiente plantilla. Guarda la plantilla como :

{
 "LoggingEnabled": {
 "TargetBucket": "<Logging_BucketName>",
 "TargetPrefix": "<LogFilePrefix>",
 "TargetGrants": [
 {
 "Grantee": {
 "Type": "AmazonCustomerByEmail",
 "EmailAddress": "<EmailID>"
 },
 "Permission": "FULL_CONTROL"
 }
 ]
 }
}

Ejecuta el comando put-bucket-logging con el nombre del segmento y como entrada. Para obtener más información, consulta put-bucket-logging:

aws s3api put-bucket-logging --bucket <BucketName> --bucket-logging-status file://<FileName.Json>

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`S3 Bucket Logging Enabled`

Nombre de la categoría en la API: S3_BUCKET_LOGGING_ENABLED

La función de registro de acceso al servidor de AWS S3 registra las solicitudes de acceso a los segmentos de almacenamiento, lo que resulta útil para las auditorías de seguridad. De forma predeterminada, el registro de acceso al servidor no está habilitado en los buckets de S3.

Recomendación: comprueba si el almacenamiento de registros está habilitado en todos los buckets de S3

Para solucionar este problema, siga estos pasos:

Terraform

En el siguiente ejemplo se muestra cómo crear dos contenedores:

Un segmento de registro
Un segmento conforme

variable "bucket_acl_map" {
  type = map(any)
  default = {
    "logging-bucket"   = "log-delivery-write"
    "compliant-bucket" = "private"
  }
}

resource "aws_s3_bucket" "all" {
  for_each            = var.bucket_acl_map
  bucket              = each.key
  object_lock_enabled = true
  tags = {
    "Pwd"    = "s3"
  }
}

resource "aws_s3_bucket_acl" "private" {
  for_each = var.bucket_acl_map
  bucket   = each.key
  acl      = each.value
}

resource "aws_s3_bucket_versioning" "enabled" {
  for_each = var.bucket_acl_map
  bucket   = each.key
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_logging" "enabled" {
  for_each      = var.bucket_acl_map
  bucket        = each.key
  target_bucket = aws_s3_bucket.all["logging-bucket"].id
  target_prefix = "log/"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  for_each = var.bucket_acl_map
  bucket   = each.key

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
    }
  }
}

Consola de AWS

Para obtener información sobre cómo habilitar el registro de acceso a S3 a través de la consola de AWS, consulta Habilitar el registro de acceso al servidor de Amazon S3 en la documentación de AWS.

CLI de AWS

En el siguiente ejemplo se muestra cómo hacer lo siguiente:

Crea una política de segmento para conceder al principal de servicio de registro permiso para PutObject en tu segmento de registro.

policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3ServerAccessLogsPolicy",
            "Effect": "Allow",
            "Principal": {"Service": "logging.s3.amazonaws.com"},
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::MyBucket/Logs/*",
            "Condition": {
                "ArnLike": {"aws:SourceARN": "arn:aws:s3:::SOURCE-BUCKET-NAME"},
                "StringEquals": {"aws:SourceAccount": "SOURCE-AWS-ACCOUNT-ID"}
            }
        }
    ]
}

aws s3api put-bucket-policy \
  --bucket my-bucket
  --policy file://policy.json

Aplica la política a tu segmento de registro

logging.json

{
    "LoggingEnabled": {
        "TargetBucket": "MyBucket",
        "TargetPrefix": "Logs/"
    }
}

aws s3api put-bucket-logging \
  --bucket MyBucket \
  --bucket-logging-status file://logging.json

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`S3 Bucket Policy Set Deny Http Requests`

Nombre de la categoría en la API: S3_BUCKET_POLICY_SET_DENY_HTTP_REQUESTS

A nivel de segmento de Amazon S3, puede configurar los permisos mediante una política de segmento para que los objetos solo sean accesibles a través de HTTPS.

Recomendación: Asegúrate de que la política de buckets de S3 esté configurada para denegar las solicitudes HTTP

Para solucionar este problema, siga estos pasos:

Consola de AWS

Usar el generador de políticas de AWS:

Repite los pasos del 1 al 4 que se indican más arriba.
Haz clic en Policy Generator en la parte inferior del editor de políticas de cubos.
Selecciona Tipo de política
S3 Bucket Policy
Añadir instrucciones
- Effect = Deny
- Principal = *
- AWS Service = Amazon S3
- Actions = *
- Amazon Resource Name =
Generar política
Copia el texto y añádelo a la política del contenedor.

CLI de AWS

Exporta la política del contenedor a un archivo JSON.

aws s3api get-bucket-policy --bucket <bucket_name> --query Policy --output text > policy.json

Modifica el archivo policy.json añadiendo esta instrucción:

{
 "Sid": <optional>",
 "Effect": "Deny",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": "arn:aws:s3:::<bucket_name>/*",
 "Condition": {
 "Bool": {
 "aws:SecureTransport": "false"
 }
 }
 }

Aplica esta política modificada al segmento de S3:

aws s3api put-bucket-policy --bucket <bucket_name> --policy file://policy.json

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`S3 Bucket Replication Enabled`

Nombre de la categoría en la API: S3_BUCKET_REPLICATION_ENABLED

Este control comprueba si un bucket de Amazon S3 tiene habilitada la replicación entre regiones. El control falla si el bucket no tiene habilitada la opción Replicación entre regiones o si también tiene habilitada la opción Replicación en la misma región.

La replicación es la copia automática y asíncrona de objetos entre segmentos de la misma región de AWS o de diferentes regiones. La replicación copia los objetos recién creados y las actualizaciones de objetos de un segmento de origen a uno o varios segmentos de destino. En las prácticas recomendadas de AWS, se recomienda la replicación para los contenedores de origen y de destino que pertenecen a la misma cuenta de AWS. Además de la disponibilidad, debes tener en cuenta otros ajustes de protección del sistema.

Recomendación: comprueba si los buckets de S3 tienen habilitada la opción Replicación entre regiones

Para habilitar la replicación entre regiones en un bucket de S3, consulta Configurar la replicación para buckets de origen y de destino propiedad de la misma cuenta en la guía del usuario de Amazon Simple Storage Service. En Segmento de origen, elija Aplicar a todos los objetos del segmento.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`S3 Bucket Server Side Encryption Enabled`

Nombre de la categoría en la API: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED

Esta comprobación verifica que tu segmento de S3 tenga habilitado el cifrado predeterminado de Amazon S3 o que la política del segmento de S3 deniegue explícitamente las solicitudes de inserción de objetos sin cifrado del lado del servidor.

Recomendación: Asegúrate de que todos los buckets de S3 usen el cifrado en reposo

Para solucionar este problema, siga estos pasos:

Terraform

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

Consola de AWS

Para habilitar el cifrado predeterminado en un bucket de S3

Abre la consola de Amazon S3 en https://console.aws.amazon.com/s3/.
En el panel de navegación de la izquierda, elija Contenedores.
Elige el contenedor de S3 de la lista.
Selecciona Propiedades.
Elige Cifrado predeterminado.
En Cifrado, elija AES-256 o AWS KMS.
Elige AES-256 para usar las claves que gestiona Amazon S3 para el cifrado predeterminado. Para obtener más información sobre cómo usar el cifrado del lado del servidor de Amazon S3 para cifrar tus datos, consulta la guía del usuario de Amazon Simple Storage Service.
Elige AWS KMS para usar las claves gestionadas por AWS KMS para el cifrado predeterminado. A continuación, elige una clave maestra de la lista de claves maestras de KMS de AWS que hayas creado.
Escribe el nombre de recurso de Amazon (ARN) de la clave de KMS de AWS que quieras usar. Puedes encontrar el ARN de tu clave de AWS KMS en la consola de IAM, en Claves de cifrado. También puedes elegir un nombre de clave de la lista desplegable.
Importante: Si usas la opción de AWS KMS para tu configuración de cifrado predeterminada, estarás sujeto a las cuotas de RPS (solicitudes por segundo) de AWS KMS. Para obtener más información sobre las cuotas de AWS KMS y cómo solicitar un aumento de cuota, consulta la Guía para desarrolladores de AWS Key Management Service.
Selecciona Guardar.

Para obtener más información sobre cómo crear una clave de KMS de AWS, consulta la guía para desarrolladores de AWS Key Management Service.

Para obtener más información sobre cómo usar AWS KMS con Amazon S3, consulta la guía del usuario de Amazon Simple Storage Service.

Si habilitas el cifrado predeterminado, puede que tengas que actualizar la política de tu contenedor. Para obtener más información sobre cómo pasar de las políticas de los contenedores al cifrado predeterminado, consulta la guía del usuario de Amazon Simple Storage Service.

CLI de AWS

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`S3 Bucket Versioning Enabled`

Nombre de la categoría en la API: S3_BUCKET_VERSIONING_ENABLED

Amazon S3 es una forma de mantener varias variantes de un objeto en el mismo segmento y puede ayudarte a recuperarte más fácilmente de las acciones no deseadas de los usuarios y de los fallos de las aplicaciones.

Recomendación: comprueba que la gestión de versiones esté habilitada en todos los buckets de S3

Para solucionar este problema, siga estos pasos:

Terraform

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"

  versioning {
    enabled = true
  }
}

Consola de AWS

Para habilitar o inhabilitar la gestión de versiones en un bucket de S3

Inicia sesión en la consola de administración de AWS y abre la consola de Amazon S3 en https://console.aws.amazon.com/s3/.
En la lista Segmentos, elija el nombre del segmento para el que quiera habilitar el control de versiones.
Selecciona Propiedades.
En Versionado de cubos, elige Editar.
Elige Suspender o Habilitar y, a continuación, selecciona Guardar cambios.

CLI de AWS

aws s3control put-bucket-versioning \
--bucket <bucket_name> \
--versioning-configuration Status=Enabled

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`S3 Default Encryption Kms`

Nombre de la categoría en la API: S3_DEFAULT_ENCRYPTION_KMS

Comprueba si los buckets de Amazon S3 están encriptados con AWS Key Management Service (AWS KMS)

Recomendación: comprueba que todos los buckets estén cifrados con KMS

Para solucionar este problema, siga estos pasos:

Terraform

resource "aws_kms_key" "s3_encryption" {
  description         = "Used for S3 Bucket encryption configuration"
  enable_key_rotation = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket   = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      kms_master_key_id = aws_kms_key.s3_encryption.arn
      sse_algorithm     = "aws:kms"
    }
  }
}

Consola de AWS

Para habilitar el cifrado predeterminado en un bucket de S3

Abre la consola de Amazon S3 en https://console.aws.amazon.com/s3/.
En el panel de navegación de la izquierda, elija Contenedores.
Elige el contenedor de S3 de la lista.
Selecciona Propiedades.
Elige Cifrado predeterminado.
En Cifrado, elige AWS-KMS.
Elige AWS KMS para usar las claves gestionadas por AWS KMS para el cifrado predeterminado. A continuación, elige una clave maestra de la lista de claves maestras de KMS de AWS que hayas creado. Para obtener más información sobre cómo crear claves de KMS, consulta la documentación de AWS sobre cómo crear claves.
Escribe el nombre de recurso de Amazon (ARN) de la clave de KMS de AWS que quieras usar. Puedes encontrar el ARN de tu clave de AWS KMS en la consola de IAM, en Claves de cifrado. También puedes elegir un nombre de clave de la lista desplegable.
Importante: Esta solución está sujeta a las cuotas de RPS (solicitudes por segundo) de AWS KMS. Para obtener más información sobre las cuotas de AWS KMS y cómo solicitar un aumento de cuota, consulta la Guía para desarrolladores de AWS Key Management Service.
Selecciona Guardar.

Para obtener más información sobre cómo usar AWS KMS con Amazon S3, consulta la guía del usuario de Amazon Simple Storage Service.

CLI de AWS

Crear una clave de KMS

aws kms create-key \
  --description "Key to encrypt S3 buckets"

Habilitar la rotación de claves

aws kms enable-key-rotation \
  --key-id <key_id_from_previous_command>

Actualizar segmento

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"KMSMasterKeyID": "<id_from_key>", "SSEAlgorithm": "AES256"}}]}'

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Sagemaker Notebook Instance Kms Key Configured`

Nombre de la categoría en la API: SAGEMAKER_NOTEBOOK_INSTANCE_KMS_KEY_CONFIGURED

Comprueba si se ha configurado una clave de AWS Key Management Service (AWS KMS) para una instancia de bloc de notas de Amazon SageMaker. La regla es NON_COMPLIANT si no se especifica 'KmsKeyId' para la instancia de cuaderno de SageMaker.

Recomendación: comprueba que todas las instancias de bloc de notas de SageMaker estén configuradas para usar KMS

Para configurar KMS en SageMaker, consulta Gestión de claves en la documentación de Amazon SageMaker.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Sagemaker Notebook No Direct Internet Access`

Nombre de la categoría en la API: SAGEMAKER_NOTEBOOK_NO_DIRECT_INTERNET_ACCESS

Comprueba si el acceso directo a Internet está inhabilitado en una instancia de bloc de notas de SageMaker. Para ello, comprueba si el campo DirectInternetAccess está inhabilitado en la instancia de cuaderno.

Si configuras tu instancia de SageMaker sin una VPC, el acceso directo a Internet estará habilitado de forma predeterminada en tu instancia. Debes configurar tu instancia con una VPC y cambiar el ajuste predeterminado a Inhabilitar: acceder a Internet a través de una VPC.

Para entrenar o alojar modelos desde un cuaderno, necesitas tener acceso a Internet. Para habilitar el acceso a Internet, asegúrate de que tu VPC tenga una pasarela NAT y de que tu grupo de seguridad permita las conexiones salientes. Para obtener más información sobre cómo conectar una instancia de cuaderno a recursos de una VPC, consulta Conectar una instancia de cuaderno a recursos de una VPC en la Guía para desarrolladores de Amazon SageMaker.

También debes asegurarte de que solo los usuarios autorizados tengan acceso a tu configuración de SageMaker. Restringe los permisos de IAM de los usuarios para modificar la configuración y los recursos de SageMaker.

Recomendación: comprueba si el acceso directo a Internet está inhabilitado en todas las instancias de bloc de notas de Amazon SageMaker

Para solucionar este problema, siga estos pasos:

Consola de AWS

Ten en cuenta que no puedes cambiar el ajuste de acceso a Internet después de crear una instancia de cuaderno. Debes detenerlo, eliminarlo y volver a crearlo.

Para configurar una instancia de bloc de notas de SageMaker para denegar el acceso directo a Internet, sigue estos pasos:

Abre la consola de SageMaker en https://console.aws.amazon.com/sagemaker/.
Ve a Instancias de cuaderno.
Elimina la instancia que tiene habilitado el acceso directo a Internet. Elige la instancia, selecciona Acciones y, a continuación, elige Detener.
Cuando la instancia se haya detenido, elige Acciones y, a continuación, Eliminar.
Elige Crear instancia de cuaderno. Proporciona los detalles de la configuración.
Despliega la sección de red y elige una VPC, una subred y un grupo de seguridad. En Acceso directo a Internet, elige Inhabilitar: acceder a Internet a través de una VPC.
Elige Crear instancia de cuaderno.

Para obtener más información, consulta Conectar una instancia de cuaderno a recursos de una VPC en la guía para desarrolladores de Amazon SageMaker.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Secretsmanager Rotation Enabled Check`

Nombre de la categoría en la API: SECRETSMANAGER_ROTATION_ENABLED_CHECK

Comprueba si un secreto almacenado en AWS Secrets Manager está configurado con la rotación automática. La comprobación falla si el secreto no está configurado con la rotación automática. Si proporcionas un valor personalizado para el parámetro maximumAllowedRotationFrequency, el control solo se realizará si la clave secreta se rota automáticamente en el periodo de tiempo especificado.

Secrets Manager te ayuda a mejorar la postura de seguridad de tu organización. Los secretos incluyen credenciales de bases de datos, contraseñas y claves de APIs de terceros. Puedes usar Secret Manager para almacenar secretos de forma centralizada, cifrarlos automáticamente, controlar el acceso a ellos y rotarlos de forma segura y automática.

Secrets Manager puede rotar secretos. Puedes usar la rotación para sustituir secretos a largo plazo por secretos a corto plazo. Al rotar tus secretos, se limita el tiempo que un usuario no autorizado puede usar un secreto vulnerado. Por este motivo, debes rotar tus secretos con frecuencia. Para obtener más información sobre la rotación, consulta el artículo sobre cómo rotar los secretos de AWS Secrets Manager en la guía del usuario de AWS Secrets Manager.

Recomendación: comprueba que todos los secretos de AWS Secrets Manager tengan la rotación habilitada

Para activar la rotación automática de los secretos de Secrets Manager, consulta el artículo Set up automatic rotation for AWS Secrets Manager secrets using the console (Configurar la rotación automática de los secretos de AWS Secrets Manager mediante la consola) de la guía del usuario de AWS Secrets Manager. Debes elegir y configurar una función de AWS Lambda para la rotación.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Sns Encrypted Kms`

Nombre de la categoría en la API: SNS_ENCRYPTED_KMS

Comprueba si un tema de SNS está encriptado en reposo con AWS KMS. La comprobación falla si un tema de SNS no usa una clave de KMS para el cifrado del lado del servidor (SSE).

El cifrado de datos en reposo reduce el riesgo de que un usuario no autenticado en AWS acceda a los datos almacenados en el disco. También añade otro conjunto de controles de acceso para limitar la capacidad de los usuarios no autorizados de acceder a los datos. Por ejemplo, se necesitan permisos de API para descifrar los datos antes de poder leerlos. Los temas de SNS deben cifrarse en reposo para añadir una capa de seguridad.

Recomendación: comprueba que todos los temas de SNS estén encriptados con KMS

Para activar el SSE en un tema de SNS, consulta el artículo sobre cómo habilitar el cifrado del lado del servidor (SSE) en un tema de Amazon SNS de la guía para desarrolladores de Amazon Simple Notification Service. Antes de usar SSE, también debes configurar las políticas de claves de AWS KMS para permitir el cifrado de temas y el cifrado y descifrado de mensajes. Para obtener más información, consulta Configurar permisos de AWS KMS en la guía para desarrolladores de Amazon Simple Notification Service.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Vpc Default Security Group Closed`

Nombre de la categoría en la API: VPC_DEFAULT_SECURITY_GROUP_CLOSED

Este control comprueba si el grupo de seguridad predeterminado de una VPC permite el tráfico entrante o saliente. El control falla si el grupo de seguridad permite el tráfico entrante o saliente.

Las reglas del grupo de seguridad predeterminado permiten todo el tráfico saliente y entrante de las interfaces de red (y sus instancias asociadas) que se asignan al mismo grupo de seguridad. Te recomendamos que no uses el grupo de seguridad predeterminado. Como el grupo de seguridad predeterminado no se puede eliminar, debes cambiar el ajuste de las reglas del grupo de seguridad predeterminado para restringir el tráfico entrante y saliente. De esta forma, se evita el tráfico no intencionado si el grupo de seguridad predeterminado se configura accidentalmente para recursos como las instancias EC2.

Recomendación: Asegúrate de que el grupo de seguridad predeterminado de cada VPC restrinja todo el tráfico

Para solucionar este problema, empieza creando grupos de seguridad con el mínimo de privilegios. Para obtener instrucciones, consulta el artículo sobre cómo crear un grupo de seguridad en la guía del usuario de Amazon VPC. A continuación, asigna los nuevos grupos de seguridad a tus instancias EC2. Para obtener instrucciones, consulta el artículo sobre cómo cambiar el grupo de seguridad de una instancia en la guía del usuario de Amazon EC2 para instancias Linux.

Después de asignar los nuevos grupos de seguridad a tus recursos, elimina todas las reglas de entrada y salida de los grupos de seguridad predeterminados. Para obtener instrucciones, consulta el artículo sobre cómo eliminar reglas de grupos de seguridad en la guía del usuario de Amazon VPC.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Vpc Flow Logging Enabled All Vpcs`

Nombre de la categoría en la API: VPC_FLOW_LOGGING_ENABLED_ALL_VPCS

Los registros de flujo de VPCs son una función que te permite obtener información sobre el tráfico de IPs que entra y sale de las interfaces de red de tu VPC. Una vez que haya creado un registro de flujo, podrá ver y recuperar sus datos en Amazon CloudWatch Logs. Se recomienda habilitar los registros de flujo de VPC para los paquetes rechazados de las VPCs.

Recomendación: Asegúrate de que el registro de flujo de VPC esté habilitado en todas las VPCs

Para solucionar este problema, siga estos pasos:

Consola de AWS

Iniciar sesión en la consola de gestión
Selecciona Services y, a continuación, VPC.
En el panel de navegación de la izquierda, selecciona Your VPCs
Selecciona una VPC
En el panel de la derecha, selecciona la pestaña Flow Logs.
Si no existe ningún registro de flujo, haz clic en Create Flow Log.
En Filtro, selecciona Reject.
Introduce un Role y un Destination Log Group.
Haz clic en Create Log Flow.
Haz clic en CloudWatch Logs Group.

Nota: Si se define el filtro como "Rechazar", se reducirá drásticamente la acumulación de datos de registro de esta recomendación y se proporcionará información suficiente para detectar brechas de seguridad, investigar y corregir. Sin embargo, durante los periodos de ingeniería de grupos de seguridad con el mínimo de privilegios, definir este filtro como "Todos" puede ser muy útil para descubrir los flujos de tráfico necesarios para que un entorno que ya está en funcionamiento funcione correctamente.

CLI de AWS

Crea un documento de política con el nombre role_policy_document.json y pega el siguiente contenido:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "test",
 "Effect": "Allow",
 "Principal": {
 "Service": "ec2.amazonaws.com"
 },
 "Action": "sts:AssumeRole"
 }
 ]
}

Crea otro documento de política, llámalo iam_policy.json y pega el siguiente contenido:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action":[
 "logs:CreateLogGroup",
 "logs:CreateLogStream",
 "logs:DescribeLogGroups",
 "logs:DescribeLogStreams",
 "logs:PutLogEvents",
 "logs:GetLogEvents",
 "logs:FilterLogEvents"
 ],
 "Resource": "*"
 }
 ]
}

Ejecuta el siguiente comando para crear un rol de IAM:

aws iam create-role --role-name <aws_support_iam_role> --assume-role-policy-document file://<file-path>role_policy_document.json

Ejecuta el siguiente comando para crear una política de gestión de identidades y accesos:

aws iam create-policy --policy-name <ami-policy-name> --policy-document file://<file-path>iam-policy.json

Ejecuta el comando attach-group-policy con el ARN de la política de gestión de identidades y accesos devuelto en el paso anterior para adjuntar la política al rol de gestión de identidades y accesos (si el comando se ejecuta correctamente, no se devuelve ningún resultado):

aws iam attach-group-policy --policy-arn arn:aws:iam::<aws-account-id>:policy/<iam-policy-name> --group-name <group-name>

Ejecuta describe-vpcs para obtener el VpcId disponible en la región seleccionada:

aws ec2 describe-vpcs --region <region>

El resultado del comando debe devolver el ID de VPC disponible en la región seleccionada.
Ejecuta create-flow-logs para crear un registro de flujo de la VPC:

aws ec2 create-flow-logs --resource-type VPC --resource-ids <vpc-id> --traffic-type REJECT --log-group-name <log-group-name> --deliver-logs-permission-arn <iam-role-arn>

Repite el paso 8 con las demás VPCs disponibles en la región seleccionada.
Cambia la región actualizando --region y repite el procedimiento de corrección para otras VPCs.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Vpc Sg Open Only To Authorized Ports`

Nombre de la categoría en la API: VPC_SG_OPEN_ONLY_TO_AUTHORIZED_PORTS

Este control comprueba si un grupo de seguridad de Amazon EC2 permite el tráfico entrante sin restricciones desde puertos no autorizados. El estado de control se determina de la siguiente manera:

Si usas el valor predeterminado de authorizedTcpPorts, el control fallará si el grupo de seguridad permite el tráfico entrante sin restricciones desde cualquier puerto que no sean los puertos 80 y 443.

Si proporciona valores personalizados para authorizedTcpPorts o authorizedUdpPorts, el control falla si el grupo de seguridad permite el tráfico entrante sin restricciones desde cualquier puerto no incluido en la lista.

Si no se usa ningún parámetro, el control falla en cualquier grupo de seguridad que tenga una regla de tráfico entrante sin restricciones.

Los grupos de seguridad proporcionan un filtrado con estado del tráfico de red de entrada y salida a AWS. Las reglas de los grupos de seguridad deben seguir el principio de mínimos accesos. El acceso sin restricciones (dirección IP con el sufijo /0) aumenta las oportunidades de que se produzcan actividades maliciosas, como hackeos, ataques de denegación de servicio y pérdida de datos. A menos que se permita un puerto específicamente, este debe denegar el acceso sin restricciones.

Recomendación: comprueba que cualquier grupo de seguridad con 0.0.0.0/0 de cualquier VPC solo permita tráfico TCP/UDP entrante específico

Para modificar un grupo de seguridad, consulta Trabajar con grupos de seguridad en la guía del usuario de Amazon VPC.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

`Both VPC VPN Tunnels Up`

Nombre de la categoría en la API: VPC_VPN_2_TUNNELS_UP

Un túnel VPN es un enlace cifrado por el que pueden pasar datos desde la red del cliente a AWS o desde AWS a la red del cliente en una conexión VPN de sitio a sitio de AWS. Cada conexión VPN incluye dos túneles VPN que puedes usar simultáneamente para lograr una alta disponibilidad. Es importante asegurarse de que ambos túneles de VPN estén activos para que la conexión VPN sea segura y tenga una alta disponibilidad entre una VPC de AWS y tu red remota.

Este control comprueba que los dos túneles de VPN proporcionados por la VPN de sitio a sitio de AWS estén activos. El control falla si uno o ambos túneles tienen el estado DOWN.

Recomendación: comprueba que los dos túneles de VPN de AWS proporcionados por la conexión de sitio a sitio de AWS estén activos

Para modificar las opciones de los túneles VPN, consulta Modificar las opciones de los túneles VPN de sitio a sitio en la guía del usuario de VPN de sitio a sitio de AWS.

Consulta información sobre los recursos admitidos y los ajustes de análisis de este tipo de resultado.

Corregir resultados de Security Health Analytics Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Corrección de Security Health Analytics

Desactivación automática de las detecciones

Access Transparency disabled

Roles obligatorios

Pasos de resolución

AlloyDB auto backup disabled

AlloyDB backups disabled

AlloyDB CMEK disabled

AlloyDB log min error statement severity

AlloyDB log min messages

AlloyDB log error verbosity

AlloyDB Public IP

AlloyDB SSL not enforced

Admin service account

Alpha cluster enabled

API key APIs unrestricted

API key apps unrestricted

API key exists

API key not rotated

Audit config not monitored

Crear métrica

Crear política de alertas

Audit logging disabled

Auto backup disabled

Auto repair disabled

Auto upgrade disabled

BigQuery table CMEK disabled

Binary authorization disabled

Bucket CMEK disabled

Bucket IAM not monitored

Crear métrica

Crear política de alertas

Bucket logging disabled

Bucket policy only disabled

Cloud Asset API disabled

Cluster logging disabled

Cluster monitoring disabled

Cluster private Google access disabled

Cluster secrets encryption disabled

Cluster shielded nodes disabled

Compute project wide SSH keys allowed

Compute Secure Boot disabled

Compute serial ports enabled

Confidential Computing disabled

COS not used

Custom role not monitored

Crear métrica

Crear política de alertas

Dataproc CMEK disabled

Dataproc image outdated

Dataset CMEK disabled

Default network

Default service account used

Disk CMEK disabled

Disk CSEK disabled

Eliminar y crear un disco

Habilitar el detector

DNS logging disabled

DNSSEC disabled

Effectively Anonymous Users Granted GKE Cluster Access

Campos restringidos

Valores permitidos

Egress deny rule not set

Essential contacts not configured

Firewall not monitored

Crear métrica

Crear política de alertas

Firewall rule logging disabled

Flow logs disabled

Flow logs settings not recommended

Full API access

HTTP load balancer

Instance OS login disabled

Integrity monitoring disabled

Intranode visibility disabled

IP alias disabled

IP forwarding enabled

KMS key not rotated

KMS project has owner

Corregir resultados de Security Health Analytics

`Access Transparency disabled`

`AlloyDB auto backup disabled`

`AlloyDB backups disabled`

`AlloyDB CMEK disabled`

`AlloyDB log min error statement severity`

`AlloyDB log min messages`

`AlloyDB log error verbosity`

`AlloyDB Public IP`

`AlloyDB SSL not enforced`

`Admin service account`

`Alpha cluster enabled`

`API key APIs unrestricted`

`API key apps unrestricted`

`API key exists`

`API key not rotated`

`Audit config not monitored`

`Audit logging disabled`

`Auto backup disabled`

`Auto repair disabled`

`Auto upgrade disabled`

`BigQuery table CMEK disabled`

`Binary authorization disabled`

`Bucket CMEK disabled`

`Bucket IAM not monitored`

`Bucket logging disabled`

`Bucket policy only disabled`

`Cloud Asset API disabled`

`Cluster logging disabled`

`Cluster monitoring disabled`

`Cluster private Google access disabled`

`Cluster secrets encryption disabled`

`Cluster shielded nodes disabled`

`Compute project wide SSH keys allowed`

`Compute Secure Boot disabled`

`Compute serial ports enabled`

`Confidential Computing disabled`

`COS not used`

`Custom role not monitored`

`Dataproc CMEK disabled`

`Dataproc image outdated`

`Dataset CMEK disabled`

`Default network`

`Default service account used`

`Disk CMEK disabled`

`Disk CSEK disabled`

`DNS logging disabled`

`DNSSEC disabled`

`Effectively Anonymous Users Granted GKE Cluster Access`

`Egress deny rule not set`

`Essential contacts not configured`

`Firewall not monitored`

`Firewall rule logging disabled`

`Flow logs disabled`

`Flow logs settings not recommended`

`Full API access`

`HTTP load balancer`

`Instance OS login disabled`

`Integrity monitoring disabled`

`Intranode visibility disabled`

`IP alias disabled`

`IP forwarding enabled`

`KMS key not rotated`

`KMS project has owner`

`KMS public key`

`KMS role separation`

`Legacy authorization enabled`

`Legacy metadata enabled`

`Legacy network`

`Load balancer logging disabled`

`Locked retention policy not set`

`Log not exported`

`Master authorized networks disabled`

`MFA not enforced`

`Network not monitored`

`Network policy disabled`

`Nodepool boot CMEK disabled`

`Nodepool secure boot disabled`

`Non org IAM member`

`Object versioning disabled`