Soluciona los problemas de las estadísticas de estado de seguridad

En esta página, se proporciona una lista de guías de referencia y técnicas para corregir los resultados de las estadísticas del estado de seguridad mediante el Security Command Center.

Necesitas funciones adecuadas de Identity and Access Management (IAM) para ver o editar los resultados, y acceder o modificar los recursos de Google Cloud. Si encuentras errores de permisos cuando accedes a Security Command Center en la consola de Google Cloud, pídele asistencia a tu administrador y, para obtener información sobre los roles, consulta Control de acceso. Para resolver errores de recursos, consulta la documentación de los productos afectados.

Nota: Si eres cliente Premium y quieres cambiar al nivel Estándar, te recomendamos que resuelvas todos los resultados antes de cambiar de nivel. Los resultados que informan los detectores Premium no se pueden resolver de forma automática en el nivel Estándar. Para obtener más información, consulta Cambia los niveles.

Solución de estadísticas de estado de seguridad

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

Para encontrar tipos que están asignados a las comparativas de CIS, la guía de solución proviene del Centro para la Seguridad en Internet (CIS), a menos que se indique lo contrario. Para obtener más información, consulta Detectores y cumplimiento.

Precaución: Si se hace de forma incorrecta, la modificación de la configuración de tus recursos puede afectar de forma negativa el entorno de producción. Además, habilitar algunos servicios sugeridos de Google Cloud puede aumentar tus costos de la nube. Comprende el impacto de todos los pasos de solución antes de realizar cambios.

Desactivación de los resultados después de la solución

Después de solucionar una vulnerabilidad o un resultado de configuración incorrecta, Security Health Analytics establece automáticamente el estado del resultado en INACTIVE la próxima vez que lo analice. El tiempo que tarda Security Health Analytics en establecer un resultado solucionado en INACTIVE depende de cuándo se solucione el problema y del programa del análisis que lo detecte.

Security Health Analytics también establece el estado de un hallazgo en INACTIVE cuando un análisis detecta que se borró el recurso afectado por el hallazgo. Si quieres quitar un resultado de un recurso borrado de la pantalla mientras esperas a que Security Health Analytics detecte que el recurso se borró, puedes silenciarlo. Para silenciar un resultado, consulta Silencia resultados en Security Command Center.

No uses la función de silenciamiento para ocultar los resultados corregidos de los recursos existentes. Si el problema se repite y Security Health Analytics restablece 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 las estadísticas del estado de la seguridad.

Access Transparency disabled

Nombre de categoría en la API: ACCESS_TRANSPARENCY_DISABLED

La Transparencia de acceso registra cuando los empleados de Google Cloud acceden a los proyectos de tu organización para brindar asistencia. Habilita la 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 Transparencia de acceso.

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

Roles obligatorios

Para obtener los permisos que necesitas para realizar esta tarea, pídele a tu administrador que te otorgue el rol de IAM de Administrador de transparencia de acceso (roles/axt.admin) a nivel de la organización. Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso.

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

Pasos para soluciones

Para solucionar este resultado, completa los siguientes pasos:

1. Verifica tus permisos a nivel de la organización:

   1. Ve a la página Administración de identidades y accesos en la console de Google Cloud.

      Ir a Identity and Access Management

   2. Si se te solicita, selecciona la organización de Google Cloud en el menú de selección.

2. Selecciona cualquier proyecto de Google Cloud dentro de la organización mediante el menú de selección.

   La Transparencia de acceso se configura en una página del proyecto de Google Cloud, pero está habilitada para toda la organización.

3. Ve a la página IAM y administración > Configuración.

4. Haz clic en Habilitar la transparencia de acceso.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

AlloyDB auto backup disabled

Nombre de 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 la pérdida de datos, activa las copias de seguridad automáticas para tu clúster. Para obtener más información, consulta Configura copias de seguridad automáticas adicionales.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de clústeres de AlloyDB para PostgreSQL en la console de Google Cloud.

   Ve a los clústeres de AlloyDB para PostgreSQL

2. Haz clic en un clúster en la columna Nombre del recurso.

3. Haz clic en Protección de datos.

4. En la sección Política de copia de seguridad automática, haz clic en Editar en la fila Copias de seguridad automáticas.

5. Selecciona la casilla de verificación Automatizar copias de seguridad.

6. Haz clic en Actualizar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

AlloyDB backups disabled

Nombre de 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 continuas.

Para evitar la pérdida de datos, activa las copias de seguridad automáticas o continuas para tu clúster. Para obtener más información, consulta Configura copias de seguridad adicionales.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de clústeres de AlloyDB para PostgreSQL en la console de Google Cloud.

   Ve a los clústeres de AlloyDB para PostgreSQL

2. En la columna Nombre del recurso, haz clic en el nombre del clúster que se identifica en el resultado.

3. Haz clic en Protección de datos.

4. Configura una política de copia de seguridad.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

AlloyDB CMEK disabled

Nombre de categoría en la API: ALLOYDB_CMEK_DISABLED

Un clúster de AlloyDB no usa claves de encriptación administradas por el cliente (CMEK).

Con CMEK, las claves que creas y administras en Cloud KMS envuelven las claves que usa Google para encriptar tus datos, lo que te brinda más control sobre el acceso a tus datos. Para obtener más información, consulta Acerca de CMEK. Las CMEK generan costos adicionales relacionados con Cloud KMS.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de clústeres de AlloyDB para PostgreSQL en la console de Google Cloud.

   Ir a los clústeres de AlloyDB para PostgreSQL

2. En la columna Nombre del recurso, haz clic en el nombre del clúster que se identifica en el resultado.

3. Haz clic en Crear copia de seguridad. Establece un ID de copia de seguridad.

4. Haz clic en Crear.

5. En la sección Copia de seguridad/Restablecimiento, haz clic en Restablecer junto a la entrada ID de copia de seguridad que elegiste.

6. Establece un ID y una red de clúster nuevos.

7. Haz clic en Advanced Encryption Options. Selecciona la CMEK con la que deseas encriptar el clúster nuevo.

8. Haz clic en Restore.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

AlloyDB log min error statement severity

Nombre de 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 configurada en error ni en otro valor recomendado.

La marca log_min_error_statement controla si las instrucciones de SQL que causan condiciones de error se registran en los registros del servidor. Se registran las instrucciones de SQL de la gravedad especificada o de una gravedad más alta. Cuanto mayor sea la gravedad, menos mensajes se registrarán. Si se establece en un nivel de gravedad demasiado alto, es posible que los mensajes de error no se registren.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de clústeres de AlloyDB para PostgreSQL en la console de Google Cloud.

   Ve a los clústeres de AlloyDB para PostgreSQL

2. Haz clic en el clúster en la columna Nombre del recurso.

3. En la sección Instancias en tu clúster, haz clic en Editar para la instancia.

4. Haz clic en Advanced Configuration Options.

5. En la sección Marcas, configura la marca de base de datos log_min_error_statement con uno de los siguientes valores recomendados, según la política de registro de tu organización.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning
   • error

6. Haz clic en Actualizar instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

AlloyDB log min messages

Nombre de 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 configurada como mínimo en warning.

La marca log_min_messages controla qué niveles de mensajes se registran en los registros del servidor. Mientras mayor sea la gravedad, menos mensajes se registrarán. Establecer un umbral demasiado bajo puede aumentar el tamaño y la longitud del almacenamiento de registros, lo que dificulta la detección de errores reales.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de clústeres de AlloyDB para PostgreSQL en la console de Google Cloud.

   Ir a los clústeres de AlloyDB para PostgreSQL

2. Haz clic en el clúster en la columna Nombre del recurso.

3. En la sección Instancias en tu clúster, haz clic en Editar para la instancia.

4. Haz clic en Advanced Configuration Options.

5. En la sección Marcas, configura la marca de base de datos log_min_messages con uno de los siguientes valores recomendados, según la política de registro de tu organización.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning

6. Haz clic en Actualizar instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

AlloyDB log error verbosity

Nombre de 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 configurada como default o en otro valor menos restrictivo.

La marca log_error_verbosity controla la cantidad de detalles en los mensajes registrados. Mientras mayor sea la verbosidad, más detalles se registrarán en los mensajes. Te recomendamos establecer esta marca en default o en otro valor menos restrictivo.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de clústeres de AlloyDB para PostgreSQL en la console de Google Cloud.

   Ve a los clústeres de AlloyDB para PostgreSQL

2. Haz clic en el clúster en la columna Nombre del recurso.

3. En la sección Instancias en tu clúster, haz clic en Editar para la instancia.

4. Haz clic en Advanced Configuration Options.

5. En la sección Marcas, configura la marca de base de datos log_error_verbosity con uno de los siguientes valores recomendados, según la política de registro de tu organización.

   • default
   • verbose

6. Haz clic en Actualizar instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

AlloyDB Public IP

Nombre de 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 proporcionan una seguridad de red mejorada y una menor latencia para tu aplicación.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de clústeres de AlloyDB para PostgreSQL en la console de Google Cloud.

   Ve a los clústeres de AlloyDB para PostgreSQL

2. En la columna Nombre del recurso, haz clic en el nombre del clúster que se identifica en el resultado.

3. En la sección Instancias en tu clúster, haz clic en Editar para la instancia.

4. En la sección Conectividad, desmarca la casilla de verificación Habilitar IP pública.

5. Haz clic en Actualizar instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

AlloyDB SSL not enforced

Nombre de 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 evitar que se filtren datos sensibles en tránsito a través de comunicaciones no encriptadas, todas las conexiones entrantes a tu instancia de base de datos de AlloyDB deben usar SSL. Obtén más información sobre la configuración de certificados SSL/TLS.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de clústeres de AlloyDB para PostgreSQL en la console de Google Cloud.

   Ve a los clústeres de AlloyDB para PostgreSQL

2. En la columna Nombre del recurso, haz clic en el nombre del clúster que se identifica en el resultado.

3. En la sección Instancias en tu clúster, haz clic en Editar para la instancia.

4. En la sección Seguridad de redes, haz clic en la casilla de Requerir encriptación de SSL.

5. Haz clic en Actualizar instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Admin service account

Nombre de categoría en la API: ADMIN_SERVICE_ACCOUNT

Una cuenta de servicio de tu organización o proyecto tiene las funciones Administrador, Editor o Propietario asignadas a ella. Estas funciones tienen permisos amplios y no se deben asignar a cuentas de servicio. Para obtener información sobre las cuentas de servicio y las funciones disponibles para ellas, consulta Cuentas de servicio.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de política de IAM en la consola de Google Cloud.

   Ir a la política de IAM

2. Sigue estos pasos para cada principal identificada en el resultado:

   1. Haz clic en Editar principal junto a la principal.
   2. Para quitar los permisos, haz clic en Borrar rol junto al rol.
   3. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Alpha cluster enabled

Nombre de categoría en la API: ALPHA_CLUSTER_ENABLED

Las características del clúster alfa están habilitadas para un clúster de Google Kubernetes Engine (GKE).

Los clústeres alfa permiten a los usuarios pioneros experimentar con cargas de trabajo que usan funciones nuevas antes de que se lancen al público general. Los clústeres alfa tienen todas las funciones de la API de Kubernetes habilitadas, pero no están cubiertos por el ANS de GKE, no reciben actualizaciones de seguridad, tienen inhabilitada la actualización y la reparación automáticas de nodos y no se pueden actualizar. Además, se borran automáticamente después de 30 días.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

No se pueden inhabilitar los clústeres Alfa. Debes crear un clúster nuevo con funciones alfa inhabilitadas.

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

   Ir a clústeres de Kubernetes

2. Haga clic en Crear.

3. Selecciona Configurar junto al tipo de clúster que quieres crear.

4. En la pestaña Funciones, asegúrate de que la opción Habilitar funciones Alfa de Kubernetes en este clúster esté inhabilitada.

   Nota: Si seleccionasteAutopilot de GKE, no verás esta opción porque los clústeres alfa no son compatibles.

5. Haga clic en Crear.

6. Para mover las cargas de trabajo al clúster nuevo, consulta Migra cargas de trabajo a diferentes tipos de máquina.

7. Para borrar el clúster original, consulta Borra un clúster.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

API key APIs unrestricted

Nombre de categoría en la API: API_KEY_APIS_UNRESTRICTED

Hay claves de API que se usan de una forma demasiado general.

Las claves de API no restringidas son inseguras porque se pueden recuperar desde los dispositivos en los que están almacenadas o se pueden ver públicamente, por ejemplo, desde un navegador. De acuerdo con el principio de mínimo privilegio, configura las claves de API para que solo llamen a las API requeridas por la aplicación. Para obtener más información, consulta Aplica restricciones de clave de API.

Para solucionar este resultado, completa los siguientes pasos:

1. En la consola de Google Cloud, ve a la página Biblioteca de API.

   Ir a claves de API

2. En el caso de cada clave de API:

   1. En la sección Claves de API, en la fila de cada clave de API para la que necesitas restringir las 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 las APIs. Aparecerá el menú desplegable Seleccionar las APIs.
   4. En la lista desplegable Seleccionar las API, selecciona las API que quieres permitir.
      Advertencia: No configures las restricciones de API para las APIs de Google Cloud, ya que permite el acceso a todos los servicios que ofrece Google Cloud.
   5. Haz clic en Guardar. La configuración puede demorar hasta cinco minutos en aplicarse.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

API key apps unrestricted

Nombre de categoría en la API: API_KEY_APPS_UNRESTRICTED

Hay claves de API que se usan de manera ilimitada y permiten el uso de cualquier app no confiable.

Las claves de API no restringidas son inseguras porque se pueden recuperar en dispositivos en los que están almacenadas o se pueden ver públicamente, por ejemplo, desde un navegador. De acuerdo con el principio de mínimo privilegio, restringe el uso de la clave de API a los hosts, referentes HTTP y apps de confianza. Para obtener más información, consulta Aplica restricciones de clave de API.

Para solucionar este resultado, completa los siguientes pasos:

1. En la consola de Google Cloud, ve a la página Biblioteca de API.

   Ir a claves de API

2. En el caso de cada clave de API:

   1. En la sección Claves de API, en la fila de cada clave de API para la que necesitas restringir las 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 aplicaciones, selecciona una categoría de restricción. Puedes configurar una restricción de aplicaciones por clave.
   4. En el campo Agregar un elemento que aparece cuando seleccionas una restricción, haz clic en Agregar un elemento para agregar restricciones según las necesidades de tu aplicación.
   5. Cuando termines de agregar los elementos, haz clic en Listo.
      Advertencia: No configures referentes HTTP en tarjetas comodín que permitan el acceso a cualquier referente HTTP o amplio, por ejemplo, *, *.[TLD] o .[TLD]/*). No configures direcciones IP ni referentes para permitir ningún host (0.0.0.0, ::0 o 0.0.0.0/0).
   6. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

API key exists

Nombre de 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 strings encriptadas de forma simple y fáciles de encontrar y usar. Se pueden recuperar en dispositivos en los que están almacenadas o se pueden ver de forma pública, por ejemplo, desde un navegador. Además, las claves de API no son un identificador único de usuarios o aplicaciones que realizan solicitudes. Como alternativa, puedes usar un flujo de autenticación estándar, con cuentas de servicio o cuentas de usuario.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

1. Asegúrate de que tus aplicaciones estén configuradas con un método de autenticación alternativo.

2. Ve a la página Credenciales de API en la consola de Google Cloud.

   Ir a Credenciales de API

3. En la sección Claves de API de la fila correspondiente a cada clave de API que necesites borrar, haz clic en Acciones.

4. En el menú Acciones, haz clic en Borrar clave de API.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

API key not rotated

Nombre de categoría en la API: API_KEY_NOT_ROTATED

Una clave de API no se rota hace más de 90 días.

Las claves de API no vencen, por lo que las claves robadas se pueden usar de forma indefinida hasta que el propietario del proyecto las revoque o rote. Cuando vuelves a generar las claves de API con frecuencia, se reduce la cantidad de tiempo que se puede usar una clave robada para acceder a los datos en cuenta vulnerada o inhabilitada. Rota las claves de API al menos cada 90 días. Para obtener más información, consulta Prácticas recomendadas para administrar las claves de API.

Para solucionar este resultado, completa los siguientes pasos:

1. En la consola de Google Cloud, ve a la página Biblioteca de API.

   Ir a claves de API

2. En el caso de cada clave de API:

   1. En la sección Claves de API, en la fila correspondiente a cada clave de API que necesites 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 en el campo Fecha de creación es anterior a 90 días, haz clic en Regenerar clave. Se genera una clave nueva.
   4. Haz clic en Guardar.
   5. Para garantizar que tus aplicaciones sigan funcionando sin interrupciones, actualízalas a fin de que usen la clave de API nueva. La clave de API anterior funciona durante 24 horas antes de que se desactive de forma permanente.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Audit config not monitored

Nombre de categoría en la API: AUDIT_CONFIG_NOT_MONITORED

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

Cloud Audit Logging produce actividad de administrador y registros de acceso a los datos, lo que permite realizar análisis de seguridad, hacer un seguimiento de cambios en los recursos y auditorías de cumplimiento. Mediante la supervisión de los cambios en la configuración de auditoría, te aseguras de que todas las actividades en tu proyecto se puedan auditar en cualquier momento. Para obtener más información, consulta Descripción general de las métricas basadas en registros.

Según la cantidad de información, los costos de Cloud Monitoring pueden ser significativos. Para obtener información sobre el uso del servicio y sus costos, consulta Precios de Google Cloud Observability.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

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

Crear métrica

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

   Ir a Métricas basadas en registros

2. Haga clic en Crear métrica.

3. En Tipo de métrica, selecciona Contador.

4. En Detalles, haz lo siguiente:

   1. Establece un nombre de métrica de registro.
   2. Agrega una descripción.
   3. Establece las Unidades en 1.

5. En Selección de filtro, copia y pega el siguiente texto en el cuadro Crear filtro y reemplaza el texto existente, si es necesario:

     protoPayload.methodName="SetIamPolicy"
     AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*

6. Haga clic en Crear métrica. Verás un mensaje de confirmación.

Crear una política de alertas

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

   Ir a Métricas basadas en registros

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Logging.

2. En la sección Métricas definidas por el usuario, selecciona la métrica que creaste en la sección anterior.

3. Haz clic en Más y, luego, en Crear alerta a partir de métricas.

   Se abre el cuadro de diálogo Condición nueva con las opciones de transformación de métricas y datos ya propagadas.

4. Haga clic en Next.
   1. Revisa la configuración ya propagada. Te recomendamos modificar el Valor del umbral.
   2. Haz clic en Nombre de la condición y, luego, ingresa un nombre para la condición.
5. Haz clic en Siguiente.

6. Para agregar notificaciones a tu política de alertas, haz clic en Canales de notificaciones. En el diálogo, selecciona uno o más canales de notificaciones del menú y, luego, haz clic en Aceptar.

   Si quieres recibir notificaciones cuando se abran y se cierren incidentes, marca Notificar el cierre de incidentes. De forma predeterminada, se envían notificaciones solo cuando los incidentes se abren.

7. Opcional: Actualiza la Duración del cierre automático de incidentes. Este campo determina cuándo Monitoring cierra los incidentes ante la ausencia de datos de métricas.
8. Opcional: Haz clic en Documentación y, luego, agrega la información que deseas incluir en un mensaje de notificación.
9. Haz clic en Nombre de la alerta y, luego, ingresa un nombre para la política de alertas.
10. Haz clic en Crear política.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Audit logging disabled

Nombre de categoría en la API: AUDIT_LOGGING_DISABLED

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

El registro de auditoría está inhabilitado para uno o más servicios de Google Cloud, o bien uno o más principales están exentos del registro de auditoría de acceso a los datos.

Habilita Cloud Logging para todos los servicios a fin de realizar un seguimiento de todas las actividades de administrador, acceso de lectura y escritura a los datos del usuario. Según la cantidad de información, los costos de Cloud Logging pueden ser significativos. Para obtener información sobre el uso del servicio y su costo, consulta Precios de Google Cloud Observability.

Si algún principal está exento del registro de auditoría de acceso a los datos en la configuración predeterminada del registro de auditoría de acceso a los datos o en las configuraciones de registro de cualquier servicio individual, quita la exención.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Configuración predeterminada de los registros de auditoría de acceso a los datos en la consola de Google Cloud.

   Ir a la configuración predeterminada

2. En la pestaña Tipos de registro, activa el registro de auditoría de acceso a los datos en la configuración predeterminada:

   1. Selecciona Lectura de administración, Lectura de datos y Escritura de datos.
   2. Haz clic en Guardar.

3. En la pestaña Principales exentos, quita a todos los usuarios exentos de la configuración predeterminada:

   1. Para quitar cada principal de la lista, haz clic en Borrar junto a cada nombre.
   2. Haz clic en Guardar.

4. Ve a la página Registros de auditoría.

   Ve a los registros de auditoría

5. Quita los principales exentos de la configuración del registro de auditoría de acceso a los datos de los servicios individuales.

   1. En Configuración de registros de auditoría de acceso a los datos, para cada servicio que muestre una principal exenta, haz clic en el servicio. Se abrirá un panel de configuración del registro de auditoría para el servicio.
   2. En la pestaña Principales exentas, haz clic en Borrar junto a cada nombre para quitar todas las principales exentas.
   3. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Auto backup disabled

Nombre de categoría en la API: AUTO_BACKUP_DISABLED

Una base de datos de Cloud SQL no tiene habilitadas las copias de seguridad automáticas.

Para evitar la pérdida de datos, activa las copias de seguridad automáticas para tus instancias de SQL. Para obtener más información, consulta Crea y administra copias de seguridad automáticas y bajo demanda.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias

2. Haga clic en el nombre de la instancia.

3. Haz clic en Copias de seguridad.

4. Junto a Configuración, haz clic en Editar.

5. Selecciona la casilla de verificación Copias de seguridad diarias automáticas.

6. Opcional: En el cuadro Cantidad de días, ingresa la cantidad de días de copias de seguridad que deseas conservar.

7. Opcional: En la lista Período de copia de seguridad, selecciona el período en el que se crearán las copias de seguridad.

8. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Auto repair disabled

Nombre de categoría en la API: AUTO_REPAIR_DISABLED

Se inhabilita la función de reparación automática de un clúster de Google Kubernetes Engine (GKE), que mantiene los nodos en buen estado.

Cuando está habilitada, GKE realiza controles periódicos al estado de cada nodo en el clúster. Si un nodo falla en varias verificaciones de estado consecutivas durante un período prolongado, GKE inicia un proceso de reparación para ese nodo. Para obtener más información, consulta Reparación automática de nodos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a clústeres de Kubernetes

2. Haz clic en la pestaña Nodos.

3. 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 Administración, selecciona Habilitar reparación automática.
   4. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Auto upgrade disabled

Nombre de categoría en la API: AUTO_UPGRADE_DISABLED

Se inhabilita una función de actualización automática de un clúster de GKE, que mantiene los clústeres y grupos de nodos en la última versión estable de Kubernetes.

Para obtener más información, consulta la información sobre cómo actualizar automáticamente los nodos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a clústeres de Kubernetes

2. En la lista de clústeres, haz clic en el nombre del clúster.

3. Haz clic en la pestaña Nodos.

4. 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 Administración, selecciona Habilitar actualización automática.
   4. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

BigQuery table CMEK disabled

Nombre de categoría en la API: BIGQUERY_TABLE_CMEK_DISABLED

Una tabla de BigQuery no está configurada para usar una clave de encriptación administrada por el cliente (CMEK).

Con CMEK, las claves que creas y administras en Cloud KMS envuelven las claves que usa Google Cloud para encriptar tus datos, lo que te brinda más control sobre el acceso a tus datos. Para obtener más información, consulta Protege datos con claves de Cloud KMS.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

1. Crea una tabla protegida por Cloud Key Management Service.
2. Copia la tabla en la nueva tabla con CMEK habilitada.
3. Borra la tabla original.

Para establecer una clave CMEK predeterminada que encripte todas las tablas nuevas de un conjunto de datos, consulta Configura una clave predeterminada de conjunto de datos.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Binary authorization disabled

Nombre de 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, ya que solo permite que las imágenes de contenedor firmadas por autoridades de confianza durante el proceso de desarrollo se implementen en el clúster. Cuando aplicas una implementación basada en firmas, obtienes un mayor control sobre el entorno de contenedores, lo que garantiza que solo se puedan implementar imágenes verificadas.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a clústeres de Kubernetes

2. En la sección Seguridad, haz clic en Editar en la fila Autorización binaria.

   Si la configuración del clúster cambió recientemente, el botón de edición puede estar inhabilitado. Si no puedes editar la configuración del clúster, espera unos minutos y vuelve a intentarlo.

3. En el cuadro de diálogo, selecciona Habilitar Autorización binaria.

4. Haz clic en Guardar cambios.

5. Ve a la página Autorización binaria.

   Ve a Autorización binaria

6. Asegúrate de que esté configurada una política que requiera certificadores y que la regla predeterminada del proyecto no esté configurada para Permitir todas las imágenes. Para obtener más información, consulta Configura GKE.

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

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Bucket CMEK disabled

Nombre de categoría en la API: BUCKET_CMEK_DISABLED

Un bucket no está encriptado con claves de encriptación administradas por el cliente (CMEK).

Establecer una CMEK predeterminada en un bucket te brinda más control sobre el acceso a tus datos. Para obtener más información, consulta Claves de encriptación administradas por el cliente.

Para solucionar este problema, usa CMEK con un bucket mediante el uso de claves de encriptación administradas por el cliente. Las CMEK generan costos adicionales relacionados con Cloud KMS.

Nota: La configuración de una clave predeterminada no volverá a encriptar de forma retroactiva los objetos que se encuentran en este momento en el bucket con una clave nueva.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Bucket IAM not monitored

Nombre de categoría en la API: BUCKET_IAM_NOT_MONITORED

Las métricas y alertas de registros no están configuradas para supervisar los cambios de permiso de IAM de Cloud Storage.

La supervisión de los cambios en los permisos del bucket de Cloud Storage te ayuda a identificar a los usuarios con privilegios excesivos o las actividades sospechosas. Para obtener más información, consulta Descripción general de las métricas basadas en registros.

Según la cantidad de información, los costos de Cloud Monitoring pueden ser significativos. Para obtener información sobre el uso del servicio y sus costos, consulta Precios de Google Cloud Observability.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

Crear métrica

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

   Ir a Métricas basadas en registros

2. Haga clic en Crear métrica.

3. En Tipo de métrica, selecciona Contador.

4. En Detalles, haz lo siguiente:

   1. Establece un nombre de métrica de registro.
   2. Agrega una descripción.
   3. Establece las Unidades en 1.

5. En Selección de filtro, copia y pega el siguiente texto en el cuadro Crear filtro y reemplaza el texto existente, si es necesario:

     resource.type=gcs_bucket
     AND protoPayload.methodName="storage.setIamPermissions"

6. Haga clic en Crear métrica. Verás un mensaje de confirmación.

Crear una política de alertas

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

   Ir a Métricas basadas en registros

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Logging.

2. En la sección Métricas definidas por el usuario, selecciona la métrica que creaste en la sección anterior.

3. Haz clic en Más y, luego, en Crear alerta a partir de métricas.

   Se abre el cuadro de diálogo Condición nueva con las opciones de transformación de métricas y datos ya propagadas.

4. Haga clic en Next.
   1. Revisa la configuración ya propagada. Te recomendamos modificar el Valor del umbral.
   2. Haz clic en Nombre de la condición y, luego, ingresa un nombre para la condición.
5. Haz clic en Siguiente.

6. Para agregar notificaciones a tu política de alertas, haz clic en Canales de notificaciones. En el diálogo, selecciona uno o más canales de notificaciones del menú y, luego, haz clic en Aceptar.

   Si quieres recibir notificaciones cuando se abran y se cierren incidentes, marca Notificar el cierre de incidentes. De forma predeterminada, se envían notificaciones solo cuando los incidentes se abren.

7. Opcional: Actualiza la Duración del cierre automático de incidentes. Este campo determina cuándo Monitoring cierra los incidentes ante la ausencia de datos de métricas.
8. Opcional: Haz clic en Documentación y, luego, agrega la información que deseas incluir en un mensaje de notificación.
9. Haz clic en Nombre de la alerta y, luego, ingresa un nombre para la política de alertas.
10. Haz clic en Crear política.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Bucket logging disabled

Nombre de categoría en la API: BUCKET_LOGGING_DISABLED

Hay un bucket de almacenamiento sin el registro habilitado.

Para investigar los problemas de seguridad y supervisar el consumo de almacenamiento, habilita los registros de acceso y la información de almacenamiento en tus buckets de Cloud Storage. Los registros de acceso proporcionan información de todas las solicitudes hechas a un bucket específico, y los registros de almacenamiento ofrecen información sobre el consumo de almacenamiento de ese bucket.

Para solucionar este problema, configura el registro del bucket que indican las estadísticas de estado de seguridad mediante la guía Registros de acceso y registros de almacenamiento.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Bucket policy only disabled

Nombre de categoría en la API: BUCKET_POLICY_ONLY_DISABLED

El acceso uniforme a nivel de bucket, que antes se denominaba Solo política del bucket, no está configurado.

El acceso uniforme a nivel de bucket simplifica el control de acceso a buckets mediante la inhabilitación de los permisos a nivel de objeto (LCA). Cuando se habilita, solo los permisos de nivel de bucket de IAM otorgan acceso al bucket y a los objetos que contiene. Para obtener más información, consulta Acceso uniforme a nivel de buckets.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página del navegador de Cloud Storage en la consola de Google Cloud.

   Ir al navegador de Cloud Storage

2. En la lista de buckets, haz clic en el nombre del bucket deseado.

3. Haz clic en la pestaña Configuración.

4. En Permisos, en la fila Control de acceso, haz clic en Editar modelo de control de acceso.

5. En el cuadro de diálogo, selecciona Uniforme.

6. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Cloud Asset API disabled

Nombre de categoría en la API: CLOUD_ASSET_API_DISABLED

El servicio de Cloud Asset Inventory no está habilitado para el proyecto.

Para solucionar este resultado, completa los siguientes pasos:

1. En la consola de Google Cloud, ve a la página Biblioteca de API.

   Ir a la biblioteca de la API

2. Busca Cloud Asset Inventory.

3. Selecciona el resultado del servicio de la API de Cloud Asset.

4. Asegúrate de que se muestre API habilitada.

Cluster logging disabled

Nombre de categoría en la API: CLUSTER_LOGGING_DISABLED

Logging no está habilitado para un clúster de GKE.

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

Según la cantidad de información, los costos de Cloud Logging pueden ser significativos. Para obtener información sobre el uso del servicio y su costo, consulta Precios de Google Cloud Observability.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Clústeres de Kubernetes

2. Selecciona el clúster enumerado en el resultado de las estadísticas del estado de seguridad.

3. Haz clic en  Editar.

   Si la configuración del clúster cambió recientemente, el botón de edición puede estar inhabilitado. Si no puedes editar la configuración del clúster, espera unos minutos y vuelve a intentarlo.

4. En la lista desplegable Stackdriver Logging heredado o Stackdriver Kubernetes Engine Monitoring, selecciona Habilitado.

   Estas opciones no son compatibles. Asegúrate de usar Stackdriver Logging heredado con Stackdriver Monitoring heredado o solo Stackdriver Kubernetes Engine Monitoring.

5. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Cluster monitoring disabled

Nombre de categoría en la API: CLUSTER_MONITORING_DISABLED

Monitoring está inhabilitado en los clústeres de GKE.

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

Según la cantidad de información, los costos de Cloud Monitoring pueden ser significativos. Para obtener información sobre el uso del servicio y sus costos, consulta Precios de Google Cloud Observability.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Clústeres de Kubernetes

2. Selecciona el clúster enumerado en el resultado de las estadísticas del estado de seguridad.

3. Haz clic en  Editar.

   Si la configuración del clúster cambió recientemente, el botón de edición puede estar inhabilitado. Si no puedes editar la configuración del clúster, espera unos minutos y vuelve a intentarlo.

4. En la lista desplegable Stackdriver Monitoring heredado o Stackdriver Kubernetes Engine Monitoring, selecciona Habilitado.

   Estas opciones no son compatibles. Asegúrate de usar Stackdriver Monitoring heredado con Stackdriver Logging heredado o solo Stackdriver Kubernetes Engine Monitoring.

5. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Cluster private Google access disabled

Nombre de categoría en la API: CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

Los hosts de clústeres no están configurados con el fin de usar solo direcciones IP internas privadas para acceder a las API de Google.

El Acceso privado a Google permite que las instancias de máquinas virtuales (VM) solo con direcciones IP internas privadas puedan alcanzar las direcciones IP públicas de los servicios y las API de Google. Para obtener más información, consulta Configura el acceso privado a Google.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a las redes de VPC

2. En la lista de redes, haz clic en el nombre de la red deseada.

3. En la página Detalles de la red de VPC, haz clic en la pestaña Subredes.

4. En la lista de subredes, haz clic en el nombre de la subred asociada con el clúster de Kubernetes en el resultado.

5. En la página Detalles de la subred, haz clic en Editar.

6. En Acceso privado a Google, selecciona Activado.

7. Haz clic en Guardar.

8. Para quitar IP públicas (externas) de instancias de VM cuyo único tráfico externo es a las API de Google, consulta Anula la asignación de una dirección IP externa estática.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Cluster secrets encryption disabled

Nombre de categoría en la API: CLUSTER_SECRETS_ENCRYPTION_DISABLED

La encriptación de secretos de la capa de aplicación está inhabilitada en un clúster de GKE.

La encriptación de secretos de la capa de aplicación garantiza que los secretos de GKE se encripten con claves de Cloud KMS. La característica proporciona una capa adicional de seguridad para datos sensibles, como los secretos definidos por el usuario y los secretos necesarios para la operación del clúster, como las claves de las cuentas de servicio, que se almacenan en etcd.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Claves de Cloud KMS

2. Revisa las claves de tu aplicación o crea una clave de encriptación de base de datos (DEK). Para obtener más información, consulta Crea una clave de Cloud KMS.

3. Ir a la página Clústeres de Kubernetes

   Ir a clústeres de Kubernetes

4. Selecciona el clúster en el resultado.

5. En Seguridad, en el campo Encriptación de Secrets de la capa de la aplicación, haz clic en Editar encriptación de Secrets en la capa de la aplicación.

6. Selecciona la casilla de verificación Habilitar la encriptación de Secrets de la capa de la aplicación y elige la DEK que creaste.

7. Haz clic en Save Changes.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Cluster shielded nodes disabled

Nombre de categoría en la API: CLUSTER_SHIELDED_NODES_DISABLED

Los nodos de GKE protegidos no están habilitados para un clúster.

Sin los nodos de GKE protegidos, los atacantes pueden aprovechar una vulnerabilidad en un pod para robar credenciales de arranque y cambiar 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 resultado, completa los siguientes pasos:

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

   Ir a clústeres de Kubernetes

2. Selecciona el clúster en el resultado.

3. En Seguridad, en el campo Nodos de GKE protegidos, haz clic en Editar nodos de GKE protegidos.

4. Selecciona la casilla de verificación Habilitar nodos de GKE protegidos.

5. Haz clic en Save Changes.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Compute project wide SSH keys allowed

Nombre de categoría en la API: COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

Se usan claves SSH de nivel de proyecto, lo que permite acceder a todas las instancias del proyecto.

Usar claves SSH de nivel de proyecto facilita la administración de claves de SSH, pero si se ve comprometida, representa un riesgo de seguridad que puede afectar a todas las instancias dentro de un proyecto. Debes usar claves SSH específicas de la instancia, que limitan la superficie de ataque si se vulneran las claves SSH. Para obtener más información, consulta Administra claves SSH en los metadatos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de VM

2. En la lista de instancias, haz clic en el nombre de la instancia en el resultado.

3. En la página Detalles de la instancia de VM, haz clic en Editar.

   Nota:No puedes editar instancias creadas con plantillas de instancias. Para realizar cambios en la configuración de una plantilla de instancias, consulta Cómo actualizar plantillas de instancias.

4. En Claves SSH, selecciona Bloquear Claves SSH para todo el proyecto.

5. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Compute Secure Boot disabled

Nombre de categoría en la API: COMPUTE_SECURE_BOOT_DISABLED

Esta VM protegida no tiene el Inicio seguro habilitado.

El uso de Inicio seguro ayuda a proteger tus máquinas virtuales contra rootkits y bootkits. Compute Engine no habilita Inicio seguro de forma predeterminada porque algunos controladores sin firmar y softwares de bajo nivel no son compatibles. Si tu VM no usa software incompatible y se inicia con Inicio seguro habilitado, Google recomienda usar Inicio seguro. Si usas módulos de terceros con controladores NVIDIA, asegúrate de que sean compatibles con Inicio seguro antes de habilitarlo.

Para obtener más información, consulta la documentación sobre el inicio seguro.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de VM

2. En la lista de instancias, haz clic en el nombre de la instancia en el resultado.

3. En la página Detalles de instancia de VM, haz clic en Detener.

4. Una vez que la instancia se detenga, haz clic en Editar.

5. En VM protegida, selecciona Activar Inicio seguro.

6. Haz clic en Guardar.

7. Haz clic en Iniciar para iniciar la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Compute serial ports enabled

Nombre de categoría en la API: COMPUTE_SERIAL_PORTS_ENABLED

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

Si habilitas la consola en serie interactiva en una instancia, los clientes pueden intentar conectarse a esa instancia desde cualquier dirección IP. Por lo tanto, se debe inhabilitar la compatibilidad con esta consola. Para obtener más información, consulta Habilita el acceso a un proyecto.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de VM

2. En la lista de instancias, haz clic en el nombre de la instancia en el resultado.

3. En la página Detalles de instancia de VM, haz clic en Editar.

4. En Acceso remoto (Remote access), desactiva Habilitar la conexión a puertos en serie (Enable connecting to serial ports).

5. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Confidential Computing disabled

Nombre de categoría en la API: CONFIDENTIAL_COMPUTING_DISABLED

Una instancia de Compute Engine no tiene habilitado Confidential Computing.

Confidential Computing agrega un tercer pilar a la encriptación de extremo a extremo con la encriptación de datos mientras están en uso. Con los entornos de ejecución confidenciales que proporciona Confidential Computing y la virtualización encriptada segura (SEV) de AMD, 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 borrar la instancia actual y crear una nueva.

Para obtener más información, consulta Confidential VMs y Compute Engine.

Nota: Confidential Computing solo es compatible con los tipos de máquina N2D.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de VM

2. En la lista de instancias, haz clic en el nombre de la instancia en el resultado.

3. En la página Detalles de la instancia de VM, haz clic en Borrar.

4. Crea una Confidential VM con la consola de Google Cloud.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

COS not used

Nombre de categoría en la API: COS_NOT_USED

Las VM de Compute Engine no usan Container-Optimized OS, que está diseñado para ejecutar contenedores de Docker en Google Cloud de forma segura.

Container-Optimized OS es el SO que Google recomienda para alojar y ejecutar contenedores en Google Cloud. El tamaño reducido del SO minimiza los riesgos de seguridad, a la vez que actualiza las vulnerabilidades de seguridad del parche de forma automática y oportuna. Para obtener más información, consulta Descripción general de Container-Optimized OS.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a clústeres de Kubernetes

2. En la lista de clústeres, haz clic en el nombre del clúster en el resultado.

3. Haz clic en la pestaña Nodos.

4. 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, luego, haz clic en Cambiar.
   5. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Custom role not monitored

Nombre de categoría en la API: CUSTOM_ROLE_NOT_MONITORED

Las métricas y las alertas de registros no están configuradas para supervisar los cambios de funciones personalizadas.

IAM proporciona funciones predefinidas y personalizadas que otorgan acceso a recursos específicos de Google Cloud. Mediante la supervisión de la creación, eliminación y actualización de funciones, puedes identificar funciones con privilegios excesivos en las etapas iniciales. Para obtener más información, consulta Descripción general de las métricas basadas en registros.

Según la cantidad de información, los costos de Cloud Monitoring pueden ser significativos. Para obtener información sobre el uso del servicio y sus costos, consulta Precios de Google Cloud Observability.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

Crear métrica

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

   Ir a Métricas basadas en registros

2. Haga clic en Crear métrica.

3. En Tipo de métrica, selecciona Contador.

4. En Detalles, haz lo siguiente:

   1. Establece un nombre de métrica de registro.
   2. Agrega una descripción.
   3. Establece las Unidades en 1.

5. En Selección de filtro, copia y pega el siguiente texto en el cuadro Crear filtro y reemplaza el texto existente, si es necesario:

     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")

6. Haga clic en Crear métrica. Verás un mensaje de confirmación.

Crear una política de alertas

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

   Ir a Métricas basadas en registros

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Logging.

2. En la sección Métricas definidas por el usuario, selecciona la métrica que creaste en la sección anterior.

3. Haz clic en Más y, luego, en Crear alerta a partir de métricas.

   Se abre el cuadro de diálogo Condición nueva con las opciones de transformación de métricas y datos ya propagadas.

4. Haga clic en Next.
   1. Revisa la configuración ya propagada. Te recomendamos modificar el Valor del umbral.
   2. Haz clic en Nombre de la condición y, luego, ingresa un nombre para la condición.
5. Haz clic en Siguiente.

6. Para agregar notificaciones a tu política de alertas, haz clic en Canales de notificaciones. En el diálogo, selecciona uno o más canales de notificaciones del menú y, luego, haz clic en Aceptar.

   Si quieres recibir notificaciones cuando se abran y se cierren incidentes, marca Notificar el cierre de incidentes. De forma predeterminada, se envían notificaciones solo cuando los incidentes se abren.

7. Opcional: Actualiza la Duración del cierre automático de incidentes. Este campo determina cuándo Monitoring cierra los incidentes ante la ausencia de datos de métricas.
8. Opcional: Haz clic en Documentación y, luego, agrega la información que deseas incluir en un mensaje de notificación.
9. Haz clic en Nombre de la alerta y, luego, ingresa un nombre para la política de alertas.
10. Haz clic en Crear política.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Dataproc CMEK disabled

Nombre de categoría en la API: DATAPROC_CMEK_DISABLED

Se creó un clúster de Dataproc sin una CMEK de configuración de encriptación. Con CMEK, las claves que creas y administras en Cloud Key Management Service envuelven las claves que usa Google Cloud para encriptar tus datos, lo que te brinda más control sobre el acceso a tus datos.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Clústeres de Dataproc

2. Selecciona tu proyecto y haz clic en Crear clúster.

3. En la sección Administrar seguridad, haz clic en Encriptación y selecciona Clave administrada por el cliente.

4. Selecciona una clave administrada por el cliente de la lista.

   Si no tienes una clave administrada por el cliente, debes crear una para usarla. Para obtener más información, consulta Claves de encriptación administradas por el cliente.

5. Asegúrate de que la clave de KMS seleccionada tenga el rol de encriptador/desencriptador de CryptoKey de Cloud KMS asignado a la cuenta de servicio del clúster de Dataproc ("serviceAccount:[e-mail]").

6. Después de crear el clúster, migra todas tus cargas de trabajo del clúster anterior al nuevo.

7. Ve a Clústeres de Dataproc y selecciona tu proyecto.

8. Selecciona el clúster anterior y haz clic en Borrar clúster.

9. Repite todos los pasos anteriores para otros clústeres de Dataproc disponibles en el proyecto seleccionado.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Dataproc image outdated

Nombre de categoría en la API: DATAPROC_IMAGE_OUTDATED

Un clúster de Dataproc se creó mediante una versión de imagen de Dataproc afectada por vulnerabilidades de seguridad en la utilidad Apache Log4j 2 (CVE-2021-44228 y CVE-) 2021-45046.

Este detector busca vulnerabilidades cuando verifica si el campo softwareConfig.imageVersion en la propiedad config de un Cluster tiene cualquiera de las siguientes versiones afectadas:

• Versiones con imágenes anteriores a la 1.3.95
• Versiones con imágenes submenores anteriores a 1.4.77, 1.5.53 y 2.0.27

El número de versión de una imagen personalizada de Dataproc se puede anular de forma manual. Considere estas situaciones:

• La versión de una imagen personalizada afectada se puede modificar para que no lo parezca. En este caso, este detector no emite un resultado.
• Se puede anular la versión de una imagen personalizada no afectada por una que se sabe que tiene la vulnerabilidad. En este caso, este detector emite un resultado falso positivo. Para suprimir estos resultados falsos positivos, puedes silenciarlos.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

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

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Dataset CMEK disabled

Nombre de categoría en la API: DATASET_CMEK_DISABLED

Un conjunto de datos de BigQuery no está configurado para usar una clave de encriptación predeterminada administrada por el cliente (CMEK).

Con CMEK, las claves que creas y administras en Cloud KMS envuelven las claves que usa Google Cloud para encriptar tus datos, lo que te brinda más control sobre el acceso a tus datos. Para obtener más información, consulta Protege datos con claves de Cloud KMS.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

No puedes cambiar una tabla entre las encriptaciones predeterminadas y la encriptación de CMEK. A fin de establecer una clave CMEK predeterminada para encriptar todas las tablas nuevas en el conjunto de datos, sigue las instrucciones de modo que puedas configurar una clave predeterminada del conjunto de datos.

Si configuras una clave predeterminada, no se volverán a encriptar de forma retroactiva las tablas que están en el conjunto de datos con una clave nueva. Sigue estos pasos si quieres usar CMEK en los datos existentes:

1. Crea un nuevo conjunto de datos.
2. Establece una clave CMEK predeterminada en el conjunto de datos que creaste.
3. Si deseas copiar las tablas en tu conjunto de datos habilitado para CMEK, sigue las instrucciones para copiar una tabla.
4. Después de copiar los datos correctamente, borra los conjuntos de datos originales.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Default network

Nombre de categoría en la API: DEFAULT_NETWORK

La red predeterminada existe en un proyecto.

Las redes predeterminadas crean automáticamente reglas de firewall y configuraciones de red que podrían no ser seguras. Para obtener más información, consulta Red predeterminada.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a las redes de VPC

2. En la lista de redes, haz clic en el nombre de la red predeterminada.

3. En la página Detalles de la red de VPC, haz clic en Borrar red de VPC.

4. Para crear una red nueva con reglas de firewall personalizadas, consulta Crea redes.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Default service account used

Nombre de 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 la función Editor en el proyecto, lo que permite el acceso de lectura y escritura a la mayoría de los servicios de Google Cloud. Para protegerte contra la elevación de privilegios y el acceso no autorizado, no uses la cuenta de servicio predeterminada de Compute Engine. En su lugar, crea una cuenta de servicio nueva y asigna solo los permisos que necesita tu instancia. Lee Control de acceso para obtener información sobre los roles y los permisos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de VM

2. Selecciona la instancia relacionada con el resultado de Security Health Analytics.

3. En la página Detalles de la instancia que se carga, haz clic en Detener.

4. Una vez que la instancia se detenga, haz clic en Editar.

5. En la sección Cuenta de servicio, selecciona una cuenta de servicio que no sea la predeterminada de Compute Engine. Es posible que primero debas crear una cuenta de servicio nueva. Lee Control de acceso para obtener información sobre las funciones y los permisos de IAM.

6. Haz clic en Guardar. La configuración nueva aparecerá en la página Detalles de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Disk CMEK disabled

Nombre de categoría en la API: DISK_CMEK_DISABLED

Los discos de esta VM no se encriptan con claves de encriptación administradas por el cliente (CMEK).

Con CMEK, las claves que creas y administras en Cloud KMS envuelven las claves que usa Google Cloud para encriptar tus datos, lo que te brinda más control sobre el acceso a tus datos. Para obtener más información, consulta Protege recursos con las claves de Cloud KMS.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de Compute Engine en la consola de Google Cloud.

   Ir a Discos de Compute Engine

2. En la lista de discos, haz clic en el nombre del disco que aparece en el resultado.

3. En la página Administrar disco, haz clic en Borrar.

4. Para crear un disco nuevo con CMEK habilitadas, consulta Encripta un disco persistente nuevo con tus propias claves. Las CMEK generan costos adicionales relacionados con Cloud KMS.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Disk CSEK disabled

Nombre de categoría en la API: DISK_CSEK_DISABLED

Los discos de esta VM no se encriptan con claves de encriptación proporcionadas por el cliente (CSEK). Los discos para las VM importantes se deben encriptar con CSEK.

Si proporcionas tus propias claves de encriptación, Compute Engine usa tu clave a fin de proteger las generadas por Google que se usan para encriptar y desencriptar tus datos. Para obtener más información, consulta Claves de encriptación proporcionadas por el cliente. Las CSEK generan costos adicionales relacionados con Cloud KMS.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

Borra y crea un disco

Solo puedes encriptar discos persistentes nuevos con tu propia clave. No puedes usarla para encriptar discos persistentes existentes.

1. Ve a la página de Compute Engine en la consola de Google Cloud.

   Ir a Discos de Compute Engine

2. En la lista de discos, haz clic en el nombre del disco que aparece en el resultado.

3. En la página Administrar disco, haz clic en Borrar.

4. Para crear un disco nuevo con la CSEK habilitada, consulta Encripta discos con claves de encriptación proporcionadas por el cliente.

5. Completa los pasos restantes para habilitar el detector.

Habilita el detector

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

   Ir a recursos

2. 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, ingresa Disk en el campo de búsqueda y, luego, haz clic en Aplicar.

   El panel Resultados se actualiza para mostrar solo instancias del tipo de recurso compute.Disk.

3. En la columna Nombre visible, selecciona la casilla junto al nombre del disco que deseas usar con CSEK y, luego, haz clic en Configurar marcas de seguridad.

4. En el cuadro de diálogo, haz clic en Agregar marca.

5. En el campo clave, ingresa enforce_customer_supplied_disk_encryption_keys y, en el campo valor, ingresa true.

6. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

DNS logging disabled

Nombre de categoría en la API: DNS_LOGGING_DISABLED

La supervisión de los registros de Cloud DNS proporciona visibilidad a los nombres de DNS que solicitan los clientes en la red de VPC. Estos registros pueden supervisarse en busca de nombres de dominio anómalos y evaluarse en función de la inteligencia de amenazas. Te recomendamos que habilites el registro de DNS para las redes de VPC.

Según la cantidad de información, los costos del registro de Cloud Logging pueden ser significativos. Para obtener información sobre el uso del servicio y su costo, consulta Precios de la observabilidad de Google Cloud: Cloud Logging.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a las redes de VPC

2. En la lista de redes, haz clic en el nombre de la red de VPC.

3. Crea una política de servidor nueva (si no existe una) o edita una existente:

   • Si la red no tiene una política de servidor DNS, completa los siguientes pasos:

     1. Haz clic en  Editar.
     2. En el campo Política del servidor DNS, haz clic en Crear una nueva política de servidor.
     3. Ingresa un nombre para la política del servidor nueva.
     4. Establece Registros como Activados.
     5. Haz clic en Guardar.

   • Si la red tiene una política de servidor DNS, completa los siguientes pasos:

     1. En el campo Política del servidor DNS, haz clic en el nombre de la política de DNS.
     2. Haz clic en Editar política.
     3. Establece Registros como Activados.
     4. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

DNSSEC disabled

Nombre de categoría en la API: DNSSEC_DISABLED

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

Las DNSSEC validan las respuestas de DNS y mitigan los riesgos, como la usurpación de DNS y los ataques de intermediarios, mediante la firma criptográfica de los registros DNS. Debes habilitar DNSSEC. Consulta la página sobre la descripción general de las extensiones de seguridad de DNS (DNSSEC) para obtener más información.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a las redes de Cloud DNS

2. Ubica la fila con la zona DNS indicada en el resultado.

3. Haz clic en la configuración de DNSSEC en la fila y, luego, en DNSSEC, selecciona Activado.

4. Lee el diálogo que aparece. Si estás satisfecho, haz clic en Habilitar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Effectively Anonymous Users Granted GKE Cluster Access

Nombre de categoría en la API: GKE_PRIVILEGE_ESCALATION_DEFAULT_USERS_GROUPS

Alguien creó una vinculación de RBAC que hace referencia a uno de los siguientes usuarios o grupos:

• system:anonymous
• system:authenticated
• system:unauthenticated

Estos usuarios y grupos son, en realidad, anónimos y no deben usarse en RoleBindings ni ClusterRoleBindings. Para obtener más información, consulta Evita los roles y los grupos predeterminados.

Para solucionar este problema, aplica los siguientes pasos a los recursos afectados:

1. Abre el manifiesto de cada ClusterRoleBinding o RoleBinding afectado.
2. Establece los siguientes campos restringidos con 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 o system:unauthenticated

Egress deny rule not set

Nombre de categoría en la API: EGRESS_DENY_RULE_NOT_SET

Una regla de denegación de salida no está configurada en un firewall.

Un firewall que rechace todo el tráfico de red de salida evita todas las conexiones de red de salida no deseadas, excepto aquellas que otros firewalls autoricen de forma explícita. Para obtener más información, consulta Casos de salida.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir al Firewall

2. Haga clic en Crear regla de firewall.

3. Asigna un nombre al firewall y, si quieres, una descripción.

4. En Dirección del tráfico, selecciona Salida.

5. En Acción en caso de coincidencia, selecciona Rechazar.

6. En el menú desplegable Destinos, selecciona Todas las instancias de la red.

7. En el menú desplegable Filtro de destino, selecciona Rangos de IP y, luego, escribe 0.0.0.0/0 en el cuadro Rangos de IP de destino.

8. En Protocolos y puertos, selecciona Rechazar todo.

9. Haz clic en Inhabilitar regla y, luego, en Aplicación, selecciona Habilitado.

10. Haz clic en Crear.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Essential contacts not configured

Nombre de categoría en la API: ESSENTIAL_CONTACTS_NOT_CONFIGURED

Tu organización no designó a una persona o un grupo para que reciba notificaciones de Google Cloud sobre eventos importantes, como ataques, vulnerabilidades e incidentes de datos dentro de tu organización de Google Cloud. Te recomendamos que designes como contacto esencial a una o más personas o grupos de tu organización comercial.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Contactos esenciales

2. Asegúrate de que la organización aparezca en el selector de recursos en la parte superior de la página. El selector de recursos te indica para qué proyecto, organización o carpeta administras los contactos.

3. Haz clic en + Agregar contacto. Se abrirá el panel Agregar un contacto.

4. En los campos Correo electrónico y Confirmar correo electrónico, ingresa la dirección de correo electrónico del contacto.

5. En la sección Categorías de notificaciones, selecciona las categorías de notificaciones con las que deseas que el contacto reciba comunicaciones. Asegúrate de que las direcciones de correo electrónico adecuadas estén configuradas correctamente para cada una de las siguientes categorías de notificación:

   1. Legal
   2. Seguridad
   3. Suspensión
   4. Técnico

6. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Firewall not monitored

Nombre de categoría en la API: FIREWALL_NOT_MONITORED

Nota: El filtro de métricas basadas en registros de este detector se cambió el 27 de octubre de 2021.

Las métricas y las alertas de registros no están configuradas para supervisar los cambios de la regla de firewall de la red de VPC.

La supervisión de los eventos de actualización y creación de reglas de firewall te brinda estadísticas sobre los cambios en el acceso a la red, y puede ayudarte a detectar con rapidez actividades sospechosas. Para obtener más información, consulta Descripción general de las métricas basadas en registros.

Según la cantidad de información, los costos de Cloud Monitoring pueden ser significativos. Para obtener información sobre el uso del servicio y sus costos, consulta Precios de Google Cloud Observability.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

Crear métrica

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

   Ir a Métricas basadas en registros

2. Haga clic en Crear métrica.

3. En Tipo de métrica, selecciona Contador.

4. En Detalles, haz lo siguiente:

   1. Establece un nombre de métrica de registro.
   2. Agrega una descripción.
   3. Establece las Unidades en 1.

5. En Selección de filtro, copia y pega el siguiente texto en el cuadro Crear filtro y reemplaza el texto existente, si es necesario:

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

6. Haga clic en Crear métrica. Verás un mensaje de confirmación.

Crear una política de alertas

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

   Ir a Métricas basadas en registros

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Logging.

2. En la sección Métricas definidas por el usuario, selecciona la métrica que creaste en la sección anterior.

3. Haz clic en Más y, luego, en Crear alerta a partir de métricas.

   Se abre el cuadro de diálogo Condición nueva con las opciones de transformación de métricas y datos ya propagadas.

4. Haga clic en Next.
   1. Revisa la configuración ya propagada. Te recomendamos modificar el Valor del umbral.
   2. Haz clic en Nombre de la condición y, luego, ingresa un nombre para la condición.
5. Haz clic en Siguiente.

6. Para agregar notificaciones a tu política de alertas, haz clic en Canales de notificaciones. En el diálogo, selecciona uno o más canales de notificaciones del menú y, luego, haz clic en Aceptar.

   Si quieres recibir notificaciones cuando se abran y se cierren incidentes, marca Notificar el cierre de incidentes. De forma predeterminada, se envían notificaciones solo cuando los incidentes se abren.

7. Opcional: Actualiza la Duración del cierre automático de incidentes. Este campo determina cuándo Monitoring cierra los incidentes ante la ausencia de datos de métricas.
8. Opcional: Haz clic en Documentación y, luego, agrega la información que deseas incluir en un mensaje de notificación.
9. Haz clic en Nombre de la alerta y, luego, ingresa un nombre para la política de alertas.
10. Haz clic en Crear política.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Firewall rule logging disabled

Nombre de categoría en la API: FIREWALL_RULE_LOGGING_DISABLED

El registro de las reglas de firewall está inhabilitado.

El Registro de reglas de firewall te permite inspeccionar, verificar y analizar los efectos de tus reglas de firewall. Esto puede ser útil para auditar el acceso a la red o proporcionar una advertencia temprana de que la red se está usando de manera no aprobada. El costo de los registros puede ser significativo. Para obtener más información sobre el registro de reglas de firewall y su costo, consulta Usa el registro de reglas de firewall.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall deseada.

3. Haz clic en  Editar.

4. En Registros, selecciona Activar.

5. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Flow logs disabled

Nombre de categoría en la API: FLOW_LOGS_DISABLED

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

Los registros de flujo de VPC registran una muestra de los flujos de red que se envían y se reciben en las instancias de VM. Estos registros se pueden utilizar para supervisar redes, detectar intrusiones, realizar un análisis de la seguridad en tiempo real y optimizar gastos. Para obtener más información sobre los registros de flujo y su costo, consulta Usa registros de flujo de VPC.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a las redes de VPC

2. En la lista de redes, haz clic en el nombre de la red deseada.

3. En la página Detalles de la red de VPC, haz clic en la pestaña Subredes.

4. En la lista de subredes, haz clic en el nombre de la subred indicada en el resultado.

5. En la página Detalles de la subred, haz clic en Editar.

6. En Registros de flujo, selecciona Activado.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Flow logs settings not recommended

Nombre de categoría en la API: VPC_FLOW_LOGS_SETTINGS_NOT_RECOMMENDED

En la configuración de una subred en una red de VPC, el servicio de registros de flujo de VPC está desactivado o no está configurado según las recomendaciones de CIS Benchmark 1.3. Los registros de flujo de VPC registran una muestra de flujos de red enviados y recibidos por instancias de VM que se pueden usar para detectar amenazas.

Nota: Los registros de flujo de VPC pueden generar costos, y las recomendaciones de CIS Benchmark no están optimizadas para reducirlos. Para reducir costos, usa un intervalo de agregación de 15 minutos y una tasa de muestreo de entre un 5% y un 10%, lo que proporciona un buen equilibrio entre el costo y la detección de amenazas. Sin embargo, si usas esta configuración balanceada, seguirás recibiendo este resultado, ya que esta no coincide con las recomendaciones actuales de la CIS Benchmark.

Para obtener más información sobre los registros de flujo de VPC y su costo, consulta Usa los registros de flujo de VPC.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a las redes de VPC

2. En la lista de redes, haz clic en el nombre de la red.

3. En la página Detalles de la red de VPC, haz clic en la pestaña Subredes.

4. En la lista de subredes, haz clic en el nombre de la subred indicada en el resultado.

5. En la página Detalles de la subred, haz clic en Editar.

6. En Registros de flujo, selecciona Activado.

   1. De manera opcional, puedes modificar la configuración de los registros si haces clic en Configurar registros para expandir la pestaña. Las comparativas de CIS recomiendan la siguiente configuración:
      1. Establece el Intervalo de agregación en 5 SEGUNDOS.
      2. En la casilla de verificación Campos adicionales, selecciona la opción Incluir metadatos.
      3. Establece la Tasa de muestreo en 100%.
      4. Haz clic en el botón GUARDAR.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Full API access

Nombre de 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 API de Google Cloud.

Una instancia configurada con la cuenta de servicio predeterminada y el permiso de acceso a la API establecido en Permitir el acceso total a todas las APIs de Cloud podría permitir que los usuarios realicen operaciones o llamadas a la API para las cuales no tienen permisos de IAM. Para obtener más información, consulta Cuenta de servicio predeterminada de Compute Engine.

Importante: El siguiente procedimiento cambia las APIs a las que tiene acceso la cuenta de servicio predeterminada. Es posible que se vean afectados los procesos o las cargas de trabajo de VM que usan la cuenta de servicio predeterminada. La Inteligencia de políticas puede ayudarte a comprender cómo se usa la cuenta de servicio predeterminada. Para obtener más información, consulta Herramientas para comprender el uso de las cuentas de servicio.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de VM

2. En la lista de instancias, haz clic en el nombre de la instancia en el resultado.

3. Si la instancia está en ejecución, haz clic en Detener.

4. Cuando la instancia se detenga, haz clic en Editar.

5. En la sección Seguridad y acceso, en Cuentas de servicio, selecciona Cuenta de servicio predeterminada de Compute Engine.

6. En Permisos de acceso, selecciona Permitir acceso predeterminado o Configurar acceso para cada API. Esto limita las APIs a las que puede acceder cualquier proceso o carga de trabajo que use la cuenta de servicio predeterminada de la VM.

7. Si seleccionaste Configurar acceso para cada API, haz lo siguiente:

   • Para inhabilitar Cloud Platform, configúralo como Ninguna.
   • Habilita las APIs específicas a las que la cuenta de servicio predeterminada de la VM requiere acceso.

8. Haz clic en Guardar.

9. Haz clic en Iniciar para iniciar la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

HTTP load balancer

Nombre de categoría en la API: HTTP_LOAD_BALANCER

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

A fin de proteger la integridad de tus datos y evitar que intrusos alteren tus comunicaciones, configura tus balanceadores de cargas HTTP(S) para permitir solo tráfico HTTPS. Para obtener más información, consulta Descripción general del balanceo de cargas de HTTP(S) externo.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Grupos de destino en la consola de Google Cloud.

   Ir a Proxies de destino

2. En la lista de proxies de destino, haz clic en el nombre del proxy de destino en el resultado.

3. Haz clic en el vínculo en Mapa de URL.

4. Haz clic en  Editar.

5. Haga clic en Configuración de frontend.

6. Borra todas las configuraciones de IP de frontend y puerto que permitan el tráfico HTTP y crea otras nuevas que permitan el tráfico HTTPS.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Instance OS login disabled

Nombre de categoría en la API: INSTANCE_OS_LOGIN_DISABLED

El Acceso al SO está inhabilitado en esta instancia de Compute Engine.

El Acceso al SO habilita la administración centralizada de la clave SSH con la IAM y, además, inhabilita la configuración de la clave SSH basada en metadatos en todas las instancias de un proyecto. Obtén información sobre cómo configurar el acceso a SO.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de VM

2. En la lista de instancias, haz clic en el nombre de la instancia en el resultado.

3. En la página Detalles de la instancia que se carga, haz clic en Detener.

4. Una vez que la instancia se detenga, haz clic en Editar.

5. En la sección Metadatos personalizados, asegúrate de que el elemento con la clave enable-oslogin tenga el valor TRUE.

6. Haz clic en Guardar.

7. Haz clic en Iniciar para iniciar la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Integrity monitoring disabled

Nombre de categoría en la API: INTEGRITY_MONITORING_DISABLED

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

La supervisión de integridad te permite supervisar y verificar la integridad de inicio del entorno de ejecución de los nodos protegidos con Monitoring. Esto te permite responder a las fallas de integridad y evitar que los nodos vulnerados se implementen en el clúster.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

Una vez que se aprovisiona un nodo, no se puede actualizar para habilitar la supervisión de integridad. Debes crear un grupo de nodos nuevo con la supervisión de integridad habilitada.

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

   Ir a clústeres de Kubernetes

2. Haz clic en el nombre del clúster en el resultado.

3. Haz clic en AGREGAR GRUPO DE NODOS.

4. En la pestaña Seguridad, asegúrate de que esté habilitada la opción Habilitar supervisión de integridad.

5. Haga clic en Crear.

6. Para migrar tus cargas de trabajo de grupos de nodos existentes que no cumplen con los grupos de nodos nuevos, consulta Migra cargas de trabajo a diferentes tipos de máquinas.

7. Después de que se hayan transferido tus cargas de trabajo, borra los grupos de nodos originales que no cumplan con los requisitos.

   1. En la página del clúster de Kubernetes, en el menú Grupos de nodos, haz clic en el nombre del grupo de nodos que quieres borrar.
   2. Haz clic en Quitar grupo de nodos.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Intranode visibility disabled

Nombre de categoría en la API: INTRANODE_VISIBILITY_DISABLED

La visibilidad dentro de los nodos está inhabilitada para un clúster de GKE.

Si habilitas la visibilidad dentro de los nodos, el tráfico de un Pod a otro dentro del mismo nodo será visible para la estructura de red. Esta característica permite usar el registro de flujo de VPC y otras funciones de VPC para supervisar o controlar el tráfico dentro de los nodos. Debes habilitar los registros de flujo de VPC en la subred seleccionada para obtener los registros. Para obtener más información, consulta Usa los registros de flujo de VPC.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

Una vez que se aprovisiona un nodo, no se puede actualizar para habilitar la supervisión de integridad. Debes crear un grupo de nodos nuevo con la supervisión de integridad habilitada.

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

   Ir a clústeres de Kubernetes

2. En la sección Herramientas de redes, haz clic en Editar visibilidad dentro de los nodos en la fila Visibilidad dentro de los nodos.

   Si la configuración del clúster cambió recientemente, el botón de edición puede estar inhabilitado. Si no puedes editar la configuración del clúster, espera unos minutos y vuelve a intentarlo.

3. En el diálogo, selecciona Habilitar la visibilidad dentro de los nodos.

4. Haz clic en Save Changes.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

IP alias disabled

Nombre de categoría en la API: IP_ALIAS_DISABLED

Se creó un clúster de GKE con los rangos de IP de alias inhabilitados.

Cuando habilitas los rangos de alias de IP, los clústeres de GKE asignan direcciones IP desde un bloque CIDR conocido para que el clúster sea escalable y, además, interactúe mejor con los productos y entidades de Google Cloud. Para obtener más información, consulta Descripción general de los rangos de alias de IP.

Para solucionar este resultado, completa los siguientes pasos:

No puedes migrar un clúster existente para que use IP de alias. Sigue estos pasos para crear un clúster nuevo con IP de alias habilitadas:

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

   Ir a clústeres de Kubernetes

2. Haga clic en Crear.

3. En el panel de navegación, en Clúster, haz clic en Redes.

4. En Opciones avanzadas de redes, selecciona Habilitar el enrutamiento de tráfico nativo de la VPC (con alias de IP).

5. Haga clic en Crear.

   Nota:No se puede modificar un clúster mientras se está reconfigurando.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

IP forwarding enabled

Nombre de categoría en la API: IP_FORWARDING_ENABLED

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

Inhabilita el desvío de IP de los paquetes de datos de tus VM para prevenir la pérdida de datos o la divulgación de información.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de VM

2. En la lista de instancias, marca la casilla junto al nombre de la instancia en el resultado.

3. Haz clic en Borrar.

4. Selecciona Crear instancia para crear una instancia nueva que reemplace la que borraste.

5. Para asegurarte de que el reenvío de IP esté inhabilitado, haz clic en Administración, discos, redes, claves SSH y, luego, en Herramientas de redes.

6. En Interfaces de red, haz clic en Editar.

7. En Reenvío de IP, en el menú desplegable, asegúrate de que la opción Desactivado esté seleccionada.

8. Especifica el resto de los parámetros de la instancia y, luego, haz clic en Crear. Para obtener más información, consulta Crea e inicia una instancia de VM.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

KMS key not rotated

Nombre de categoría en la API: KMS_KEY_NOT_ROTATED

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

La rotación de las claves de encriptación proporciona protección con regularidad en caso de que se vulnere una clave y limita la cantidad de mensajes encriptados disponibles para realizar un criptoanálisis de una versión de clave específica. Para obtener más información, consulta Rotación de claves.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Claves de Cloud KMS

2. Haz clic en el nombre del llavero de claves que se indica en el resultado.

3. Haz clic en el nombre de la clave indicada en el resultado.

4. Haz clic en Editar período de rotación.

5. Establece el período de rotación en un máximo de 90 días.

6. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

KMS project has owner

Nombre de categoría en la API: KMS_PROJECT_HAS_OWNER

Un usuario tiene permisos roles/Owner en un proyecto que tiene claves criptográficas. Para obtener más información, consulta el artículo sobre permisos y funciones.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de IAM en la consola de Google Cloud.

   Ir a la página IAM

2. Si es necesario, selecciona el proyecto en el resultado.

3. Sigue estos pasos por cada principal asignado a la función Propietario:

   1. Haz clic en  Editar.
   2. En el panel Editar permisos, junto al rol de Propietario, haz clic en Borrar.
   3. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

KMS public key

Nombre de categoría en la API: KMS_PUBLIC_KEY

Tanto la clave criptográfica de Cloud KMS como un llavero de claves de Cloud KMS son públicos y cualquier persona en Internet puede acceder a ellos. Para obtener más información, consulta Usa IAM con Cloud KMS.

Para solucionar este hallazgo, si está relacionado con una CryptoKey, haz lo siguiente:

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

   Claves criptográficas

2. En Nombre, selecciona el llavero de claves que contiene la clave criptográfica relacionada con el resultado de Security Health Analytics.

3. En la página Detalles del llavero de claves que se carga, selecciona la casilla de verificación junto a la clave criptográfica.

4. Si laPANEL DE INFORMACIÓN no se muestra, haz clic en el MOSTRAR PANEL DE INFORMACIÓN.

5. Usa el cuadro de filtro que precede a Función / Principal para buscar principales de allUsers y allAuthenticatedUsers, y haz clic en Borrar para quitar el acceso a estos principales.

Sigue estos pasos para solucionar el problema, si está relacionado con un llavero de claves:

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

   Claves criptográficas

2. Busca la fila con el llavero de claves en el resultado y selecciona la casilla de verificación.

3. Si laPANEL DE INFORMACIÓN no se muestra, haz clic en el MOSTRAR PANEL DE INFORMACIÓN.

4. Usa el cuadro de filtro que precede a Función / Principal para buscar principales de allUsers y allAuthenticatedUsers, y haz clic en Borrar para quitar el acceso a estos principales.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

KMS role separation

Nombre de categoría en la API: KMS_ROLE_SEPARATION

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

Uno o más principales tienen varios permisos de Cloud KMS asignados. Recomendamos que ninguna cuenta tenga permisos de administrador de Cloud KMS de manera simultánea con otros permisos de Cloud KMS. Para obtener más información, consulta el artículo sobre permisos y funciones.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de IAM en la consola de Google Cloud.

   Ir a IAM

2. Para cada principal de la lista que aparece en el resultado, haz lo siguiente:

   1. Para verificar si la función se heredó de una carpeta o recurso de organización, consulta la columna Herencia. Si la columna contiene un vínculo a un recurso superior, haz clic en el vínculo para ir a la página de IAM del recurso superior.
   2. Haz clic en Editar junto a una persona principal.
   3. Para quitar permisos, haz clic en Borrar junto a Administrador de Cloud KMS. Si deseas quitar todos los permisos a las principales, haz clic en Borrar junto a todos los otros permisos.

3. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Legacy authorization enabled

Nombre de categoría en la API: LEGACY_AUTHORIZATION_ENABLED

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

En Kubernetes, el control de acceso basado en funciones (RBAC) te permite definir funciones con reglas que contienen una serie de permisos y otorgar permisos en el nivel de clúster y espacio de nombres. Esto proporciona mayor seguridad y garantiza que los usuarios solo tengan acceso a los recursos específicos. Considera inhabilitar el control de acceso basado en atributos (ABAC) heredados.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Clústeres de Kubernetes

2. Selecciona el clúster enumerado en el resultado de las estadísticas del estado de seguridad.

3. Haz clic en  Editar.

   Si la configuración del clúster cambió recientemente, el botón de edición puede estar inhabilitado. Si no puedes editar la configuración del clúster, espera unos minutos y vuelve a intentarlo.

4. En la lista desplegable Autorización heredada, selecciona Inhabilitada.

5. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Legacy metadata enabled

Nombre de categoría en la API: LEGACY_METADATA_ENABLED

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

El servidor de metadatos de instancia de Compute Engine expone los extremos heredados /0.1/ y /v1beta1/ que no aplican encabezados de consulta de metadatos. Esta es una característica de las API /v1/ que dificulta a un atacante potencial recuperar metadatos de la instancia. A menos que sea necesario, te recomendamos inhabilitar las API heredadas /0.1/ y /v1beta1/.

Para obtener más información, consulta Inhabilita y realiza la transición desde la API de metadatos heredados.

Para solucionar este resultado, completa los siguientes pasos:

Solo puedes inhabilitar las API de metadatos heredados cuando creas un clúster nuevo o agregas un grupo de nodos nuevo a un clúster existente. Para actualizar un clúster existente e inhabilitar las API de metadatos heredados, consulta Migra cargas de trabajo a diferentes tipos de máquina.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Legacy network

Nombre de categoría en la API: LEGACY_NETWORK

Existe una red heredada en un proyecto.

No recomendamos usar redes heredadas porque muchas funciones de seguridad nuevas de Google Cloud no son compatibles con ellas. En su lugar, usa redes de VPC. Para obtener más información, consulta Redes heredadas.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a las redes de VPC

2. Para crear una nueva red no heredada, haz clic en Crear red.

3. Regrese a la página Redes de VPC.

4. En la lista de redes, haz clic en legacy_network.

5. En la página Detalles de la red de VPC, haz clic en Borrar red de VPC.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Load balancer logging disabled

Nombre de categoría en la API: LOAD_BALANCER_LOGGING_DISABLED

El registro está inhabilitado para el servicio de backend en un balanceador de cargas.

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

Precaución: Una tasa de muestreo alta puede generar costos de almacenamiento más altos para el archivo de registro. Debes encontrar un equilibrio entre la tasa de muestreo y los posibles costos de almacenamiento adecuados para tu empresa.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Balanceo de cargas de Cloud en la consola de Google Cloud.

   Ir a Cloud Load Balancing

2. Haz clic en el nombre de tu balanceador de cargas.

3. Haz clic en  Editar.

4. Haga clic en Configuración de backend.

5. En la página Configuración de backend, haz clic en Editar.

6. En la sección Logging, selecciona Habilitar registro y elige la mejor tasa de muestreo para el proyecto.

7. Para terminar de editar el servicio de backend, haz clic en Actualizar.

8. Para terminar de editar el balanceador de cargas, haz clic en Actualizar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Locked retention policy not set

Nombre de categoría en la API: LOCKED_RETENTION_POLICY_NOT_SET

Una política de retención bloqueada no se establece para los registros.

Una política de retención bloqueada evita que se reemplacen los registros y que se borre el bucket de registro. Para obtener más información, consulta Bloqueo de buckets.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Navegador de Storage en la consola de Google Cloud.

   Ir al navegador de almacenamiento

2. Selecciona el bucket enumerado en el resultado de las estadísticas del estado de seguridad.

3. En la página de detalles del bucket, haga clic en la pestaña Permisos.

4. Si no se estableció una política de retención, haz clic en Configurar política de retención.

5. Ingresa un período de retención.

6. Haz clic en Guardar. La política de retención se muestra en la pestaña Retención.

7. Haz clic en Bloquear para garantizar que el período de retención no se abrevie ni se quite.

   Precaución: Bloquear una política de retención es una acción irreversible y solo se puede deshacer si borras todo el bucket. Para obtener más información, consulta Bloqueo de buckets.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Log not exported

Nombre de categoría en la API: LOG_NOT_EXPORTED

Un recurso no tiene configurado un receptor de registros adecuado.

Cloud Logging te ayuda a encontrar con rapidez las causas principales de los problemas en tus sistemas y aplicaciones. Sin embargo, la mayoría de los registros solo se conservan durante 30 días de forma predeterminada. Exporta las copias de todas las entradas de registro para extender el período de almacenamiento. Para obtener más información, consulta la Descripción general de las exportaciones de registros.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Enrutador de registros

2. Haz clic en Crear receptor.

3. Para asegurarte de que todos los registros se exporten, deja los filtros de inclusión y exclusión vacíos.

4. Haz clic en Crear receptor.

   Nota: Mediante estas instrucciones, se crea un receptor a nivel de proyecto. Los receptores también pueden crearse a nivel de la organización o la carpeta. Para obtener más información, consulta Exporta registros con la consola de Google Cloud.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Master authorized networks disabled

Nombre de 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 mejoran la seguridad de tu clúster de contenedores mediante el bloqueo de direcciones IP específicas a fin de que no puedan acceder al plano de control de tu clúster. Si deseas obtener más información, consulta Agrega redes autorizadas para el acceso al plano de control.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Clústeres de Kubernetes

2. Selecciona el clúster enumerado en el resultado de las estadísticas del estado de seguridad.

3. Haz clic en  Editar.

   Si la configuración del clúster cambió recientemente, el botón de edición puede estar inhabilitado. Si no puedes editar la configuración del clúster, espera unos minutos y vuelve a intentarlo.

4. En la lista desplegable Redes autorizadas del plano de control, selecciona Habilitadas.

5. Haga clic en Agregar red autorizada.

6. Especifica las redes autorizadas que deseas utilizar.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

MFA not enforced

Nombre de categoría en la API: MFA_NOT_ENFORCED

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

La autenticación de varios factores, específicamente la verificación en dos pasos (2SV), está inhabilitada para algunos usuarios de tu organización.

La autenticación de varios factores se usa con el fin de proteger las cuentas del acceso no autorizado y es la herramienta más importante para que no se vulneren las credenciales de acceso de tu organización. Para obtener más información, consulta Protege tu empresa con la verificación en dos pasos.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Consola del administrador en la consola de Google Cloud.

   Ir a la Consola del administrador

2. Aplicar la verificación en 2 pasos en todas las unidades organizativas.

Cómo suprimir los resultados de este tipo

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

Aunque no es una forma recomendada de suprimir los resultados, también puedes agregar marcas de seguridad específicas a los recursos para que los detectores de las estadísticas del estado de la seguridad no creen resultados de seguridad para esos recursos.

• Para evitar que se vuelva a activar este resultado, agrega la marca de seguridad allow_mfa_not_enforced con un valor de true al recurso.
• Para ignorar posibles incumplimientos de unidades organizativas específicas, agrega la marca de seguridad excluded_orgunits al recurso con una lista de rutas de acceso de unidades organizativas separadas por comas en el campo value. Por ejemplo, excluded_orgunits:/people/vendors/vendorA,/people/contractors/contractorA.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Network not monitored

Nombre de categoría en la API: NETWORK_NOT_MONITORED

Nota: El filtro de métricas basadas en registros de este detector se cambió el 27 de octubre de 2021.

Las métricas y las alertas de registros no están configuradas para supervisar los cambios de la red de VPC

Para detectar cambios incorrectos o no autorizados en tu configuración de red, supervisa los cambios en la red de VPC. Para obtener más información, consulta Descripción general de las métricas basadas en registros.

Según la cantidad de información, los costos de Cloud Monitoring pueden ser significativos. Para obtener información sobre el uso del servicio y sus costos, consulta Precios de Google Cloud Observability.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

Crear métrica

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

   Ir a Métricas basadas en registros

2. Haga clic en Crear métrica.

3. En Tipo de métrica, selecciona Contador.

4. En Detalles, haz lo siguiente:

   1. Establece un nombre de métrica de registro.
   2. Agrega una descripción.
   3. Establece las Unidades en 1.

5. En Selección de filtro, copia y pega el siguiente texto en el cuadro Crear filtro y reemplaza el texto existente, si es necesario:

     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")

6. Haga clic en Crear métrica. Verás un mensaje de confirmación.

Crear una política de alertas

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

   Ir a Métricas basadas en registros

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Logging.

2. En la sección Métricas definidas por el usuario, selecciona la métrica que creaste en la sección anterior.

3. Haz clic en Más y, luego, en Crear alerta a partir de métricas.

   Se abre el cuadro de diálogo Condición nueva con las opciones de transformación de métricas y datos ya propagadas.

4. Haga clic en Next.
   1. Revisa la configuración ya propagada. Te recomendamos modificar el Valor del umbral.
   2. Haz clic en Nombre de la condición y, luego, ingresa un nombre para la condición.
5. Haz clic en Siguiente.

6. Para agregar notificaciones a tu política de alertas, haz clic en Canales de notificaciones. En el diálogo, selecciona uno o más canales de notificaciones del menú y, luego, haz clic en Aceptar.

   Si quieres recibir notificaciones cuando se abran y se cierren incidentes, marca Notificar el cierre de incidentes. De forma predeterminada, se envían notificaciones solo cuando los incidentes se abren.

7. Opcional: Actualiza la Duración del cierre automático de incidentes. Este campo determina cuándo Monitoring cierra los incidentes ante la ausencia de datos de métricas.
8. Opcional: Haz clic en Documentación y, luego, agrega la información que deseas incluir en un mensaje de notificación.
9. Haz clic en Nombre de la alerta y, luego, ingresa un nombre para la política de alertas.
10. Haz clic en Crear política.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Network policy disabled

Nombre de categoría en la API: NETWORK_POLICY_DISABLED

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

Según la configuración predeterminada, la comunicación entre pods está abierta. Las comunicaciones abiertas permiten que los pods se conecten directamente en los nodos, con o sin traducción de direcciones de red. Un recurso NetworkPolicy es como un firewall a nivel de pods que restringe las conexiones entre los pods, a menos que el recurso NetworkPolicy permita la conexión de forma explícita. Obtén más información para definir una política de red.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Clústeres de Kubernetes

2. Haz clic en el nombre del clúster que aparece en el resultado de Security Health Analytics.

3. En Herramientas de redes, en la fila de Política de red de Calico Kubernetes, haz clic en Editar.

   Si la configuración del clúster cambió recientemente, el botón de edición puede estar inhabilitado. Si no puedes editar la configuración del clúster, espera unos minutos y vuelve a intentarlo.

4. En el cuadro de diálogo, selecciona Habilitar la política de red de Calico Kubernetes para el plano de control y Habilitar la política de red de Calico Kubernetes para nodos.

5. Haz clic en Save Changes.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Nodepool boot CMEK disabled

Nombre de categoría en la API: NODEPOOL_BOOT_CMEK_DISABLED

Los discos de arranque de este grupo de nodos no se encriptan con claves de encriptación administradas por el cliente (CMEK). Las CMEK permiten que el usuario configure las claves de encriptación predeterminadas para los discos de arranque en un grupo de nodos.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a clústeres de Kubernetes

2. En la lista de clústeres, haz clic en el nombre del clúster en el resultado.

3. Haz clic en la pestaña Nodos.

4. Para cada grupo de nodos default-pool, haz clic en Borrar.

5. Cuando se te solicite confirmar, haz clic en Borrar.

6. Para crear grupos de nodos nuevos mediante CMEK, consulta Usa claves de encriptación administradas por el cliente (CMEK). Las CMEK generan costos adicionales relacionados con Cloud KMS.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Nodepool secure boot disabled

Nombre de categoría en la API: NODEPOOL_SECURE_BOOT_DISABLED

El inicio seguro está inhabilitado para un clúster de GKE.

Habilita el inicio seguro para que los nodos de GKE protegidos verifiquen las firmas digitales de los componentes de inicio de los nodos. Para obtener más información, consulta la documentación sobre el inicio seguro.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

Una vez que se aprovisiona un grupo de nodos, no se puede actualizar para habilitar el inicio seguro. Debes crear un nuevo grupo de nodos con el inicio seguro habilitado.

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

   Ir a clústeres de Kubernetes

2. Haz clic en el nombre del clúster en el resultado.

3. Haz clic en AGREGAR GRUPO DE NODOS.

4. En el menú Grupos de nodos, sigue estos pasos:

   1. Haz clic en el nuevo grupo de nodos nuevo para expandir la pestaña.
   2. Selecciona Seguridad y, en Opciones protegidas, selecciona Habilitar inicio seguro.
   3. Haga clic en Crear.
   4. Para migrar tus cargas de trabajo de grupos de nodos existentes que no cumplen con los grupos de nodos nuevos, consulta Migra cargas de trabajo a diferentes tipos de máquinas.
   5. Después de que se hayan transferido tus cargas de trabajo, borra los grupos de nodos originales que no cumplan con los requisitos.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Non org IAM member

Nombre de categoría en la API: NON_ORG_IAM_MEMBER

Un usuario fuera de tu organización o proyecto tiene permisos de IAM en un proyecto o una organización. Obtén más información sobre los permisos de IAM.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de IAM en la consola de Google Cloud.

   Ir a IAM

2. Selecciona la casilla de verificación junto a los usuarios fuera de tu organización o proyecto.

3. Haz clic en Quitar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Object versioning disabled

Nombre de categoría en la API: OBJECT_VERSIONING_DISABLED

El control de versiones de objetos no está habilitado en un bucket de almacenamiento en el que están configurados los receptores.

Para admitir la recuperación de objetos que se borran o reemplazan, Cloud Storage ofrece la función de control de versiones de objetos. Habilita el control de versiones de objetos para proteger los datos de Cloud Storage y evitar que se reemplacen o borren por accidente. Obtén más información sobre cómo habilitar el control de versiones de objetos.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

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

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

Reemplaza finding.assetDisplayName por el nombre del bucket relevante.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open Cassandra port

Nombre de categoría en la API: OPEN_CASSANDRA_PORT

Las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos de Cassandra pueden exponer tus servicios de Cassandra a atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio de Cassandra:

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

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open ciscosecure websm port

Nombre de categoría en la API: OPEN_CISCOSECURE_WEBSM_PORT

Es posible que las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos de Cisco Secure/WebSM expongan tus servicios de CiscoSecure/WebSM a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

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

• TCP - 9090

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open directory services port

Nombre de categoría en la API: OPEN_DIRECTORY_SERVICES_PORT

Las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos del directorio pueden exponer tus servicios de directorio a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio del directorio:

• TCP - 445
• UDP - 445

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open DNS port

Nombre de categoría en la API: OPEN_DNS_PORT

Es probable que las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos de DNS expongan los servicios de DNS a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio de DNS:

• TCP - 53
• UDP - 53

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open Elasticsearch port

Nombre de categoría en la API: OPEN_ELASTICSEARCH_PORT

Es posible que las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos de Elasticsearch expongan tus servicios de Elasticsearch a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio de Elasticsearch:

• TCP - 9200, 9300

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open firewall

Nombre de categoría en la API: OPEN_FIREWALL

Las reglas de Firewall que permiten conexiones desde todas las direcciones IP, como 0.0.0.0/0, o desde todos los puertos, pueden exponer innecesariamente los recursos a ataques de fuentes no previstas. Debes quitar estas reglas o restringir su alcance explícitamente al rango o los puertos de IP de origen deseados. Por ejemplo, en las aplicaciones destinadas a ser públicas, considera restringir los puertos permitidos a los necesarios para la aplicación, como 80 y 443. Si tu aplicación necesita permitir conexiones desde todas las direcciones IP o puertos, considera agregar el recurso a una lista de entidades permitidas. Obtén más información sobre cómo actualizar reglas de firewall.

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Reglas de Firewall en la consola de Google Cloud.

   Ir a Reglas de firewall

2. Haz clic en la regla de firewall que se indica en el resultado de las estadísticas del estado de la seguridad y, luego, en Editar.

3. En Rangos de IP de origen, edita los valores de IP para restringir el rango de IP permitidas.

4. En Protocolos y puertos, selecciona Protocolos y puertos especificados, elige los protocolos permitidos y, luego, ingresa los puertos que se permiten.

5. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open FTP port

Nombre de categoría en la API: OPEN_FTP_PORT

Es probable que las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos de FTP expongan los servicios de FTP a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio de FTP:

• TCP - 21

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open group IAM member

Nombre de categoría en la API: OPEN_GROUP_IAM_MEMBER

Uno o más principales que tienen acceso a una organización, proyecto o carpeta son cuentas de Grupos de Google que se pueden unir sin aprobación.

Los clientes de Google Cloud pueden usar Grupos de Google para administrar funciones y permisos de los miembros de sus organizaciones o aplicar políticas de acceso a colecciones de usuarios. En lugar de otorgar funciones directamente a los miembros, los administradores pueden otorgar funciones y permisos a los Grupos de Google y, luego, agregar miembros a grupos específicos. Los miembros del grupo heredan todos los roles y los permisos de un grupo, lo que permite que los miembros accedan a recursos y servicios específicos.

Si se usa una cuenta de Grupos de Google abierta como principal en una vinculación de IAM, cualquier persona puede heredar el rol asociado solo si se une al grupo de forma directa o indirecta (a través de un subgrupo). Recomendamos revocar los roles de los grupos abiertos o restringir el acceso a esos grupos.

Para solucionar este problema, realiza uno de los siguientes procedimientos.

Quita el grupo de la política de IAM

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

1. Ve a la página de IAM en la consola de Google Cloud.

   Ir a IAM

2. Si es necesario, selecciona el proyecto, la carpeta o la organización en el resultado.

3. Revoca el rol de cada grupo abierto identificado en el resultado.

Restringe el acceso a los grupos abiertos

1. Accede a Grupos de Google.
2. Actualiza la configuración de cada grupo abierto y sus subgrupos para especificar quién puede unirse al grupo y quién debe aprobarlo.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open HTTP port

Nombre de categoría en la API: OPEN_HTTP_PORT

Es probable que las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos HTTP expongan tus servicios HTTP a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio de HTTP:

• TCP - 80

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open LDAP port

Nombre de categoría en la API: OPEN_LDAP_PORT

Es probable que las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos de LDAP expongan tus servicios de LDAP a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio de LDAP:

• TCP - 389, 636
• UDP - 389

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open Memcached port

Nombre de categoría en la API: OPEN_MEMCACHED_PORT

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

Los siguientes son los puertos de servicio de Memcached:

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

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open MongoDB port

Nombre de categoría en la API: OPEN_MONGODB_PORT

Es probable que las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos de MongoDB expongan tus servicios de MongoDB a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio de MongoDB:

• TCP - 27017, 27018, 27019

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open MySQL port

Nombre de categoría en la API: OPEN_MYSQL_PORT

Es probable que las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos de MySQL expongan tus servicios de MySQL a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos del servicio de MySQL:

• TCP - 3306

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open NetBIOS port

Nombre de categoría en la API: “OPEN_NETBIOS_PORT”

Las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos de NetBIOS pueden exponer tus servicios de NetBIOS a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio de NetBIOS:

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

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open OracleDB port

Nombre de categoría en la API: OPEN_ORACLEDB_PORT

Es posible que las reglas de Firewall que permiten que cualquier dirección IP se conecte a los puertos de OracleDB expongan tus servicios de OracleDB a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio de OracleDB:

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

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open POP3 port

Nombre de categoría en la API: OPEN_POP3_PORT

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

Los siguientes son los puertos de servicio de POP3:

• TCP - 110

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open PostgreSQL port

Nombre de categoría en la API: OPEN_POSTGRESQL_PORT

Es posible que las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos de PostgreSQL expongan tus servicios de PostgreSQL a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio de PostgreSQL:

• TCP - 5432
• UDP - 5432

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open RDP port

Nombre de categoría en la API: OPEN_RDP_PORT

Es posible que las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos de RDP expongan tus servicios de RDP a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio de RDP:

• TCP - 3389
• UDP - 3389

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open Redis port

Nombre de categoría en la API: OPEN_REDIS_PORT

Es probable que las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos de Redis expongan los servicios de Redis a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Estos son los puertos de servicio de Redis:

• TCP - 6379

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open SMTP port

Nombre de categoría en la API: OPEN_SMTP_PORT

Es posible que las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos SMTP expongan tus servicios SMTP a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio de SMTP:

• TCP - 25

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open SSH port

Nombre de categoría en la API: OPEN_SSH_PORT

Es probable que las reglas de firewall que permiten que cualquier dirección IP se conecte a los puertos SSH expongan tus servicios SSH a los atacantes. Para obtener más información, consulta la Descripción general de las reglas de firewall de VPC.

Los siguientes son los puertos de servicio de SSH:

• SCTP - 22
• TCP - 22

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Open Telnet port

Nombre de categoría en la API: OPEN_TELNET_PORT

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

Los siguientes son los puertos del servicio de Telnet:

• TCP - 23

Este resultado se genera en las reglas de firewall vulnerables, incluso si las inhabilitas de forma intencional. Los resultados activos para las reglas de firewall inhabilitadas te alertan sobre las configuraciones inseguras que permitirán el tráfico no deseado si se habilita.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Firewall en la consola de Google Cloud.

   Ir a Firewall

2. En la lista de reglas de firewall, haz clic en el nombre de la regla de firewall en el resultado.

3. Haz clic en  Editar.

4. En Rangos de IP de origen, borra 0.0.0.0/0.

5. Agrega las direcciones IP específicas o los rangos de IP que deseas que se conecten a la instancia.

6. Agrega los puertos y protocolos específicos que quieres abrir en tu instancia.

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Org policy Confidential VM policy

Nombre de categoría en la API: ORG_POLICY_CONFIDENTIAL_VM_POLICY

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

Tu organización requiere que esta VM tenga habilitado el servicio de Confidential VM. Las VM que no tienen este servicio habilitado no usarán la encriptación de memoria del entorno de ejecución, lo que las dejará expuestas a ataques de memoria del entorno de ejecución.

Nota: Confidential VM genera costos adicionales además de los precios de Compute Engine. Para obtener más información, consulta Precios.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de VM

2. En la lista de instancias, haz clic en el nombre de la instancia en el resultado.

3. Si la VM no requiere el servicio de Confidential VM, trasládala a una nueva carpeta o proyecto.

4. Si la VM requiere Confidential VM, haz clic en Borrar.

5. Para crear una instancia nueva con Confidential VM habilitada, consulta la Guía de inicio rápido: Crea una instancia de Confidential VM.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Org policy location restriction

Nombre de 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 Restringe las ubicaciones de recursos.

Nota: Las restricciones de ubicación de recursos no se aplican de forma retroactiva, por lo que si los valores de restricción cambian, los recursos existentes no se alteran. Es posible que se generen resultados de ORG_POLICY_LOCATION_RESTRICTION si las ubicaciones de recursos existentes infringen las restricciones nuevas.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

El detector ORG_POLICY_LOCATION_RESTRICTION abarca muchos tipos de recursos, y las instrucciones de solución son diferentes para cada recurso. El enfoque general para solucionar los incumplimientos de ubicación incluye lo siguiente:

1. Copiar, mover o crear una copia de seguridad del recurso fuera de la región o sus datos en un recurso que esté dentro de la región Leer la documentación de los servicios individuales para obtener instrucciones sobre cómo mover recursos
2. Borrar el recurso fuera de región original o sus datos

Este enfoque no es posible para todos los tipos de recursos. Para obtener orientación, consulta las recomendaciones personalizadas que se proporcionan en el resultado.

Consideraciones adicionales

Cuando corrijas este resultado, ten en cuenta lo siguiente.

Recursos administrados

A veces, otros recursos administran y controlan los ciclos de vida de los recursos. Por ejemplo, un grupo de instancias administrado de Compute Engine crea y destruye instancias de Compute Engine según la política de ajuste de escala automático del grupo de instancias. Si los recursos administrados están dentro del alcance de la aplicación de la ubicación, ambos se pueden marcar como incumplimientos de la política de la organización. La solución de los resultados para los recursos administrados debe realizarse en el recurso de administración a fin de garantizar la estabilidad operativa.

Recursos en uso

Otros recursos los usan. Por ejemplo, un disco de Compute Engine que está 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 la organización de la ubicación, debes asegurarte de que el recurso no esté en uso antes de abordar la violación de la ubicación.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

OS login disabled

Nombre de categoría en la API: OS_LOGIN_DISABLED

El Acceso al SO está inhabilitado en esta instancia de Compute Engine.

El Acceso al SO habilita la administración centralizada de la clave SSH con la IAM y, además, inhabilita la configuración de la clave SSH basada en metadatos en todas las instancias de un proyecto. Obtén información sobre cómo configurar el acceso a SO.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a metadatos

2. Haz clic en Editar y, luego, en Agregar elemento.

3. Agrega un elemento con la clave enable-oslogin y el valor TRUE.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Over privileged account

Nombre de categoría en la API: OVER_PRIVILEGED_ACCOUNT

Un nodo de GKE usa el nodo de servicio predeterminado de Compute Engine, que tiene un acceso amplio de forma predeterminada y puede tener privilegios excesivos para ejecutar tu clúster de GKE.

Para solucionar este resultado, completa los siguientes pasos:

Sigue las instrucciones para usar cuentas de servicio de Google con privilegios mínimos.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Over privileged scopes

Nombre de 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 heredado que permite especificar permisos para tu instancia. Para reducir la posibilidad de una elevación de privilegios en un ataque, debes crear y usar una cuenta de servicio con privilegios mínimos de modo que puedas ejecutar tu clúster de GKE.

Para solucionar este resultado, sigue las instrucciones en Usa las cuentas de servicio de Google con privilegios mínimos.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Over privileged service account user

Nombre de categoría en la API: OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

Un usuario tiene las funciones iam.serviceAccountUser o iam.serviceAccountTokenCreator a nivel del proyecto, la carpeta o la organización, en lugar de una cuenta de servicio específica.

Cuando otorgas esas funciones a un usuario para un proyecto, organización o carpeta, permites que este acceda a todas las cuentas de servicio existentes y futuras de ese alcance. Esto puede generar una situación no deseada de privilegios. Para obtener más información, consulta Permisos de cuentas de servicio.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de IAM en la consola de Google Cloud.

   Ir a la página IAM

2. Si es necesario, selecciona el proyecto, la carpeta o la organización en el resultado.

3. Sigue estos pasos para cada principal asignado a roles/iam.serviceAccountUser o roles/iam.serviceAccountTokenCreator:

   1. Haz clic en  Editar.
   2. En el panel Editar permisos, junto a los roles, haz clic en Borrar.
   3. Haz clic en Guardar.

4. Sigue esta guía para otorgar permisos a los usuarios individuales a fin de que puedan actuar en nombre de una sola cuenta de servicio. Deberás seguir la guía en cada cuenta de servicio para la que quieres permitir que los usuarios seleccionados actúen en su nombre.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Owner not monitored

Nombre de categoría en la API: OWNER_NOT_MONITORED

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

La función de propietario en Cloud IAM tiene el nivel más alto de privilegios en un proyecto. A fin de proteger tus recursos, configura alertas para recibir notificaciones cuando se agreguen o quiten propietarios nuevos. Para obtener más información, consulta Descripción general de las métricas basadas en registros.

Según la cantidad de información, los costos de Cloud Monitoring pueden ser significativos. Para obtener información sobre el uso del servicio y sus costos, consulta Precios de Google Cloud Observability.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

Crear métrica

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

   Ir a Métricas basadas en registros

2. Haga clic en Crear métrica.

3. En Tipo de métrica, selecciona Contador.

4. En Detalles, haz lo siguiente:

   1. Establece un nombre de métrica de registro.
   2. Agrega una descripción.
   3. Establece las Unidades en 1.

5. En Selección de filtro, copia y pega el siguiente texto en el cuadro Crear filtro y reemplaza el texto existente, si es necesario:

     (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")

6. Haga clic en Crear métrica. Verás un mensaje de confirmación.

Crear una política de alertas

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

   Ir a Métricas basadas en registros

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Logging.

2. En la sección Métricas definidas por el usuario, selecciona la métrica que creaste en la sección anterior.

3. Haz clic en Más y, luego, en Crear alerta a partir de métricas.

   Se abre el cuadro de diálogo Condición nueva con las opciones de transformación de métricas y datos ya propagadas.

4. Haga clic en Next.
   1. Revisa la configuración ya propagada. Te recomendamos modificar el Valor del umbral.
   2. Haz clic en Nombre de la condición y, luego, ingresa un nombre para la condición.
5. Haz clic en Siguiente.

6. Para agregar notificaciones a tu política de alertas, haz clic en Canales de notificaciones. En el diálogo, selecciona uno o más canales de notificaciones del menú y, luego, haz clic en Aceptar.

   Si quieres recibir notificaciones cuando se abran y se cierren incidentes, marca Notificar el cierre de incidentes. De forma predeterminada, se envían notificaciones solo cuando los incidentes se abren.

7. Opcional: Actualiza la Duración del cierre automático de incidentes. Este campo determina cuándo Monitoring cierra los incidentes ante la ausencia de datos de métricas.
8. Opcional: Haz clic en Documentación y, luego, agrega la información que deseas incluir en un mensaje de notificación.
9. Haz clic en Nombre de la alerta y, luego, ingresa un nombre para la política de alertas.
10. Haz clic en Crear política.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Pod security policy disabled

Nombre de categoría en la API: POD_SECURITY_POLICY_DISABLED

Que PodSecurityPolicy está inhabilitada en un clúster de GKE.

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

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

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

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Primitive roles used

Nombre de categoría en la API: PRIMITIVE_ROLES_USED

Un usuario tiene una de las siguientes funciones básicas de IAM: roles/owner, roles/editor o roles/viewer. Estas funciones son demasiado permisivas y no se deben usar. En su lugar, se deben asignar solo por proyecto.

Para obtener más información, consulta Comprende las funciones.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de política de IAM en la consola de Google Cloud.

   Ir a la política de IAM

2. Para cada usuario al que se le asignó una función básica, considera usar funciones más detalladas.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Private cluster disabled

Nombre de categoría en la API: PRIVATE_CLUSTER_DISABLED

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

Los clústeres privados permiten que los nodos solo tengan direcciones IP privadas. Esta función limita el acceso a Internet saliente para los nodos. Si los nodos del clúster no tienen una dirección IP pública, no son detectables ni están expuestos a la Internet pública. Aun así, puedes dirigir el tráfico a estos con un balanceador de cargas interno. Para obtener más información, consulta Clústeres privados.

No puedes convertir un clúster existente en privado. Para solucionar este resultado, crea un clúster privado nuevo:

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

   Ir a Clústeres de Kubernetes

2. Haz clic en Crear clúster.

3. En el menú de navegación, en Clúster, selecciona Herramientas de redes.

4. Selecciona el botón de selección de Clúster privado.

5. En Opciones avanzadas de redes, selecciona la casilla de verificación Habilitar enrutamiento de tráfico nativo de la VPC (con alias de IP).

6. Haz clic en Crear.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Private Google access disabled

Nombre de categoría en la API: PRIVATE_GOOGLE_ACCESS_DISABLED

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

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

Para obtener más información, consulta Configura el acceso privado a Google.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a las redes de VPC

2. En la lista de redes, haz clic en el nombre de la red deseada.

3. En la página Detalles de la red de VPC, haz clic en la pestaña Subredes.

4. En la lista de subredes, haz clic en el nombre de la subred asociada con el clúster de Kubernetes en el resultado.

5. En la página Detalles de la subred, haz clic en Editar.

6. En Acceso privado a Google, selecciona Activado.

7. Haz clic en Guardar.

8. Para quitar IP públicas (externas) de instancias de VM cuyo único tráfico externo es a las API de Google, consulta Anula la asignación de una dirección IP externa estática.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Public bucket ACL

Nombre de categoría en la API: PUBLIC_BUCKET_ACL

Un bucket es público y cualquier persona puede acceder a él.

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

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página Navegador de Storage en la consola de Google Cloud.

   Ir al navegador de almacenamiento

2. Selecciona el bucket enumerado en el resultado de las estadísticas del estado de seguridad.

3. En la página Detalles del depósito, haz clic en la pestaña Permisos.

4. Junto a Ver por, haz clic en Funciones.

5. En la casilla Filtro, busca allUsers y allAuthenticatedUsers.

6. Haz clic en Borrar para quitar todos los permisos de IAM otorgados a allUsers y allAuthenticatedUsers.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Public Compute image

Nombre de categoría en la API: PUBLIC_COMPUTE_IMAGE

Una imagen de Compute Engine es pública y cualquiera puede acceder a ella. allUsers representa a cualquier persona en Internet y allAuthenticatedUsers representa a cualquier persona que esté autenticada con Cuenta de Google ninguno está restringido a los usuarios de tu organización.

Las imágenes de Compute Engine pueden contener información sensible como claves de encriptación o software con licencia. Este tipo de información no debe ser accesible de manera pública. Si quieres que esta imagen de Compute Engine sea pública, asegúrate de que no contenga información sensible.

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

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a imágenes de Compute Engine

2. Selecciona el cuadro junto a la imagen public-image y, a continuación, haz clic en Mostrar panel de información.

3. En el cuadro Filtro, busca los principales allUsers y allAuthenticatedUsers.

4. Expande la función de la que deseas quitar usuarios.

5. Haz clic en Borrar para quitar un usuario de ese rol.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Public dataset

Nombre de categoría en la API: PUBLIC_DATASET

Un conjunto de datos de BigQuery es público y cualquier persona puede acceder a él desde Internet. El principal de IAM allUsers representa a cualquier persona en Internet y el allAuthenticatedUsers representa a cualquier persona que haya accedido a un servicio de Google. Ninguno está restringido a los usuarios de tu organización.

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

Para solucionar este resultado, completa los siguientes pasos:

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

   Ve al conjunto de datos de BigQuery

2. En la lista de conjuntos de datos, haz clic en el nombre del conjunto de datos que se identifica en el resultado. Se abrirá el panel Información del conjunto de datos.

3. Cerca de la parte superior del panel Información del conjunto de datos, haz clic en COMPARTIR.

4. En el menú desplegable, haz clic en Permisos.

5. En el panel Permisos del conjunto de datos, ingresa allUsers y allAuthenticatedUsers y quita el acceso para estos principales.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Public IP address

Nombre de 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 tus organizaciones, evita asignar direcciones IP públicas a tus VM. Las instancias detenidas se pueden marcar con un resultado de IP pública, por ejemplo, si las interfaces de red están configuradas para asignar una IP pública efímera al inicio. Asegúrate de que la configuración de red para las instancias detenidas no incluya el acceso externo.

Para obtener más información, consulta Conéctate a instancias de VM de forma segura.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de VM

2. En la lista de instancias, marca la casilla junto al nombre de la instancia en el resultado.

3. Haz clic en  Editar.

4. Para cada interfaz en Interfaces de red, haz clic en Editar y establece IP externa en Ninguna.

5. Haz clic en Listo y, luego, en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Public log bucket

Nombre de categoría en la API: PUBLIC_LOG_BUCKET

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

Un bucket de almacenamiento es público y se usa como un receptor de registros, lo que significa que cualquier persona en Internet puede acceder a los registros almacenados en este bucket. allUsers representa a cualquier persona en Internet, y allAuthenticatedUsers representa a cualquier persona que haya accedido a un servicio de Google; ninguno está restringido a los usuarios de tu organización.

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

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página del navegador de Cloud Storage en la consola de Google Cloud.

   Ir al navegador de Cloud Storage

2. En la lista de buckets, haz clic en el nombre del bucket indicado en el resultado.

3. Haz clic en la pestaña Permisos.

4. Quita allUsers y allAuthenticatedUsers de la lista de principales.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Public SQL instance

Nombre de categoría en la API: PUBLIC_SQL_INSTANCE

La instancia de SQL tiene 0.0.0.0/0 como una red permitida. Esto significa que cualquier cliente IPv4 puede pasar el firewall de red y tratar de acceder a tu instancia, incluidos los clientes que no pretendes admitir. Sin embargo, los clientes deberán tener credenciales válidas para acceder a tu instancia con éxito.

Para obtener más información, consulta la sección sobre cómo autorizar mediante redes autorizadas.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En el panel de navegación, haz clic en Conexiones.

5. En Redes autorizadas, borra 0.0.0.0/0 y agrega direcciones IP o rangos de IP específicos que desees permitir para conectarte a tu instancia.

6. Haz clic en Listo y, luego, en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Pubsub CMEK disabled

Nombre de categoría en la API: PUBSUB_CMEK_DISABLED

Un tema de Pub/Sub no está encriptado con las claves de encriptación administradas por el cliente (CMEK).

Con CMEK, las claves que creas y administras en Cloud KMS envuelven las claves que usa Google para encriptar tus datos, lo que te brinda más control sobre el acceso a tus datos.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar el problema, borra el tema existente y crea uno nuevo:

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

   Ir a temas

2. Si es necesario, selecciona el proyecto que contiene el tema de Pub/Sub.

3. Selecciona la casilla de verificación junto al tema que aparece en el resultado y, luego, haz clic en Borrar.

4. Para crear un tema de Pub/Sub nuevo con CMEK habilitadas, consulta Usa claves de encriptación administradas por el cliente. Las CMEK generan costos adicionales relacionados con Cloud KMS.

5. Publica los resultados y otros datos en el tema de Pub/Sub habilitado para CMEK.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Route not monitored

Nombre de categoría en la API: ROUTE_NOT_MONITORED

Nota: El filtro de métricas basadas en registros de este detector se cambió el 27 de octubre de 2021.

Las métricas y las alertas de registros no están configuradas para supervisar los cambios de ruta de la red de VPC

Las rutas de Google Cloud son destinos y saltos que definen la ruta que toma el tráfico de red de una instancia de VM a una IP de destino. Mediante la supervisión de los cambios en las tablas de ruta, puedes ayudar a garantizar que todo el tráfico de VPC fluya a través de una ruta de acceso esperada.

Para obtener más información, consulta Descripción general de las métricas basadas en registros.

Según la cantidad de información, los costos de Cloud Monitoring pueden ser significativos. Para obtener información sobre el uso del servicio y sus costos, consulta Precios de Google Cloud Observability.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

Crear métrica

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

   Ir a Métricas basadas en registros

2. Haga clic en Crear métrica.

3. En Tipo de métrica, selecciona Contador.

4. En Detalles, haz lo siguiente:

   1. Establece un nombre de métrica de registro.
   2. Agrega una descripción.
   3. Establece las Unidades en 1.

5. En Selección de filtro, copia y pega el siguiente texto en el cuadro Crear filtro y reemplaza el texto existente, si es necesario:

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

6. Haga clic en Crear métrica. Verás un mensaje de confirmación.

Crear una política de alertas

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

   Ir a Métricas basadas en registros

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Logging.

2. En la sección Métricas definidas por el usuario, selecciona la métrica que creaste en la sección anterior.

3. Haz clic en Más y, luego, en Crear alerta a partir de métricas.

   Se abre el cuadro de diálogo Condición nueva con las opciones de transformación de métricas y datos ya propagadas.

4. Haga clic en Next.
   1. Revisa la configuración ya propagada. Te recomendamos modificar el Valor del umbral.
   2. Haz clic en Nombre de la condición y, luego, ingresa un nombre para la condición.
5. Haz clic en Siguiente.

6. Para agregar notificaciones a tu política de alertas, haz clic en Canales de notificaciones. En el diálogo, selecciona uno o más canales de notificaciones del menú y, luego, haz clic en Aceptar.

   Si quieres recibir notificaciones cuando se abran y se cierren incidentes, marca Notificar el cierre de incidentes. De forma predeterminada, se envían notificaciones solo cuando los incidentes se abren.

7. Opcional: Actualiza la Duración del cierre automático de incidentes. Este campo determina cuándo Monitoring cierra los incidentes ante la ausencia de datos de métricas.
8. Opcional: Haz clic en Documentación y, luego, agrega la información que deseas incluir en un mensaje de notificación.
9. Haz clic en Nombre de la alerta y, luego, ingresa un nombre para la política de alertas.
10. Haz clic en Crear política.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Redis role used on org

Nombre de categoría en la API: REDIS_ROLE_USED_ON_ORG

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

Una función de IAM de Redis se asigna a nivel de organización o carpeta.

Las siguientes funciones de IAM de Redis se deben asignar solo por proyecto, no a nivel de organización o 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 resultado, completa los siguientes pasos:

1. Ve a la página de política de IAM en la consola de Google Cloud.

   Ir a la política de IAM

2. Quita las funciones de IAM de Redis que se indican en el resultado y agrégalas en los proyectos individuales.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Release channel disabled

Nombre de categoría en la API: RELEASE_CHANNEL_DISABLED

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

Suscríbete a un canal de versiones para automatizar las actualizaciones de las versiones al clúster de GKE. Estas funciones también reducen la complejidad de la administración de versiones a la cantidad de funciones y el nivel de estabilidad necesarios. Para obtener más información, consulta Canales de versiones.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a clústeres de Kubernetes

2. En la sección Conceptos básicos del clúster, haz clic en Actualizar la versión maestra del clúster en la fila Canal de versiones.

   Si la configuración del clúster cambió recientemente, el botón de edición puede estar inhabilitado. Si no puedes editar la configuración del clúster, espera unos minutos y vuelve a intentarlo.

3. En el cuadro de diálogo, selecciona Canal de versiones y, luego, elige el canal de versiones al que deseas suscribirte.

   Si la versión del plano de control de tu clúster no se puede actualizar a un canal de versiones, ese canal podría inhabilitarse como opción.

4. Haz clic en Save Changes.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

RSASHA1 for signing

Nombre de categoría en la API: RSASHA1_FOR_SIGNING

RSASHA1 se usa para la firma de claves en las zonas de Cloud DNS. El algoritmo que se usa para firmar las claves no debe ser débil.

Para solucionar este problema, reemplaza el algoritmo por uno recomendado mediante la guía Usa opciones de firma avanzadas.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Service account key not rotated

Nombre de categoría en la API: SERVICE_ACCOUNT_KEY_NOT_ROTATED

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

La clave de una cuenta de servicio administrada por el usuario no se rota durante más de 90 días.

En general, las claves de las cuentas de servicio administradas por el usuario se deben rotar al menos cada 90 días para garantizar que no se pueda acceder a los datos con una clave antigua que podría haberse perdido, vulnerado o robado. Para obtener más información, consulta Rota las claves de la cuenta de servicio para reducir el riesgo de seguridad generado por claves filtradas.

Si generaste el par de clave pública/privada, almacenaste la clave privada en un módulo de seguridad de hardware (HSM) y subiste la clave pública a Google, es posible que no necesites rotar la clave cada 90 días. En cambio, puedes rotar la clave si crees que se vulneró su seguridad.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Cuentas de servicio

2. Si es necesario, selecciona el proyecto indicado en el resultado.

3. En la lista de cuentas de servicio, busca la cuenta de servicio que se muestra en el resultado y haz clic en Borrar. Antes de continuar, ten en cuenta el impacto de borrar una cuenta de servicio en tus recursos de producción.

4. Crea una clave de cuenta de servicio nueva para reemplazar la antigua. Para obtener más información, consulta Crea claves de cuentas de servicio.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Service account role separation

Nombre de categoría en la API: SERVICE_ACCOUNT_ROLE_SEPARATION

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

Una o más principales de tu organización tienen varios permisos asignados sobres las cuentas de servicio. Ninguna cuenta debe tener administrador de cuentas de servicio junto con otros permisos de cuentas de servicio simultáneamente. Para obtener más información sobre las cuentas de servicio y las funciones disponibles para ellas, consulta Cuentas de servicio.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

1. Ve a la página de IAM en la consola de Google Cloud.

   Ir a IAM

2. Para cada principal de la lista que aparece en el resultado, haz lo siguiente:

   1. Para verificar si la función se heredó de una carpeta o recurso de organización, consulta la columna Herencia. Si la columna contiene un vínculo a un recurso superior, haz clic en el vínculo para ir a la página de IAM del recurso superior.
   2. Haz clic en Editar junto a una persona principal.
   3. Para quitar permisos, haz clic en Borrar junto a Administrador de cuenta de servicio. Si deseas quitar todos los permisos de la cuenta de servicio, haz clic en Borrar junto a todos los demás permisos.

3. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Shielded VM disabled

Nombre de categoría en la API: SHIELDED_VM_DISABLED

La VM protegida está inhabilitada en esta instancia de Compute Engine.

Las VM protegidas son máquinas virtuales (VM) en Google Cloud endurecidas gracias a un conjunto de controles de seguridad destinados a protegerlas de los rootkits y bootkits. Las VM protegidas ayudan a garantizar que el cargador y el firmware de inicio estén firmados y verificados. Más información sobre las VM protegidas

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de VM

2. Selecciona la instancia relacionada con el resultado de Security Health Analytics.

3. En la página Detalles de la instancia que se carga, haz clic en Detener.

4. Una vez que la instancia se detenga, haz clic en Editar.

5. En la sección VM protegida, presiona los botones Activar vTPM y Activar la supervisión de integridad para habilitar una VM protegida.

6. De manera opcional, si no usas ningún controlador personalizado o sin firmar, también habilita el Inicio seguro.

7. Haz clic en Guardar. La configuración nueva aparecerá en la página Detalles de la instancia.

8. Haz clic en Iniciar para iniciar la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL CMEK disabled

Nombre de categoría en la API: SQL_CMEK_DISABLED

Una instancia de base de datos SQL no usa claves de encriptación administradas por el cliente (CMEK).

Con CMEK, las claves que creas y administras en Cloud KMS envuelven las claves que usa Google para encriptar tus datos, lo que te brinda más control sobre el acceso a tus datos. Si deseas obtener más información, consulta la descripción general de CMEK para tu producto: Cloud SQL para MySQL, Cloud SQL para PostgreSQL o Cloud SQL para SQL Server. Las CMEK generan costos adicionales relacionados con Cloud KMS.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en Borrar.

4. A fin de crear una instancia nueva con las CMEK habilitadas, sigue las instrucciones para configurar CMEK en tu producto:

   1. Cloud SQL para MySQL
   2. Cloud SQL para PostgreSQL
   3. Cloud SQL para SQL Server

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL contained database authentication

Nombre de 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 configurada en Desactivado.

La marca de autenticación de base de datos contenida controla si puedes crear o adjuntar bases de datos contenidas en el Motor de base de datos. Una base de datos contenida incluye todas las opciones de configuración y los metadatos necesarios para definir la base de datos y no tiene dependencias de configuración en la instancia del Motor de base de datos donde se instala la base de datos.

No se recomienda habilitar esta marca debido a las siguientes razones:

• Los usuarios se pueden conectar a la base de datos sin autenticación a nivel de motor de base de datos.
• Aislar la base de datos del Motor de base de datos permite trasladarla a otra instancia de SQL Server.

Las bases de datos contenidas enfrentan amenazas únicas que los administradores del Motor de base de datos de SQL Server deben entender y mitigar. La mayoría de las amenazas son producto del proceso de autenticación USUARIO CON CONTRASEÑA, que traslada el límite de autenticación desde el nivel del Motor de base de datos al nivel de la base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, configura la marca de base de datos autenticación de base de datos contenida con el valor Desactivado.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL cross DB ownership chaining

Nombre de 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 encadenamiento de propiedad de la base de datos cruzada configurada como Desactivada.

La marca cadena de propiedad de bases de datos cruzadas te permite controlar la cadena de propiedad de bases de datos cruzadas a nivel de la base de datos o permitir la cadena de propiedad de bases de datos cruzadas para todas las declaraciones 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 la cadena de propiedad de bases de datos cruzadas y estés al tanto de las implicaciones de seguridad de esta configuración.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, configura la marca de bases de datos cadenas de propiedad de bases de datos cruzadas con el valor Desactivado.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL external scripts enabled

Nombre de 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 secuencias de comandos externas habilitadas configurada como Desactivada.

Cuando se activa, esta configuración permite la ejecución de secuencias de comandos con ciertas extensiones de lenguaje remotas. Dado que esta función puede afectar de forma negativa la seguridad del sistema, te recomendamos inhabilitarla.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de base de datos, configura la marca de base de datos secuencias de comandos externas habilitadas con el valor Desactivadas.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL instance not monitored

Nombre de categoría en la API: SQL_INSTANCE_NOT_MONITORED

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

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

La mala configuración de las opciones de instancias de SQL puede causar riesgos de seguridad. Si inhabilitas las opciones de copia de seguridad automática y la alta disponibilidad, se podría afectar la continuidad del negocio, y si no restringes las redes autorizadas, se podría aumentar la exposición a redes que no son de confianza. La supervisión de los cambios en la configuración de la instancia de SQL te permite reducir el tiempo que lleva detectar y corregir alguna configuración incorrecta.

Para obtener más información, consulta Descripción general de las métricas basadas en registros.

Según la cantidad de información, los costos de Cloud Monitoring pueden ser significativos. Para obtener información sobre el uso del servicio y sus costos, consulta Precios de Google Cloud Observability.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

Crear métrica

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

   Ir a Métricas basadas en registros

2. Haga clic en Crear métrica.

3. En Tipo de métrica, selecciona Contador.

4. En Detalles, haz lo siguiente:

   1. Establece un nombre de métrica de registro.
   2. Agrega una descripción.
   3. Establece las Unidades en 1.

5. En Selección de filtro, copia y pega el siguiente texto en el cuadro Crear filtro y reemplaza el texto existente, si es necesario:

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

6. Haga clic en Crear métrica. Verás un mensaje de confirmación.

Crear una política de alertas

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

   Ir a Métricas basadas en registros

   Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Logging.

2. En la sección Métricas definidas por el usuario, selecciona la métrica que creaste en la sección anterior.

3. Haz clic en Más y, luego, en Crear alerta a partir de métricas.

   Se abre el cuadro de diálogo Condición nueva con las opciones de transformación de métricas y datos ya propagadas.

4. Haga clic en Next.
   1. Revisa la configuración ya propagada. Te recomendamos modificar el Valor del umbral.
   2. Haz clic en Nombre de la condición y, luego, ingresa un nombre para la condición.
5. Haz clic en Siguiente.

6. Para agregar notificaciones a tu política de alertas, haz clic en Canales de notificaciones. En el diálogo, selecciona uno o más canales de notificaciones del menú y, luego, haz clic en Aceptar.

   Si quieres recibir notificaciones cuando se abran y se cierren incidentes, marca Notificar el cierre de incidentes. De forma predeterminada, se envían notificaciones solo cuando los incidentes se abren.

7. Opcional: Actualiza la Duración del cierre automático de incidentes. Este campo determina cuándo Monitoring cierra los incidentes ante la ausencia de datos de métricas.
8. Opcional: Haz clic en Documentación y, luego, agrega la información que deseas incluir en un mensaje de notificación.
9. Haz clic en Nombre de la alerta y, luego, ingresa un nombre para la política de alertas.
10. Haz clic en Crear política.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL local infile

Nombre de 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 configurada como Desactivada. Debido a problemas de seguridad asociados con la marca local_infile, debe estar inhabilitada. Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de base de datos, configura la marca de base de datos local_infile con el valor Desactivada.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log checkpoints disabled

Nombre de 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 registro de base de datos log_checkpoint configurada en Activado.

Si habilitas log_checkpoints, se registran los puntos de control y los puntos de reinicio en el registro del servidor. Algunas estadísticas se incluyen en los mensajes de registro, incluida la cantidad de búferes escritos y el tiempo dedicado a escribirlos.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, configura la marca de base de datos log_checkpoints con el valor Activado.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log connections disabled

Nombre de 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 configurada en Activado.

Habilitar la configuración log_connections hace que se registren los intentos de conexión al servidor, junto con la finalización exitosa de la autenticación del cliente. Los registros pueden ser útiles para solucionar problemas y confirmar intentos de conexión inusuales al servidor.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, configura la marca de base de datos log_connections con el valor Activado.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log disconnections disabled

Nombre de categoría en la API: SQL_LOG_DISCONNECTIONS_DISABLED

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

Si habilitas la configuración log_disconnections, se crean entradas de registro al final de cada sesión. Los registros son útiles para solucionar problemas y confirmar actividad inusual durante un período determinado. Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, configura la marca de base de datos log_disconnections con el valor Activado.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log duration disabled

Nombre de 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 configurada como Activada.

Cuando log_duration está habilitada, esta configuración hace que se registre el tiempo de ejecución y la duración de cada declaración completada. Supervisar la cantidad de tiempo que lleva ejecutar consultas puede ser fundamental para identificar consultas lentas y solucionar problemas de la base de datos.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de base de datos, configura la marca de base de datos log_duration como Activada.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log error verbosity

Nombre de 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 configurada como predeterminada o verbosa.

La marca log_error_verbosity controla la cantidad de detalles en los mensajes registrados. Mientras mayor sea la verbosidad, más detalles se registrarán en los mensajes. Te recomendamos configurar esta marca como default o verbose.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, establece la marca de base de datos log_error_verbosity como predeterminada o detallada.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log lock waits disabled

Nombre de 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 log_lock_waits configurada en Activado.

Si habilitas la configuración log_lock_waits, se crean entradas de registro cuando los tiempos de espera de sesión son más largos que el tiempo de deadlock_timeout para adquirir un bloqueo. Los registros son útiles para determinar si las esperas de bloqueo provocan un rendimiento deficiente.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, configura la marca de base de datos log_lock_waits con el valor Activado.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log min duration statement enabled

Nombre de 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 configurada en -1.

La marca log_min_duration_statement hace que se registren las instrucciones de SQL que se ejecutan más tiempo que un registro especificado. Considera inhabilitar esta configuración porque las instrucciones de SQL pueden contener información sensible que no se debe registrar. Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de base de datos, configura la marca de base de datos log_min_duration_statement con el valor −1.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log min error statement

Nombre de 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 establecida de forma correcta.

La marca log_min_error_statement controla si las instrucciones de SQL que causan condiciones de error se registran en los registros del servidor. Las instrucciones de SQL de la gravedad especificada o de una gravedad más alta se registran con mensajes para las instrucciones de error. Mientras mayor sea la gravedad, menos mensajes se registrarán.

Si log_min_error_statement no se configura en el valor deseado, es posible que los mensajes no se clasifiquen como mensajes de error. Una gravedad establecida demasiado baja aumenta la cantidad de mensajes y es más difícil encontrar errores reales. Si un conjunto de gravedad es demasiado alto, es posible que no se registren mensajes de error para errores reales.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de base de datos, configura la marca de base de datos log_min_error_statement como uno de los siguientes valores recomendados, según la política de registro de tu organización.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning
   • error

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log min error statement severity

Nombre de 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 establecida de forma correcta.

La marca log_min_error_statement controla si las instrucciones de SQL que causan condiciones de error se registran en los registros del servidor. Las instrucciones de SQL de la gravedad especificada o de una gravedad más estricta se registran con mensajes para las instrucciones de error. Mientras más estricta sea la gravedad, menos mensajes se registrarán.

Si log_min_error_statement no se configura en el valor deseado, es posible que los mensajes no se clasifiquen como mensajes de error. Si un conjunto de gravedad es demasiado bajo, aumenta la cantidad de mensajes y es más difícil encontrar errores reales. Un nivel de gravedad demasiado alto (demasiado estricto) puede causar que los mensajes de error de los errores reales no se registren.

Te recomendamos configurar esta marca como error o más estricta.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de base de datos, configura la marca de base de datos log_min_error_statement como uno de los siguientes valores recomendados, según la política de registro de tu organización.

   • error
   • log
   • fatal
   • panic

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log min messages

Nombre de 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 configurada como advertencia como mínimo.

La marca log_min_messages controla qué niveles de mensajes se registran en los registros del servidor. Mientras mayor sea la gravedad, menos mensajes se registrarán. Establecer un umbral demasiado bajo puede aumentar el tamaño y la longitud del almacenamiento de registros, lo que dificulta la detección de errores reales.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de base de datos, configura la marca de base de datos log_min_messages con uno de los siguientes valores recomendados, según la política de registro de tu organización.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log executor stats enabled

Nombre de 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 configurada como Desactivada.

Cuando se activa la marca log_executor_stats, se incluyen estadísticas de rendimiento del ejecutor en los registros de PostgreSQL para cada consulta. Este parámetro de configuración puede ser útil para solucionar problemas, pero es posible que aumente de forma significativa la cantidad de registros y la sobrecarga de rendimiento.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, configura la marca de base de datos log_executor_stats como Desactivada.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log hostname enabled

Nombre de 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 configurada como Desactivada.

Cuando se activa la marca log_hostname, se registra el nombre del host que se conecta. De forma predeterminada, los mensajes de registro de conexión solo muestran la dirección IP. Este parámetro de configuración puede ser útil para solucionar problemas. Sin embargo, puede generar una sobrecarga en el rendimiento del servidor debido a que se requiere la resolución de DNS para convertir una dirección IP en un nombre de host en cada declaración que se registra.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, configura la marca de base de datos log_hostname como Desactivada.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log parser stats enabled

Nombre de 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 configurada como Desactivada.

Cuando se activa la marca log_parser_stats, se incluyen estadísticas de rendimiento del analizador en los registros de PostgreSQL para cada consulta. Este parámetro de configuración puede ser útil para solucionar problemas, pero es posible que aumente de forma significativa la cantidad de registros y la sobrecarga de rendimiento.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, configura la marca de base de datos log_parser_stats como Desactivada.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log planner stats enabled

Nombre de 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 configurada como Desactivada.

Cuando se activa la marca log_planner_stats, se usa un método sin procesar de creación de perfiles para registrar las estadísticas de rendimiento del planificador de PostgreSQL. Este parámetro de configuración puede ser útil para solucionar problemas, pero es posible que aumente de forma significativa la cantidad de registros y la sobrecarga de rendimiento.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, configura la marca de base de datos log_planner_stats como Desactivada.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log statement

Nombre de 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 configurada como ddl.

El valor de esta marca controla qué instrucciones de SQL se registran. Logging ayuda a solucionar problemas operativos y permite el análisis forense. Si esta marca no se configura en el valor correcto, es posible que se omita información relevante o que esta se oculte en demasiados mensajes. Se recomienda un valor de ddl (todas las declaraciones de definición de datos), a menos que la política de registro de tu organización indique lo contrario.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, configura la marca de base de datos log_statement como ddl.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log statement stats enabled

Nombre de 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 log_statement_stats configurada como Desactivada.

Cuando se activa la marca log_statement_stats, se incluyen estadísticas de rendimiento de extremo a extremo en los registros de PostgreSQL para cada consulta. Este parámetro de configuración puede ser útil para solucionar problemas, pero es posible que aumente de forma significativa la cantidad de registros y la sobrecarga de rendimiento.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, configura la marca de base de datos log_statement_stats como Desactivada.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL log temp files

Nombre de 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 configurada en 0.

Se pueden crear archivos temporales para los órdenes, los hashes y los resultados de consultas temporales. Si configuras la marca log_temp_files en 0, se registrará toda la información de los archivos temporales. El registro de todos los archivos temporales es útil para identificar posibles problemas de rendimiento. Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de la base de datos, configura la marca log_temp_files con el valor 0.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL no root password

Nombre de categoría en la API: SQL_NO_ROOT_PASSWORD

Una instancia de base de datos de MySQL no tiene una contraseña establecida para la cuenta raíz. Debes agregar una contraseña a la instancia de base de datos de MySQL. Para obtener más información, consulta Usuarios de MySQL.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. En la página Detalles de la instancia que se carga, selecciona la pestaña Usuarios.

4. Junto al usuario root, haz clic en Más y, luego, selecciona Cambiar contraseña.

5. Ingresa una contraseña segura y nueva y, a continuación, haz clic en Aceptar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL public IP

Nombre de 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 proporcionan una seguridad de red mejorada y una menor latencia para tu aplicación.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. En el menú de la izquierda, haz clic en Conexiones.

4. Haz clic en la pestaña Redes y desmarca la casilla de verificación IP pública.

5. Si la instancia aún no está configurada para usar una IP privada, consulta Configura la IP privada en una instancia existente.

6. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL remote access enabled

Nombre de 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 de acceso remoto configurada como Desactivado.

Cuando se activa, esta configuración otorga permiso para ejecutar procedimientos almacenados de forma local desde servidores remotos o procedimientos almacenados de forma remota desde el servidor local. Esta funcionalidad puede usarse de forma inadecuada para lanzar un ataque de denegación del servicio (DoS) en servidores remotos mediante la descarga del procesamiento de consultas a un destino. Para evitar usos inadecuados, te recomendamos inhabilitar esta configuración.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas, configura el acceso remoto como Desactivado.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL skip show database disabled

Nombre de 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 configurada como Activada.

Cuando se activa, esta marca evita que los usuarios usen la declaración SHOW DATABASES si no tienen el privilegio SHOW DATABASES. Con este parámetro de configuración, los usuarios que no tengan un permiso explícito no podrán ver las bases de datos que pertenecen a otros usuarios. Te recomendamos que habilites esta marca.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas, configura skip_show_database como Activada.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL trace flag 3625

Nombre de 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 (marca de seguimiento) configurada como Activada.

Esta marca limita la cantidad de información que se muestra a los usuarios que no son miembros del rol de servidor fijo sysadmin, mediante el enmascaramiento de los parámetros de algunos mensajes de error con asteriscos (******). Para evitar la divulgación de información sensible, te recomendamos habilitar esta marca.

Nota: Algunas versiones de la comparativa de CIS aconsejan, de manera incorrecta, establecer la marca 3625 (marca de seguimiento) en Desactivado. La configuración más segura es Activada. Para obtener más información, consulta la propuesta de cambio de CIS.Asegúrate de que la marca de la base de datos “3625 (marca de seguimiento)” para todas las instancias de Cloud SQL Server esté configurada como “activada” (se requiere registro).

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de base de datos, configura 3625 como Activada.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL user connections configured

Nombre de 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 conexiones de usuario.

La opción conexiones de usuario especifica la cantidad máxima de conexiones de usuario simultáneas permitidas en una instancia de SQL Server. Dado que es una opción dinámica (autoconfiguración), SQL Server ajusta la cantidad máxima de conexiones de usuarios de forma automática 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 este motivo, no recomendamos configurar la marca de base de datos conexiones de usuario.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de base de datos, junto a conexiones de usuario, haz clic en Borrar.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL user options configured

Nombre de 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 opciones de usuario.

Este parámetro de configuración anula los valores predeterminados globales de las opciones SET de todos los usuarios. Dado que los usuarios y las aplicaciones pueden suponer que las opciones predeterminadas SET de la base de datos están en uso, configurar las opciones de usuario puede generar resultados inesperados. Por este motivo, no recomendamos configurar la marca de base de datos opciones de usuario.

Para obtener más información, consulta Configura marcas de base de datos.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. Haz clic en  Editar.

4. En la sección Marcas de bases de datos, junto a opciones de usuario, haz clic en Borrar.

5. Haz clic en Guardar. La configuración nueva aparecerá en la página Descripción general de la instancia.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SQL weak root password

Nombre de categoría en la API: SQL_WEAK_ROOT_PASSWORD

Una instancia de base de datos de MySQL tiene una contraseña poco segura establecida para la cuenta raíz. Debes establecer una contraseña segura para la instancia. Para obtener más información, consulta Usuarios de MySQL.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. En la página Detalles de la instancia que se carga, selecciona la pestaña Usuarios.

4. Junto al usuario root, haz clic en Más y, luego, selecciona Cambiar contraseña.

5. Ingresa una contraseña segura y nueva y, a continuación, haz clic en Aceptar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

SSL not enforced

Nombre de categoría en la API: SSL_NOT_ENFORCED

Una instancia de base de datos de Cloud SQL no requiere que todas las conexiones entrantes usen SSL.

Para evitar que se filtren datos sensibles en tránsito a través de comunicaciones no encriptadas, todas las conexiones entrantes a tu instancia de base de datos SQL deben usar SSL. Obtén más información sobre la configuración de certificados SSL/TLS.

A fin de solucionar este problema, solo permite conexiones SSL para las instancias de SQL:

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

   Ir a Instancias de Cloud SQL

2. Selecciona la instancia que aparece en el resultado de las estadísticas de estado de seguridad.

3. En la pestaña Conexiones, haz clic en Solo permitir conexiones SSL o Exigir certificados de cliente de confianza. Para obtener más información, consulta Aplica la encriptación SSL/TLS.

4. Si elegiste Exigir certificados de cliente de confianza, crea un certificado de cliente nuevo. Para obtener más información, consulta Cómo crear un nuevo certificado de cliente.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Too many KMS users

Nombre de categoría en la API: TOO_MANY_KMS_USERS

Limita a tres la cantidad de usuarios principales que pueden usar claves criptográficas. Las siguientes funciones predefinidas 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 el artículo sobre permisos y funciones.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Claves de Cloud KMS

2. Haz clic en el nombre del llavero de claves que se indica en el resultado.

3. Haz clic en el nombre de la clave indicada en el resultado.

4. Selecciona el cuadro junto a la versión principal y, luego, haz clic en Mostrar panel de información.

5. Reduce a tres o menos la cantidad de principales que tienen permisos para encriptar, desencriptar o firmar datos. Para revocar permisos, haz clic en Borrar junto a cada principal.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Unconfirmed AppArmor profile

Nombre de categoría en la API: GKE_APP_ARMOR

AppArmor puede configurar explícitamente un contenedor para que sea unconfined. Esto garantiza que no se aplique ningún perfil de AppArmor al contenedor y, por lo tanto, no esté restringido por un perfil. Inhabilitar el control de seguridad preventivo aumenta el riesgo de escape del contenedor.

Para solucionar este problema, aplica los siguientes pasos a las cargas de trabajo afectadas:

1. Abre el manifiesto de cada carga de trabajo afectada.
2. Establece los siguientes campos restringidos con 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 categoría en la API: USER_MANAGED_SERVICE_ACCOUNT_KEY

Un usuario administra una clave de cuenta de servicio. Las claves de cuenta de servicio son un riesgo de seguridad si no se administran de forma adecuada. Debes elegir una alternativa más segura a las claves de la cuenta de servicio siempre que sea posible. Si te debes autenticar con una clave de cuenta de servicio, eres responsable de la seguridad de la clave privada y de otras operaciones que se describen en Prácticas recomendadas para administrar claves de cuenta de servicio. Si no se te permite crear una clave de cuenta de servicio, es posible que la creación de claves de cuentas de servicio esté inhabilitada para tu organización. Para obtener más información, consulta Administra los recursos de la organización con seguridad de forma predeterminada.

Precaución: Estos pasos de solución pueden interrumpir tu entorno de producción. Si es necesario, cambia las cargas de trabajo, los datos o los permisos a recursos nuevos antes de borrar los existentes.

Para solucionar este resultado, completa los siguientes pasos:

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

   Ir a Cuentas de servicio

2. Si es necesario, selecciona el proyecto indicado en el resultado.

3. Borra las claves de cuentas de servicio administradas por el usuario indicadas en los resultados si ninguna aplicación las usa.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Weak SSL policy

Nombre de 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 Cloud con una versión de TLS inferior a 1.2.

Los balanceadores de cargas de proxy SSL y HTTPS usan políticas SSL para determinar los protocolos y el conjunto de algoritmo de cifrado que se usan en las conexiones TLS que se establecieron entre Internet y los usuarios. Estas conexiones encriptan datos sensibles para evitar que los espías maliciosos accedan a ellos. Una política de SSL débil permite que los clientes que usan versiones desactualizadas de TLS se conecten con un protocolo o un conjunto de algoritmo de cifrado menos seguro. Para obtener una lista de los conjuntos de algoritmo de cifrado recomendados y obsoletos, visita la página de parámetros de TLS de iana.org.

Nota: La actualización de una política de SSL puede reducir la compatibilidad para usuarios con versiones desactualizadas de TLS.

En el caso de las activaciones a nivel del proyecto del nivel Premium de Security Command Center, este hallazgo solo está disponible si el nivel Estándar está habilitado en la organización superior.

Los pasos de solución para este hallazgo varían según si se activó por el uso de una política de SSL predeterminada de Google Cloud o una política de SSL que permite un conjunto de algoritmos de cifrado débil o una versión TLS mínima inferior a 1.2. Sigue el procedimiento que se indica a continuación y que corresponde al activador del hallazgo.

Solución predeterminada de la política de SSL de Google Cloud

1. Ve a la página Grupos de destino en la consola de Google Cloud.

   Ir a Proxies de destino

2. Busca el proxy de destino indicado en las reglas de reenvío de notas y resultados en la columna En uso por.

3. Si quieres crear una política de SSL nueva, consulta Usa 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.

4. Para usar un perfil personalizado, asegúrate de que los siguientes conjuntos de algoritmos 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

5. Aplica la política de SSL a cada regla de reenvío que anotaste antes.

Se permitió la solución para el conjunto de algoritmos de cifrado débil o la versión de TLS de nivel inferior

1. En la consola de Google Cloud, ve a la página Políticas de SSL .

   Ir a Políticas de SSL

2. Busca el balanceador de cargas indicado en la columna En uso por.

3. Haz clic debajo del nombre de la política.

4. Haz clic en  Editar.

5. Cambia la Versión mínima de TLS a TLS 1.2 y el Perfil a Moderno o Restringido.

6. Para usar un perfil personalizado, asegúrate de que los siguientes conjuntos de algoritmos 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

7. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Web UI enabled

Nombre de categoría en la API: WEB_UI_ENABLED

La IU web de GKE (panel) está habilitada.

Una cuenta de servicio de Kubernetes con una gran cantidad de privilegios respalda la interfaz web de Kubernetes. Se puede abusar de la cuenta de servicio si se vulnera. Si ya usas la consola de Google Cloud, la interfaz web de Kubernetes extiende la superficie de ataque de forma innecesaria. Aprende a inhabilitar la interfaz web de Kubernetes.

Para solucionar este resultado, inhabilita la interfaz web de Kubernetes de la siguiente manera:

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

   Ir a Clústeres de Kubernetes

2. Haz clic en el nombre del clúster que aparece en el resultado de Security Health Analytics.

3. Haz clic en  Editar.

   Si la configuración del clúster cambió recientemente, el botón de edición puede estar inhabilitado. Si no puedes editar la configuración del clúster, espera unos minutos y vuelve a intentarlo.

4. Haz clic en Complementos. La sección se expande para mostrar los complementos disponibles.

5. En la lista desplegable del panel de Kubernetes, selecciona Inhabilitado.

6. Haz clic en Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Workload Identity disabled

Nombre de categoría en la API: WORKLOAD_IDENTITY_DISABLED

Workload Identity está inhabilitada en un clúster de GKE.

Workload Identity es la manera recomendada de acceder a los servicios de Google Cloud desde GKE, ya que ofrece propiedades de seguridad y capacidad de administración superiores. Si habilitas esta función, algunos metadatos potencialmente sensibles del sistema estarán protegidos de las cargas de trabajo del usuario que se ejecutan en tu clúster. Obtén más información sobre el ocultamiento de metadatos.

Para solucionar este problema, sigue la guía sobre cómo habilitar Workload Identity en un clúster.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Soluciona los errores de configuración de AWS

Solo para el nivel empresarial: Esta función solo está disponible con el nivel empresarial de Security Command Center.

AWS Cloud Shell Full Access Restricted

Nombre de categoría en la API: ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED

AWS CloudShell es una forma conveniente de ejecutar comandos de CLI en los servicios de AWS. Una política de IAM administrada ("AWSCloudShellFullAccess") proporciona acceso completo a CloudShell, lo que permite subir y descargar archivos entre el sistema local de un usuario y el entorno de CloudShell. Dentro del entorno de CloudShell, un usuario tiene permisos de sudo y puede acceder a Internet. Por lo tanto, es posible instalar software de transferencia de archivos (por ejemplo) y mover datos de CloudShell a servidores de Internet externos.

Recomendación: Asegúrate de que el acceso a AWSCloudShellFullAccess esté restringido

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Abre la consola de IAM en https://console.aws.amazon.com/iam/.
2. En el panel izquierdo, selecciona Políticas.
3. Busca y selecciona AWSCloudShellFullAccess
4. En la pestaña Entidades adjuntas, marca la casilla de cada elemento y selecciona Desvincular.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Access Keys Rotated Every 90 Days or Less

Nombre de categoría en la API: ACCESS_KEYS_ROTATED_90_DAYS_LESS

Las claves de acceso consisten en un ID de clave de acceso y una clave de acceso secreta, que se usan para firmar las solicitudes programáticas que realizas a AWS. Los usuarios de AWS necesitan sus propias claves de acceso para realizar llamadas programáticas a AWS desde la interfaz de línea de comandos de AWS (AWS CLI), las herramientas para Windows PowerShell, los SDK de AWS o llamadas HTTP directas con las APIs de servicios individuales de AWS. Se recomienda que todas las claves de acceso se roten con regularidad.

Recomendación: Asegúrate de que las claves de acceso se roten cada 90 días o menos

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Ve a la consola de administración (https://console.aws.amazon.com/iam).
2. Haz clic en Users.
3. Haz clic en Security Credentials.
4. Como administrador
   - Haz clic en Make Inactive para ver las claves que no se han rotado en 90 días.
5. Como usuario de IAM
   - Haz clic en Make Inactive o Delete para ver las claves que no se han rotado ni usado en 90 días.
6. Haz clic en Create Access Key.
7. Actualiza la llamada programática con nuevas credenciales de clave de acceso

CLI de AWS

1. 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 llaves de acceso activas.

2. Actualiza todas las aplicaciones y herramientas para que usen la nueva clave de acceso.
3. Usa este comando para determinar si la primera clave de acceso sigue en uso:

aws iam get-access-key-last-used

4. Un enfoque es esperar varios días y, luego, verificar si se usó la clave de acceso anterior antes de continuar.

Incluso si el paso 3 indica que no se usa la clave anterior, te recomendamos que no borres de inmediato la primera clave de acceso. En su lugar, cambia el estado de la primera clave de acceso a Inactivo con este comando:

aws iam update-access-key

5. Usa solo la nueva clave de acceso para confirmar que tus aplicaciones funcionen. En este punto, todas las aplicaciones y herramientas que aún usen la clave de acceso original dejarán de funcionar porque ya no tendrán acceso a los recursos de AWS. Si encuentras una aplicación o herramienta de este tipo, puedes volver a cambiar su estado a Activo para volver a habilitar la primera clave de acceso. Luego, vuelve al paso 2 y actualiza esta aplicación para que use la clave nueva.

6. Después de esperar un período para asegurarte de que se hayan actualizado todas las aplicaciones y herramientas, puedes borrar la primera clave de acceso con este comando:

aws iam delete-access-key

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

All Expired Ssl Tls Certificates Stored Aws Iam Removed

Nombre de 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 administrador de certificados solo cuando debas admitir conexiones HTTPS en una región que ACM no admite. La IAM encripta de forma segura tus claves privadas y almacena la versión encriptada en el almacenamiento de certificados SSL de la IAM. IAM admite la implementación de certificados de servidor en todas las regiones, pero debes obtener tu certificado de un proveedor externo para usarlo con AWS. No puedes subir un certificado de ACM a IAM. Además, no puedes administrar tus certificados desde la Consola de IAM.

Recomendación: Asegúrate de quitar todos los certificados SSL o TLS vencidos que estén almacenados en IAM de AWS

Para solucionar este problema, completa los siguientes pasos:

AWS console

Por el momento, no se admite la eliminación de certificados vencidos a través de la consola de administración de AWS. Para borrar 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 borrar un certificado vencido, ejecuta el siguiente comando y reemplaza CERTIFICATE_NAME por el nombre del certificado que deseas borrar:

aws iam delete-server-certificate --server-certificate-name <CERTIFICATE_NAME>

Cuando el comando anterior se ejecuta correctamente, no muestra ningún resultado.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Autoscaling Group Elb Healthcheck Required

Nombre de categoría en la API: AUTOSCALING_GROUP_ELB_HEALTHCHECK_REQUIRED

Esta opción verifica si tus grupos de ajuste de escala automático asociados con un balanceador de cargas usan las verificaciones de estado del balanceo de cargas elásticas.

Esto garantiza que el grupo pueda determinar el estado de una instancia en función de las pruebas adicionales que proporciona el balanceador de cargas. El uso de verificaciones de estado de Elastic Load Balancing puede ayudar a admitir la disponibilidad de las aplicaciones que usan grupos de ajuste de escala automático de EC2.

Recomendación: Verifica que todos los grupos de ajuste de escala automático asociados con un balanceador de cargas utilicen verificaciones de estado

Para solucionar este problema, completa los siguientes pasos:

AWS console

Cómo habilitar las verificaciones de estado de Elastic Load Balancing

1. Abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
2. En el panel de navegación, en Ajuste de escala automático, elige Grupos de ajuste de escala automático.
3. Selecciona la casilla de verificación de tu grupo.
4. Selecciona Editar.
5. En Verificaciones de estado, en Tipo de verificación de estado, elige ELB.
6. Para el período de gracia de la verificación de estado, ingresa 300.
7. En la parte inferior de la página, elige Actualizar.

Para obtener más información sobre el uso de un balanceador de cargas con un grupo de escalamiento automático, consulta la Guía del usuario de AWS Auto Scaling.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Auto Minor Version Upgrade Feature Enabled Rds Instances

Nombre de categoría en la API: AUTO_MINOR_VERSION_UPGRADE_FEATURE_ENABLED_RDS_INSTANCES

Asegúrate de que las instancias de la base de datos de RDS tengan habilitada la marca de actualización automática de versión secundaria para recibir automáticamente actualizaciones menores del motor durante el período de mantenimiento especificado. Por lo tanto, las instancias de RDS pueden obtener las funciones, las correcciones de errores y los parches de seguridad nuevos para sus motores de base de datos.

Recomendación: Asegúrate de que la función de actualización automática de versiones secundarias esté habilitada para las instancias de RDS

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de administración de AWS y navega al panel de RDS en https://console.aws.amazon.com/rds/.
2. En el panel de navegación de la izquierda, haz clic en Databases.
3. Selecciona la instancia de RDS que quieres actualizar.
4. Haz clic en el botón Modify que se encuentra en la parte superior derecha.
5. En la página Modify DB Instance: <instance identifier>, en la sección Maintenance, selecciona Auto minor version upgrade haz clic en el botón de selección Yes.
6. En la parte inferior de la página, haz clic en Continue, marca Aplicar inmediatamente para aplicar los cambios de inmediato o selecciona Apply during the next scheduled maintenance window para evitar cualquier tiempo de inactividad.
7. Revisa los cambios y haz clic en Modify DB Instance. El estado de la instancia debería cambiar de disponible a en modificación y, luego, a disponible. Una vez que se habilite la función, el estado Auto Minor Version Upgrade debería cambiar a Yes.

CLI de AWS

1. Ejecuta el comando describe-db-instances para obtener una lista de todos los nombres de instancias de la base de datos de RDS disponibles en la región de AWS seleccionada:

aws rds describe-db-instances --region <regionName> --query 'DBInstances[*].DBInstanceIdentifier'

2. El resultado del comando debe mostrar cada identificador de instancia de la base de datos.
3. Ejecuta el comando modify-db-instance para modificar la configuración de la instancia de RDS seleccionada. Este comando aplicará los cambios de inmediato. Quita --apply-immediately para aplicar los cambios durante el próximo período de mantenimiento programado y evitar cualquier tiempo de inactividad:

aws rds modify-db-instance --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --auto-minor-version-upgrade --apply-immediately

4. El resultado del comando debería revelar los nuevos metadatos de configuración de la instancia de RDS y verificar el valor del parámetro AutoMinorVersionUpgrade.
5. Ejecuta el comando describe-db-instances para verificar si la función de actualización de versión secundaria automática se habilitó correctamente:

aws rds describe-db-instances --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --query 'DBInstances[*].AutoMinorVersionUpgrade'

6. El resultado del comando debe mostrar el estado actual de la función establecido en true, la función es enabled y las actualizaciones menores del motor se aplicarán a la instancia de RDS seleccionada.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Aws Config Enabled All Regions

Nombre de categoría en la API: AWS_CONFIG_ENABLED_ALL_REGIONS

AWS Config es un servicio web que realiza la administración de la configuración de los recursos de AWS admitidos en tu cuenta y te entrega archivos de registro. La información registrada incluye el elemento de configuración (recurso de AWS), las relaciones entre los elementos de configuración (recursos de AWS) y cualquier cambio de configuración entre los recursos. Se recomienda que AWS Config esté habilitado en todas las regiones.

Recomendación: Asegúrate de que AWS Config esté habilitado en todas las regiones

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Selecciona la región en la que deseas centrarte en la parte superior derecha de la consola.
2. Haz clic en Servicios.
3. Haz clic en Config
4. Si hay un registrador de configuración habilitado en esta región, debes navegar a la página Configuración desde el menú de navegación de la izquierda. Si aún no se habilitó un registrador de configuración en esta región, selecciona "Comenzar".
5. Selecciona "Registrar todos los recursos compatibles con esta región".
6. Elige incluir recursos globales (recursos de IAM)
7. Especifica un bucket de S3 en la misma cuenta o en otra cuenta de AWS administrada.
8. Crea un tema de SNS desde la misma cuenta de AWS o desde otra cuenta de AWS administrada

CLI de AWS

1. Asegúrate de que haya un bucket S3, un tema de SNS y un rol de IAM adecuados según los requisitos previos del servicio de AWS Config.
2. 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

3. Crea un archivo de configuración del canal de publicación de forma local que especifique los atributos del canal, propagados desde 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"
 }
}

4. Ejecuta este comando para crear un nuevo canal de publicación y hacer referencia al archivo de configuración JSON que creaste en el paso anterior:

aws configservice put-delivery-channel --delivery-channel file://deliveryChannel.json

5. Ejecuta el siguiente comando para iniciar el grabador de configuración:

aws configservice start-configuration-recorder --configuration-recorder-name default

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Aws Security Hub Enabled

Nombre de categoría en la API: AWS_SECURITY_HUB_ENABLED

Security Hub recopila datos de seguridad de todas las cuentas, los servicios y los productos de socios externos compatibles de AWS, y te ayuda a analizar tus tendencias de seguridad y a identificar los problemas de seguridad de mayor prioridad. Cuando habilitas Security Hub, este comienza a consumir, agregar, organizar y priorizar los resultados de los servicios de AWS que habilitaste, como Amazon GuardDuty, Amazon Inspector y Amazon Macie. También puedes habilitar integraciones con productos de seguridad de socios de AWS.

Recomendación: Asegúrate de que AWS Security Hub esté habilitado

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Usa las credenciales de la identidad de IAM para acceder a la consola de Security Hub.
2. Cuando abras la consola de Security Hub por primera vez, elige Habilita AWS Security Hub.
3. En la página de bienvenida, en Estándares de seguridad, se enumeran los estándares de seguridad que admite Security Hub.
4. Elige Habilita Security Hub.

CLI de AWS

1. Ejecuta el comando enable-security-hub. Para habilitar los estándares predeterminados, incluye --enable-default-standards.

aws securityhub enable-security-hub --enable-default-standards

2. 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

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Cloudtrail Logs Encrypted Rest Using Kms Cmks

Nombre de categoría en la API: CLOUDTRAIL_LOGS_ENCRYPTED_REST_USING_KMS_CMKS

AWS CloudTrail es un servicio web que registra las llamadas a la API de AWS de una cuenta y pone esos registros a disposición de los usuarios y recursos de acuerdo con las políticas de IAM. AWS Key Management Service (KMS) es un servicio administrado que ayuda a crear y controlar las claves de encriptación que se usan para encriptar los datos de la cuenta y usa módulos de seguridad de hardware (HSM) para proteger la seguridad de las claves de encriptación. Los registros de CloudTrail se pueden configurar para aprovechar la encriptación del servidor (SSE) y las claves maestras (CMK) creadas por el cliente de KMS para proteger aún más los registros de CloudTrail. Se recomienda que CloudTrail se configure para usar SSE-KMS.

Recomendación: Asegúrate de que los registros de CloudTrail estén encriptados en reposo con CMK de KMS

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de administración de AWS y abre la consola de CloudTrail en https://console.aws.amazon.com/cloudtrail.
2. En el panel de navegación izquierdo, elige Trails .
3. Haz clic en un sendero.
4. En la sección S3, haz clic en el botón de edición (ícono de lápiz).
5. Haz clic en Advanced.
6. Selecciona una CMK existente en el menú desplegable KMS key Id
   - Nota: Asegúrate de que la CMK se encuentre en la misma región que el bucket de S3
   - Nota: Deberás aplicar una política de claves de KMS en la CMK seleccionada para que CloudTrail como servicio encripte y desencripte los archivos de registro con la CMK proporcionada. Aquí se proporcionan los pasos para editar la política de claves de CMK seleccionada.
7. Haz clic en Save.
8. Verás un mensaje de notificación que indica que debes tener permisos de desencriptación en la clave de KMS especificada para desencriptar los archivos de registro.
9. 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>

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Cloudtrail Log File Validation Enabled

Nombre de categoría en la API: CLOUDTRAIL_LOG_FILE_VALIDATION_ENABLED

La validación del archivo 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 cambió, borró o no se modificó después de que CloudTrail lo entregó. Se recomienda habilitar la validación de archivos en todos los CloudTrail.

Recomendación: Asegúrate de que la validación del archivo de registro de CloudTrail esté habilitada

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/cloudtrail.
2. Haz clic en Trails en el panel de navegación izquierdo.
3. Haz clic en la ruta de destino.
4. En la sección General details, haz clic en edit.
5. En la sección Advanced settings
6. Marca la casilla de habilitación en Log file validation.
7. Haz clic en Save changes.

CLI de AWS

aws cloudtrail update-trail --name <trail_name> --enable-log-file-validation

Ten en cuenta que puedes ejecutar el siguiente comando para realizar la validación periódica de los registros con estos resúmenes:

aws cloudtrail validate-logs --trail-arn <trail_arn> --start-time <start_time> --end-time <end_time>

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Cloudtrail Trails Integrated Cloudwatch Logs

Nombre de categoría en la API: CLOUDTRAIL_TRAILS_INTEGRATED_CLOUDWATCH_LOGS

AWS CloudTrail es un servicio web que registra las llamadas a la API de AWS realizadas en una cuenta de AWS determinada. La información registrada incluye la identidad del llamador de la API, la hora de la llamada a la API, la dirección IP de origen del llamador de la API, los parámetros de solicitud y los elementos de respuesta que muestra el servicio de AWS. CloudTrail usa Amazon S3 para el almacenamiento y la entrega de archivos de registro, por lo que estos se almacenan de forma duradera. Además de capturar registros de CloudTrail en un bucket de S3 especificado para el análisis a largo plazo, se puede realizar un análisis en tiempo real configurando CloudTrail para que envíe registros a los registros de CloudWatch. En el caso de un seguimiento habilitado en todas las regiones de una cuenta, CloudTrail envía los archivos de registro de todas esas regiones a un grupo de registros de CloudWatch Logs. Se recomienda que los registros de CloudTrail se envíen a los registros de CloudWatch.

Nota: El objetivo de esta recomendación es garantizar que se capture, supervise y genere una alarma adecuada para la actividad de la cuenta de AWS. CloudWatch Logs es una forma nativa de lograr esto con los servicios de AWS, pero no excluye el uso de una solución alternativa.

Recomendación: Asegúrate de que los registros de CloudTrail estén integrados en los registros de CloudWatch

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de CloudTrail en https://console.aws.amazon.com/cloudtrail/.
2. Selecciona el Trail que se debe actualizar.
3. Desplázate hacia abajo hasta CloudWatch Logs.
4. Haz clic en Edit.
5. En CloudWatch Logs, haz clic en la casilla Enabled.
6. En Log Group, elige uno nuevo o selecciona un grupo de registros existente.
7. Edita el Log group name para que coincida con CloudTrail o elige el grupo de CloudWatch existente.
8. En IAM Role, elige una nueva o selecciona una existente.
9. Edita el Role name para que coincida con CloudTrail o elige el rol de IAM existente.
10. 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>

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Cloudwatch Alarm Action Check

Nombre de categoría en la API: CLOUDWATCH_ALARM_ACTION_CHECK

Esta función verifica si Amazon CloudWatch tiene acciones definidas cuando una alarma realiza la transición entre los estados "OK", "ALARM" e "INSUFFICIENT_DATA".

Es muy importante configurar acciones para el estado ALARM en las alarmas de Amazon CloudWatch para activar una respuesta inmediata cuando las métricas supervisadas superen los umbrales.
Garantiza una resolución rápida de problemas, reduce el tiempo de inactividad y permite la solución automática, lo que mantiene el estado del sistema y evita las interrupciones.

Las alarmas tienen al menos una acción.
Las alarmas tienen al menos una acción cuando la alarma pasa al estado "INSUFFICIENT_DATA" desde cualquier otro estado.
(Opcional) Las alarmas tienen al menos una acción cuando la alarma pasa a un estado "OK" desde cualquier otro estado.

Recomendación: Verifica si las alarmas de CloudWatch tienen al menos una acción de alarma, una acción INSUFFICIENT_DATA o una acción OK habilitadas.

Para solucionar este problema, completa los siguientes pasos:

AWS console

Para configurar acciones de ALARM para tus alarmas de Amazon CloudWatch, haz lo siguiente.

1. Abre la consola de Amazon CloudWatch en https://console.aws.amazon.com/cloudwatch/.
2. En el panel de navegación, en "Alarmas", selecciona "Todas las alarmas".
3. Elige la alarma de Amazon CloudWatch que deseas modificar, elige "Acciones" y selecciona "Editar".
4. A la izquierda, elige "Paso 2: Acciones opcionales de configuración".
5. En "Activador de estado de alarma", selecciona la opción "En alarma" para configurar una acción basada en ALARMA.
6. Para enviar una notificación a un tema de SNS recién creado, selecciona "Crear tema nuevo".
7. En el cuadro "Crear tema nuevo…", especifica un nombre de tema de SNS único.
8. En el cuadro "Los extremos de correo electrónico que recibirán la notificación…", especifica una o más direcciones de correo electrónico.
9. Luego, selecciona "Crear tema" para crear el tema de Amazon SNS requerido.
10. En la parte inferior derecha, selecciona "Siguiente", "Siguiente" y elige "Actualizar alarma" para aplicar los cambios.
11. Abre tu cliente de correo electrónico y, en el correo electrónico de AWS Notifications, haz clic en el vínculo para confirmar tu suscripción al tema de SNS en cuestión.
12. Repite los pasos del 4 al 11 y, durante el paso 5, elige "OK" y "Datos insuficientes" para el "Activador de estado de alarma" para configurar acciones para esos dos estados.
13. Repite el proceso para todas las demás alarmas de CloudWatch en la misma región de AWS.
14. Repite el proceso para todas las demás alarmas de CloudWatch en todas las demás regiones de AWS.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Cloudwatch Log Group Encrypted

Nombre de categoría en la API: CLOUDWATCH_LOG_GROUP_ENCRYPTED

Esta verificación garantiza que los registros de CloudWatch estén configurados con KMS.

Los datos de los grupos de registros siempre se encriptan en los registros de CloudWatch. De forma predeterminada, CloudWatch Logs usa la encriptación del servidor para los datos de registro en reposo. Como alternativa, puedes usar el servicio de administración de claves de AWS para esta encriptación. Si lo haces, la encriptación se realiza con una clave de AWS KMS. La encriptación con AWS KMS se habilita a nivel del grupo de registros. Para ello, se asocia una clave de KMS con un grupo de registros, ya sea cuando lo creas o después de que exista.

Recomendación: Verifica que todos los grupos de registros de Amazon CloudWatch Logs estén encriptados con KMS

Para obtener más información, consulta Cómo encriptar datos de registro en los registros de CloudWatch con AWS Key Management Service en la guía del usuario de Amazon CloudWatch.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

CloudTrail CloudWatch Logs Enabled

Nombre de categoría en la API: CLOUD_TRAIL_CLOUD_WATCH_LOGS_ENABLED

Este control verifica si los registros de CloudTrail están configurados para enviar registros a los registros de CloudWatch. El control falla si la propiedad CloudWatchLogsLogGroupArn del seguimiento está vacía.

CloudTrail registra las llamadas a la API de AWS que se realizan en una cuenta determinada. La información registrada incluye lo siguiente:

• La identidad del llamador de la API
• La hora de la llamada a la API
• La dirección IP de origen del llamador de la API
• Los parámetros de la solicitud
• Los elementos de respuesta que muestra el servicio de AWS

CloudTrail usa Amazon S3 para el almacenamiento y la entrega de archivos de registro. Puedes capturar registros de CloudTrail en un bucket de S3 especificado para el análisis a largo plazo. Para realizar análisis en tiempo real, puedes 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 los archivos de registro de todas esas regiones a un grupo de registros de CloudWatch Logs.

Security Hub recomienda que envíes los registros de CloudTrail a los registros de CloudWatch. Ten en cuenta que esta recomendación tiene como objetivo garantizar que se capture, supervise y active correctamente la actividad de la cuenta. Puedes usar CloudWatch Logs para configurar esto con tus servicios de AWS. Esta recomendación no excluye el uso de una solución diferente.

El envío de registros de CloudTrail a los registros de CloudWatch facilita el registro de actividades históricas y en tiempo real según el usuario, la API, el recurso y la dirección IP. Puedes usar este enfoque para establecer alarmas y notificaciones para la actividad anómala o sensible de la cuenta.

Recomendación: Comprueba que todos los registros de CloudTrail estén configurados para enviar registros a AWS CloudWatch

Para integrar CloudTrail con los registros de CloudWatch, consulta Cómo enviar eventos a los registros de CloudWatch en la Guía del usuario de AWS CloudTrail.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

No AWS Credentials in CodeBuild Project Environment Variables

Nombre de categoría en la API: CODEBUILD_PROJECT_ENVVAR_AWSCRED_CHECK

Esto verifica 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 simple, ya que esto podría provocar una exposición de datos no deseada y un acceso no autorizado.

Recomendación: Verifica que todos los proyectos que contengan las variables de entorno AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY no estén en texto simple

Para quitar variables de entorno de un proyecto de CodeBuild, consulta Cómo 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.

Puedes almacenar variables de entorno con valores sensibles en el Parameter Store de AWS Systems Manager o en AWS Secrets Manager y, luego, recuperarlas desde tu especificación de compilación. Para obtener instrucciones, consulta el cuadro etiquetado como Importante en la sección Entorno de la Guía del usuario de AWS CodeBuild.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Codebuild Project Source Repo Url Check

Nombre de categoría en la API: CODEBUILD_PROJECT_SOURCE_REPO_URL_CHECK

Esta función verifica 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 personales o un nombre de usuario y una contraseña.

Las credenciales de acceso no deben almacenarse ni transmitirse en texto simple ni aparecer en la URL del repositorio de origen. En lugar de tokens de acceso personal o credenciales de acceso, debes acceder a tu proveedor de origen en CodeBuild y cambiar la URL del repositorio de origen para que contenga solo la ruta de acceso a la ubicación del repositorio de Bitbucket. El uso de tokens de acceso personales o credenciales de acceso podría generar una exposición de datos no deseada o un acceso no autorizado.

Recomendación: Verifica que todos los proyectos que usen GitHub o Bitbucket como fuente utilicen OAuth

Puedes actualizar tu proyecto de CodeBuild para usar OAuth.

Para quitar la autenticación básica o el token de acceso personal (GitHub) de la fuente del proyecto de CodeBuild

1. Abre la consola de CodeBuild en https://console.aws.amazon.com/codebuild/.
2. Elige el proyecto de compilación que contiene tokens de acceso personal o un nombre de usuario y una contraseña.
3. En Editar, elige Fuente.
4. Elige Desconectarse de GitHub o Bitbucket.
5. Elige Conectar con OAuth y, luego, Conectar a GitHub o Bitbucket.
6. Cuando se te solicite, autoriza según corresponda.
7. Vuelve a configurar la URL del repositorio y los parámetros de configuración adicionales según sea necesario.
8. Elige Actualizar fuente.

Para obtener más información, consulta los ejemplos basados en casos de uso de CodeBuild en la Guía del usuario de AWS CodeBuild.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Credentials Unused 45 Days Greater Disabled

Nombre de categoría en la API: CREDENTIALS_UNUSED_45_DAYS_GREATER_DISABLED

Los usuarios de IAM de AWS pueden acceder a los recursos de AWS con diferentes tipos de credenciales, como contraseñas o claves de acceso. Se recomienda que se desactiven o quiten 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 usen durante 45 días o más estén inhabilitadas

Para solucionar este problema, completa los siguientes pasos:

AWS console

Realiza lo siguiente para administrar la contraseña sin usar (acceso de la consola del usuario de IAM)

1. Accede a la Consola de administración de AWS:
2. Haz clic en Services.
3. Haz clic en IAM.
4. Haz clic en Users.
5. Haz clic en Security Credentials.
6. Seleccionar el usuario cuyo Console last sign-in es superior a 45 días
7. Haz clic en Security credentials.
8. En la sección Sign-in credentials, Console password haz clic en Manage.
9. En Acceso a la consola, selecciona Disable
   10. Haz clic en Apply.

Para desactivar las claves de acceso, haz lo siguiente:

1. Accede a la Consola de administración de AWS:
2. Haz clic en Services.
3. Haz clic en IAM.
4. Haz clic en Users.
5. Haz clic en Security Credentials.
6. Selecciona las claves de acceso que tengan más de 45 días y que se hayan usado.
   - Haz clic en Make Inactive.
7. 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.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Default Security Group Vpc Restricts All Traffic

Nombre de categoría en la API: DEFAULT_SECURITY_GROUP_VPC_RESTRICTS_ALL_TRAFFIC

Una VPC incluye un grupo de seguridad predeterminado cuya configuración inicial rechaza 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 especificas un grupo de seguridad cuando inicias una instancia, esta se asigna 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 la VPC predeterminada de cada región debe estar actualizado para cumplir con la política. Todas las VPC nuevas contendrán automáticamente un grupo de seguridad predeterminado que deberá corregirse para cumplir con esta recomendación.

NOTA: Cuando se implementa esta recomendación, el registro de flujos de VPC es invaluable para determinar el acceso de puerto con privilegio mínimo que requieren los sistemas para funcionar correctamente, ya que puede registrar todas las aceptaciones y rechazos de paquetes que se producen en los grupos de seguridad actuales. Esto reduce de forma significativa la barrera principal para la ingeniería de privilegio mínimo: descubrir los puertos mínimos que requieren los sistemas en el entorno. Incluso si no se adopta la recomendación de registro de flujo de VPC en esta comparativa como una medida de seguridad permanente, se debe usar durante cualquier período de descubrimiento y de ingeniería para los grupos de seguridad con menos privilegios.

Recomendación: Asegúrate de que el grupo de seguridad predeterminado de cada VPC restrinja todo el tráfico

Miembros del grupo de seguridad

Realiza lo siguiente para implementar el estado prescrito:

1. Identifica los recursos de AWS que existen dentro del grupo de seguridad predeterminado
2. Crea un conjunto de grupos de seguridad de privilegio mínimo para esos recursos.
3. Coloca los recursos en esos grupos de seguridad
4. Quita los recursos mencionados en el paso 1 del grupo de seguridad predeterminado.

Estado del grupo de seguridad

1. Accede a la Consola de administración de AWS en https://console.aws.amazon.com/vpc/home.
2. Repite los siguientes pasos para todas las VPC, incluida la VPC predeterminada de cada región de AWS:
3. En el panel izquierdo, haz clic en Security Groups.
4. Para cada grupo de seguridad predeterminado, haz lo siguiente:
5. Selecciona el grupo de seguridad default.
6. Haz clic en la pestaña Inbound Rules.
7. Quita todas las reglas entrantes
8. Haz clic en la pestaña Outbound Rules.
9. Quita todas las reglas de salida.

Recomendado:

Los grupos de IAM te permiten editar el campo "nombre". Después de corregir las reglas de los grupos predeterminados para todas las VPC de todas las regiones, edita este campo para agregar un texto similar a "NO USAR. NO AGREGUES REGLAS".

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Dms Replication Not Public

Nombre de categoría en la API: DMS_REPLICATION_NOT_PUBLIC

Verifica si las instancias de replicación de AWS DMS son públicas. Para ello, examina el valor del campo PubliclyAccessible.

Una instancia de replicación privada tiene una dirección IP privada a la que no puedes acceder fuera de la red de replicación. 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 con una VPN, AWS Direct Connect o el intercambio de tráfico entre VPC. 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 el acceso a la configuración de tu instancia de AWS DMS se limite solo a los usuarios autorizados. Para ello, restringe los permisos de IAM de los usuarios para modificar la configuración y los recursos de AWS DMS.

Recomendación: Verifica 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 la configuración de acceso público, borra tu instancia actual y vuelve a crearla. No selecciones la opción de acceso público.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Do Setup Access Keys During Initial User Setup All Iam Users Console

Nombre de categoría en la API: DO_SETUP_ACCESS_KEYS_DURING_INITIAL_USER_SETUP_ALL_IAM_USERS_CONSOLE

De forma predeterminada, AWS Console no selecciona ninguna casilla de verificación cuando se crea un usuario de IAM nuevo. Cuando crees las credenciales de usuario de IAM, debes determinar qué tipo de acceso requieren.

Acceso programático: Es posible que el usuario de IAM deba realizar llamadas a la API, usar AWS CLI o usar las herramientas para Windows PowerShell. En ese caso, crea una clave de acceso (ID de clave de acceso y 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, créale una contraseña.

Recomendación: No establezcas claves de acceso durante la configuración inicial de ningún usuario de IAM que tenga una contraseña de la consola

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la Consola de administración de AWS:
2. Haz clic en Services.
3. Haz clic en IAM.
4. Haz clic en Users.
5. Haz clic en Security Credentials.
6. Como administrador
   - Haz clic en la X (Delete) para las claves que se crearon al mismo tiempo que el perfil de usuario, pero que no se usaron.
7. Como usuario de IAM
   - Haz clic en la X (Delete) para las claves que se crearon al mismo tiempo que el perfil de usuario, pero que no se usaron.

CLI de AWS

aws iam delete-access-key --access-key-id <access-key-id-listed> --user-name <users-name>

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Dynamodb Autoscaling Enabled

Nombre de categoría en la API: DYNAMODB_AUTOSCALING_ENABLED

Esto verifica si una tabla de Amazon DynamoDB puede escalar su capacidad de lectura y escritura según sea necesario. Este control se pasa si la tabla usa el modo de capacidad on demand o el modo aprovisionado con el ajuste de escala automático configurado. La escalabilidad de la capacidad con la demanda evita las excepciones de limitación, lo que ayuda a mantener la disponibilidad de tus aplicaciones.

Las tablas de DynamoDB en el modo de capacidad a pedido solo se limitan por las cuotas de tabla predeterminadas de capacidad de procesamiento de DynamoDB. Para aumentar estas cuotas, puedes enviar un ticket de asistencia a través de la Asistencia de AWS.

Las tablas de DynamoDB en el modo aprovisionado con el ajuste de escala automático ajustan la capacidad de rendimiento 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 la sección Limitación de solicitudes y capacidad de ráfaga en la Guía para desarrolladores de Amazon DynamoDB.

Recomendación: Las tablas de DynamoDB deben ajustar la escala de la capacidad automáticamente según la demanda

Para obtener instrucciones detalladas sobre cómo habilitar el ajuste de escala automático de DynamoDB en tablas existentes en el modo de capacidad, consulta Cómo habilitar el ajuste de escala automático de DynamoDB en tablas existentes en la Guía para desarrolladores de Amazon DynamoDB.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Dynamodb In Backup Plan

Nombre de categoría en la API: DYNAMODB_IN_BACKUP_PLAN

Este control evalúa si una tabla de DynamoDB está cubierta por un plan de copias de seguridad. El control falla si una tabla de DynamoDB no está cubierta por un plan de copias de seguridad. Este control solo evalúa las tablas de DynamoDB que están en el estado ACTIVE.

Las copias de seguridad te ayudan a recuperarte más rápido de un incidente de seguridad. También fortalecen la resiliencia de tus sistemas. Si incluyes tablas de DynamoDB en un plan de copia de seguridad, podrás proteger tus datos contra pérdidas o eliminaciones no deseadas.

Recomendación: Las tablas de DynamoDB deben contar con un plan de copias de seguridad

Para agregar una tabla de DynamoDB a un plan de copias de seguridad de AWS Backup, consulta Cómo asignar recursos a un plan de copias de seguridad en la Guía para desarrolladores de AWS Backup.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Dynamodb Pitr Enabled

Nombre de categoría en la API: DYNAMODB_PITR_ENABLED

La recuperación de un momento determinado (PITR) es uno de los mecanismos disponibles para crear copias de seguridad de tablas de DynamoDB.

Una copia de seguridad de un momento determinado se conserva durante 35 días. Si necesitas una retención más larga, consulta Cómo configurar copias de seguridad programadas para Amazon DynamoDB con AWS Backup en la documentación de AWS.

Recomendación: Verifica que la recuperación de un momento determinado (PITR) esté habilitada para todas las tablas de AWS DynamoDB

Para solucionar este problema, completa los siguientes pasos:

Terraform

Para configurar la PITR para las tablas de DynamoDB, establece el bloque point_in_time_recovery:

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  point_in_time_recovery {
    enabled = true
  }
}

AWS console

Para habilitar la recuperación de un momento determinado de DynamoDB para una tabla existente

1. Abre la consola de DynamoDB en https://console.aws.amazon.com/dynamodb/.
2. Elige la tabla con la que deseas trabajar y, luego, selecciona Copias de seguridad.
3. En la sección Recuperación de un momento determinado, en Estado, elige Habilitar.
4. 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"

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Dynamodb Table Encrypted Kms

Nombre de categoría en la API: DYNAMODB_TABLE_ENCRYPTED_KMS

Verifica si todas las tablas de DynamoDB están encriptadas con una clave de KMS administrada por el cliente (no predeterminada).

Recomendación: Verifica que todas las tablas de DynamoDB estén encriptadas con el servicio de administración de claves (KMS) de AWS

Para solucionar este problema, completa los siguientes pasos:

Terraform

Para corregir este control, crea una clave de AWS KMS y úsala para encriptar el recurso de DynamoDB que incumple la política.

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
  }
}

AWS console

Suponiendo que hay una clave de AWS KMS existente disponible para encriptar DynamoDB.

Para cambiar la encriptación de una tabla de DynamoDB a una clave de KMS administrada y propiedad del cliente.

1. Abre la consola de DynamoDB en https://console.aws.amazon.com/dynamodb/.
2. Elige la tabla con la que deseas trabajar y, luego, Configuración adicional.
3. En Encriptación, elige Administrar encriptación.
4. Para la encriptación en reposo, elige Almacenado en tu cuenta y que tú seas el propietario y el administrador.
5. Selecciona la clave de AWS que deseas usar. Guarden los cambios.

CLI de AWS

aws dynamodb update-table \
  --table-name <value> \
  --sse-specification "Enabled=true,SSEType=KMS,KMSMasterKeyId=<kms_key_arn>"

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Ebs Optimized Instance

Nombre de categoría en la API: EBS_OPTIMIZED_INSTANCE

Comprueba si la optimización de EBS está habilitada para tus instancias de EC2 que pueden optimizarse para EBS

Recomendación: Comprueba que la optimización de EBS esté habilitada para todas las instancias que la admitan

Para configurar la configuración de instancias optimizadas para EBS, consulta Instancias optimizadas para Amazon EBS en la guía del usuario de Amazon EC2.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Ebs Snapshot Public Restorable Check

Nombre de categoría en la API: EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK

Verifica si las instantáneas de Amazon Elastic Block Store no son públicas. El control falla si cualquier persona puede restablecer las instantáneas de Amazon EBS.

Las instantáneas de EBS se usan para crear copias de seguridad de los datos de tus volúmenes de EBS en Amazon S3 en un momento específico. Puedes usar las instantáneas para restablecer estados anteriores de los volúmenes de EBS. Rara vez se acepta compartir una instantánea con el público. Por lo general, la decisión de compartir una instantánea de forma pública se toma por error o sin comprender completamente las implicaciones. Esta verificación ayuda a garantizar que todo este tipo de uso compartido se haya planificado y realizado de forma intencional.

Recomendación: Las instantáneas de Amazon EBS no deben poder restablecerse públicamente

Para solucionar este problema, completa los siguientes pasos:

AWS console

Para solucionar este problema, actualiza la instantánea de EBS para que sea privada en lugar de pública.

Para hacer privada una instantánea pública de EBS, sigue estos pasos:

1. Abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
2. En el panel de navegación, en Elastic Block Store, elige el menú Snapshots y, luego, tu instantánea pública.
3. En Acciones, elige Modificar permisos.
4. Elige Privado.
5. (Opcional) Agrega los números de cuenta de AWS de las cuentas autorizadas con las que deseas compartir tu instantánea y elige Agregar permiso.
6. Selecciona Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Ebs Volume Encryption Enabled All Regions

Nombre de categoría en la API: EBS_VOLUME_ENCRYPTION_ENABLED_ALL_REGIONS

Elastic Compute Cloud (EC2) admite la encriptación en reposo cuando se usa el servicio Elastic Block Store (EBS). Si bien está inhabilitada de forma predeterminada, se admite la aplicación forzosa de la encriptación en la creación de volúmenes de EBS.

Recomendación: Asegúrate de que la encriptación de volumen de EBS esté habilitada en todas las regiones

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de administración de AWS y abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
2. En Account attributes, haz clic en EBS encryption.
3. Haz clic en Manage.
4. Haz clic en la casilla de verificación Enable.
5. Haz clic en Update EBS encryption.
6. Repite el proceso para cada región que requiera el cambio.

Nota: La encriptación de volúmenes de EBS se configura por región.

CLI de AWS

1. Ejecutar

aws --region <region> ec2 enable-ebs-encryption-by-default

2. Verifica que se muestre "EbsEncryptionByDefault": true.
3. Repite el proceso para cada región que requiera el cambio.

Nota: La encriptación de volúmenes de EBS se configura por región.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Ec2 Instances In Vpc

Nombre de categoría en la API: EC2_INSTANCES_IN_VPC

Amazon VPC proporciona más funciones de seguridad que EC2 Classic. Se recomienda que todos los nodos pertenezcan a una VPC de Amazon.

Recomendación: Garantiza que todas las instancias pertenezcan a una VPC

Para solucionar este problema, completa los siguientes pasos:

Terraform

Si tienes instancias clásicas de EC2 definidas en Terraform, puedes modificar tus recursos para que formen parte de una VPC. Esta migración dependerá de una arquitectura que se adapte mejor a tus necesidades. El siguiente es un ejemplo simple de Terraform que ilustra un EC2 expuesto 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 [e-mail]"
  }

  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"
    }
  }

AWS console

Para migrar tu instancia de EC2 clásica a VPC, consulta Cómo migrar de EC2 clásica a una VPC.

CLI de AWS

En este ejemplo de la CLI de AWS, se ilustra 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

Crea una subred pública

  aws ec2 create-subnet \
  --availability-zone 1a \
  --cidr-block 10.0.1.0/24 \
  --vpc-id <id_from_create-vpc_command>

Crea una puerta de enlace de Internet

  aws ec2 create-internet-gateway

Cómo conectar la puerta de enlace de Internet a la VPC

  aws ec2 attach-internet-gateway \
  --internet-gateway-id <id_from_create-internet-gateway_command> \
  --vpc-id <id_from_create-vpc_command>

Create Key Pair: 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

Crea un grupo de seguridad

  aws ec2 create-security-group \
  --group-name "http and ssh" \
  --vpc-id <id_from_create-vpc_command>

Crea reglas de grupo de seguridad: Para obtener un acceso más restringido, 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

Crea una 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>

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Ec2 Instance No Public Ip

Nombre de categoría en la API: EC2_INSTANCE_NO_PUBLIC_IP

Las instancias de EC2 que tienen una dirección IP pública tienen un mayor riesgo de vulneración. Se recomienda que las instancias de EC2 no se configuren con una dirección IP pública.

Recomendación: Garantiza que ninguna instancia tenga una IP pública

Para solucionar este problema, completa los siguientes 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
}

AWS console

De forma predeterminada, las subredes que no son predeterminadas tienen el atributo de direccionamiento público IPv4 configurado como falso, y las subredes predeterminadas tienen este atributo configurado como verdadero. Una excepción es una subred no predeterminada que crea el asistente de inicio de instancias de Amazon EC2. El asistente establece el atributo como verdadero. Puedes modificar este atributo con la consola de Amazon VPC.

Para modificar el comportamiento de direccionamiento IPv4 público de tu subred

1. Abre la consola de Amazon VPC en https://console.aws.amazon.com/vpc/.
2. En el panel de navegación, elige Subredes.
3. Selecciona tu subred y elige Acciones, Editar configuración de subred.
4. Si se selecciona la casilla de verificación Habilitar la asignación automática de direcciones IPv4 públicas, se solicita una dirección IPv4 pública para todas las instancias que se inician en la subred seleccionada. Selecciona o desmarca la casilla de verificación según sea necesario y, luego, elige Guardar.

CLI de AWS

El siguiente comando ejecuta una instancia de 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

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Ec2 Managedinstance Association Compliance Status Check

Nombre de 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 tus instancias administradas. La configuración define el estado que deseas 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 se deben cerrar ciertos puertos. Las instancias de EC2 que tienen una asociación con AWS Systems Manager están bajo la administración de Systems Manager, lo que facilita la aplicación de parches, la corrección de parámetros de configuración incorrectos y la respuesta a eventos de seguridad.

Recomendación: Verifica el estado de cumplimiento de la asociación de AWS Systems Manager

Para solucionar este problema, completa los siguientes pasos:

Terraform

En el siguiente ejemplo, se muestra cómo crear una instancia de EC2 simple, un documento de AWS Systems Manager (SSM) y una asociación entre SSM y la instancia de EC2. Los documentos compatibles 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]
  }
}

AWS console

Para obtener información sobre cómo configurar asociaciones con AWS Systems Manager mediante la consola, consulta Cómo crear asociaciones en la documentación de AWS Systems Manager.

CLI de AWS

Crea un documento de SSM

aws ssm create-document \
--name <document_name> \
--content  file://path/to-file/document.json \
--document-type "Command"

Crea una asociación de SSM

aws ssm create-association \
--name <association_name> \
--targets "Key=InstanceIds,Values=<instance-id-1>,<instance-id-2>"

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Ec2 Managedinstance Patch Compliance Status Check

Nombre de categoría en la API: EC2_MANAGEDINSTANCE_PATCH_COMPLIANCE_STATUS_CHECK

Este control verifica si el estado de cumplimiento de la asociación de AWS Systems Manager es COMPLIANT o NON_COMPLIANT después de que se ejecuta la asociación en una instancia. El control falla si el estado de cumplimiento de la asociación es NON_COMPLIANT.

Una asociación de State Manager es una configuración que se asigna a tus instancias administradas. La configuración define el estado que deseas mantener en tus instancias. Por ejemplo, una asociación puede especificar que se debe instalar y ejecutar software antivirus en tus instancias o que se deben cerrar ciertos puertos.

Después de crear una o más asociaciones con el Administrador de estados, la información del estado de cumplimiento estará disponible de inmediato. Puedes ver el estado de cumplimiento en la consola o en respuesta a los comandos de AWS CLI o las acciones de la API de Systems Manager correspondientes. En el caso de las asociaciones, el cumplimiento de la configuración muestra el estado de cumplimiento (Cumple o No cumple). También 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 la asociación de State Manager, consulta Acerca del cumplimiento de la asociación de State Manager en la Guía del usuario de AWS Systems Manager.

Recomendación: Verifica el estado de cumplimiento de parches de AWS Systems Manager

Una asociación fallida puede estar relacionada con diferentes elementos, incluidos los objetivos y los nombres de los documentos de SSM. Para solucionar este problema, primero debes identificar e investigar la asociación. Para ello, consulta el historial de asociaciones. Para obtener instrucciones sobre cómo ver el historial de asociaciones, consulta Cómo ver los 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 nombre, un programa, un nivel de gravedad o unos objetivos nuevos. Después de editar una asociación, AWS Systems Manager crea una versión nueva. Para obtener instrucciones sobre cómo editar una asociación, consulta Cómo editar y crear una versión nueva de una asociación en la Guía del usuario de AWS Systems Manager.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Ec2 Metadata Service Allows Imdsv2

Nombre de categoría en la API: EC2_METADATA_SERVICE_ALLOWS_IMDSV2

Cuando se habilita el servicio de metadatos en las instancias de AWS EC2, los usuarios tienen la opción de usar la versión 1 del servicio de metadatos de instancias (IMDSv1; un método de solicitud/respuesta) o la versión 2 del servicio de metadatos de instancias (IMDSv2; un método orientado a la sesión).

Recomendación: Asegúrate de que el servicio de metadatos de EC2 solo permita IMDSv2

Desde Play Console:
1. Accede a 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. Para cada instancia, selecciónala y, luego, elige Acciones > Modificar opciones de metadatos de la instancia.
4. Si el servicio de metadatos de la instancia está habilitado, establece IMDSv2 como Obligatorio.

Desde la línea de comandos:

aws ec2 modify-instance-metadata-options --instance-id <instance_id> --http-tokens required

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Ec2 Volume Inuse Check

Nombre de categoría en la API: EC2_VOLUME_INUSE_CHECK

Identificar y quitar los volúmenes de Elastic Block Store (EBS) sin conectar (sin usar) de tu cuenta de AWS para reducir el costo de tu factura mensual de AWS Si borras los volúmenes de EBS que no se usan, también se reduce el riesgo de que los datos confidenciales o sensibles salgan de tu instalación. Además, este control también verifica si las instancias de EC2 archivadas están configuradas para borrar volúmenes al finalizar.

De forma predeterminada, las instancias de EC2 están configuradas para borrar los datos de cualquier volumen de EBS asociado con la instancia y para borrar el volumen raíz de EBS de la instancia. Sin embargo, cualquier volumen de EBS que no sea raíz conectado a la instancia, en el inicio o durante la ejecución, se conserva después de la finalización de forma predeterminada.

Recomendación: Verifica si los volúmenes de EBS están adjuntos a instancias de EC2 y configurados para borrarse en cuanto finalice la instancia

Para solucionar este problema, completa los siguientes pasos:

Terraform

Para evitar esta situación con Terraform, crea instancias de EC2 con bloques de EBS incorporados. Esto garantiza que cualquier bloque de EBS asociado con la instancia (no solo la raíz) se borre cuando finalice la instancia, ya que el atributo ebs_block_device.delete_on_termination se establece de forma predeterminada en true.

resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    ebs_block_device {
      delete_on_termination = true # Default
      device_name           = "/dev/sdh"
    }

AWS console

Para borrar un volumen de EBS con la consola

1. Abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
2. En el panel de navegación, elige Volumes.
3. Selecciona el volumen que quieres borrar y elige Acciones, Borrar volumen.
4. Nota: Si la opción Borrar volumen está inhabilitada, significa que el volumen está adjunto a una instancia. Debes desconectar el volumen de la instancia para poder borrarlo.
5. En el cuadro de diálogo de confirmación, elige Borrar.

CLI de AWS

En este comando de ejemplo, se borra un volumen disponible con el ID de volumen vol-049df61146c4d7901. Si el comando se ejecuta de forma correcta, no se muestra ningún resultado.

aws ec2 delete-volume --volume-id vol-049df61146c4d7901

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Efs Encrypted Check

Nombre de categoría en la API: EFS_ENCRYPTED_CHECK

Amazon EFS admite dos formas de encriptación para sistemas de archivos: la encriptación de datos en tránsito y la encriptación en reposo. De esta manera, se verifica que todos los sistemas de archivos EFS estén configurados con encriptación en reposo en todas las regiones habilitadas de la cuenta.

Recomendación: Verifica si EFS está configurado para encriptar datos de archivos con KMS

Para solucionar este problema, completa los siguientes pasos:

Terraform

El siguiente fragmento de código se puede usar para crear un EFS encriptado por KMS (Nota: El atributo kms_key_id es opcional y se creará una clave si no se pasa un 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"
  }
}

AWS console

Para configurar EFS con encriptación mediante la consola de AWS, consulta Cómo encriptar un sistema de archivos inactivo con la consola.

CLI de AWS

Es importante tener en cuenta que, si bien la creación de EFS desde la consola habilita la encriptación en reposo de forma predeterminada, esto no es cierto para los EFS creados con la CLI, la API o el SDK. En el siguiente ejemplo, se muestra cómo crear un sistema de archivos encriptado en tu infraestructura.

aws efs create-file-system \
--backup \
--encrypted \
--region us-east-1 \

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Efs In Backup Plan

Nombre de categoría en la API: EFS_IN_BACKUP_PLAN

Las prácticas recomendadas de Amazon recomiendan configurar copias de seguridad para tus sistemas de archivos Elastic File System (EFS). De esta manera, se verifican todos los EFS de todas las regiones habilitadas de tu cuenta de AWS en busca de copias de seguridad habilitadas.

Recomendación: Verifica si los sistemas de archivos EFS se incluyen en los planes de copias de seguridad de AWS

Para solucionar este problema, completa los siguientes pasos:

Terraform

Usa el recurso aws_efs_backup_policy para configurar una política de copia de seguridad para los sistemas de archivos 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"
  }
}

AWS console

Existen dos opciones para crear copias de seguridad de EFS: el servicio de AWS Backup y la solución de copia de seguridad de EFS a EFS. Para solucionar el problema de los EFS sin copia de seguridad con la consola, consulta los siguientes artículos:

1. Cómo usar AWS Backup para crear copias de seguridad de sistemas de archivos EFS de Amazon y restablecerlas
2. Copia de seguridad de EFS a EFS

CLI de AWS

Existen algunas opciones para crear sistemas de archivos EFS que cumplan con los requisitos mediante la CLI:

1. Crear un EFS con la copia de seguridad automática habilitada (predeterminada para el almacenamiento de una zona y condicional a la disponibilidad de la copia de seguridad en la región de AWS)
2. Crea un EFS y establece una política de copia de seguridad

Sin embargo, si se supone que la solución debe realizarse en EFS existentes, la mejor opción es crear una política de copia de seguridad y asociarla a tu EFS que no cumple con los requisitos. Necesitarás un comando para 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

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Elb Acm Certificate Required

Nombre de categoría en la API: ELB_ACM_CERTIFICATE_REQUIRED

Verifica si el balanceador de cargas clásico usa certificados HTTPS/SSL proporcionados por AWS Certificate Manager (ACM). El control falla si el balanceador de cargas clásico configurado con el objeto de escucha HTTPS/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 cargas.

ACM se integra en los balanceadores de cargas clásicos para que puedas implementar el certificado en tu balanceador de cargas. También debes renovar estos certificados automáticamente.

Recomendación: Verifica que todos los balanceadores de cargas clásicos utilicen los certificados SSL proporcionados por AWS Certificate Manager

Para obtener información sobre cómo asociar un certificado SSL/TLS de ACM con un balanceador de cargas clásico, consulta el artículo del Centro de conocimiento de AWS ¿Cómo puedo asociar un certificado SSL/TLS de ACM con un balanceador de cargas clásico, de aplicaciones o de red?

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Elb Deletion Protection Enabled

Nombre de categoría en la API: ELB_DELETION_PROTECTION_ENABLED

Verifica si un balanceador de cargas de aplicaciones tiene habilitada la protección contra la eliminación. El control falla si no se configura la protección contra la eliminación.

Habilita la protección contra la eliminación para proteger tu balanceador de cargas de aplicaciones de la eliminación.

Recomendación: Se debe habilitar la protección contra eliminaciones del balanceador de cargas de aplicaciones

Para solucionar este problema, completa los siguientes pasos:

AWS console

Para evitar que se borre accidentalmente tu balanceador de cargas, puedes habilitar la protección contra eliminaciones. De forma predeterminada, la protección contra la eliminación está inhabilitada para tu balanceador de cargas.

Si habilitas la protección contra la eliminación para tu balanceador de cargas, debes inhabilitarla para poder borrarlo.

Para habilitar la protección contra la eliminación desde la consola.

1. Abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
2. En el panel de navegación, en BALANCEO DE CARGAS, elige Balanceadores de cargas.
3. Elige el balanceador de cargas.
4. En la pestaña Descripción, elige Editar atributos.
5. En la página Editar atributos del balanceador de cargas, selecciona Habilitar para la protección contra borrado y, luego, elige Guardar.
6. Elige Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Elb Logging Enabled

Nombre de categoría en la API: ELB_LOGGING_ENABLED

Esto verifica si el balanceador de cargas de aplicaciones y el balanceador de cargas clásico tienen habilitado el registro. El control falla si access_logs.s3.enabled es falso.

El balanceo de cargas de Elastic proporciona registros de acceso que capturan información detallada sobre las solicitudes que se envían a tu balanceador de cargas. Cada registro contiene información como la hora en que se recibió la solicitud, la dirección IP del cliente, las latencias, las rutas de solicitud y las respuestas del servidor. Puedes usar estos registros de acceso para analizar los patrones de tráfico y solucionar problemas.

Para obtener más información, consulta Registros de acceso de tu balanceador de cargas clásico en la Guía del usuario de los balanceadores de cargas clásicos.

Recomendación: Verifica si los balanceadores de cargas clásicos y de aplicaciones tienen el registro habilitado

Para solucionar este problema, completa los siguientes pasos:

AWS console

Para solucionar este problema, actualiza los balanceadores de cargas para habilitar el registro.

Para habilitar los registros de acceso, sigue estos pasos:

1. Abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
2. En el panel de navegación, elige Balanceadores de cargas.
3. Elige un balanceador de cargas de aplicaciones o un balanceador de cargas clásico.
4. En Acciones, elige Editar atributos.
5. En Registros de acceso, selecciona Habilitar.
6. Ingresa tu ubicación de S3. Esta ubicación puede existir o se puede crear para ti. Si no especificas un prefijo, los registros de acceso se almacenarán en la raíz del bucket de S3.
7. Elige Guardar.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Elb Tls Https Listeners Only

Nombre de categoría en la API: ELB_TLS_HTTPS_LISTENERS_ONLY

Esta verificación garantiza que todos los balanceadores de cargas clásicos estén configurados para usar una comunicación segura.

Un objeto de escucha es un proceso que verifica las solicitudes de conexión. Se configura con un protocolo y un puerto para las conexiones de frontend (cliente a balanceador de cargas) y un protocolo y un puerto para las conexiones de backend (balanceador de cargas a instancia). Para obtener información sobre los puertos, los protocolos y las configuraciones de los objetos de escucha que admite Elastic Load Balancing, consulta Objetos de escucha para tu balanceador de cargas clásico.

Recomendación: Verifica que todos los balanceadores de cargas clásicos estén configurados con objetos de escucha SSL o HTTPS

Para configurar SSL o TLS para balanceadores de cargas clásicos, consulta Cómo crear un balanceador de cargas HTTPS/SSL con la consola de administración de AWS.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Encrypted Volumes

Nombre de categoría en la API: ENCRYPTED_VOLUMES

Verifica si los volúmenes de EBS que están en un estado adjunto están encriptados. Para que se apruebe esta verificación, los volúmenes de EBS deben estar en uso y encriptados. Si el volumen de EBS no está adjunto, no está sujeto a esta verificación.

Para obtener una capa adicional de seguridad de tus datos sensibles en los volúmenes de EBS, debes habilitar la encriptación de EBS en reposo. La encriptación de Amazon EBS ofrece una solución de encriptación sencilla para tus recursos de EBS que no requiere que crees, mantengas ni protejas tu propia infraestructura de administración de claves. Usa claves de KMS cuando crea instantáneas y volúmenes encriptados.

Para obtener más información sobre la encriptación de Amazon EBS, consulta la sección Encriptación de Amazon EBS en la Guía del usuario de Amazon EC2 para instancias de Linux.

Recomendación: Los volúmenes de Amazon EBS adjuntos deben estar encriptados en reposo

Para solucionar este problema, completa los siguientes pasos:

AWS console

No hay una forma directa de encriptar un volumen o una instantánea no encriptados existentes. Solo puedes encriptar un volumen o una instantánea nuevos cuando los creas.

Si habilitaste la encriptación de forma predeterminada, Amazon EBS encripta el volumen o la instantánea nuevos resultantes con la clave predeterminada para la encriptación de Amazon EBS. Incluso si no habilitaste la encriptación de forma predeterminada, puedes habilitarla cuando creas un volumen o una instantánea individuales. En ambos casos, puedes anular la clave predeterminada de la encriptación de Amazon EBS y elegir una clave simétrica administrada por el cliente.

Para obtener más información, consulta Cómo crear un volumen de Amazon EBS y Cómo copiar una instantánea de Amazon EBS en la Guía del usuario de Amazon EC2 para instancias de Linux.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Encryption At Rest Enabled Rds Instances

Nombre de categoría en la API: ENCRYPTION_AT_REST_ENABLED_RDS_INSTANCES

Las instancias de bases de datos encriptadas de Amazon RDS usan el algoritmo de encriptación AES-256 estándar de la industria para encriptar tus datos en el servidor que aloja tus instancias de bases de datos de Amazon RDS. Después de que se encriptan tus datos, Amazon RDS controla la autenticación de acceso y la desencriptación de tus datos de forma transparente con un impacto mínimo en el rendimiento.

Recomendación: Asegúrate de que la encriptación en reposo esté habilitada para las instancias de RDS

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la Consola de administración de AWS y abre el panel de RDS en https://console.aws.amazon.com/rds/.
2. En el panel de navegación de la izquierda, haz clic en Databases.
3. Selecciona la instancia de la base de datos que se debe encriptar.
4. Haz clic en el botón Actions ubicado en la parte superior derecha y selecciona Take Snapshot.
5. En la página Tomar instantánea, ingresa el nombre de la base de datos de la que deseas tomar una instantánea en el campo Snapshot Name y haz clic en Take Snapshot.
6. Selecciona la instantánea recién creada, haz clic en el botón Action ubicado en la parte superior derecha y selecciona Copy snapshot en el menú Acción.
7. En la página Make Copy of DB Snapshot, haz lo siguiente:

• En el campo Nuevo identificador de instantánea de la base de datos, ingresa un nombre para el new snapshot.
• Marca Copy Tags, La instantánea nueva debe tener las mismas etiquetas que la instantánea de origen.
• Selecciona Yes en la lista desplegable Enable Encryption para habilitar la encriptación. Puedes usar la clave de encriptación predeterminada de AWS o la clave personalizada de la lista desplegable Clave principal.

8. Haz clic en Copy Snapshot para crear una copia encriptada de la instantánea de la instancia seleccionada.
9. Selecciona la nueva copia encriptada de la instantánea y haz clic en el botón Action ubicado en la parte superior derecha y selecciona el botón Restore Snapshot en el menú Acción. Esto restablecerá la instantánea encriptada en una nueva instancia de base de datos.
10. En la página Restaurar instancia de base de datos, ingresa un nombre único para la nueva instancia de base de datos en el campo Identificador de instancia de base de datos.
11. Revisa los detalles de la configuración de la instancia y haz clic en Restore DB Instance.
12. A medida que se completa el proceso de aprovisionamiento de la nueva instancia, se puede actualizar la configuración de la aplicación para que haga referencia al extremo de la nueva instancia de base de datos encriptada. Una vez que se cambia el extremo de la base de datos a nivel de la aplicación, se puede quitar la instancia no encriptada.

CLI de AWS

1. Ejecuta el comando describe-db-instances para mostrar una lista de todos los nombres de bases de datos de RDS disponibles en la región de AWS seleccionada. El resultado del comando debe mostrar el identificador de la instancia de la base de datos.

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

2. Ejecuta el comando create-db-snapshot para crear una instantánea de la instancia de base de datos seleccionada. El resultado del comando mostrará 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>

3. Ahora, ejecuta el comando list-aliases para enumerar los alias de claves de KMS disponibles en una región especificada. El resultado del comando debería mostrar cada key alias currently available. Para nuestro proceso de activación de la encriptación de RDS, busca el ID de la clave de KMS predeterminada de AWS.

aws kms list-aliases --region <region-name>

4. Ejecuta el comando copy-db-snapshot con el ID de clave de KMS predeterminado para las instancias de RDS que se mostró antes para crear una copia encriptada de la instantánea de la instancia de la base de datos. El resultado del comando mostrará 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>

5. Ejecuta el comando restore-db-instance-from-db-snapshot para restablecer la instantánea encriptada que se creó en el paso anterior en una instancia de base de datos nueva. Si se realiza correctamente, el resultado del comando debería mostrar la nueva configuración de la instancia de base de datos encriptada.

aws rds restore-db-instance-from-db-snapshot --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --db-snapshot-identifier <DB-Snapshot-Name-Encrypted>

6. Ejecuta el comando describe-db-instances para mostrar una lista de todos los nombres de bases de datos de RDS disponibles en la región de AWS seleccionada. El resultado mostrará el nombre del identificador de la instancia de la base de datos. Selecciona el nombre de la base de datos encriptada que acabamos de crear, DB-Name-Encrypted.

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

7. Vuelve a ejecutar el comando describe-db-instances con el identificador de instancia de RDS que se mostró antes para determinar si la instancia de base de datos seleccionada está encriptada. El resultado del comando debería mostrar el estado de encriptación True.

aws rds describe-db-instances --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --query 'DBInstances[*].StorageEncrypted'

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Encryption Enabled Efs File Systems

Nombre de categoría en la API: ENCRYPTION_ENABLED_EFS_FILE_SYSTEMS

Los datos de EFS deben encriptarse en reposo con AWS KMS (servicio de administración de claves).

Recomendación: Asegúrate de que la encriptación esté habilitada para los sistemas de archivos EFS

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de administración de AWS y navega al panel de Elastic File System (EFS).
2. Selecciona File Systems en el panel de navegación izquierdo.
3. Haz clic en el botón Create File System en el menú superior del panel para iniciar el proceso de configuración del sistema de archivos.

4. En la página de configuración de Configure file system access, realiza las siguientes acciones.
   - Elige la VPC correcta en la lista desplegable de VPC.
   - En la sección Crear destinos de activación, selecciona las casillas de verificación de todas las zonas de disponibilidad (AZ) dentro de la VPC seleccionada. Estos serán tus destinos de activación.
   - Haz clic en Next step para continuar.

5. Realiza lo siguiente en la página Configure optional settings.
   - Crea tags para describir tu nuevo sistema de archivos.
   : Elige performance mode según tus requisitos.
   - Marca la casilla de verificación Enable encryption y elige aws/elasticfilesystem en la lista desplegable Seleccionar clave maestra de KMS para habilitar la encriptación del nuevo sistema de archivos con la clave maestra predeterminada que proporciona y administra AWS KMS.
   - Haz clic en Next step para continuar.

6. Revisa los detalles de configuración del sistema de archivos en la página review and create y, luego, haz clic en Create File System para crear tu nuevo sistema de archivos EFS de AWS.

7. Copia los datos del sistema de archivos EFS no encriptado anterior en el sistema de archivos encriptado que acabas de crear.
8. Quita el sistema de archivos no encriptado en cuanto se complete la migración de datos al sistema de archivos encriptado que acabas de crear.
9. 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 (no encriptado) (consulta la sección de auditoría para identificar el recurso correcto):

aws efs describe-file-systems --region <region> --file-system-id <file-system-id from audit section step 2 output>

2. El resultado del comando debería mostrar la información de configuración solicitada.
3. Para aprovisionar un nuevo sistema de archivos EFS de AWS, debes generar un identificador único universal (UUID) para crear el token que requiere el comando create-file-system. Para crear el token requerido, puedes usar un UUID generado de forma aleatoria en "https://www.uuidgenerator.net".
4. Ejecuta el comando create-file-system con el token único que creaste en el paso anterior.

aws efs create-file-system --region <region> --creation-token <Token (randomly generated UUID from step 3)> --performance-mode generalPurpose --encrypted

5. El resultado del comando debería mostrar los metadatos de configuración del nuevo sistema de archivos.
6. Ejecuta el comando create-mount-target con el ID del sistema de archivos EFS creado recientemente que se mostró en el paso anterior como identificador y el ID de la zona de disponibilidad (AZ) que representará el destino de activación:

aws efs create-mount-target --region <region> --file-system-id <file-system-id> --subnet-id <subnet-id>

7. El resultado del comando debería mostrar los metadatos del nuevo destino de activación.
8. Ahora puedes activar tu sistema de archivos desde una instancia de EC2.
9. Copia los datos del sistema de archivos EFS no encriptado anterior al sistema de archivos encriptado que acabas de crear.
10. Quita el sistema de archivos no encriptado en cuanto se complete la migración de datos al sistema de archivos encriptado que acabas de crear.

aws efs delete-file-system --region <region> --file-system-id <unencrypted-file-system-id>

11. Para cambiar la región de AWS, actualiza la opción --region y repite todo el proceso para otras regiones de AWS.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Iam Password Policy

Nombre de categoría en la API: IAM_PASSWORD_POLICY

AWS permite políticas de contraseñas personalizadas en tu cuenta de AWS para especificar requisitos de complejidad y períodos de rotación obligatorios para las contraseñas de tus usuarios de IAM. Si no configuras una política de contraseñas personalizada, las contraseñas de los usuarios de IAM deben cumplir con la política de contraseñas predeterminada de AWS. Las prácticas recomendadas de seguridad de AWS recomiendan los siguientes requisitos de complejidad de contraseñas:

• Se requiere al menos un carácter en mayúscula en la contraseña.
• Se requiere al menos un carácter en minúscula en las contraseñas.
• Se requiere al menos un símbolo en las contraseñas.
• Se requiere al menos un número en las contraseñas.
• Requiere una longitud mínima de contraseña de al menos 14 caracteres.
• Se requieren al menos 24 contraseñas antes de permitir la reutilización.
• Requerir al menos 90 días antes del vencimiento de la contraseña

De esta manera, se controlan todos los requisitos de la política de contraseñas especificada.

Recomendación: Verifica si la política de contraseñas de la cuenta para los usuarios de IAM cumple con los requisitos especificados

Para solucionar este problema, completa los siguientes 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
}

AWS console

Cómo crear una política de contraseñas personalizada

1. Accede a la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
2. En el panel de navegación, elige Configuración de la cuenta.
3. En la sección Política de contraseñas, elige Cambiar política de contraseñas.
4. Selecciona las opciones que deseas aplicar a tu política de contraseñas y elige Guardar cambios.

Cómo cambiar una política de contraseñas personalizada

1. Accede a la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
2. En el panel de navegación, elige Configuración de la cuenta.
3. En la sección Política de contraseñas, elige Cambiar.
4. Selecciona las opciones que deseas 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

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Iam Password Policy Prevents Password Reuse

Nombre de categoría en la API: IAM_PASSWORD_POLICY_PREVENTS_PASSWORD_REUSE

Las políticas de contraseñas de IAM pueden evitar que el mismo usuario vuelva a usar una contraseña determinada. Se recomienda que la política de contraseñas evite la reutilización de contraseñas.

Recomendación: Asegúrate de que la política de contraseñas de IAM evite la reutilización de contraseñas

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de AWS (con los permisos adecuados para ver la configuración de la cuenta de Identity Access Management)
2. Ve al servicio de IAM en la consola de AWS
3. Haz clic en Configuración de la cuenta en el panel izquierdo.
4. Marca la opción "Prevenir la reutilización de contraseñas".
5. Se estableció "Cantidad de contraseñas que se recuerdan" en 24.

CLI de AWS

 aws iam update-account-password-policy --password-reuse-prevention 24

Nota: Todos los comandos que comienzan con "aws iam update-account-password-policy" se pueden combinar en un solo comando.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Iam Password Policy Requires Minimum Length 14 Greater

Nombre de 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 requisitos de complejidad de contraseñas. Las políticas de contraseñas de IAM se pueden usar para garantizar 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 o más

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de AWS (con los permisos adecuados para ver la configuración de la cuenta de Identity Access Management)
2. Ve al servicio de IAM en la consola de AWS
3. Haz clic en Configuración de la cuenta en el panel izquierdo.
4. Establece "Longitud mínima de la contraseña" en 14 o un valor superior.
5. 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 comienzan con "aws iam update-account-password-policy" se pueden combinar en un solo comando.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Iam Policies Allow Full Administrative Privileges Attached

Nombre de categoría en la API: IAM_POLICIES_ALLOW_FULL_ADMINISTRATIVE_PRIVILEGES_ATTACHED

Las políticas de IAM son el medio por el que se otorgan privilegios a los usuarios, los grupos o las funciones. Se recomienda y se considera un consejo de seguridad estándar otorgar privilegios mínimos, es decir, otorgar solo los permisos necesarios para realizar una tarea. Determina lo que los usuarios deben hacer y, luego, crea políticas que les permitan realizar solo esas tareas, en lugar de permitirles privilegios administrativos completos.

Recomendación: Asegúrate de que no se adjunten políticas de IAM que permitan privilegios administrativos completos de "*:*"

Para solucionar este problema, completa los siguientes pasos:

AWS console

Para separar la política que tiene privilegios administrativos completos, haz lo siguiente:

1. Accede a la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
2. En el panel de navegación, haz clic en Políticas y, luego, busca el nombre de la política que se encuentra en el paso de auditoría.
3. Selecciona la política que se debe borrar.
4. En el menú de acciones de la política, selecciona primero Detach.
5. Selecciona todos los usuarios, grupos y roles que tengan esta política adjunta.
6. Haz clic en Detach Policy.
7. En el menú de acciones de la política, selecciona Detach.

CLI de AWS

Realiza lo siguiente para desvincular la política que tiene privilegios administrativos completos, como se encontró en el paso de auditoría:

1. Muestra una lista de todos los usuarios, grupos y roles de IAM a los que se adjunta la política administrada especificada.

 aws iam list-entities-for-policy --policy-arn <policy_arn>

2. Desconecta la política de todos los usuarios de IAM:

 aws iam detach-user-policy --user-name <iam_user> --policy-arn <policy_arn>

3. Desconecta la política de todos los grupos de IAM:

 aws iam detach-group-policy --group-name <iam_group> --policy-arn <policy_arn>

4. Desconecta la política de todos los roles de IAM:

 aws iam detach-role-policy --role-name <iam_role> --policy-arn <policy_arn>

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Iam Users Receive Permissions Groups

Nombre de categoría en la API: IAM_USERS_RECEIVE_PERMISSIONS_GROUPS

Los usuarios de IAM obtienen acceso a los servicios, las funciones y los datos a través de las políticas de IAM. Existen cuatro maneras de definir políticas para un usuario: 1) Editar la política del usuario directamente, también conocida como política intercalada o del usuario; 2) adjuntar una política directamente a un usuario; 3) agregar al usuario a un grupo de IAM que tenga una política adjunta; 4) agregar al usuario a un grupo de IAM que tenga una política intercalada.

Solo se recomienda la tercera implementación.

Recomendación: Asegúrate de que los usuarios de IAM reciban permisos solo a través de grupos

Para crear un grupo de IAM y asignarle una política, haz lo siguiente:

1. Accede a la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
2. En el panel de navegación, haz clic en Groups y, luego, en Create New Group .
3. En el cuadro Group Name, escribe el nombre del grupo y, luego, haz clic en Next Step .
4. En la lista de políticas, selecciona la casilla de verificación de cada política que deseas aplicar a todos los miembros del grupo. Luego, haz clic en Next Step .
5. Haz clic en Create Group.

Para agregar un usuario a un grupo determinado, sigue estos pasos:

1. Accede a la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
2. En el panel de navegación, haz clic en Groups.
3. Selecciona el grupo al que deseas agregar un usuario.
4. Haz clic en Add Users To Group.
5. Selecciona los usuarios que se agregarán al grupo.
6. Haz clic en Add Users.

Para quitar una asociación directa entre un usuario y una política, haz lo siguiente:

1. Accede a la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
2. En el panel de navegación de la izquierda, haz clic en Usuarios.
3. Para cada usuario:
   - Selecciona el usuario.
   - Haz clic en la pestaña Permissions.
   - Expande Permissions policies.
   - Haz clic en X para cada política y, luego, en Desvincular o Quitar (según el tipo de política).

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Iam User Group Membership Check

Nombre de categoría en la API: IAM_USER_GROUP_MEMBERSHIP_CHECK

Los usuarios de IAM siempre deben ser parte de un grupo de IAM para cumplir con las prácticas recomendadas de seguridad de IAM.

Cuando se agregan usuarios a un grupo, es posible compartir políticas entre los tipos de usuarios.

Recomendación: Verifica si los usuarios de IAM son miembros de al menos un grupo de IAM

Para solucionar este problema, completa los siguientes 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]
}

AWS console

Cuando usas la consola de administración de AWS para borrar un usuario de IAM, IAM borra automáticamente la siguiente información por ti:

1. El usuario
2. Cualquier membresía de grupo de usuarios, es decir, el usuario se quita de cualquier grupo de usuarios de IAM del que era miembro
3. Cualquier contraseña asociada con el usuario
4. Cualquier clave de acceso que pertenezca al usuario
5. Todas las políticas intercaladas incorporadas en el usuario (no se ven afectadas las políticas que se aplican a un usuario a través de los permisos de grupo de usuarios)

Para borrar un usuario de IAM, sigue estos pasos:

1. Accede a la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
2. En el panel de navegación, elige Usuarios y, luego, selecciona la casilla de verificación junto al nombre del usuario que deseas borrar.
3. En la parte superior de la página, elige Borrar.
4. En el cuadro de diálogo de confirmación, ingresa el nombre de usuario en el campo de entrada de texto para confirmar la eliminación del usuario.
5. Selecciona Borrar.

Para agregar un usuario a un grupo de usuarios de IAM, sigue estos pasos:

1. Accede a la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.
2. En el panel de navegación, elige Grupos de usuarios y, luego, elige el nombre del grupo.
3. Elige la pestaña Usuarios y, luego, Agregar usuarios. Selecciona la casilla de verificación junto a los usuarios que deseas agregar.
4. Elige Agregar usuarios.

CLI de AWS

A diferencia de la Consola de administración de Amazon Web Services, cuando borras un usuario de forma programática, debes borrar los elementos adjuntos al usuario de forma manual, o bien la eliminación fallará.

Antes de intentar borrar un usuario, quita los siguientes elementos:

1. Contraseña ( DeleteLoginProfile )
2. Claves de acceso ( DeleteAccessKey )
3. Certificado de firma ( DeleteSigningCertificate )
4. Clave pública SSH ( DeleteSSHPublicKey )
5. Credenciales de Git ( DeleteServiceSpecificCredential )
6. Dispositivo de autenticación de varios factores (MFA) ( DeactivateMFADevice , DeleteVirtualMFADevice )
7. Políticas intercaladas ( DeleteUserPolicy )
8. Políticas administradas adjuntas ( DetachUserPolicy )
9. Membresías de grupo ( RemoveUserFromGroup )

Para borrar un usuario, después de borrar todos los elementos adjuntos a él, sigue estos pasos:

aws iam delete-user \
  --user-name "test-user"

Para agregar un usuario de IAM a un grupo de IAM, sigue estos pasos:

aws iam add-user-to-group \
  --group-name "test-group"
  --user-name "test-user"

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Iam User Mfa Enabled

Nombre de categoría en la API: IAM_USER_MFA_ENABLED

La autenticación de varios factores (MFA) es una práctica recomendada que agrega una capa extra de protección a los nombres de usuario y las contraseñas. Con la MFA, cuando un usuario accede a la Consola de administración de AWS, debe proporcionar un código de autenticación con límite de tiempo que le proporciona un dispositivo físico o virtual registrado.

Recomendación: Comprueba si los usuarios de IAM de AWS tienen habilitada la autenticación de varios factores (MFA)

Para solucionar este problema, completa los siguientes pasos:

Terraform

En el caso de Terraform, existen algunas opciones para solucionar la ausencia de dispositivos de MFA. Es probable que ya tengas una estructura adecuada para organizar a tus usuarios en grupos y políticas restrictivas.

En el siguiente ejemplo, se muestra cómo hacer lo siguiente:

1. Crear usuarios
2. Crea perfiles de acceso de los usuarios con una clave pública de PGP.
3. Crea un grupo y una política de grupo que permitan la autoadministración del perfil de IAM.
4. Adjunta usuarios al grupo.
5. Crea dispositivos de MFA virtuales para los usuarios.
6. Proporciona a cada usuario el código QR y la contraseña de salida.

variable "users" {
  type = set(string)
  default = [
    "[e-mail]",
    "[e-mail]"
  ]
}

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 {"[e-mail]": <PGPEncryptedPassword>, "[e-mail]": <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 {"[e-mail]": <QRCode>, "[e-mail]": <QRCode>}
  value = { for k, v in aws_iam_virtual_mfa_device.test_mfa : k => v.qr_code_png }
}

AWS console

Para habilitar la MFA en las cuentas de usuario que tengan acceso a la consola de AWS, consulta Cómo habilitar un dispositivo de autenticación de varios factores (MFA) virtual (consola) en la documentación de AWS.

CLI de AWS

Crea un dispositivo de MFA

aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name "[e-mail]" \
  --outfile ./QRCode.png \
  --bootstrap-method QRCodePNG

Habilita el dispositivo de MFA para un usuario existente

aws iam enable-mfa-device \
  --user-name "[e-mail]" \
  --serial-number "arn:aws:iam::123456976749:mfa/[e-mail]" \
  --authentication-code1 123456 \
  --authentication-code2 654321

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Iam User Unused Credentials Check

Nombre de categoría en la API: IAM_USER_UNUSED_CREDENTIALS_CHECK

De esta forma, se verifican las contraseñas de IAM o las claves de acceso activas que no se hayan usado en los últimos 90 días.

Se recomienda quitar, desactivar o rotar todas las credenciales que no se hayan usado durante 90 días o más. Esto reduce la ventana de oportunidad para que se usen las credenciales asociadas a una cuenta comprometida o abandonada.

Recomendación: Verifica que todos los usuarios de IAM de AWS tengan contraseñas o claves de acceso activas que no se hayan usado en maxCredentialUsageAge días (valor predeterminado: 90)

Para solucionar este problema, completa los siguientes pasos:

Terraform

Para quitar las claves de acceso vencidas creadas a través de Terraform, quita el recurso aws_iam_access_key de tu módulo y aplica el cambio.

Para restablecer la contraseña de acceso de un usuario de IAM, usa -replace cuando ejecutes terraform apply.

Supongamos que el siguiente es el perfil de acceso del usuario

resource "aws_iam_user" "example" {
  name          = "[e-mail]"
  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 restablecer la contraseña del perfil de acceso del usuario.

terraform apply -replace="aws_iam_user_login_profile.example"

AWS console

Para inhabilitar las credenciales de las cuentas inactivas, sigue estos pasos:

1. Abre la consola de IAM en https://console.aws.amazon.com/iam/.
2. Elige Usuarios.
3. Elige el nombre del usuario que tiene credenciales de más de 90 días o que se usaron por última vez.
4. Elige Credenciales de seguridad.
5. Para cada credencial de acceso y clave de acceso que no se haya usado durante al menos 90 días, elige Hacer inactivo.

Para solicitar una contraseña nueva a los usuarios de la consola en el próximo acceso, haz lo siguiente:

1. Abre la consola de IAM en https://console.aws.amazon.com/iam/.
2. Elige Usuarios.
3. Elige el nombre del usuario que tiene credenciales de más de 90 días o que se usaron por última vez.
4. Elige Credenciales de seguridad.
5. En Credenciales de acceso y contraseña de la consola, elige Administrar.
6. Establece una contraseña nueva (autogenerada o personalizada).
7. Marca la casilla para solicitar el restablecimiento de la contraseña.
8. Elige Aplicar.

CLI de AWS

Cómo inhabilitar las claves de acceso

aws iam update-access-key \
  --access-key-id <value> \
  --status "Inactive"

Para borrar las claves de acceso, haz lo siguiente:

aws iam delete-access-key \
  --access-key-id <value>

Cómo restablecer la contraseña del perfil de acceso de un usuario

aws iam update-login-profile \
  --user-name "[e-mail]" \
  --password <temporary_password> \
  --password-reset-required

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Kms Cmk Not Scheduled For Deletion

Nombre de categoría en la API: KMS_CMK_NOT_SCHEDULED_FOR_DELETION

Este control verifica si las claves de KMS están programadas para su eliminación. El control falla si se programó la eliminación de una clave de KMS.

Las claves de KMS no se pueden recuperar una vez que se borran. Los datos encriptados con una clave de KMS tampoco se pueden recuperar de forma permanente si se borra la clave de KMS. Si se encriptaron datos significativos con una clave de KMS programada para su eliminación, considera desencriptarlos o volver a encriptarlos con una clave de KMS nueva, a menos que realices una eliminación criptográfica de forma intencional.

Cuando se programa la eliminación de una clave de KMS, se aplica un período de espera obligatorio para permitir que se revierta la eliminación, si se programó por error. El período 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 período de espera, se puede cancelar la eliminación programada y no se borrará la clave de KMS.

Para obtener información adicional sobre la eliminación de claves de KMS, consulta Cómo borrar claves de KMS en la Guía para desarrolladores de AWS Key Management Service.

Recomendación: Verifica que ninguna clave de CMK esté programada para su eliminación

Para cancelar una eliminación de claves de KMS programada, consulta Cómo cancelar la eliminación de claves en Programación y cancelación de la eliminación de claves (consola) en la Guía para desarrolladores de AWS Key Management Service.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Lambda Concurrency Check

Nombre de categoría en la API: LAMBDA_CONCURRENCY_CHECK

Verifica si la función Lambda está configurada con un límite de ejecución simultánea a nivel de la función. La regla es NON_COMPLIANT si la función Lambda no está configurada con un límite de ejecución simultánea a nivel de la función.

Recomendación: Comprueba si las funciones Lambda están configuradas con un límite de ejecución simultáneo a nivel del rol

Para configurar un límite de ejecución simultánea a nivel de la función, consulta Configura la simultaneidad reservada en la documentación de AWS Lambda.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Lambda Dlq Check

Nombre de categoría en la API: LAMBDA_DLQ_CHECK

Verifica si una función de Lambda está configurada con una fila de mensajes no entregados. La regla es NON_COMPLIANT si la función Lambda no está configurada con una cola de mensajes no entregados.

Recomendación: Comprueba si las funciones Lambda están configuradas con una cola de mensajes no entregados

Para actualizar las funciones de Lambda para usar las DLQ, consulta Colas de mensajes no entregados en la documentación de AWS.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Lambda Function Public Access Prohibited

Nombre de categoría en la API: LAMBDA_FUNCTION_PUBLIC_ACCESS_PROHIBITED

Las prácticas recomendadas de AWS recomiendan que la función de Lambda no se exponga públicamente. Esta política verifica 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: Verifica si la política adjunta a la función Lambda prohíbe el acceso público

Para solucionar este problema, completa los siguientes pasos:

Terraform

En el siguiente ejemplo, se muestra cómo usar Terraform para aprovisionar un rol de IAM que restrinja el acceso a una función de Lambda y 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"

}

AWS console

Si una función Lambda no pasa este control, significa que la declaración de política basada en recursos de la función Lambda permite el acceso público.

Para solucionar el problema, debes actualizar la política para quitar los permisos o agregar la condición AWS:SourceAccount. Solo puedes actualizar la política basada en recursos desde la API de Lambda.

En las siguientes instrucciones, se usa la consola para revisar la política y la interfaz de línea de comandos de AWS para quitar los permisos.

Para ver la política basada en recursos de una función de Lambda

1. Abre la consola de AWS Lambda en https://console.aws.amazon.com/lambda/.
2. En el panel de navegación, elige Funciones.
3. Elige la función.
4. 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.
5. Examina la política basada en recursos.
6. Identifica la declaración de política que tiene valores de 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 AWS CLI.

Anota el valor del ID de la sentencia (Sid) de la sentencia que quieres quitar.

CLI de AWS

Para usar la CLI y quitar permisos de una función de Lambda, emite el comando remove-permission de la siguiente manera.

aws lambda remove-permission \
--function-name <value> \
--statement-id <value>

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Lambda Inside Vpc

Nombre de categoría en la API: LAMBDA_INSIDE_VPC

Verifica si una función de Lambda se encuentra en una VPC. Es posible que veas resultados con errores para los recursos de Lambda@Edge.

No evalúa la configuración de enrutamiento de subredes de la VPC para determinar la accesibilidad pública.

Recomendación: Comprueba si las funciones Lambda existen en una VPC

Para solucionar este problema, completa los siguientes pasos:

AWS console

Para configurar una función que se conecte a subredes privadas en una nube privada virtual (VPC) de tu cuenta, haz lo siguiente:

1. Abre la consola de AWS Lambda en https://console.aws.amazon.com/lambda/.
2. Navega a Funciones y, luego, selecciona tu función de Lambda.
3. Desplázate hasta Red y, luego, selecciona una VPC con los requisitos de conectividad de la función.
4. Para ejecutar tus funciones en el modo de alta disponibilidad, Security Hub recomienda que elijas al menos dos subredes.
5. Elige al menos un grupo de seguridad que tenga los requisitos de conectividad de la función.
6. Selecciona Guardar.

Para obtener más información, consulta la sección sobre cómo configurar una función de Lambda para acceder a recursos en una VPC en la Guía para desarrolladores de AWS Lambda.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Mfa Delete Enabled S3 Buckets

Nombre de categoría en la API: MFA_DELETE_ENABLED_S3_BUCKETS

Una vez que se habilita la eliminación de MFA en tu bucket de S3 sensible y clasificado, el usuario debe 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 de MFA con la consola de administración de AWS. Debes usar la API o AWS CLI.
- Debes usar tu cuenta "raíz" para habilitar la eliminación de MFA en los buckets de S3.

Desde la línea de comandos:

1. 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”

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Mfa Enabled Root User Account

Nombre de categoría en la API: MFA_ENABLED_ROOT_USER_ACCOUNT

La cuenta de usuario "root" es el usuario con más privilegios en una cuenta de AWS. La autenticación de varios factores (MFA) agrega una capa adicional de protección a un nombre de usuario y una contraseña. Con la MFA habilitada, cuando un usuario acceda a un sitio web de AWS, se le solicitará 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 para cuentas "root", se recomienda que el dispositivo que se use NO sea personal, sino un dispositivo móvil dedicado (tablet o teléfono) que se administre para que se mantenga cargado y protegido independientemente de cualquier dispositivo personal individual. ("MFA virtual no personal"). Esto reduce los riesgos de perder el acceso a la MFA debido a la pérdida o el intercambio 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 establecer la MFA para la cuenta de usuario "raíz":

1. Accede a la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam/.

Nota: Para administrar los dispositivos de MFA de la cuenta de AWS "root", debes usar las credenciales de la cuenta "root" para acceder a AWS. No puedes administrar los dispositivos de MFA de la cuenta "root" con otras credenciales.

2. Elige Dashboard y , en Security Status , expande Activate MFA en tu cuenta raíz.
3. Elegir Activate MFA
4. En el asistente, elige el dispositivo A virtual MFA y, luego, Next Step .
5. IAM genera y muestra información de configuración para el dispositivo de 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 está disponible para la entrada manual en dispositivos que no admiten códigos QR.
6. Abre tu aplicación de MFA virtual. (Para obtener una lista de las apps que puedes usar para alojar dispositivos de MFA virtuales, 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 nueva (un nuevo dispositivo de MFA virtual).
7. Determina si la app de la MFA admite códigos QR y, luego, haz una de las siguientes acciones:

• Usa la app para escanear el código QR. Por ejemplo, puedes elegir el ícono de la cámara o una opción similar a Scan code y, luego, usar la cámara del dispositivo para escanear el código.
• En el asistente para administrar dispositivos de MFA, elige Mostrar clave secreta para la configuración manual y, luego, escribe la clave de configuración secreta en tu aplicación de MFA.

Cuando termines, el dispositivo de MFA virtual comenzará a generar contraseñas de un solo uso.

En el cuadro Código de autenticación 1 del asistente para administrar dispositivos de MFA, escribe la contraseña de un solo uso que aparece actualmente en el dispositivo virtual de MFA. Espera hasta 30 segundos para que el dispositivo genere una nueva contraseña de un solo uso. Luego, escribe la segunda contraseña de un solo uso en el cuadro Código de autenticación 2. Elige Asignar MFA virtual.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Multi Factor Authentication Mfa Enabled All Iam Users Console

Nombre de categoría en la API: MULTI_FACTOR_AUTHENTICATION_MFA_ENABLED_ALL_IAM_USERS_CONSOLE

La autenticación de varios factores (MFA) agrega una capa adicional de garantía de autenticación más allá de las credenciales tradicionales. Con la MFA habilitada, cuando un usuario acceda a la consola de AWS, se le solicitará 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 para todas las cuentas que tengan una contraseña de la consola.

Recomendación: Asegúrate de que la autenticación de varios factores (MFA) esté habilitada para todos los usuarios de IAM que tengan una contraseña de la consola

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de administración de AWS y abre la consola de IAM en "https://console.aws.amazon.com/iam/".
2. En el panel izquierdo, selecciona Users.
3. En la lista User Name, elige el nombre del usuario de MFA de destino.
4. Elige la pestaña Security Credentials y, luego, Manage MFA Device.
5. En Manage MFA Device wizard, elige el dispositivo Virtual MFA y, luego, Continue.

IAM genera y muestra información de configuración para el dispositivo de 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 está disponible para la entrada manual en dispositivos que no admiten códigos QR.

6. Abre tu aplicación de MFA virtual. (Para obtener una lista de las apps que puedes usar para alojar dispositivos de MFA virtuales, 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 nueva (un nuevo dispositivo de MFA virtual).
7. Determina si la app de la MFA admite códigos QR y, luego, haz una de las siguientes acciones:

• Usa la app para escanear el código QR. Por ejemplo, puedes elegir el ícono de la cámara o una opción similar a Scan code y, luego, usar la cámara del dispositivo para escanear el código.
• En el asistente para administrar dispositivos de MFA, elige Mostrar clave secreta para la configuración manual y, luego, escribe la clave de configuración secreta en tu aplicación de MFA.

Cuando termines, el dispositivo de MFA virtual comenzará a generar contraseñas de un solo uso.

8. En Manage MFA Device wizard, en MFA Code 1 box, escribe el one-time password que aparece actualmente en el dispositivo de MFA virtual. Espera hasta 30 segundos para que el dispositivo genere una nueva contraseña de un solo uso. Luego, escribe el segundo one-time password en MFA Code 2 box.

9. Haz clic en Assign MFA.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

No Network Acls Allow Ingress 0 0 0 0 Remote Server Administration

Nombre de 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 a la 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 NACL permita el acceso de entrada sin restricciones a los puertos de administración del servidor remoto, como SSH al puerto 22 y RDP al puerto 3389, con los protocolos TDP (6), UDP (17) o TODOS (-1).

Recomendación: Asegúrate de que ninguna LCA de red permita la entrada de 0.0.0.0/0 a los puertos de administración del servidor remoto

Para solucionar este problema, completa los siguientes pasos:

AWS console

Realiza lo siguiente:
1. Accede a la Consola de administración de AWS en https://console.aws.amazon.com/vpc/home
2. En el panel izquierdo, haz clic en Network ACLs
. 3. Para cada LCA de red que se corrija, haz lo siguiente:
- Selecciona la LCA de red
- Haz clic en la pestaña Inbound Rules
- Haz clic en Edit inbound rules
- A) Actualiza el campo Fuente a un rango que no sea 0.0.0.0/0 o, B) haz clic en Delete para quitar la regla entrante ofensiva
- Haz clic en Save

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

No Root User Account Access Key Exists

Nombre de categoría en la API: NO_ROOT_USER_ACCOUNT_ACCESS_KEY_EXISTS

La cuenta de usuario "root" es el usuario con más privilegios en una cuenta de AWS. Las claves de acceso de AWS proporcionan acceso programático a una cuenta de AWS determinada. Se recomienda que se borren todas las claves de acceso asociadas con la cuenta de usuario “raíz”.

Recomendación: Asegúrate de que no exista una clave de acceso a una cuenta de usuario "raíz"

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de administración de AWS como "root" y abre la consola de IAM en https://console.aws.amazon.com/iam/.
2. Haz clic en <root_account> en la parte superior derecha y selecciona My Security Credentials en la lista desplegable.
3. En la pantalla emergente, haz clic en Continue to Security Credentials.
4. Haz clic en Access Keys (ID de clave de acceso y clave de acceso secreta).
5. En la columna Status (si hay alguna clave activa).
6. Haz clic en Delete (Nota: Las claves borradas no se pueden recuperar).

Nota: Si bien se puede inhabilitar una clave, esta seguirá apareciendo en el comando de la CLI del procedimiento de auditoría y puede provocar que una clave se marque falsamente como no conforme.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

No Security Groups Allow Ingress 0 0 0 0 Remote Server Administration

Nombre de 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 del servidor remoto, como SSH al puerto 22 y RDP al puerto 3389, con los protocolos TDP (6), UDP (17) o TODOS (-1).

Recomendación: Asegúrate de que ningún grupo de seguridad permita la entrada de 0.0.0.0/0 a los puertos de administración del servidor remoto

Realiza lo siguiente para implementar el estado prescrito:

1. Accede a la Consola de administración de AWS en https://console.aws.amazon.com/vpc/home.
2. En el panel izquierdo, haz clic en Security Groups.
3. Para cada grupo de seguridad, haz lo siguiente:
4. Selecciona el grupo de seguridad
5. Haz clic en la pestaña Inbound Rules.
6. Haz clic en el botón Edit inbound rules.
7. Identifica las reglas que se editarán o quitarán
8. A) Actualiza el campo Origen a un rango que no sea 0.0.0.0/0 o B) Haz clic en Delete para quitar la regla entrante ofensiva.
9. Haz clic en Save rules.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

No Security Groups Allow Ingress 0 Remote Server Administration

Nombre de categoría en la API: NO_SECURITY_GROUPS_ALLOW_INGRESS_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 del servidor remoto, como SSH al puerto 22 y RDP al puerto 3389.

Recomendación: Asegúrate de que ningún grupo de seguridad permita la entrada de ::/0 a los puertos de administración del servidor remoto

Realiza lo siguiente para implementar el estado prescrito:

1. Accede a la Consola de administración de AWS en https://console.aws.amazon.com/vpc/home.
2. En el panel izquierdo, haz clic en Security Groups.
3. Para cada grupo de seguridad, haz lo siguiente:
4. Selecciona el grupo de seguridad
5. Haz clic en la pestaña Inbound Rules.
6. Haz clic en el botón Edit inbound rules.
7. Identifica las reglas que se editarán o quitarán
8. A) Actualiza el campo Fuente a un rango que no sea ::/0 o B) Haz clic en Delete para quitar la regla entrante ofensiva.
9. Haz clic en Save rules.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

One Active Access Key Available Any Single Iam User

Nombre de categoría en la API: ONE_ACTIVE_ACCESS_KEY_AVAILABLE_ANY_SINGLE_IAM_USER

Las claves de acceso son credenciales a largo plazo para un usuario de IAM o el usuario "root" de la cuenta de AWS. Puedes usar claves de acceso para firmar solicitudes programáticas a la CLI de AWS o a la API de AWS (directamente o con el SDK de AWS).

Recomendación: Asegúrate de que solo haya disponible una clave de acceso activa para cada usuario de IAM

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de administración de AWS y navega al panel de IAM en https://console.aws.amazon.com/iam/.
2. En el panel de navegación izquierdo, elige Users.
3. Haz clic en el nombre de usuario de IAM que quieres examinar.
4. En la página de configuración de usuarios de IAM, selecciona la pestaña Security Credentials.
5. En la sección Access Keys, elige una clave de acceso que tenga menos de 90 días de antigüedad. Esta debe ser la única clave activa que use 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 funcione.
6. En la misma sección Access Keys, identifica las claves de acceso que no están en funcionamiento (excepto la elegida) y haz clic en el vínculo Make Inactive para desactivarlas.
7. Si recibes el cuadro de confirmación Change Key Status, haz clic en Deactivate para desactivar la clave seleccionada.
8. Repite los pasos del 3 al 7 para cada usuario de IAM en tu cuenta de AWS.

CLI de AWS

1. Con la información del usuario y la clave de acceso de IAM proporcionada en Audit CLI, elige una clave de acceso que tenga menos de 90 días. Esta debe ser la única clave activa que use 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 funcione.

2. Ejecuta el siguiente comando update-access-key con el nombre de usuario de IAM y los IDs de clave de acceso no operativos 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 muestra ningún resultado:

aws iam update-access-key --access-key-id <access-key-id> --status Inactive --user-name <user-name>

3. Para confirmar que el par de claves de acceso seleccionado se 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 exponer los metadatos de cada clave de acceso asociada con el usuario de IAM. Si los pares de claves no operativos Status se establecen en Inactive, la clave se desactivó correctamente y la configuración de acceso de los usuarios de IAM ahora cumple con esta recomendación.

4. Repite los pasos 1 a 3 para cada usuario de IAM en tu cuenta de AWS.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Public Access Given Rds Instance

Nombre de categoría en la API: PUBLIC_ACCESS_GIVEN_RDS_INSTANCE

Asegúrate de que las instancias de bases de datos de RDS aprovisionadas en tu 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 de acceso público, debes inhabilitar la marca de acceso público de la base de datos y actualizar el grupo de seguridad de la VPC asociado con la instancia.

Recomendación: Asegúrate de que no se otorgue acceso público a la instancia de RDS

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de administración de AWS y navega al panel de RDS en https://console.aws.amazon.com/rds/.
2. En el panel de navegación, en el panel RDS, haz clic en Databases.
3. Selecciona la instancia de RDS que deseas actualizar.
4. Haz clic en Modify en el menú superior del panel.
5. En el panel Modificar instancia de la base de datos, en la sección Connectivity, haz clic en Additional connectivity configuration y actualiza el valor de Publicly Accessible a No se puede acceder de forma pública para restringir el acceso público. Sigue los pasos que se indican a continuación para actualizar la configuración de subredes:
   - Selecciona la pestaña Connectivity and security y haz clic en el valor del atributo de VPC dentro de la sección Networking.
   - Selecciona la pestaña Details en el panel inferior del panel de VPC y haz clic en el valor del atributo de configuración de la tabla de enrutamiento.
   - En la página de detalles de la tabla de rutas, selecciona la pestaña Rutas en el panel inferior del panel y haz clic en Edit routes.
   - En la página Editar rutas, actualiza el destino de destino, que está configurado en igw-xxxxx, y haz clic en las rutas Save.
6. En el panel Modificar instancia de base de datos, haz clic en Continue y, en la sección Programación de modificaciones, realiza una de las siguientes acciones según tus requisitos:
   - Selecciona Aplicar durante el próximo período de mantenimiento programado para aplicar los cambios automáticamente durante el próximo período de mantenimiento programado.
   - Selecciona Aplicar de inmediato para aplicar los cambios de inmediato. Con esta opción, las modificaciones pendientes se aplicarán de forma asíncrona lo antes posible, independientemente de la configuración del período de mantenimiento de esta instancia de base de datos de RDS. Ten en cuenta que también se aplican los cambios disponibles en la fila de modificaciones pendientes. Si alguna de las modificaciones pendientes requiere tiempo de inactividad, elegir esta opción puede provocar un tiempo de inactividad inesperado de la aplicación.
7. Repite los pasos del 3 al 6 para cada instancia de RDS disponible en la región actual.
8. Cambia la región de AWS en la barra de navegación para repetir el proceso en otras regiones.

CLI de AWS

1. Ejecuta el comando describe-db-instances para obtener una lista de 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'

2. El resultado del comando debe mostrar cada identificador de instancia de la base de datos.
3. Ejecuta el comando modify-db-instance para modificar la configuración de la instancia de RDS seleccionada. Luego, usa el siguiente comando para inhabilitar la marca Publicly Accessible para 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, haz lo siguiente:

aws rds modify-db-instance --region <region-name> --db-instance-identifier <db-name> --no-publicly-accessible --apply-immediately

4. El resultado del comando debería revelar la configuración de PubliclyAccessible en los valores pendientes y debería aplicarse a la hora especificada.
5. Actualmente, no se admite la actualización del destino de la puerta de enlace de Internet a través de AWS CLI. Para actualizar la información sobre la puerta de enlace de Internet, usa el procedimiento de la consola de AWS.
6. Repite los pasos del 1 al 5 para cada instancia de RDS aprovisionada en la región actual.
7. Cambia la región de AWS con el filtro --region para repetir el proceso en otras regiones.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Rds Enhanced Monitoring Enabled

Nombre de categoría en la API: RDS_ENHANCED_MONITORING_ENABLED

La supervisió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 detalles, consulta Supervisa las métricas del SO con la supervisión mejorada.

Recomendación: Comprueba si la supervisión mejorada está habilitada para todas las instancias de la base de datos de RDS

Para solucionar este problema, completa los siguientes pasos:

Terraform

Para corregir este control, habilita la supervisión mejorada en tus instancias de RDS de la siguiente manera:

Crea un rol de IAM 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 administrada de AWS para la supervisió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 supervisión y un ARN de rol de supervisión para la instancia de RDS infractora para habilitar la supervisió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
}

AWS console

Puedes activar el monitoreo mejorado cuando creas una instancia de DB, un clúster de DB multi-AZ o una réplica de lectura, o cuando modificas una instancia de DB o un clúster de DB multi-AZ. Si modificas una instancia de la base de datos para activar la supervisión mejorada, no es necesario que reinicies la instancia para que se aplique el cambio.

Puedes activar la supervisión mejorada en la consola de RDS cuando realices una de las siguientes acciones en la página Bases de datos:

• Crear una instancia de base de datos o un clúster de base de datos multi-AZ: Elige Crear base de datos.
• Crear una réplica de lectura: Elige Acciones y, luego, Crear réplica de lectura.
• Modificar una instancia de base de datos o un clúster de base de datos multi-AZ: Elige Modificar.

Cómo activar o desactivar la supervisión mejorada en la consola de RDS

1. Desplázate hasta Configuración adicional.
2. En Supervisión, elige Habilitar la supervisión mejorada para tu instancia de base de datos o réplica de lectura. Para desactivar la supervisión mejorada, elige Inhabilitar la supervisión mejorada.
3. Establece la propiedad Rol de supervisión en el rol de IAM que creaste para permitir que Amazon RDS se comunique con Amazon CloudWatch Logs por ti, o bien elige Predeterminado para que RDS cree un rol llamado rds-monitoring-role.
4. Establece la propiedad Granularidad en el intervalo, en segundos, entre los puntos en los que se recopilan las métricas para tu instancia de la base de datos o la réplica de lectura. La propiedad Granularidad se puede establecer en uno de los siguientes valores: 1, 5, 10, 15, 30 o 60. La consola de RDS se actualiza cada 5 segundos como máximo. Si configuras el nivel de detalle en 1 segundo en la consola de RDS, seguirás viendo las métricas actualizadas solo cada 5 segundos. Puedes recuperar actualizaciones de métricas de 1 segundo con los registros de CloudWatch.

CLI de AWS

Crea el rol de IAM 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 supervisión mejorada. Para ello, configura --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"

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Rds Instance Deletion Protection Enabled

Nombre de 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 la base 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 puede borrar una instancia de la base de datos de RDS. Para que una solicitud de eliminación se realice correctamente, se debe inhabilitar la protección contra la eliminación.

Recomendación: Comprueba si todas las instancias de RDS tienen habilitada la protección contra la eliminación

Para solucionar este problema, completa los siguientes pasos:

Terraform

Para solucionar este problema, establece deletion_protection en true en el recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  deletion_protection = true
}

AWS console

Para habilitar la protección contra la eliminación de una instancia de la base de datos de RDS

1. Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
2. En el panel de navegación, elige Bases de datos y, luego, la instancia de la base de datos que deseas modificar.
3. Elige Modificar.
4. En Protección contra la eliminación, elige Habilitar protección contra la eliminación.
5. Selecciona Continuar.
6. En Scheduling of modifications, elige cuándo aplicar las modificaciones. Las opciones son Aplicar durante el próximo período de mantenimiento programado o Aplicar de inmediato.
7. Elige Modificar la instancia de base de datos.

CLI de AWS

Lo mismo se aplica a la CLI de AWS. Establece --deletion-protection como se indica a continuación.

aws rds modify-db-instance \
  --db-instance-identifier = "test-rds" \
  --deletion-protection

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Rds In Backup Plan

Nombre de categoría en la API: RDS_IN_BACKUP_PLAN

Esta verificación evalúa si las instancias de la base 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 copia de seguridad completamente administrado que centraliza y automatiza la creación de copias de seguridad de los datos en los servicios de AWS. Con AWS Backup, puedes crear políticas de copia de seguridad llamadas planes de copia de seguridad. Puedes usar estos planes para definir tus requisitos de copia de seguridad, como la frecuencia con la que crear copias de seguridad de tus datos y por cuánto tiempo retenerlas. Si incluyes instancias de base de datos de RDS en un plan de copias de seguridad, podrás proteger tus datos contra la pérdida o eliminación no deseadas.

Recomendación: Las instancias de base de datos de RDS deben contar con un plan de copias de seguridad

Para solucionar este problema, completa los siguientes pasos:

Terraform

Para solucionar este control, establece backup_retention_period en un valor mayor que 7 en el recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other Configuration ...
  backup_retention_period = 7
}

AWS console

Cómo habilitar las copias de seguridad automáticas de inmediato

1. Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
2. En el panel de navegación, elige Bases de datos y, luego, la instancia de la base de datos que deseas modificar.
3. Elige Modificar para abrir la página Modificar instancia de base de datos.
4. En Período de retención de copias de seguridad, elige un valor positivo distinto de cero, por ejemplo, 30 días, y, luego, selecciona Continuar.
5. Selecciona la sección Programación de modificaciones y elige cuándo aplicar las modificaciones: puedes elegir Aplicar durante el próximo período de mantenimiento programado o Aplicar de inmediato.
6. Luego, en la página de confirmación, elige Modificar instancia de base de datos para guardar los cambios y habilitar las copias de seguridad automáticas.

CLI de AWS

Lo mismo se aplica a la CLI de AWS. Para habilitar las copias de seguridad automáticas, cambia backup-retention-period a un valor superior a 0 (predeterminado).

aws rds modify-db-instance --db-instance-identifier "test-rds" --backup-retention-period 7

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Rds Logging Enabled

Nombre de categoría en la API: RDS_LOGGING_ENABLED

Esto verifica 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 relevantes. El registro de la base de datos proporciona registros detallados de las solicitudes que se realizan a RDS. Los registros de la base de datos pueden ayudar con las auditorías de seguridad y acceso, y pueden ayudar a diagnosticar problemas de disponibilidad.

Recomendación: Comprueba si los registros exportados están habilitados para todas las instancias de la base de datos de RDS

Para solucionar este problema, completa los siguientes 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"
  }
}

Para MariaDB, además, crea un grupo de opciones personalizado y establece 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"
    }
  }
}

AWS console

Cómo crear un grupo de parámetros de base de datos personalizado

1. Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
2. En el panel de navegación, elige Grupos de parámetros.
3. Elige Crear grupo de parámetros.
4. En la lista Familia de grupos de parámetros, elige una familia de grupos de parámetros de la base de datos.
5. En la lista Tipo, elige Grupo de parámetros de la base de datos.
6. En Nombre del grupo, ingresa el nombre del nuevo grupo de parámetros de la base de datos.
7. En Descripción, ingresa una descripción para el nuevo grupo de parámetros de la base de datos.
8. Elige Crear.

Para crear un nuevo grupo de opciones para el registro de MariaDB con la consola

1. Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
2. En el panel de navegación, elige Grupos de opciones.
3. Elige Crear grupo.
4. En la ventana Crear grupo de opciones, proporciona la siguiente información:
   * Nombre: Debe ser único en tu cuenta de AWS. Solo letras, dígitos y guiones.
   * Descripción: Solo se usa con fines de visualización.
   * Motor: Selecciona tu motor de BD.
   * Versión principal del motor: Selecciona la versión principal del motor de la base de datos.
5. Elige Crear.
6. Elige el nombre del grupo de opciones que acabas de crear.
7. Elige la opción Agregar.
8. Elige MARIADB_AUDIT_PLUGIN en la lista de nombres de opciones.
9. Establece SERVER_AUDIT_EVENTS en CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML, QUERY_DCL.
10. Elige la opción Agregar.

Para publicar registros de la base de datos de SQL Server, Oracle o PostgreSQL en los registros de CloudWatch desde la consola de administración de AWS

1. Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
2. En el panel de navegación, elige Bases de datos.
3. Elige la instancia de la base de datos que deseas modificar.
4. Elige Modificar.
5. En Exportaciones de registros, elige todos los archivos de registro que deseas comenzar a publicar en los registros de CloudWatch.
6. Las exportaciones de registros solo están disponibles para las versiones de motor de base de datos que admiten la publicación en los registros de CloudWatch.
7. Selecciona Continuar. Luego, en la página de resumen, elige Modificar instancia de DB.

Para aplicar un nuevo grupo de parámetros o un grupo de opciones de la base de datos a una instancia de la base de datos de RDS

1. Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
2. En el panel de navegación, elige Bases de datos.
3. Elige la instancia de la base de datos que deseas modificar.
4. Elige Modificar.
5. En Opciones de la base de datos, cambia el grupo de parámetros y el grupo de opciones de la base de datos según sea necesario.
6. Cuando termines de hacer los cambios, elige Continuar. Revisa el resumen de las modificaciones.
7. Elige Modificar instancia de base de datos para guardar los cambios.

CLI de AWS

Recupera las familias de motores y elige la que coincida con el motor y la versión de la instancia de la 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 MySQL5.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 agregar 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

Modifica la instancia de la 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, para 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"
    }
  ]
}

Agrega 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

Modifica la instancia de MariaDB para asociar el grupo de opciones a la instancia de la base de datos.

aws rds modify-db-instance \
  --db-instance-identifier "rds-test-mariadb" \
  --option-group-name "rds-mariadb-option-group"

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Rds Multi Az Support

Nombre de categoría en la API: RDS_MULTI_AZ_SUPPORT

Las instancias de la base de datos de RDS deben configurarse para varias zonas de disponibilidad (AZ). Esto garantiza la disponibilidad de los datos almacenados. Las implementaciones de varias zonas de disponibilidad permiten la conmutación por error automática si hay un problema con la disponibilidad de la zona de disponibilidad y durante el mantenimiento normal de RDS.

Recomendación: Comprueba si la alta disponibilidad está habilitada para todas las instancias de la base de datos de RDS

Para solucionar este problema, completa los siguientes pasos:

Terraform

Para solucionar este control, establece multi_az en verdadero en el recurso aws_db_instance.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  multi_az                = true
}

AWS console

Cómo habilitar varias zonas de disponibilidad para una instancia de la base de datos

1. Abre la consola de Amazon RDS en https://console.aws.amazon.com/rds/.
2. En el panel de navegación, elige Bases de datos y, luego, la instancia de la base de datos que deseas modificar.
3. Elige Modificar. Aparecerá la página Modificar instancia de base de datos.
4. En Especificaciones de la instancia, establece la implementación de varios AZ en Sí.
5. Elige Continuar y, luego, revisa el resumen de las modificaciones.
6. (Opcional) Elige Aplicar de inmediato para aplicar los cambios de inmediato. En algunos casos, elegir esta opción puede provocar una interrupción. Para obtener más información, consulta el artículo sobre cómo usar la configuración Aplicar de inmediato en la Guía del usuario de Amazon RDS.
7. 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 se aplica a AWS CLI. Proporciona la opción --multi-az para habilitar la compatibilidad con varios Az.

modify-db-instance
  --db-instance-identifier "test-rds" \
  --multi-az

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Redshift Cluster Configuration Check

Nombre de categoría en la API: REDSHIFT_CLUSTER_CONFIGURATION_CHECK

Esta opción verifica los elementos esenciales de un clúster de Redshift: la encriptación en reposo, el registro y el tipo de nodo.

Estos elementos de configuración son importantes para mantener un clúster de Redshift seguro y observable.

Recomendación: Verifica que todos los clústeres de Redshift tengan la encriptación en reposo, el registro y el tipo de nodo configurados.

Para solucionar este problema, completa los siguientes 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"]
  }
}

AWS console

Para habilitar el registro de auditoría del clúster

1. Abre la consola de Amazon Redshift en https://console.aws.amazon.com/redshift/.
2. En el menú de navegación, elige Clústeres y, luego, el nombre del clúster que deseas modificar.
3. Elige Propiedades.
4. Elige Editar y Editar registro de auditoría.
5. Activa la opción Configurar registro de auditoría, establece el tipo de exportación de registros en CloudWatch (recomendado) y elige los registros que deseas exportar.

Para usar AWS S3 y administrar los registros de auditoría de Redshift, consulta Redshift: Registro de auditoría de la base de datos en la documentación de AWS.

6. Elige Guardar cambios.

Para modificar la encriptación de la base de datos en un clúster, sigue estos pasos:

1. Accede a la Consola de administración de AWS y abre la consola de Amazon Redshift en https://console.aws.amazon.com/redshift/.
2. En el menú de navegación, elige Clústeres y, luego, el clúster en el que deseas modificar la encriptación.
3. Elige Propiedades.
4. Elige Editar y Editar encriptación.
5. Elige la encriptación que deseas usar (KMS o HSM) y proporciona la siguiente información:

• Para KMS: clave que se usará
• Para HSM: conexión y certificado de cliente

CLI de AWS

1. Crea una clave de KMS y recupera el ID de clave

aws kms create-key \
  --description "Key to encrypt Redshift Clusters"

2. Modifica el clúster

aws redshift modify-cluster \
  --cluster-identifiers "test-redshift-cluster" \
  --encrypted \
  --kms-key-id <value>

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Redshift Cluster Maintenancesettings Check

Nombre de categoría en la API: REDSHIFT_CLUSTER_MAINTENANCESETTINGS_CHECK

Las actualizaciones automáticas de versiones principales se realizan según el período de mantenimiento.

Recomendación: Verifica que todos los clústeres de Redshift tengan allowVersionUpgrade habilitado, y preferredMaintenanceWindow y automatedSnapshotRetentionPeriod configurados

Para solucionar este problema, completa los siguientes pasos:

Terraform

Esta verificación cumple con todos los valores predeterminados que proporciona Terraform. En caso de que el clúster de Redshift falle, revisa los requisitos y quita 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
}

AWS console

Cuando creas un clúster de Redshift a través de la consola de AWS, los valores predeterminados ya cumplen con este control.

Para obtener más información, consulta Administra clústeres con la consola.

CLI de AWS

Para solucionar este control con la CLI de AWS, haz lo siguiente:

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --allow-version-upgrade

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Redshift Cluster Public Access Check

Nombre de 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 se puede acceder al clúster de forma pública. Cuando el clúster se configura con PubliclyAccessible establecido como verdadero, es una instancia orientada a Internet que tiene un nombre de DNS que se puede resolver públicamente, que se resuelve en una dirección IP pública.

Cuando no se puede acceder al clúster de forma pública, 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 se pueda acceder públicamente a tu clúster, no debes configurarlo con PubliclyAccessible establecido como verdadero.

Recomendación: Verifica si se puede acceder públicamente a los clústeres de Redshift

Para solucionar este problema, completa los siguientes pasos:

Terraform

Para solucionar este control, es necesario modificar el recurso del clúster de Redshift y establecer publicly_accessible en false. El valor predeterminado es true.

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  publicly_accessible = false
}

AWS console

Para inhabilitar el acceso público a un clúster de Amazon Redshift

1. Abre la consola de Amazon Redshift en https://console.aws.amazon.com/redshift/.
2. En el menú de navegación, elige Clústeres y, luego, el nombre del clúster con el grupo de seguridad que deseas modificar.
3. Elige Acciones y, luego, Modificar configuración de acceso público.
4. En Permitir que instancias y dispositivos fuera de la VPC se conecten a tu base de datos a través del extremo del clúster, elige No.
5. Selecciona Confirmar.

CLI de AWS

Usa el comando modify-cluster para configurar --no-publicly-accessible.

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --no-publicly-accessible

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Restricted Common Ports

Nombre de categoría en la API: RESTRICTED_COMMON_PORTS

De esta manera, se verifica si los puertos especificados que tienen el mayor riesgo pueden acceder al tráfico entrante sin restricciones de los grupos de seguridad. Este control falla si alguna de las reglas de un grupo de seguridad permite el tráfico de entrada de "0.0.0.0/0" o "::/0" para esos puertos.

El acceso sin restricciones (0.0.0.0/0) aumenta las oportunidades de actividad maliciosa, como hackeo, ataques de denegación del 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 y 1434 (MSSQL)
• 3, 000 (frameworks de desarrollo web de Go, Node.js y Ruby)
• 3306 (MySQL)
• 3389 (RDP)
• 4333 (ahsp)
• 5,000 (frameworks de desarrollo web de Python)
• 5432 (postgresql)
• 5500 (fcp-addr-srvr1)
• 5601 (paneles de OpenSearch)
• 8080 (proxy)
• 8088 (puerto HTTP heredado)
• 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, completa los siguientes pasos:

AWS console

Para borrar una regla de grupo de seguridad, haz lo siguiente:

1. Abre la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.
2. En el panel de navegación, elige Grupos de seguridad.
3. Selecciona el grupo de seguridad que deseas actualizar, elige Acciones y, luego, Editar reglas entrantes para quitar una regla entrante o Editar reglas salientes para quitar una regla saliente.
4. Elige el botón Borrar a la derecha de la regla que quieres borrar.
5. Elige Vista previa de los cambios y Confirmar.

Para obtener información sobre cómo borrar reglas de un grupo de seguridad, consulta Configura reglas de grupos de seguridad en la Guía del usuario de Amazon EC2.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Restricted Ssh

Nombre de 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. Quitar la conectividad sin restricciones a los servicios de consola remota, como SSH, reduce la exposición de un servidor a riesgos.

Recomendación: Los grupos de seguridad no deben permitir la entrada de 0.0.0.0/0 al puerto 22

Para solucionar este problema, completa los siguientes pasos:

AWS console

Realiza los siguientes pasos para cada grupo de seguridad asociado con una VPC.

Abre la consola de Amazon VPC en https://console.aws.amazon.com/vpc/.

1. En el panel izquierdo, elige Grupos de seguridad.
2. Selecciona un grupo de seguridad.
3. En la sección inferior de la página, elige la pestaña Inbound Rules.
4. Elige Editar reglas.
5. Identifica la regla que permite el acceso a través del puerto 22 y, luego, elige la X para quitarla.
6. Selecciona Guardar reglas.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Rotation Customer Created Cmks Enabled

Nombre de categoría en la API: ROTATION_CUSTOMER_CREATED_CMKS_ENABLED

Verifica 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 AWS KMS creada por el cliente. La regla es NON_COMPLIANT si el rol de registrador de AWS Config de un recurso no tiene el permiso kms:DescribeKey.

Recomendación: Asegúrate de que esté habilitada la rotación de los CMK creados por el cliente

Para habilitar la rotación de claves de automatización para AWS KMS, consulta Rotación de claves de AWS KMS en la documentación de AWS.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Rotation Customer Created Symmetric Cmks Enabled

Nombre de categoría en la API: ROTATION_CUSTOMER_CREATED_SYMMETRIC_CMKS_ENABLED

El Servicio de administración de claves (KMS) de AWS permite a los clientes rotar la clave de respaldo, que es el material de clave almacenado en el KMS y que está vinculado al ID de clave de la clave maestra del cliente creada por el cliente (CMK). Es la clave de respaldo que se usa para realizar operaciones criptográficas, como la encriptación y la desencriptación. Actualmente, la rotación de claves automática retiene todas las claves de copia de seguridad anteriores para que la desencriptación de los datos encriptados pueda realizarse de forma transparente. Se recomienda habilitar la rotación de claves de CMK para las claves simétricas. No se puede habilitar la rotación de claves para ninguna CMK asimétrica.

Recomendación: Asegúrate de que esté habilitada la rotación de los CMK simétricos creados por el cliente

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de administración de AWS y abre la consola de IAM en https://console.aws.amazon.com/iam.
2. En el panel de navegación izquierdo, elige Customer managed keys .
3. Selecciona una CMK administrada por el cliente en la que Key spec = SYMMETRIC_DEFAULT
4. En el panel "Configuración general", abre la pestaña "Rotación de claves".
5. Marca la casilla de verificación "Rota esta clave de KMS automáticamente todos los años".

CLI de AWS

1. Ejecuta el siguiente comando para habilitar la rotación de claves:

 aws kms enable-key-rotation --key-id <kms_key_id>

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Routing Tables Vpc Peering Are Least Access

Nombre de categoría en la API: ROUTING_TABLES_VPC_PEERING_ARE_LEAST_ACCESS

Verifica si las tablas de enrutamiento para el intercambio de tráfico entre VPC se configuran con el principio de menos privilegios.

Recomendación: Asegúrate de que las tablas de enrutamiento del intercambio de tráfico entre VPC sea de “mínimo acceso”

Para actualizar las tablas de ruta del intercambio de tráfico de VPC, consulta Cómo actualizar las tablas de ruta para una conexión de intercambio de tráfico de VPC en la guía del usuario de VPC de AWS.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

S3 Account Level Public Access Blocks

Nombre de categoría en la API: S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS

El bloqueo de acceso público de Amazon S3 proporciona parámetros de configuración para puntos de acceso, buckets y cuentas para ayudarte a administrar el acceso público a los recursos de Amazon S3. De forma predeterminada, los buckets, los puntos de acceso y los objetos nuevos no permiten el acceso público.

Recomendación: Verifica si están configurados los parámetros requeridos del bloqueo de acceso público de S3 a nivel de la cuenta

Para solucionar este problema, completa los siguientes pasos:

Terraform

El siguiente recurso de Terraform configura el acceso a nivel de la cuenta a S3.

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
}

AWS console

Para editar la configuración de bloqueo de acceso público de todos los buckets de S3 en una cuenta de AWS.

1. Accede a la consola de administración de AWS y abre la consola de Amazon S3 en https://console.aws.amazon.com/s3/.
2. Elige la configuración de Bloquear acceso público para esta cuenta.
3. Elige Editar para cambiar la configuración de bloqueo de acceso público de todos los buckets de tu cuenta de AWS.
4. Elige los parámetros de configuración que quieras cambiar y, luego, elige Guardar cambios.
5. Cuando se te solicite confirmación, ingresa confirm. Luego, 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}'

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

S3 Buckets Configured Block Public Access Bucket And Account Settings

Nombre de 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 administrar el acceso público a los recursos de Amazon S3. De forma predeterminada, los objetos y buckets de S3 se crean con el acceso público inhabilitado. Sin embargo, un principal de IAM de AWS con permisos de S3 suficientes puede habilitar el acceso público a nivel del bucket o del objeto. Cuando está habilitado, Block public access (bucket settings) evita que un bucket individual y sus objetos contenidos sean de acceso público. De manera similar, Block public access (account settings) evita que todos los buckets y los objetos contenidos sean de acceso público 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, completa los siguientes pasos:

AWS console

Si el resultado indica true para la configuración independiente, significa que se estableció en la cuenta.

1. Accede a la consola de administración de AWS y abre la consola de Amazon S3 en https://console.aws.amazon.com/s3/.
2. Elige Bloquear acceso público (configuración de la cuenta).
3. Elige Editar para cambiar la configuración de bloqueo de acceso público de todos los buckets de tu cuenta de AWS.
4. Elige la configuración que quieras cambiar y, luego, Guardar. Para obtener detalles sobre cada parámetro de configuración, coloca el cursor sobre los íconos de i.
5. Cuando se te solicite confirmación, ingresa confirm. Luego, haz clic en Confirmar para guardar los cambios.

CLI de AWS

Para establecer la configuración de Bloquear acceso público para 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>

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

S3 Bucket Access Logging Enabled Cloudtrail S3 Bucket

Nombre de categoría en la API: S3_BUCKET_ACCESS_LOGGING_ENABLED_CLOUDTRAIL_S3_BUCKET

El registro de acceso al bucket de S3 genera un registro que contiene registros de acceso para cada solicitud que se realiza 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 que funcionaron y la hora y la fecha en que se procesó la solicitud. Se recomienda habilitar el registro de acceso al bucket en el bucket de S3 de CloudTrail.

Recomendación:

Asegúrate de que el registro de acceso al bucket de S3 esté habilitado en el bucket de S3 de CloudTrail

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de administración de AWS y abre la consola de S3 en https://console.aws.amazon.com/s3.
2. En Todos los buckets, haz clic en el bucket de S3 de destino.
3. Haz clic en Propiedades en la parte superior derecha de la consola.
4. En Bucket: <s3\_bucket\_for\_cloudtrail>, haz clic en Registros</s3\_bucket\_for\_cloudtrail>.
5. Configura el registro de bucket
   - Haz clic en la casilla de verificación Habilitada
   - Selecciona Bucket de destino de la lista
   - Ingresa un prefijo de destino
6. Haz clic en Guardar.

CLI de AWS

1. Obtén el nombre del bucket de S3 en el que CloudTrail está registrando información:

aws cloudtrail describe-trails --region <region-name> --query trailList[*].S3BucketName

2. Copia y agrega el nombre del bucket de destino en , el prefijo para el archivo de registro en y, de manera opcional, agrega una dirección de correo electrónico en la siguiente plantilla y guárdala como :

{
 "LoggingEnabled": {
 "TargetBucket": "<Logging_BucketName>",
 "TargetPrefix": "<LogFilePrefix>",
 "TargetGrants": [
 {
 "Grantee": {
 "Type": "AmazonCustomerByEmail",
 "EmailAddress": "<EmailID>"
 },
 "Permission": "FULL_CONTROL"
 }
 ]
 }
}

3. Ejecuta el comando put-bucket-logging con el nombre del bucket 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>

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

S3 Bucket Logging Enabled

Nombre de 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 buckets de almacenamiento, lo que es útil para las auditorías de seguridad. De forma predeterminada, el registro de acceso del servidor no está habilitado para los buckets de S3.

Recomendación: Verifica si el registro está habilitado en todos los buckets de S3

Para solucionar este problema, completa los siguientes pasos:

Terraform

En el siguiente ejemplo, se muestra cómo crear 2 buckets:

1. Un bucket de registro
2. Un bucket que cumpla con los requisitos

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"
    }
  }
}

AWS console

Para obtener información sobre cómo habilitar el registro de acceso de S3 a través de la consola de AWS, consulta Habilita 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:

1. Crea una política de bucket para otorgarle al principal del servicio de registro permiso a PutObject en tu bucket 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

2. Aplica la política a tu bucket de registro

logging.json

{
    "LoggingEnabled": {
        "TargetBucket": "MyBucket",
        "TargetPrefix": "Logs/"
    }
}

aws s3api put-bucket-logging \
  --bucket MyBucket \
  --bucket-logging-status file://logging.json

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

S3 Bucket Policy Set Deny Http Requests

Nombre de categoría en la API: S3_BUCKET_POLICY_SET_DENY_HTTP_REQUESTS

A nivel del bucket de Amazon S3, puedes configurar permisos a través de una política de bucket que permita el acceso a los objetos solo a través de HTTPS.

Recomendación: Asegúrate de que la política de buckets de S3 esté configurada para rechazar solicitudes HTTP

Para solucionar este problema, completa los siguientes pasos:

AWS console

con el generador de políticas de AWS:

1. Repite los pasos 1 a 4 indicados anteriormente.
2. Haz clic en Policy Generator en la parte inferior del editor de políticas de bucket.
3. Selecciona el tipo de política
   S3 Bucket Policy
4. Agregar sentencias
   - Effect = Denegar
   - Principal = *
   - AWS Service = Amazon S3
   - Actions = *
   - Amazon Resource Name =
5. Generar política
6. Copia el texto y agrégalo a la política de bucket.

CLI de AWS

1. Exporta la política de bucket a un archivo JSON.

aws s3api get-bucket-policy --bucket <bucket_name> --query Policy --output text > policy.json

2. Para modificar el archivo policy.json, agrega esta sentencia:

{
 "Sid": <optional>",
 "Effect": "Deny",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": "arn:aws:s3:::<bucket_name>/*",
 "Condition": {
 "Bool": {
 "aws:SecureTransport": "false"
 }
 }
 }

3. Vuelve a aplicar esta política modificada al bucket de S3:

aws s3api put-bucket-policy --bucket <bucket_name> --policy file://policy.json

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

S3 Bucket Replication Enabled

Nombre de categoría en la API: S3_BUCKET_REPLICATION_ENABLED

Este control verifica si un bucket de Amazon S3 tiene habilitada la replicación entre regiones. El control falla si el bucket no tiene habilitada la replicación entre regiones o si también está habilitada la replicación en la misma región.

La replicación es la copia automática y asíncrona de objetos entre buckets en la misma región de AWS o en diferentes regiones. La replicación copia los objetos creados recientemente y las actualizaciones de objetos de un bucket de origen a uno o varios buckets de destino. Las prácticas recomendadas de AWS recomiendan la replicación para los buckets de origen y destino que pertenecen a la misma cuenta de AWS. Además de la disponibilidad, debes considerar otros parámetros de configuración de endurecimiento de sistemas.

Recomendación: Verifica si los buckets de S3 tienen habilitada la replicación entre regiones

Para habilitar la replicación entre regiones en un bucket de S3, consulta Configura la replicación para los buckets de origen y destino que pertenecen a la misma cuenta en la Guía del usuario de Amazon Simple Storage Service. En Bucket de origen, elige Aplicar a todos los objetos del bucket.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

S3 Bucket Server Side Encryption Enabled

Nombre de categoría en la API: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED

De esta manera, se verifica que tu bucket de S3 tenga habilitada la encriptación predeterminada de Amazon S3 o que la política de buckets de S3 rechace de forma explícita las solicitudes de colocación de objetos sin encriptación del servidor.

Recomendación: Asegúrate de que todos los buckets de S3 utilicen la encriptación en reposo

Para solucionar este problema, completa los siguientes pasos:

Terraform

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

AWS console

Para habilitar la encriptación predeterminada en un bucket de S3, sigue estos pasos:

1. Abre la consola de Amazon S3 en https://console.aws.amazon.com/s3/.
2. En el panel de navegación izquierdo, elige Buckets.
3. Elige el bucket de S3 de la lista.
4. Elige Propiedades.
5. Elige Encriptación predeterminada.
6. Para la encriptación, elige AES-256 o AWS-KMS.
7. Elige AES-256 para usar las claves que administra Amazon S3 para la encriptación predeterminada. Para obtener más información sobre el uso de la encriptación del servidor de Amazon S3 para encriptar tus datos, consulta la Guía del usuario de Amazon Simple Storage Service.
8. Elige AWS-KMS para usar las claves que administra AWS KMS para la encriptación predeterminada. Luego, elige una clave maestra de la lista de claves maestras de AWS KMS que creaste.
9. Escribe el nombre de recurso de Amazon (ARN) de la clave de KMS de AWS que deseas usar. Puedes encontrar el ARN de tu clave de AWS KMS en la consola de IAM, en Claves de encriptación. También puedes elegir un nombre de clave de la lista desplegable.
10. Importante: Si usas la opción de AWS KMS para tu configuración de encriptación 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 del servicio de administración de claves de AWS.
11. Selecciona Guardar.

Para obtener más información sobre cómo crear una clave de AWS KMS, consulta la Guía para desarrolladores de AWS Key Management Service.

Para obtener más información sobre el uso de AWS KMS con Amazon S3, consulta la Guía del usuario de Amazon Simple Storage Service.

Cuando habilites la encriptación predeterminada, es posible que debas actualizar la política de bucket. Para obtener más información sobre cómo pasar de las políticas de bucket a la encriptación predeterminada, 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"}}]}'

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

S3 Bucket Versioning Enabled

Nombre de categoría en la API: S3_BUCKET_VERSIONING_ENABLED

Amazon S3 es una forma de mantener varias variantes de un objeto en el mismo bucket y puede ayudarte a recuperarte con mayor facilidad de las acciones no deseadas de los usuarios y las fallas de la aplicación.

Recomendación: Verifica que el control de versiones esté habilitado en todos los buckets de S3

Para solucionar este problema, completa los siguientes pasos:

Terraform

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"

  versioning {
    enabled = true
  }
}

AWS console

Para habilitar o inhabilitar el control de versiones en un bucket de S3, haz lo siguiente:

1. Accede a la consola de administración de AWS y abre la consola de Amazon S3 en https://console.aws.amazon.com/s3/.
2. En la lista de buckets, elige el nombre del bucket para el que deseas habilitar el control de versiones.
3. Elige Propiedades.
4. En Control de versiones del bucket, elige Editar.
5. Elige Suspender o Habilitar y, luego, Guardar cambios.

CLI de AWS

aws s3control put-bucket-versioning \
--bucket <bucket_name> \
--versioning-configuration Status=Enabled

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

S3 Default Encryption Kms

Nombre de categoría en la API: S3_DEFAULT_ENCRYPTION_KMS

Verifica si los buckets de Amazon S3 están encriptados con el servicio de administración de claves (KMS) de AWS

Recomendación: Verifica que todos los buckets estén encriptados con KMS

Para solucionar este problema, completa los siguientes 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"
    }
  }
}

AWS console

Para habilitar la encriptación predeterminada en un bucket de S3, sigue estos pasos:

1. Abre la consola de Amazon S3 en https://console.aws.amazon.com/s3/.
2. En el panel de navegación izquierdo, elige Buckets.
3. Elige el bucket de S3 de la lista.
4. Elige Propiedades.
5. Elige Encriptación predeterminada.
6. Para la encriptación, elige AWS-KMS.
7. Elige AWS-KMS para usar las claves que administra AWS KMS para la encriptación predeterminada. Luego, elige una clave maestra de la lista de claves maestras de AWS KMS que creaste. Para obtener más información sobre cómo crear claves de KMS, consulta la documentación de AWS: Cómo crear claves.
8. Escribe el nombre de recurso de Amazon (ARN) de la clave de KMS de AWS que deseas usar. Puedes encontrar el ARN de tu clave de AWS KMS en la consola de IAM, en Claves de encriptación. También puedes elegir un nombre de clave de la lista desplegable.
9. 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 del servicio de administración de claves de AWS.
10. Selecciona Guardar.

Para obtener más información sobre el uso de AWS KMS con Amazon S3, consulta la Guía del usuario de Amazon Simple Storage Service.

Cuando habilites la encriptación predeterminada, es posible que debas actualizar la política de bucket. Para obtener más información sobre cómo pasar de las políticas de bucket a la encriptación predeterminada, consulta la Guía del usuario de Amazon Simple Storage Service.

CLI de AWS

Crea una clave de KMS

aws kms create-key \
  --description "Key to encrypt S3 buckets"

Habilita la rotación de claves

aws kms enable-key-rotation \
  --key-id <key_id_from_previous_command>

Actualizar bucket

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"KMSMasterKeyID": "<id_from_key>", "SSEAlgorithm": "AES256"}}]}'

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Sagemaker Notebook Instance Kms Key Configured

Nombre de categoría en la API: SAGEMAKER_NOTEBOOK_INSTANCE_KMS_KEY_CONFIGURED

Verifica si se configuró una clave del servicio de administración de claves (AWS KMS) para una instancia de notebook de Amazon SageMaker. La regla es NON_COMPLIANT si no se especifica "KmsKeyId" para la instancia de notebook de SageMaker.

Recomendación: Verifica que todas las instancias de notebooks de SageMaker estén configuradas para usar KMS

Para configurar KMS para SageMaker, consulta Administración de claves en la documentación de Amazon SageMaker.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Sagemaker Notebook No Direct Internet Access

Nombre de categoría en la API: SAGEMAKER_NOTEBOOK_NO_DIRECT_INTERNET_ACCESS

Verifica si el acceso directo a Internet está inhabilitado para una instancia de notebook de SageMaker. Para ello, verifica si el campo DirectInternetAccess está inhabilitado para la instancia de notebook.

Si configuras tu instancia de SageMaker sin una VPC, el acceso directo a Internet se habilita de forma predeterminada en tu instancia. Debes configurar tu instancia con una VPC y cambiar el parámetro de configuración predeterminado a Inhabilitar: Accede a Internet a través de una VPC.

Para entrenar o alojar modelos desde una notebook, necesitas acceso a Internet. Para habilitar el acceso a Internet, asegúrate de que tu VPC tenga una puerta de enlace 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 notebook a recursos en una VPC, consulta Cómo conectar una instancia de notebook a recursos en una VPC en la Guía para desarrolladores de Amazon SageMaker.

También debes asegurarte de que el acceso a la configuración de SageMaker esté limitado solo a los usuarios autorizados. Restringe los permisos de IAM de los usuarios para modificar la configuración y los recursos de SageMaker.

Recomendación: Verifica si el acceso directo a Internet está inhabilitado para todas las instancias de notebook de Amazon SageMaker

Para solucionar este problema, completa los siguientes pasos:

AWS console

Ten en cuenta que no puedes cambiar la configuración de acceso a Internet después de crear una instancia de notebook. Se debe detener, borrar y volver a crear.

Para configurar una instancia de notebook de SageMaker que rechace el acceso directo a Internet, haz lo siguiente:

1. Abre la consola de SageMaker en https://console.aws.amazon.com/sagemaker/.
2. Navega a Instancias de notebooks.
3. Borra la instancia que tiene habilitado el acceso directo a Internet. Elige la instancia, elige Acciones y, luego, Detener.
4. Una vez que se detenga la instancia, elige Acciones y, luego, Borrar.
5. Elige Crear instancia de notebook. Proporciona los detalles de configuración.
6. Expande la sección de red y, luego, elige una VPC, una subred y un grupo de seguridad. En Acceso directo a Internet, elige Inhabilitar: Accede a Internet a través de una VPC.
7. Elige Crear instancia de notebook.

Para obtener más información, consulta Cómo conectar una instancia de notebook a recursos en una VPC en la Guía para desarrolladores de Amazon SageMaker.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Secretsmanager Rotation Enabled Check

Nombre de categoría en la API: SECRETSMANAGER_ROTATION_ENABLED_CHECK

Verifica si un secreto almacenado en AWS Secrets Manager está configurado con rotación automática. El control falla si el secreto no está configurado con rotación automática. Si proporcionas un valor personalizado para el parámetro maximumAllowedRotationFrequency, el control se aprobará solo si el secreto se rota automáticamente dentro del período especificado.

Secret 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 API de terceros. Puedes usar Secret Manager para almacenar secretos de forma centralizada, encriptarlos automáticamente, controlar el acceso a ellos y rotar los secretos de forma segura y automática.

Secret Manager puede rotar secretos. Puedes usar la rotación para reemplazar secretos a largo plazo por secretos a corto plazo. La rotación de secretos limita el tiempo que un usuario no autorizado puede usar un secreto comprometido. Por este motivo, debes rotar tus secretos con frecuencia. Para obtener más información sobre la rotación, consulta Rota los secretos de AWS Secrets Manager en la Guía del usuario de AWS Secrets Manager.

Recomendación: Verifica 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 Cómo configurar la rotación automática de los secretos de AWS Secrets Manager con la consola en la Guía del usuario de AWS Secrets Manager. Debes elegir y configurar una función de AWS Lambda para la rotación.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Sns Encrypted Kms

Nombre de categoría en la API: SNS_ENCRYPTED_KMS

Verifica si un tema de SNS está encriptado en reposo con AWS KMS. Los controles fallan si un tema de SNS no usa una clave de KMS para la encriptación del servidor (SSE).

La encriptación de datos en reposo reduce el riesgo de que un usuario que no se autentique en AWS acceda a los datos almacenados en el disco. También agrega otro conjunto de controles de acceso para limitar la capacidad de los usuarios no autorizados de acceder a los datos. Por ejemplo, se requieren permisos de API para desencriptar los datos antes de que se puedan leer. Los temas de SNS deben estar encriptados en reposo para agregar una capa adicional de seguridad.

Recomendación: Verifica que todos los temas de SNS estén encriptados con KMS

Para activar la SSE en un tema de SNS, consulta Cómo habilitar la encriptación del servidor (SSE) para un tema de Amazon SNS en la Guía para desarrolladores de Amazon Simple Notification Service. Antes de usar la SSE, también debes configurar las directivas de claves de AWS KMS para permitir la encriptación de temas y la encriptación y desencriptación de mensajes. Para obtener más información, consulta Cómo configurar permisos de AWS KMS en la Guía para desarrolladores del servicio de notificaciones simples de Amazon.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Vpc Default Security Group Closed

Nombre de categoría en la API: VPC_DEFAULT_SECURITY_GROUP_CLOSED

Este control verifica 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 entrante y saliente 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 no se puede borrar el grupo de seguridad predeterminado, debes cambiar la configuración de las reglas del grupo de seguridad predeterminado para restringir el tráfico entrante y saliente. Esto evita el tráfico no deseado si el grupo de seguridad predeterminado se configura accidentalmente para recursos como instancias de EC2.

Recomendación: Asegúrate de que el grupo de seguridad predeterminado de cada VPC restrinja todo el tráfico

Para solucionar este problema, primero crea nuevos grupos de seguridad con los privilegios mínimos. Para obtener instrucciones, consulta Cómo crear un grupo de seguridad en la Guía del usuario de Amazon VPC. Luego, asigna los nuevos grupos de seguridad a tus instancias de EC2. Para obtener instrucciones, consulta Cambia el grupo de seguridad de una instancia en la Guía del usuario de Amazon EC2 para instancias de Linux.

Después de asignar los grupos de seguridad nuevos a tus recursos, quita todas las reglas entrantes y salientes de los grupos de seguridad predeterminados. Para obtener instrucciones, consulta Cómo borrar reglas de grupos de seguridad en la Guía del usuario de Amazon VPC.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Vpc Flow Logging Enabled All Vpcs

Nombre de categoría en la API: VPC_FLOW_LOGGING_ENABLED_ALL_VPCS

Los registros de flujo de VPC son una función que te permite captar información sobre el tráfico de IP desde y hacia las interfaces de red de tu VPC. Después de crear un registro de flujo, puedes ver y recuperar sus datos en Amazon CloudWatch Logs. Se recomienda habilitar los registros de flujo de VPC para los “rechazos” de paquetes de las VPC.

Recomendación: Asegúrate de que el registro de flujo de VPC esté habilitado en todas las VPC

Para solucionar este problema, completa los siguientes pasos:

AWS console

1. Accede a la consola de administración
2. Selecciona Services y, luego, VPC.
3. En el panel de navegación izquierdo, selecciona Your VPCs.
4. Selecciona una VPC
5. En el panel derecho, selecciona la pestaña Flow Logs.
6. Si no hay ningún registro de flujo, haz clic en Create Flow Log.
7. En Filtro, selecciona Reject.
8. Ingresa un Role y un Destination Log Group
9. Haz clic en Create Log Flow.
10. Haz clic en CloudWatch Logs Group.

Nota: Si configuras el filtro en "Rechazar", se reducirá considerablemente la acumulación de datos de registro para esta recomendación y se proporcionará suficiente información para la detección, investigación y solución de violaciones de la seguridad. Sin embargo, durante los períodos de ingeniería de grupos de seguridad de privilegio mínimo, establecer este filtro en "Todos" puede ser muy útil para descubrir los flujos de tráfico existentes necesarios para el funcionamiento adecuado de un entorno que ya se está ejecutando.

CLI de AWS

1. Crea un documento de políticas, asígnale 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"
 }
 ]
}

2. Crea otro documento de políticas, asígnale el nombre 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": "*"
 }
 ]
}

3. 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

4. Ejecuta el siguiente comando para crear una política de IAM:

aws iam create-policy --policy-name <ami-policy-name> --policy-document file://<file-path>iam-policy.json

5. Ejecuta el comando attach-group-policy con el ARN de la política de IAM que se devolvió en el paso anterior para adjuntar la política al rol de IAM (si el comando se ejecuta correctamente, no se muestra ningún resultado):

aws iam attach-group-policy --policy-arn arn:aws:iam::<aws-account-id>:policy/<iam-policy-name> --group-name <group-name>

6. Ejecuta describe-vpcs para obtener el VpcId disponible en la región seleccionada:

aws ec2 describe-vpcs --region <region>

7. El resultado del comando debería mostrar el ID de VPC disponible en la región seleccionada.
8. Ejecuta create-flow-logs para crear un registro de flujo para 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>

9. Repite el paso 8 para otras VPC disponibles en la región seleccionada.
10. Para cambiar la región, actualiza --region y repite el procedimiento de solución para otros VPC.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Vpc Sg Open Only To Authorized Ports

Nombre de categoría en la API: VPC_SG_OPEN_ONLY_TO_AUTHORIZED_PORTS

Este control verifica si un grupo de seguridad de Amazon EC2 permite tráfico entrante sin restricciones desde puertos no autorizados. El estado del control se determina de la siguiente manera:

Si usas el valor predeterminado de authorizedTcpPorts, el control falla si el grupo de seguridad permite tráfico entrante sin restricciones desde cualquier puerto que no sea el 80 ni el 443.

Si proporcionas valores personalizados para authorizedTcpPorts o authorizedUdpPorts, el control fallará si el grupo de seguridad permite tráfico entrante sin restricciones desde cualquier puerto que no esté en la lista.

Si no se usa ningún parámetro, el control falla para 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 acceso de privilegio mínimo. El acceso sin restricciones (dirección IP con un sufijo /0) aumenta las oportunidades de actividades maliciosas, como hackeos, ataques de denegación del servicio y pérdida de datos. A menos que se permita un puerto de forma específica, este debe denegar el acceso sin restricciones.

Recomendación: Verifica que los grupos de seguridad con 0.0.0.0/0 de todas las VPC solo permitan tráfico de TCP/UDP entrante específico

Para modificar un grupo de seguridad, consulta Cómo trabajar con grupos de seguridad en la Guía del usuario de Amazon VPC.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.

Both VPC VPN Tunnels Up

Nombre de categoría en la API: VPC_VPN_2_TUNNELS_UP

Un túnel VPN es un vínculo encriptado por el que los datos pueden pasar de la red del cliente a AWS o desde AWS dentro de una conexión de VPN de sitio a sitio de AWS. Cada conexión de VPN incluye dos túneles VPN que puedes usar de forma simultánea para obtener alta disponibilidad. Es importante asegurarse de que ambos túneles de VPN estén activos para una conexión de VPN para confirmar una conexión segura y con alta disponibilidad entre una VPC de AWS y tu red remota.

Este control verifica que ambos túneles VPN proporcionados por la VPN de sitio a sitio de AWS estén en estado ACTIVADO. El control falla si uno o ambos túneles están en estado DOWN.

Recomendación: Verifica que estén configurados los túneles VPN de AWS proporcionados por AWS entre sitios

Para modificar las opciones de túneles de VPN, consulta Cómo modificar las opciones de túneles de VPN de sitio a sitio en la Guía del usuario de la VPN de sitio a sitio de AWS.

Obtén información sobre los elementos admitidos y la configuración de análisis de este tipo de resultados.