Recomendaciones de seguridad de identidad y acceso

En este artículo se enumeran todas las recomendaciones de seguridad de identidad y acceso que puede ver en Microsoft Defender for Cloud.

Las recomendaciones que aparecen en el entorno se basan en los recursos que está protegiendo y en la configuración personalizada.

Para obtener información sobre las acciones que puede realizar en respuesta a estas recomendaciones, consulte Corrección de recomendaciones en Defender for Cloud.

Sugerencia

Si una descripción de recomendación indica No hay ninguna directiva relacionada, normalmente es porque esa recomendación depende de otra recomendación.

Por ejemplo, se deben corregir los errores de estado de Endpoint Protection en función de la recomendación que comprueba si se instala una solución de Endpoint Protection (se debe instalar la solución Endpoint Protection). La recomendación subyacente tiene una directiva. La limitación de directivas solo a recomendaciones fundamentales simplifica la administración de directivas.

Recomendaciones de acceso e identidad de Azure

Es necesario designar un máximo de 3 propietarios para las suscripciones.

Descripción: para reducir el potencial de infracciones por parte de las cuentas de propietario en peligro, se recomienda limitar el número de cuentas de propietario a un máximo de 3 (Directiva relacionada: se debe designar un máximo de 3 propietarios para su suscripción).

Gravedad: alta

Deben estar habilitadas para MFA las cuentas con permisos de propietario de los recursos de Azure.

Descripción: si solo usa contraseñas para autenticar a los usuarios, deja abierto un vector de ataque. Los usuarios suelen usar contraseñas no seguras para varios servicios. Al habilitar la autenticación multifactor (MFA), proporciona una mejor seguridad para las cuentas, a la vez que permite a los usuarios autenticarse en casi cualquier aplicación con inicio de sesión único (SSO). La autenticación multifactor es un proceso por el que se solicita a los usuarios, durante el proceso de inicio de sesión, otra forma de identificación. Por ejemplo, es posible que un código se envíe a su teléfono móvil o que se les pida un examen de huellas digitales. Se recomienda habilitar MFA para todas las cuentas que tengan permisos de propietario en los recursos de Azure, para evitar infracciones y ataques. Encontrará más detalles y preguntas más frecuentes aquí: Administración del cumplimiento de la autenticación multifactor (MFA) en las suscripciones (no hay ninguna directiva relacionada).

Gravedad: alta

Deben estar habilitadas para MFA las cuentas con permisos de lectura de los recursos de Azure.

Descripción: si solo usa contraseñas para autenticar a los usuarios, deja abierto un vector de ataque. Los usuarios suelen usar contraseñas no seguras para varios servicios. Al habilitar la autenticación multifactor (MFA), proporciona una mejor seguridad para las cuentas, a la vez que permite a los usuarios autenticarse en casi cualquier aplicación con inicio de sesión único (SSO). La autenticación multifactor es un proceso por el que se solicita a los usuarios, durante el proceso de inicio de sesión, una forma adicional de identificación. Por ejemplo, es posible que un código se envíe a su teléfono móvil o que se les pida un examen de huellas digitales. Se recomienda habilitar MFA para todas las cuentas que tengan permisos de lectura en los recursos de Azure, para evitar infracciones y ataques. Aquí encontrará más detalles y preguntas más frecuentes. (Ninguna directiva relacionada)

Gravedad: alta

Deben estar habilitadas para MFA las cuentas con permisos de escritura de los recursos de Azure.

Descripción: si solo usa contraseñas para autenticar a los usuarios, deja abierto un vector de ataque. Los usuarios suelen usar contraseñas no seguras para varios servicios. Al habilitar la autenticación multifactor (MFA), proporciona una mejor seguridad para las cuentas, a la vez que permite a los usuarios autenticarse en casi cualquier aplicación con inicio de sesión único (SSO). La autenticación multifactor es un proceso por el que se solicita a los usuarios, durante el proceso de inicio de sesión, una forma adicional de identificación. Por ejemplo, es posible que un código se envíe a su teléfono móvil o que se les pida un examen de huellas digitales. Se recomienda habilitar MFA para todas las cuentas que tengan permisos de escritura en los recursos de Azure, para evitar infracciones y ataques. Encontrará más detalles y preguntas más frecuentes aquí: Administración del cumplimiento de la autenticación multifactor (MFA) en las suscripciones (no hay ninguna directiva relacionada).

Gravedad: alta

Las cuentas de Azure Cosmos DB deben usar Azure Active Directory como único método de autenticación.

Descripción: la mejor manera de autenticarse en los servicios de Azure es mediante el control de acceso basado en rol (RBAC). RBAC le permite mantener el principio de privilegio mínimo y admite la capacidad de revocar permisos como un método eficaz de respuesta cuando se pone en peligro. Puede configurar la cuenta de Azure Cosmos DB para aplicar RBAC como único método de autenticación. Cuando se configura la aplicación, se denegarán todos los demás métodos de acceso (claves principales o secundarias y tokens de acceso). (Ninguna directiva relacionada)

Gravedad: media

Deben quitarse las cuentas bloqueadas con permisos de propietario de los recursos de Azure.

Descripción: las cuentas que se han bloqueado para iniciar sesión en Active Directory deben quitarse de los recursos de Azure. Estas cuentas pueden ser objetivo de los atacantes que buscan formas de acceder a los datos sin ser detectados. (Ninguna directiva relacionada)

Gravedad: alta

Las cuentas bloqueadas con permisos de lectura y escritura en los recursos de Azure deberían quitarse

Descripción: las cuentas que se han bloqueado para iniciar sesión en Active Directory deben quitarse de los recursos de Azure. Estas cuentas pueden ser objetivo de los atacantes que buscan formas de acceder a los datos sin ser detectados. (Ninguna directiva relacionada)

Gravedad: alta

Las cuentas en desuso se deben quitar de las suscripciones.

Descripción: las cuentas de usuario que se han bloqueado para iniciar sesión deben quitarse de las suscripciones. Estas cuentas pueden ser objetivo de los atacantes que buscan formas de acceder a los datos sin ser detectados. (Directiva relacionada: Las cuentas en desuso deben quitarse de la suscripción).

Gravedad: alta

Las cuentas en desuso con permisos de propietario deben quitarse de la suscripción.

Descripción: las cuentas de usuario que se han bloqueado para iniciar sesión deben quitarse de las suscripciones. Estas cuentas pueden ser objetivo de los atacantes que buscan formas de acceder a los datos sin ser detectados. (Directiva relacionada: Las cuentas en desuso con permisos de propietario deben quitarse de la suscripción).

Gravedad: alta

Los registros de diagnóstico en Key Vault deben estar habilitados

Descripción: habilite los registros y guárdelos durante un año. Esto le permite volver a crear seguimientos de actividad con fines de investigación cuando se produce un incidente de seguridad o se pone en peligro la red. (Directiva relacionada: Los registros de diagnóstico de Key Vault deben estar habilitados).

Gravedad: baja

Las cuentas externas con permisos de propietario deben quitarse de las suscripciones.

Descripción: las cuentas con permisos de propietario que tienen nombres de dominio diferentes (cuentas externas) deben quitarse de la suscripción. Esto evita el acceso no supervisado. Estas cuentas pueden ser objetivo de los atacantes que buscan formas de acceder a los datos sin ser detectados. (Directiva relacionada: Las cuentas externas con permisos de propietario deben quitarse de la suscripción).

Gravedad: alta

Las cuentas externas con permisos de lectura se deben quitar de las suscripciones.

Descripción: las cuentas con permisos de lectura que tienen nombres de dominio diferentes (cuentas externas), deben quitarse de la suscripción. Esto evita el acceso no supervisado. Estas cuentas pueden ser objetivo de los atacantes que buscan formas de acceder a los datos sin ser detectados. (Directiva relacionada: Las cuentas externas con permisos de lectura deben quitarse de la suscripción).

Gravedad: alta

Las cuentas externas con permisos de escritura se deben quitar de las suscripciones.

Descripción: las cuentas con permisos de escritura que tienen nombres de dominio diferentes (cuentas externas), deben quitarse de la suscripción. Esto evita el acceso no supervisado. Estas cuentas pueden ser objetivo de los atacantes que buscan formas de acceder a los datos sin ser detectados. (Directiva relacionada: Las cuentas externas con permisos de escritura deben quitarse de la suscripción).

Gravedad: alta

El firewall debe estar habilitado en Key Vault

Descripción: el firewall de Key Vault impide que el tráfico no autorizado llegue al almacén de claves y proporciona una capa adicional de protección para los secretos. Habilite el firewall para asegurarse de que solo el tráfico de las redes permitidas pueda acceder al almacén de claves. (Directiva relacionada: El firewall debe estar habilitado en Key Vault.

Gravedad: media

Deben quitarse las cuentas de invitado con permisos de propietario de los recursos de Azure.

Descripción: las cuentas con permisos de propietario que se han aprovisionado fuera del inquilino de Azure Active Directory (nombres de dominio diferentes), deben quitarse de los recursos de Azure. Las cuentas de invitado no se administran con los mismos estándares que las identidades de inquilino empresarial. Estas cuentas pueden ser objetivo de los atacantes que buscan formas de acceder a los datos sin ser detectados. (Ninguna directiva relacionada)

Gravedad: alta

Deben quitarse las cuentas de invitado con permisos de lectura de los recursos de Azure.

Descripción: las cuentas con permisos de lectura que se han aprovisionado fuera del inquilino de Azure Active Directory (nombres de dominio diferentes), deben quitarse de los recursos de Azure. Las cuentas de invitado no se administran con los mismos estándares que las identidades de inquilino empresarial. Estas cuentas pueden ser objetivo de los atacantes que buscan formas de acceder a los datos sin ser detectados. (Ninguna directiva relacionada)

Gravedad: alta

Deben quitarse las cuentas de invitado con permisos de escritura de los recursos de Azure.

Descripción: las cuentas con permisos de escritura que se han aprovisionado fuera del inquilino de Azure Active Directory (nombres de dominio diferentes), deben quitarse de los recursos de Azure. Las cuentas de invitado no se administran con los mismos estándares que las identidades de inquilino empresarial. Estas cuentas pueden ser objetivo de los atacantes que buscan formas de acceder a los datos sin ser detectados. (Ninguna directiva relacionada)

Gravedad: alta

Las claves de Key Vault deben tener una fecha de expiración

Descripción: las claves criptográficas deben tener una fecha de expiración definida y no ser permanentes. Las claves que no expiran proporcionan a los posibles atacantes más tiempo para hacerse con ellas. Es una práctica de seguridad recomendada establecer fechas de expiración en claves criptográficas. (Directiva relacionada: Las claves de Key Vault deben tener una fecha de expiración).

Gravedad: alta

Los secretos de Key Vault deben tener una fecha de expiración

Descripción: los secretos deben tener una fecha de expiración definida y no ser permanentes. Los secretos que no expiran proporcionan a un posible atacante más tiempo para ponerlos en peligro. Es una práctica de seguridad recomendada para establecer fechas de expiración en secretos. (Directiva relacionada: Los secretos de Key Vault deben tener una fecha de expiración).

Gravedad: alta

Los almacenes de claves deben tener habilitada la protección contra operaciones de purga

Descripción: la eliminación malintencionada de un almacén de claves puede provocar una pérdida de datos permanente. Un usuario malintencionado de la organización puede eliminar y purgar los almacenes de claves. La protección contra purgas le protege frente a ataques internos mediante la aplicación de un período de retención obligatorio para almacenes de claves eliminados temporalmente. Ningún usuario de su organización o Microsoft podrá purgar los almacenes de claves durante el período de retención de eliminación temporal. (Directiva relacionada: Los almacenes de claves deben tener habilitada la protección de purga).

Gravedad: media

Los almacenes de claves deben tener habilitada la eliminación temporal

Descripción: la eliminación de un almacén de claves sin eliminación temporal habilitada elimina permanentemente todos los secretos, claves y certificados almacenados en el almacén de claves. La eliminación accidental de un almacén de claves puede provocar una pérdida de datos permanente. La eliminación temporal permite recuperar un almacén de claves eliminado accidentalmente durante un período de retención configurable. (Directiva relacionada: Los almacenes de claves deben tener habilitada la eliminación temporal).

Gravedad: alta

MFA debe estar habilitado en las cuentas con permisos de propietario en las suscripciones.

Descripción: la autenticación multifactor (MFA) debe estar habilitada para todas las cuentas de suscripción con permisos de propietario para evitar una vulneración de cuentas o recursos. (Directiva relacionada: MFA debe habilitarse en las cuentas con permisos de propietario en la suscripción).

Gravedad: alta

MFA debe estar habilitado en las cuentas con permisos de lectura de las suscripciones.

Descripción: la autenticación multifactor (MFA) debe estar habilitada para todas las cuentas de suscripción con privilegios de lectura para evitar una infracción de cuentas o recursos. (Directiva relacionada: MFA debe habilitarse en cuentas con permisos de lectura en la suscripción).

Gravedad: alta

MFA debe estar habilitado en las cuentas con permisos de escritura de las suscripciones.

Descripción: la autenticación multifactor (MFA) debe estar habilitada para todas las cuentas de suscripción con privilegios de escritura para evitar una vulneración de cuentas o recursos. (Directiva relacionada: MFA debe estar habilitada para las cuentas con permisos de escritura en la suscripción).

Gravedad: alta

Se debe habilitar Microsoft Defender para Key Vault

Descripción: Microsoft Defender for Cloud incluye Microsoft Defender para Key Vault, lo que proporciona una capa adicional de inteligencia de seguridad. Microsoft Defender para Key Vault detecta intentos inusuales y potencialmente perjudiciales de acceder a las cuentas de Key Vault o de vulnerarlas.

Las protecciones de este plan se cobran como se muestra en la página Planes de Defender. Si no tiene ningún almacén de claves en esta suscripción, no se le cobrará. Si más adelante crea almacenes de claves en esta suscripción, se protegerán automáticamente y comenzarán a aplicarse cargos. Más información sobre los detalles de los precios por región Más información en Introducción a Microsoft Defender para Key Vault (Directiva relacionada: Azure Defender para Key Vault debe estar habilitado).

Gravedad: alta

Se deben revocar los permisos de identidades inactivas en la suscripción de Azure.

Descripción: Microsoft Defender for Cloud detectó una identidad que no ha realizado ninguna acción en ningún recurso dentro de la suscripción de Azure en los últimos 45 días. Se recomienda revocar permisos de identidades inactivas para reducir la superficie expuesta a ataques del entorno en la nube.

Gravedad: media

Se debe configurar un punto de conexión privado para Key Vault

Descripción: Private Link proporciona una manera de conectar Key Vault a los recursos de Azure sin enviar tráfico a través de la red pública de Internet. Un vínculo privado proporciona varios niveles de protección contra la filtración de datos. (Directiva relacionada: El punto de conexión privado debe configurarse para Key Vault.

Gravedad: media

No se debe permitir el acceso público a la cuenta de almacenamiento

Descripción: el acceso de lectura público anónimo a contenedores y blobs en Azure Storage es una manera cómoda de compartir datos, pero podría presentar riesgos de seguridad. Para evitar las infracciones de datos producidas por el acceso anónimo no deseado, Microsoft recomienda impedir el acceso público a una cuenta de almacenamiento a menos que su escenario lo requiera. (Directiva relacionada: No se debe permitir el acceso público de la cuenta de almacenamiento).

Gravedad: media

Debe haber más de un propietario asignado a las suscripciones.

Descripción: designe más de un propietario de la suscripción para tener redundancia de acceso de administrador. (Directiva relacionada: Debe haber más de un propietario asignado a la suscripción).

Gravedad: alta

El período de validez de los certificados almacenados en Azure Key Vault no debe superar los 12 meses

Descripción: asegúrese de que los certificados no tengan un período de validez que supere los 12 meses. (Directiva relacionada: Los certificados deben tener el período de validez máximo especificado).

Gravedad: media

Las identidades sobreaprovisionadas de Azure solo deben tener los permisos necesarios (versión preliminar)

Descripción: las identidades sobreaprovisionadas o las identidades con permisos no usan muchos de sus permisos concedidos. Permisos de tamaño correcto de estas identidades periódicamente para reducir el riesgo de uso indebido de permisos, ya sea accidental o malintencionado. Esta acción reduce el radio potencial de explosión durante un incidente de seguridad.

Gravedad: media

Las super identidades del entorno de Azure deben quitarse (versión preliminar)

Descripción: Super Identity es cualquier identidad humana o de carga de trabajo, como usuarios, entidades de servicio y funciones sin servidor que tienen permisos de administrador y puede realizar cualquier acción en cualquier recurso de toda la infraestructura. Super Identities es extremadamente alto, ya que cualquier uso incorrecto de permisos malintencionados o accidentales puede dar lugar a interrupciones catastróficas del servicio, degradación del servicio o pérdida de datos. Las super identidades suponen una gran amenaza para la infraestructura en la nube. Demasiadas superidentidades pueden crear riesgos excesivos y aumentar el radio de explosión durante una infracción.

Gravedad: media

Recomendaciones de acceso e identidad de AWS

Los dominios de Amazon Elasticsearch Service deben estar en un VPC.

Descripción: VPC no puede contener dominios con un punto de conexión público. Esto no evalúa la configuración de enrutamiento de subred de VPC para determinar la accesibilidad pública.

Gravedad: alta

Se deben restringir los permisos de Amazon S3 concedidos a otras cuentas de AWS en las directivas de cubo.

Descripción: la implementación del acceso con privilegios mínimos es fundamental para reducir el riesgo de seguridad y el impacto de errores o intenciones malintencionadas. Si una directiva para los cubos de S3 permite el acceso desde cuentas externas, podría provocar la filtración de datos por una amenaza interna o un atacante. El parámetro "blacklistedactionpatterns" permite una evaluación correcta de la regla para los cubos de S3. El parámetro concede acceso a cuentas externas para patrones de acción que no se incluyen en la lista "blacklistedactionpatterns".

Gravedad: alta

Permite evitar el uso de la cuenta "raíz".

Descripción: la cuenta "raíz" tiene acceso sin restricciones a todos los recursos de la cuenta de AWS. Se recomienda encarecidamente evitar el uso de esta cuenta. La cuenta "raíz" es la cuenta de AWS con más privilegios. Minimizar el uso de esta cuenta y adoptar el principio de privilegios mínimos para la administración de acceso reducirá el riesgo de cambios accidentales y la divulgación no intencionada de credenciales con privilegios elevados.

Gravedad: alta

Las claves KMS de AWS no se deben eliminar involuntariamente.

Descripción: este control comprueba si las claves de KMS están programadas para su eliminación. Este control genera un error si una clave de KMS está programada para su eliminación. Las claves de KMS no se pueden recuperar una vez eliminadas. Los datos cifrados con una clave de KMS también son irrecuperables permanentemente si se elimina la clave de KMS. Si los datos significativos se han cifrado con una clave KMS programada para su eliminación, considere la posibilidad de descifrar los datos o volver a cifrar los datos en una nueva clave de KMS a menos que realice intencionadamente una eliminación criptográfica. Cuando una clave de KMS está programada para su eliminación, se aplica un período de espera obligatorio para permitir el tiempo de revertir la eliminación, si se programó por error. El período de espera predeterminado es de 30 días, pero se puede reducir a tan poco como siete días cuando la clave kmS está programada para su eliminación. Durante el período de espera, se puede cancelar la eliminación programada y no se eliminará la clave KMS. Para obtener más información sobre la eliminación de claves de KMS, consulte Eliminación de claves de KMS en la Guía para desarrolladores de AWS Servicio de administración de claves.

Gravedad: alta

Las identidades sobreaprovisionadas de AWS solo deben tener los permisos necesarios (versión preliminar)

Descripción: una identidad activa sobreaprovisionada es una identidad que tiene acceso a privilegios que no han usado. Las identidades activas sobreaprovisionadas, especialmente para las cuentas no humanas que tienen acciones y responsabilidades definidas, pueden aumentar el radio de explosión en caso de que un usuario, una clave o un recurso se vean comprometidos. Quite los permisos innecesarios y establezca procesos de revisión para lograr los permisos con menos privilegios.

Gravedad: media

El registro de ACL web global de AWS WAF Classic debe estar habilitado.

Descripción: este control comprueba si el registro está habilitado para una ACL web global de AWS WAF. Este control produce un error si el registro no está habilitado para la ACL web. El registro es una parte importante del mantenimiento de la confiabilidad, la disponibilidad y el rendimiento de AWS WAF globalmente. Es un requisito empresarial y de cumplimiento en muchas organizaciones y le permite solucionar problemas de comportamiento de la aplicación. También proporciona información detallada sobre el tráfico que analiza la ACL web asociada a AWS WAF.

Gravedad: media

Las distribuciones de CloudFront deben tener configurado un objeto raíz predeterminado.

Descripción: este control comprueba si una distribución de Amazon CloudFront está configurada para devolver un objeto específico que es el objeto raíz predeterminado. El control produce un error si la distribución de CloudFront no tiene configurado un objeto raíz predeterminado. A veces, un usuario puede solicitar la dirección URL raíz de las distribuciones en lugar de un objeto de la distribución. Cuando esto sucede, especificar un objeto raíz predeterminado puede ayudarle a evitar exponer el contenido de la distribución web.

Gravedad: alta

Las distribuciones de CloudFront deben tener habilitada la identidad de acceso de origen.

Descripción: este control comprueba si una distribución de Amazon CloudFront con el tipo de origen de Amazon S3 tiene configurada Origin Access Identity (OAI). Se produce un error en el control si OAI no está configurado. OAI de CloudFront impide que los usuarios accedan directamente al contenido del cubo de S3. Cuando los usuarios acceden directamente a un cubo de S3, omiten de forma eficaz la distribución de CloudFront y los permisos que se aplican al contenido del cubo de S3 subyacente.

Gravedad: media

La validación del archivo de registro de CloudTrail debe estar habilitada.

Descripción: para garantizar la comprobación de integridad adicional de los registros de CloudTrail, se recomienda habilitar la validación de archivos en todos los cloudTrails.

Gravedad: baja

CloudTrail debe estar habilitado.

Descripción: AWS CloudTrail es un servicio web que registra las llamadas a la API de AWS para su cuenta y le entrega archivos de registro. No todos los servicios habilitan el registro de forma predeterminada para todas las API y los eventos. Debe implementar cualquier pista de auditoría adicional que no sea CloudTrail y revisar la documentación de cada servicio en Integraciones y servicios admitidos de CloudTrail.

Gravedad: alta

Los registros de seguimiento de CloudTrail deben estar integrados con CloudWatch Logs.

Descripción: además de capturar registros de CloudTrail dentro de un cubo S3 especificado para el análisis a largo plazo, el análisis en tiempo real se puede realizar configurando CloudTrail para enviar registros a CloudWatch Logs. Para una pista que está habilitada en todas las regiones de una cuenta, CloudTrail envía archivos de registro de todas esas regiones a un grupo de registros de CloudWatch Logs. Se recomienda que los registros de CloudTrail se envíen a CloudWatch Logs para asegurarse de que la actividad de la cuenta de AWS se captura, supervisa y notifica correctamente. El envío de registros de CloudTrail a CloudWatch Logs facilita el registro de actividad histórico y en tiempo real en función del usuario, la API, el recurso y la dirección IP, y brinda la oportunidad de establecer alarmas y notificaciones para la actividad anómala o de la cuenta de confidencialidad.

Gravedad: baja

El registro de bases de datos debe estar habilitado.

Descripción: este control comprueba si los siguientes registros de Amazon RDS están habilitados y se envían a CloudWatch Logs:

• Oracle: (Alert, Audit, Trace, Listener)
• PostgreSQL: (Postgresql, Actualización)
• MySQL: (Auditoría, Error, General, SlowQuery)
• MariaDB: (Audit, Error, General, SlowQuery)
• SQL Server: (Error, Agente)
• Aurora: (Audit, Error, General, SlowQuery)
• Aurora-MySQL: (Auditoría, Error, General, SlowQuery)
• Aurora-PostgreSQL: (Postgresql, Upgrade). Las bases de datos de RDS deben tener habilitados los registros pertinentes. El registro de base de datos proporciona registros detallados de las solicitudes realizadas a RDS. Los registros de base de datos pueden ayudar con las auditorías de seguridad y acceso, así como con el diagnóstico de problemas de disponibilidad.

Gravedad: media

Deshabilitación del acceso directo a Internet para instancias de cuadernos de Amazon Sage Maker

Descripción: el acceso directo a Internet debe deshabilitarse para una instancia de bloc de notas de Sage Maker. Esto comprueba si el campo "DirectInternetAccess" está deshabilitado para la instancia del cuaderno. La instancia debe configurarse con una VPC y la configuración predeterminada debe ser Deshabilitar: acceso a Internet a través de una VPC. Para habilitar el acceso a Internet para entrenar u hospedar modelos desde un cuaderno, asegúrese de que la VPC tiene NAT Gateway y que el grupo de seguridad permite conexiones salientes. Asegúrese de que el acceso a la configuración de Sage Maker solo está limitado a los usuarios autorizados y restrinja los permisos de IAM de los usuarios para modificar la configuración y los recursos de Sage Maker.

Gravedad: alta

No configure claves de acceso durante la configuración de usuario inicial para todos los usuarios de IAM que tengan una contraseña de consola.

Descripción: la consola de AWS tiene como valor predeterminado la casilla para crear claves de acceso a habilitadas. Esto provoca que muchas claves de acceso se generen innecesariamente. Además de las credenciales innecesarias, también genera un trabajo de administración innecesario en la auditoría y rotación de estas claves. Requerir que el usuario realice pasos adicionales después de crear su perfil proporcionará una indicación más sólida de la intención de que las claves de acceso sean [a] necesarias para su trabajo y [b] una vez establecida la clave de acceso en una cuenta que las claves podrían estar en uso en algún lugar de la organización.

Gravedad: media

Asegúrese de que se haya creado un rol de soporte técnico para administrar los incidentes con el soporte técnico de AWS.

Descripción: AWS proporciona un centro de soporte técnico que se puede usar para la notificación y respuesta a incidentes, así como el soporte técnico y los servicios de atención al cliente. Cree un rol IAM para permitir a los usuarios autorizados administrar incidentes con el soporte técnico de AWS. Al implementar privilegios mínimos para el control de acceso, un rol de IAM requiere una directiva de IAM adecuada para permitir el acceso al Centro de soporte técnico para administrar incidentes con soporte técnico de AWS.

Gravedad: baja

Asegúrese de que las claves de acceso cambian cada 90 días o menos.

Descripción: las claves de acceso constan de un identificador de clave de acceso y una clave de acceso secreta, que se usan para firmar solicitudes mediante programación que realice en AWS. Los usuarios de AWS necesitan sus propias claves de acceso para realizar llamadas mediante programación a AWS desde la interfaz de la línea de comandos de AWS (CLI de AWS), herramientas para Windows PowerShell, los SDK de AWS o llamadas HTTP directas mediante las API para servicios individuales de AWS. Se recomienda que todas las claves de acceso se giren periódicamente. La rotación de claves de acceso reduce la ventana de oportunidad de una clave de acceso asociada a una cuenta en peligro o terminada que se va a usar. Las claves de acceso deben rotarse para asegurarse de que no se puede acceder a los datos con una clave antigua, que podría haberse perdido, descifrado o robado.

Gravedad: media

Asegúrese de que AWS Config está habilitado en todas las regiones.

Descripción: AWS Config es un servicio web que realiza la administración de la configuración de los recursos de AWS admitidos dentro de su cuenta y le 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 los cambios de configuración entre los recursos. Se recomienda habilitar AWS Config en todas las regiones.

El historial de elementos de configuración de AWS capturado por AWS Config permite el análisis de seguridad, el seguimiento de cambios de recursos y la auditoría de cumplimiento.

Gravedad: media

Asegúrese de que CloudTrail está habilitado en todas las regiones.

Descripción: AWS CloudTrail es un servicio web que registra las llamadas a la API de AWS para su cuenta y le entrega archivos de registro. La información registrada incluye la identidad del autor de la llamada API, la hora de la llamada API, la dirección IP de origen del autor de la llamada API, los parámetros de solicitud y los elementos de respuesta devueltos por el servicio AWS. CloudTrail proporciona un historial de llamadas API de AWS para una cuenta, incluidas las llamadas API realizadas a través de la consola de administración, los SDK, las herramientas de línea de comandos y los servicios de AWS de nivel superior (como CloudTrail). El historial de llamadas API de AWS generado por CloudTrail permite el análisis de seguridad, el seguimiento de cambios de recursos y la auditoría de cumplimiento. Además:

• La comprobación de que existe un rastro de varias regiones garantiza que se detecte una actividad inesperada en regiones que no se usen de otro modo.
• Comprobar que existe una pista de varias regiones garantiza que "Registro de servicios globales" esté habilitado para una pista de forma predeterminada para capturar la grabación de eventos generados en los servicios globales de AWS.
• Para una pista de varias regiones, comprobar que los eventos de administración están configurados para todo tipo de lectura y escritura garantiza la grabación de operaciones de administración que se realizan en todos los recursos de una cuenta de AWS.

Gravedad: alta

Asegúrese de que las credenciales no utilizadas durante 90 días o más estén deshabilitadas.

Descripción: los usuarios de AWS IAM pueden acceder a los recursos de AWS mediante diferentes tipos de credenciales, como contraseñas o claves de acceso. Se recomienda quitar o desactivar todas las credenciales que no se hanusado en 90 o posteriores días. Al deshabilitar o quitar credenciales innecesarias, se reduce la ventana de oportunidad de las credenciales asociadas a una cuenta en peligro o abandonada que se va a usar.

Gravedad: media

Asegúrese de que la directiva de contraseñas de IAM expire las contraseñas en un plazo máximo de 90 días.

Descripción: las directivas de contraseña de IAM pueden requerir que las contraseñas se rotan o expiren después de un número determinado de días. Se recomienda que la directiva de contraseña expire las contraseñas después de 90 días o menos. La reducción de la vigencia de la contraseña aumenta la resistencia de la cuenta frente a los intentos de inicio de sesión por fuerza bruta. Además, requerir cambios de contraseña periódicos ayuda en los escenarios siguientes:

• Las contraseñas se pueden robar o poner en peligro a veces sin su conocimiento. Esto puede ocurrir por un riesgo del sistema, una vulnerabilidad de software o una amenaza interna.
• Ciertos filtros web corporativos y gubernamentales o servidores proxy tienen la capacidad de interceptar y registrar el tráfico incluso si está cifrado.
• Muchas personas usan la misma contraseña para muchos sistemas, como trabajo, correo electrónico y personal.
• Es posible que las estaciones de trabajo del usuario final en peligro tengan un registrador de pulsaciones de teclas.

Gravedad: baja

Asegúrese de que la política de contraseñas de IAM impide la reutilización de contraseñas.

Descripción: las directivas de contraseña de IAM pueden impedir la reutilización de una contraseña determinada por el mismo usuario. Se recomienda que la directiva de contraseña impida la reutilización de contraseñas. La reducción de la vigencia de la contraseña aumenta la resistencia de la cuenta frente a los intentos de inicio de sesión por fuerza bruta.

Gravedad: baja

Asegúrese de que la directiva de contraseñas de IAM requiere al menos una letra minúscula.

Descripción: las directivas de contraseña se usan, en parte, para aplicar los requisitos de complejidad de contraseñas. Las directivas de contraseña de IAM se pueden usar para asegurarse de que la contraseña se compone de diferentes juegos de caracteres. Se recomienda que la directiva de contraseña requiera al menos una letra minúscula. Establecer una directiva de complejidad de contraseña aumenta la resistencia de la cuenta frente a los intentos de inicio de sesión por fuerza bruta.

Gravedad: media

Asegúrese de que la directiva de contraseñas de IAM requiera al menos un número.

Descripción: las directivas de contraseña se usan, en parte, para aplicar los requisitos de complejidad de contraseñas. Las directivas de contraseña de IAM se pueden usar para asegurarse de que la contraseña se compone de diferentes juegos de caracteres. Se recomienda que la directiva de contraseñas requiera al menos un número. Establecer una directiva de complejidad de contraseña aumenta la resistencia de la cuenta frente a los intentos de inicio de sesión por fuerza bruta.

Gravedad: media

Asegúrese de que la directiva de contraseñas de IAM requiere al menos un símbolo.

Descripción: las directivas de contraseña se usan, en parte, para aplicar los requisitos de complejidad de contraseñas. Las directivas de contraseña de IAM se pueden usar para asegurarse de que la contraseña se compone de diferentes juegos de caracteres. Se recomienda que la directiva de contraseñas requiera al menos un símbolo. Establecer una directiva de complejidad de contraseña aumenta la resistencia de la cuenta frente a los intentos de inicio de sesión por fuerza bruta.

Gravedad: media

Asegúrese de que la directiva de contraseñas de IAM requiere al menos una letra mayúscula.

Descripción: las directivas de contraseña se usan, en parte, para aplicar los requisitos de complejidad de contraseñas. Las directivas de contraseña de IAM se pueden usar para asegurarse de que la contraseña se compone de diferentes juegos de caracteres. Se recomienda que la directiva de contraseña requiera al menos una letra mayúscula. Establecer una directiva de complejidad de contraseña aumenta la resistencia de la cuenta frente a los intentos de inicio de sesión por fuerza bruta.

Gravedad: media

Asegúrese de que la directiva de contraseñas de IAM requiere una longitud mínima de 14 caracteres.

Descripción: las directivas de contraseña se usan, en parte, para aplicar los requisitos de complejidad de contraseñas. Las directivas de contraseñas de IAM se pueden usar para asegurarse de que la contraseña tenga al menos una longitud determinada. Se recomienda que la directiva de contraseña requiera una longitud mínima de contraseña "14". Establecer una directiva de complejidad de contraseña aumenta la resistencia de la cuenta frente a los intentos de inicio de sesión por fuerza bruta.

Gravedad: media

Asegúrese de que la autenticación multifactor (MFA) esté habilitada para todos los usuarios de IAM que tengan una contraseña de consola.

Descripción: La autenticación multifactor (MFA) agrega una capa adicional de protección sobre un nombre de usuario y una contraseña. Con MFA habilitado, cuando un usuario inicie sesión en un sitio web de AWS, se le pedirá su nombre de usuario y contraseña, así como un código de autenticación desde su dispositivo AWS MFA. Se recomienda habilitar MFA para todas las cuentas que tengan una contraseña de consola. Habilitar MFA proporciona mayor seguridad para el acceso a la consola, ya que requiere que la entidad de seguridad de autenticación posea un dispositivo que emita una clave sujeta a limitación temporal y tenga conocimiento de una credencial.

Gravedad: media

GuardDuty debe estar habilitado.

Descripción: Para proporcionar protección adicional contra intrusiones, GuardDuty debe estar habilitado en su cuenta y región de AWS.

Es posible que GuardDuty no sea una solución completa para cada entorno.

Gravedad: media

La MFA de hardware debe estar habilitada para la cuenta "raíz".

Descripción: la cuenta raíz es el usuario con más privilegios de una cuenta. MFA agrega una capa adicional de protección sobre un nombre de usuario y una contraseña. Con MFA habilitado, cuando un usuario inicia sesión en un sitio web de AWS, se le pedirá su nombre de usuario y contraseña, así como un código de autenticación desde su dispositivo AWS MFA. Para el nivel 2, se recomienda proteger la cuenta raíz con una MFA de hardware. MFA de hardware tiene una superficie de ataque más pequeña que una MFA virtual. Por ejemplo, MFA de hardware no tiene la superficie de ataque a la que está expuesto un smartphone en el que reside una MFA virtual. Cuando se usa hardware para MFA para muchos, muchas cuentas pueden crear un problema de administración de dispositivos logísticos. Si esto ocurre, considere la posibilidad de implementar esta recomendación de nivel 2 de forma selectiva en las cuentas de mayor seguridad. A continuación, puede aplicar la recomendación de nivel 1 a las cuentas restantes.

Gravedad: baja

La autenticación de IAM debe configurarse para clústeres de RDS.

Descripción: este control comprueba si un clúster de base de datos de RDS tiene habilitada la autenticación de base de datos IAM. La autenticación de base de datos IAM permite la autenticación sin contraseña en las instancias de base de datos. La autenticación usa un token de autenticación. El tráfico de red hacia y desde la base de datos se cifra mediante SSL. Para más información, vea Autenticación de bases de datos de IAM en la Guía del usuario de Amazon Aurora.

Gravedad: media

La autenticación de IAM debe configurarse para las instancias de RDS.

Descripción: este control comprueba si una instancia de base de datos de RDS tiene habilitada la autenticación de base de datos IAM. La autenticación de base de datos de IAM permite la autenticación en instancias de base de datos con un token de autenticación en lugar de una contraseña. El tráfico de red hacia y desde la base de datos se cifra mediante SSL. Para más información, vea Autenticación de bases de datos de IAM en la Guía del usuario de Amazon Aurora.

Gravedad: media

Las directivas administradas por el cliente de IAM no deben permitir acciones de descifrado en todas las claves de KMS.

Descripción: comprueba si la versión predeterminada de las directivas administradas por el cliente de IAM permite a las entidades de seguridad usar las acciones de descifrado de AWS KMS en todos los recursos. Este control usa Zelkova, un motor de razonamiento automatizado, para validar y advertirle de las directivas que podrían conceder acceso amplio a los secretos en todas las cuentas de AWS. Este control produce un error si se permiten las acciones "kms: Decrypt" o "kms: ReEncryptFrom" en todas las claves de KMS. El control evalúa las directivas administradas por el cliente adjuntas y no adjuntas. No comprueba las directivas insertadas ni las directivas administradas de AWS. Con AWS KMS, puede controlar quién puede usar las claves de KMS y obtener acceso a los datos cifrados. Las directivas de IAM definen qué acciones puede realizar una identidad (usuario, grupo o rol) en qué recursos. Siguiendo los procedimientos recomendados de seguridad, AWS recomienda permitir privilegios mínimos. En otras palabras, debe conceder a las identidades solo los permisos "kms:Decrypt" o "kms:ReEncryptFrom" y solo para las claves necesarias para realizar una tarea. De lo contrario, el usuario podría usar claves que no son adecuadas para los datos. En lugar de conceder permisos para todas las claves, determine el conjunto mínimo de claves que los usuarios necesitan para acceder a los datos cifrados. A continuación, diseñe directivas que permitan a los usuarios emplear solo esas claves. Por ejemplo, no permita el permiso "kms: Decrypt" en todas las claves de KMS. En su lugar, permita "kms: Decrypt" solo en claves de una región determinada para su cuenta. Al adoptar el principio de privilegios mínimos, puede reducir el riesgo de divulgación involuntaria de los datos.

Gravedad: media

Las directivas de administración de cliente de IAM que cree no deben permitir acciones con carácter comodín para los servicios.

Descripción: este control comprueba si las directivas basadas en identidades de IAM que se crean tienen instrucciones Allow que usan el carácter comodín * para conceder permisos para todas las acciones de cualquier servicio. Se produce un error en el control si alguna instrucción de directiva incluye 'Effect': 'Allow' con 'Action': 'Service:*'. Por ejemplo, la siguiente instrucción de una directiva genera un error de búsqueda.

'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:*',
  'Resource': '*'
}

El control también produce un error si usa "Effect": "Allow" con "NotAction": "service:". En ese caso, el elemento NotAction proporciona acceso a todas las acciones de un servicio de AWS, excepto las acciones especificadas en NotAction. Este control solo se aplica a las directivas de IAM administradas por el cliente. No se aplica a las directivas de IAM administradas por AWS. Al asignar permisos a los servicios de AWS, es importante definir el ámbito de las acciones de IAM permitidas en las directivas de IAM. Debe restringir las acciones de IAM solo a las acciones necesarias. Esto le ayuda a aprovisionar permisos con privilegios mínimos. Las directivas excesivamente permisivas pueden dar lugar a la elevación de privilegios si las directivas están asociadas a una entidad de seguridad de IAM que podría no requerir el permiso. En algunos casos, es posible que desee permitir acciones de IAM que tengan un prefijo similar, como DescribeFlowLogs y DescribeAvailabilityZones. En estos casos autorizados, puede agregar un comodín con sufijo al prefijo común. Por ejemplo, ec2:Describe.

Este control se pasa si usa una acción de IAM con prefijo que tenga un carácter comodín con sufijo. Por ejemplo, la siguiente instrucción de una directiva genera una búsqueda correcta.

 'Statement': [
{
  'Sid': 'EC2-Wildcard',
  'Effect': 'Allow',
  'Action': 'ec2:Describe*',
  'Resource': '*'
}

Al agrupar las acciones de IAM relacionadas de esta manera, también puede evitar superar los límites de tamaño de la directiva de IAM.

Gravedad: baja

Asegúrese de que las directivas de IAM se asocian solo a grupos o roles.

Descripción: de forma predeterminada, los usuarios, grupos y roles de IAM no tienen acceso a los recursos de AWS. Las directivas de IAM son los medios por los que se conceden privilegios a los usuarios, grupos o roles. Se recomienda aplicar directivas de IAM directamente a grupos y roles, pero no a los usuarios. La asignación de privilegios en el nivel de grupo o rol reduce la complejidad de la administración de acceso a medida que aumenta el número de usuarios. Reducir la complejidad de la administración de acceso también puede reducir la oportunidad de que una entidad de seguridad reciba o conserve privilegios excesivos accidentalmente.

Gravedad: baja

Asegúrese de que no se creen directivas de IAM que concedan privilegios administrativos ":" completos

Descripción: las directivas de IAM son los medios por los que se conceden privilegios a usuarios, grupos o roles. Se recomienda y se considera un consejo de seguridad estándar para conceder privilegios mínimos, es decir, conceder solo los permisos necesarios para realizar una tarea. Determine qué deben hacer los usuarios y, a continuación, cree directivas para ellos que permitan a los usuarios realizar solo esas tareas, en lugar de conceder privilegios administrativos completos. Es más seguro empezar con un conjunto mínimo de permisos y conceder permisos adicionales según sea necesario, en lugar de empezar con permisos demasiado flexibles y, a continuación, intentar reforzarlos más adelante. Proporcionar privilegios administrativos completos en lugar de restringir al conjunto mínimo de permisos para lo que el usuario debe hacer expone los recursos a acciones potencialmente no deseadas. Las directivas de IAM que tienen una instrucción con "Effect": "Allow" con "Action": "" sobre "Resource": "" se deben quitar.

Gravedad: alta

Las entidades de seguridad de IAM no deben tener directivas insertadas de IAM que permitan realizar acciones de descifrado en todas las claves de KMS.

Descripción: comprueba si las directivas insertadas que están insertadas en las identidades de IAM (rol, usuario o grupo) permiten las acciones de descifrado de AWS KMS en todas las claves de KMS. Este control usa Zelkova, un motor de razonamiento automatizado, para validar y advertirle de las directivas que podrían conceder acceso amplio a los secretos en todas las cuentas de AWS. Este control produce un error si kms:Decrypt se permiten acciones o kms:ReEncryptFrom en todas las claves de KMS de una directiva insertada. Con AWS KMS, puede controlar quién puede usar las claves de KMS y obtener acceso a los datos cifrados. Las directivas de IAM definen qué acciones puede realizar una identidad (usuario, grupo o rol) en qué recursos. Siguiendo los procedimientos recomendados de seguridad, AWS recomienda permitir privilegios mínimos. En otras palabras, debe conceder a las identidades solo los permisos que necesitan y solo para las claves necesarias para realizar una tarea. De lo contrario, el usuario podría usar claves que no son adecuadas para los datos. En lugar de conceder un permiso para todas las claves, determine el conjunto mínimo de claves que los usuarios necesitan para acceder a los datos cifrados. A continuación, diseñe directivas que permitan a los usuarios emplear solo esas claves. Por ejemplo, no permita el kms:Decrypt permiso en todas las claves de KMS. En su lugar, concédales el permiso solo en las claves de una región determinada para su cuenta. Al adoptar el principio de privilegios mínimos, puede reducir el riesgo de divulgación involuntaria de los datos.

Gravedad: media

Las funciones lambda deben restringir el acceso público.

Descripción: la directiva basada en recursos de función lambda debe restringir el acceso público. Esta recomendación no comprueba el acceso por entidades de seguridad internas. Asegúrese de que el acceso a la función está restringido a entidades de seguridad autorizadas solo mediante directivas basadas en recursos con privilegios mínimos.

Gravedad: alta

La MFA debe estar habilitada para todos los usuarios de IAM.

Descripción: todos los usuarios de IAM deben tener habilitada la autenticación multifactor (MFA).

Gravedad: media

La MFA debe estar habilitada para la cuenta "raíz".

Descripción: la cuenta raíz es el usuario con más privilegios de una cuenta. MFA agrega una capa adicional de protección sobre un nombre de usuario y una contraseña. Con MFA habilitado, cuando un usuario inicia sesión en un sitio web de AWS, se le pedirá su nombre de usuario y contraseña, así como un código de autenticación desde su dispositivo AWS MFA. Cuando se usa MFA virtual para las cuentas raíz, se recomienda que el dispositivo usado no sea un dispositivo personal. En su lugar, use un dispositivo móvil dedicado (tableta o teléfono) que administre para mantenerlo cargado y protegido independientemente de cualquier dispositivo personal individual. Esto reduce los riesgos de perder el acceso a la MFA debido a la pérdida del dispositivo, al cambio de dispositivos o a que el propietario del dispositivo ya no se encuentre en la empresa.

Gravedad: baja

Las directivas de contraseña para los usuarios de IAM deben tener configuraciones seguras.

Descripción: comprueba si la directiva de contraseñas de cuenta para los usuarios de IAM usa las siguientes configuraciones mínimas.

• RequireUppercaseCharacters: requiere al menos un carácter en mayúsculas en la contraseña. (El valor predeterminado es true)
• RequireLowercaseCharacters: requiere al menos un carácter en minúsculas en la contraseña. (El valor predeterminado es true)
• RequireNumbers: requerir al menos un número en la contraseña. (El valor predeterminado es true)
• MinimumPasswordLength: longitud mínima de contraseña. (Valor predeterminado = 7 o más)
• PasswordReusePrevention: número de contraseñas antes de permitir la reutilización. (Valor predeterminado = 4)
• MaxPasswordAge: número de días antes de la expiración de la contraseña. (Valor predeterminado = 90)

Gravedad: media

Se deben revocar los permisos de identidades inactivas en su cuenta de AWS.

Descripción: Microsoft Defender for Cloud detectó una identidad que no ha realizado ninguna acción en ningún recurso dentro de su cuenta de AWS en los últimos 45 días. Se recomienda revocar permisos de identidades inactivas para reducir la superficie expuesta a ataques del entorno en la nube.

Gravedad: media

La clave de acceso a la cuenta raíz no debe existir.

Descripción: la cuenta raíz es el usuario con más privilegios de una cuenta de AWS. Las claves de acceso de AWS proporcionan acceso mediante programación a una cuenta de AWS determinada. Se recomienda quitar todas las claves de acceso asociadas a la cuenta raíz. La eliminación de las claves de acceso asociadas a la cuenta raíz limita los vectores que pueden poner en peligro la cuenta. Además, la eliminación de las claves de acceso raíz fomenta la creación y el uso de cuentas basadas en roles con privilegios mínimos.

Gravedad: alta

La configuración de bloqueo de acceso público de S3 debe estar habilitada.

Descripción: habilitar la opción Bloquear acceso público para el cubo de S3 puede ayudar a evitar pérdidas de datos confidenciales y proteger el cubo de acciones malintencionadas.

Gravedad: media

La configuración de bloqueo de acceso público de S3 debe estar habilitada en el nivel de cubo.

Descripción: este control comprueba si los cubos de S3 tienen bloques de acceso público de nivel de cubo aplicados. Este control produce un error si alguna de las siguientes opciones de configuración se establece en false:

• ignorePublicAcls
• blockPublicPolicy
• blockPublicAcls
• restrictPublicBuckets Bloquear el acceso público en el nivel de cubo S3 proporciona controles para asegurarse de que los objetos nunca tienen acceso público. El acceso público se concede a los cubos y objetos a través de listas de control de acceso (ACL), directivas de cubo o ambos. A menos que quiera que los cubos de S3 sean accesibles públicamente, debe configurar la característica Bloquear acceso público de Amazon S3 a nivel de cubo.

Gravedad: alta

Se debe quitar el acceso de lectura público de los cubos de S3.

Descripción: quitar el acceso de lectura público al cubo de S3 puede ayudar a proteger los datos y evitar una vulneración de datos.

Gravedad: alta

Se debe quitar el acceso de escritura público de los cubos de S3.

Descripción: permitir el acceso de escritura pública a su cubo de S3 puede dejarle vulnerable a acciones malintencionadas, como almacenar datos a su costa, cifrar los archivos por rescate o usar su cubo para operar con malware.

Gravedad: alta

Los secretos de Secrets Manager deben tener habilitada la rotación automática.

Descripción: este control comprueba si un secreto almacenado en AWS Secrets Manager está configurado con rotación automática. Secrets Manager le ayuda a mejorar la posición de seguridad de su organización. Los secretos incluyen credenciales de base de datos, contraseñas y claves de API de terceros. Puede usar Secrets Manager para almacenar secretos de forma centralizada, cifrar secretos automáticamente, controlar el acceso a los secretos y rotar secretos de forma segura y automática. Secrets Manager puede rotar los secretos. Puede usar la rotación para reemplazar secretos a largo plazo por otros a corto plazo. La rotación de secretos limita cuánto tiempo un usuario no autorizado puede usar un secreto en peligro. Por este motivo, debe rotar los secretos con frecuencia. Para más información sobre la rotación, vea Rotar secretos de AWS Secrets Manager en la Guía del usuario de AWS Secrets Manager.

Gravedad: media

Las instancias de EC2 detenidas deben quitarse después de un período de tiempo especificado.

Descripción: este control comprueba si se han detenido instancias EC2 durante más de los días permitidos. Una instancia ec2 produce un error en esta comprobación si se detiene durante más tiempo que el período de tiempo máximo permitido, que de forma predeterminada es de 30 días. Un error de búsqueda indica que una instancia de EC2 no se ha ejecutado durante un período de tiempo significativo. Esto crea un riesgo de seguridad porque la instancia ec2 no se mantiene activamente (analizada, revisada, actualizada). Si se inicia más adelante, la falta de mantenimiento adecuado podría dar lugar a problemas inesperados en su entorno de AWS. Para mantener de forma segura una instancia de EC2 a lo largo del tiempo en un estado de no ejecución, iníciela periódicamente para el mantenimiento y, a continuación, deténgala después del mantenimiento. Lo ideal es que se trata de un proceso automatizado.

Gravedad: media

Las identidades sin usar en el entorno de AWS deben quitarse (versión preliminar)

Descripción: las identidades inactivas son entidades humanas y no humanas que no han realizado ninguna acción en ningún recurso en los últimos 90 días. Las identidades de IAM inactivas con permisos de alto riesgo en su cuenta de AWS pueden ser propensas a ataques si se dejan tal como está y dejan a las organizaciones abiertas al uso indebido o la explotación de credenciales. Detectar y responder proactivamente a identidades no utilizados le ayuda a evitar que las entidades no autorizadas obtengan acceso a los recursos de AWS.

Gravedad: media

Recomendaciones de acceso e identidad de GCP

Las claves criptográficas no deben tener más de tres usuarios.

Descripción: esta recomendación evalúa las directivas de IAM para anillos de claves, proyectos y organizaciones, y recupera entidades de seguridad con roles que les permiten cifrar, descifrar o firmar datos mediante claves de KMS en la nube: roles/propietario, roles/cloudkms.cryptoKeyEncrypterDecrypter, roles/cloudkms.cryptoKeyEncrypter, roles/cloudkms.cryptoKeyDecrypter, roles/cloudkms.signerVerifier.

Gravedad: media

Asegúrese de que no se creen claves de API para un proyecto.

Descripción: las claves no son seguras porque se pueden ver públicamente, como desde dentro de un explorador, o se puede acceder a ellas en un dispositivo donde reside la clave. Se recomienda usar el flujo de autenticación estándar en su lugar.

Los riesgos de seguridad que provienen del uso de claves de API aparecen a continuación:

• Las claves de API son cadenas cifradas simples
• Las claves de API no identifican al usuario ni a la aplicación que realiza la solicitud de API.
• Las claves de API suelen ser accesibles para los clientes, lo que facilita la detección y el robo de una clave de API.

Para evitar el riesgo de seguridad en el uso de claves de API, se recomienda usar el flujo de autenticación estándar en su lugar.

Gravedad: alta

Asegúrese de que las claves de API estén restringidas a solo las API que necesite acceso la aplicación.

Descripción: las claves de API no son seguras porque se pueden ver públicamente, como desde dentro de un explorador, o se puede acceder a ellas en un dispositivo donde reside la clave. Se recomienda restringir las claves de API para usar (llamar) solo a las API que requiere una aplicación.

Los riesgos de seguridad que provienen del uso de claves de API aparecen a continuación:

• Las claves de API son cadenas cifradas simples
• Las claves de API no identifican al usuario ni a la aplicación que realiza la solicitud de API.
• Las claves de API suelen ser accesibles para los clientes, lo que facilita la detección y el robo de una clave de API.

A la luz de estos posibles riesgos, Google recomienda usar el flujo de autenticación estándar en lugar de claves de API. Sin embargo, hay casos limitados en los que las claves de API son más adecuadas. Por ejemplo, si hay una aplicación móvil que necesita usar google Cloud Translation API, pero no necesita un servidor back-end, las claves de API son la manera más sencilla de autenticarse en esa API.

Para reducir las superficies expuestas a ataques proporcionando privilegios mínimos, las claves de API se pueden restringir para usar (llamar) solo a las API requeridas por una aplicación.

Gravedad: alta

Asegúrese de que las claves de API estén restringidas para que solo puedan usarlas aplicaciones y hosts especificados.

Descripción: las claves sin restricciones no son seguras porque se pueden ver públicamente, como desde dentro de un explorador, o se puede acceder a ellas en un dispositivo donde reside la clave. Se recomienda restringir el uso de claves de API a hosts de confianza, referencias HTTP y aplicaciones.

Los riesgos de seguridad que provienen del uso de claves de API aparecen a continuación:

• Las claves de API son cadenas cifradas simples
• Las claves de API no identifican al usuario ni a la aplicación que realiza la solicitud de API.
• Las claves de API suelen ser accesibles para los clientes, lo que facilita la detección y el robo de una clave de API.

A la luz de estos posibles riesgos, Google recomienda usar el flujo de autenticación estándar en lugar de claves de API. Sin embargo, hay casos limitados en los que las claves de API son más adecuadas. Por ejemplo, si hay una aplicación móvil que necesita usar google Cloud Translation API, pero no necesita un servidor back-end, las claves de API son la manera más sencilla de autenticarse en esa API.

Para reducir los vectores de ataque, las claves de API solo se pueden restringir a hosts de confianza, referencias HTTP y aplicaciones.

Gravedad: alta

Asegúrese de que las claves de API cambien cada 90 días.

Descripción: se recomienda rotar las claves de API cada 90 días.

Los riesgos de seguridad que provienen del uso de claves de API se enumeran a continuación:

• Las claves de API son cadenas cifradas simples
• Las claves de API no identifican al usuario ni a la aplicación que realiza la solicitud de API.
• Las claves de API suelen ser accesibles para los clientes, lo que facilita la detección y el robo de una clave de API.

Debido a estos posibles riesgos, Google recomienda usar el flujo de autenticación estándar en lugar de claves de API. Sin embargo, hay casos limitados en los que las claves de API son más adecuadas. Por ejemplo, si hay una aplicación móvil que necesita usar google Cloud Translation API, pero no necesita un servidor back-end, las claves de API son la manera más sencilla de autenticarse en esa API.

Una vez que se roba una clave, no tiene expiración, lo que significa que se puede usar indefinidamente a menos que el propietario del proyecto revoque o vuelva a generar la clave. La rotación de claves de API reducirá la ventana de posibilidades para que se utilice una clave de acceso asociada a una cuenta en peligro o terminada.

Las claves de API se deben rotar para asegurarse de que no se puede acceder a los datos con una clave antigua que podría haberse perdido, descifrado o robado.

Gravedad: alta

Asegúrese de que las claves de cifrado de KMS cambien en un plazo de 90 días.

Descripción: Google Cloud Servicio de administración de claves almacena claves criptográficas en una estructura jerárquica diseñada para una administración de control de acceso útil y elegante. El formato de la programación de la rotación depende de la biblioteca cliente que se use. Para la herramienta de línea de comandos de gcloud, la próxima hora de rotación debe estar en formato "ISO" o "RFC3339", y el período de rotación debe tener el formato "INTEGER[UNIT]," donde las unidades pueden ser de uno de segundos (s), minutos (m), horas (h) o días (d). Establezca un período de rotación de claves y la hora de inicio. Se puede crear una clave con un "período de rotación" especificado, que es el tiempo entre el momento en que se generan automáticamente nuevas versiones de clave. También se puede crear una clave con una hora especificada para la siguiente rotación. Una clave es un objeto con nombre que representa una "clave criptográfica" utilizada para un propósito específico. El material de clave, los bits reales usados para el "cifrado", pueden cambiar a lo largo del tiempo a medida que se crean nuevas versiones de clave. Se usa una clave para proteger algunos "corpus de datos". Una colección de archivos se podría cifrar con la misma clave y las personas con permisos de "descifrado" en esa clave podrían descifrar esos archivos. Por lo tanto, es necesario asegurarse de que el "período de rotación" esté establecido en un tiempo específico.

Gravedad: media

Asegúrese de que existan un filtro de métricas de registro y alertas para los cambios de asignaciones de propiedad del proyecto.

Descripción: para evitar asignaciones innecesarias de propiedad del proyecto a usuarios o cuentas de servicio y otros usos indebidos de proyectos y recursos, se deben supervisar todas las asignaciones de "roles/propietario". Los miembros (usuarios y cuentas de servicio) con una asignación de roles al rol primitivo "roles/propietario" son propietarios del proyecto. El propietario del proyecto tiene todos los privilegios del proyecto al que pertenece el rol. Se resumen a continuación:

• Todos los permisos de visor en todos los servicios GCP del proyecto
• Permisos para acciones que modifican el estado de todos los servicios de GCP dentro del proyecto
• Administración de roles y permisos para un proyecto y todos los recursos del proyecto
• Configurar la facturación de un proyecto Conceder el rol de propietario a un miembro (usuario/cuenta de servicio) permitirá a ese miembro modificar la directiva de administración de identidades y acceso (IAM). Por lo tanto, conceda el rol de propietario solo si el miembro tiene un propósito legítimo para administrar la directiva de IAM. Esto se debe a que la directiva de IAM del proyecto contiene datos de control de acceso confidenciales. Tener un conjunto mínimo de usuarios permitidos para administrar la directiva de IAM simplificará cualquier auditoría que pueda ser necesaria. La propiedad del proyecto tiene el nivel más alto de privilegios en un proyecto. Para evitar el uso indebido de los recursos del proyecto, las acciones de asignación o cambio de propiedad del proyecto mencionadas anteriormente se deben supervisar y alertar a los destinatarios afectados.
• Envío de invitaciones de propiedad del proyecto
• Aceptación o rechazo de la invitación de propiedad del proyecto por el usuario
• Agregar role\Owner a una cuenta de usuario o servicio
• Eliminación de una cuenta de usuario o servicio de role\Owner

Gravedad: baja

Asegúrese de que oslogin esté habilitado para un proyecto.

Descripción: al habilitar el inicio de sesión del sistema operativo, se enlazan los certificados SSH a los usuarios de IAM y se facilita la administración eficaz de certificados SSH. Al habilitar el inicio de sesión del sistema operativo, se garantiza que las claves SSH usadas para conectarse a las instancias se asignen a usuarios de IAM. Al revocar el acceso al usuario de IAM, se revocarán todas las claves SSH asociadas a ese usuario en particular. Facilita la administración centralizada y automatizada de pares de claves SSH, lo que resulta útil para controlar casos como la respuesta a pares de claves SSH en peligro o la revocación de usuarios externos, de terceros o proveedores. Para averiguar qué instancia hace que el proyecto sea incorrecto, consulte la recomendación "Asegúrese de que oslogin está habilitado para todas las instancias".

Gravedad: media

Asegúrese de que oslogin esté habilitado para todas las instancias.

Descripción: al habilitar el inicio de sesión del sistema operativo, se enlazan los certificados SSH a los usuarios de IAM y se facilita la administración eficaz de certificados SSH. Al habilitar el inicio de sesión del sistema operativo, se garantiza que las claves SSH usadas para conectarse a las instancias se asignen a usuarios de IAM. Al revocar el acceso al usuario de IAM, se revocarán todas las claves SSH asociadas a ese usuario en particular. Facilita la administración centralizada y automatizada de pares de claves SSH, lo que resulta útil para controlar casos como la respuesta a pares de claves SSH en peligro o la revocación de usuarios externos, de terceros o proveedores.

Gravedad: media

Asegúrese de que Cloud Audit Logging esté configurado correctamente en todos los servicios y en todos los usuarios de un proyecto.

Descripción: se recomienda configurar el registro de auditoría en la nube para realizar un seguimiento de todas las actividades de administrador y leer y escribir el acceso a los datos del usuario.

Cloud Audit Logging mantiene dos registros de auditoría para cada proyecto, carpeta y organización: actividad de administración y acceso a datos.

• El registro de actividad de administración contiene entradas de registro para llamadas API u otras acciones administrativas que modifican la configuración o los metadatos de los recursos.
• Los registros de auditoría de actividad de administración están habilitados para todos los servicios y no se pueden configurar.
• Los registros de auditoría de acceso a datos registran las llamadas API que crean, modifican o leen datos proporcionados por el usuario. Están deshabilitados de manera predeterminada y se deben habilitar.

Hay tres tipos de información del registro de auditoría de acceso a datos:

• Lectura de administración: registra las operaciones que leen metadatos o información de configuración. Los registros de auditoría de actividad de administración registran escrituras de metadatos e información de configuración que no se pueden deshabilitar.
• Lectura de datos: registra las operaciones que leen los datos proporcionados por el usuario.
• Escritura de datos: registra las operaciones que escriben datos proporcionados por el usuario.

Se recomienda tener configurada una configuración de auditoría predeterminada efectiva de tal manera que:

• El tipo de registro se establece en DATA_READ (para registrar el seguimiento de la actividad del usuario) y DATA_WRITES (para registrar cambios o alteraciones en los datos del usuario).
• La configuración de auditoría está habilitada para todos los servicios admitidos por la característica registros de auditoría de Acceso a datos.
• Los registros deben capturarse para todos los usuarios, es decir, no hay usuarios exentos en ninguna de las secciones de configuración de auditoría. Esto garantizará que la invalidación de la configuración de auditoría no contradiga el requisito.

Gravedad: media

Asegúrese de que las claves criptográficas de KMS en la nube no sean anónimas o accesibles públicamente

Descripción: se recomienda que la directiva de IAM en las claves criptográficas de KMS en la nube restrinja el acceso anónimo o público. Conceder permisos a "allUsers" o a "allAuthenticatedUsers" permite a cualquier usuario acceder al conjunto de datos. Este acceso podría no ser deseable si se almacenan datos confidenciales en la ubicación. En este caso, asegúrese de que no se permite el acceso anónimo o público a una clave criptográfica KMS en la nube.

Gravedad: alta

Asegúrese de que se usen las credenciales de inicio de sesión corporativas.

Descripción: use credenciales de inicio de sesión corporativo en lugar de cuentas personales, como cuentas de Gmail. Se recomienda usar cuentas corporativas de Google totalmente administradas para aumentar la visibilidad, la auditoría y controlar el acceso a los recursos de Cloud Platform. Las cuentas de Gmail basadas fuera de la organización del usuario, como las cuentas personales, no deben usarse para fines empresariales.

Gravedad: alta

Asegúrese de que los usuarios de IAM no tengan asignados los roles de usuario de cuenta de servicio o creador del token de la cuenta de servicio en el nivel de proyecto.

Descripción: se recomienda asignar los roles "Usuario de cuenta de servicio (iam.serviceAccountUser)" y "Creador de tokens de cuenta de servicio (iam.serviceAccountTokenCreator)" a un usuario para una cuenta de servicio específica en lugar de asignar el rol a un usuario en el nivel de proyecto. Una cuenta de servicio es una cuenta especial de Google que pertenece a una aplicación o a una máquina virtual, en lugar de a un usuario final individual. La aplicación o la instancia de máquina virtual usan la cuenta de servicio para llamar a la API de Google del servicio para que los usuarios no estén implicados directamente. Además de ser una identidad, una cuenta de servicio es un recurso que tiene directivas de IAM asociadas. Estas directivas determinan quién puede usar la cuenta de servicio. Los usuarios con roles de IAM para actualizar las instancias de App Engine y Compute Engine (como Implementador de App Engine o Administrador de instancias de Compute) pueden ejecutar código de forma eficaz como las cuentas de servicio usadas para ejecutar estas instancias y obtener acceso indirectamente a todos los recursos para los que las cuentas de servicio tengan acceso. Del mismo modo, el acceso SSH a una instancia de Compute Engine también puede proporcionar la capacidad de ejecutar código como esa instancia o cuenta de servicio. En función de las necesidades empresariales, podría haber varias cuentas de servicio administradas por el usuario configuradas para un proyecto. Conceder los roles "iam.serviceAccountUser" o "iam.serviceAserviceAccountTokenCreatorccountUser" a un usuario para un proyecto proporciona al usuario acceso a todas las cuentas de servicio del proyecto, incluidas las cuentas de servicio que podrían crearse en el futuro. Esto puede dar lugar a la elevación de privilegios mediante cuentas de servicio y las correspondientes "instancias del motor de proceso". Para implementar procedimientos recomendados de "privilegios mínimos", a los usuarios de IAM no se les deben asignar los roles "Usuario de cuenta de servicio" ni "Creador de tokens de cuenta de servicio" en el nivel de proyecto. En su lugar, estos roles se deben asignar a un usuario para una cuenta de servicio específica, lo que proporciona a ese usuario acceso a la cuenta de servicio. El rol "Usuario de cuenta de servicio" permite a un usuario enlazar una cuenta de servicio a un servicio de trabajo de larga duración, mientras que el rol "Creador del token de la cuenta de servicio" permite a un usuario suplantar (o realizar aserciones en su nombre) directamente la identidad de una cuenta de servicio.

Gravedad: media

Asegúrese de que se aplique la separación de obligaciones al asignar roles relacionados con KMS a los usuarios.

Descripción: se recomienda aplicar el principio de "Separación de tareas" al asignar roles relacionados con KMS a los usuarios. El rol de IAM integrado o predefinido "Administrador de Cloud KMS" permite al usuario o la identidad crear, eliminar y administrar cuentas de servicio. El rol Cloud KMS CryptoKey Encrypter/Decrypter de IAM integrado o predefinido permite al usuario o identidad (con privilegios adecuados en los recursos afectados) cifrar y descifrar datos en reposo mediante claves de cifrado. El rol Cloud KMS CryptoKey Encrypter de IAM integrado o predefinido permite al usuario o identidad (con privilegios adecuados en los recursos afectados) cifrar los datos en reposo mediante claves de cifrado. El rol Cloud KMS Crypto Key Decrypter de IAM integrado o predefinido permite al usuario o identidad (con privilegios adecuados en los recursos afectados) descifrar los datos en reposo mediante las claves de cifrado. La separación de tareas es el concepto de garantizar que una persona no tenga todos los permisos necesarios para poder completar una acción malintencionada. En KMS en la nube, esto podría ser una acción como usar una clave para acceder a los datos y descifrar a los que un usuario no debería tener acceso normalmente. La separación de obligaciones es un control empresarial que se usa normalmente en organizaciones de mayor tamaño, diseñadas para ayudar a evitar incidentes y errores de seguridad o privacidad. Se considera un procedimiento recomendado. Ningún usuario debe tener administrador de KMS en la nube y ninguno de los Cloud KMS CryptoKey Encrypter/Decrypterroles , Cloud KMS CryptoKey Encrypter, Cloud KMS CryptoKey Decrypter asignados al mismo tiempo.

Gravedad: alta

Asegúrese de que se aplique la separación de obligaciones al asignar roles relacionados con la cuenta de servicio a los usuarios.

Descripción: se recomienda aplicar el principio de "Separación de tareas" al asignar roles relacionados con la cuenta de servicio a los usuarios. El rol de IAM integrado o predefinido "Administrador de cuenta de servicio" permite al usuario o la identidad crear, eliminar y administrar cuentas de servicio. El rol de IAM integrado o predefinido "Usuario de cuenta de servicio" permite al usuario o la identidad (con privilegios adecuados en Compute y App Engine) asignar cuentas de servicio a aplicaciones o instancias de proceso. La separación de tareas es el concepto de garantizar que una persona no tenga todos los permisos necesarios para poder completar una acción malintencionada. En IAM en la nube: cuentas de servicio, esto podría ser una acción como el uso de una cuenta de servicio para acceder a los recursos a los que normalmente el usuario no debería tener acceso. La separación de obligaciones es un control empresarial que se usa normalmente en organizaciones de mayor tamaño, diseñadas para ayudar a evitar incidentes y errores de seguridad o privacidad. Se considera un procedimiento recomendado. Ningún usuario debe tener asignados los roles "Administrador de cuenta de servicio" y "Usuario de cuenta de servicio" al mismo tiempo.

Gravedad: media

Asegúrese de que la cuenta de servicio no tenga privilegios de administrador.

Descripción: una cuenta de servicio es una cuenta especial de Google que pertenece a una aplicación o una máquina virtual, en lugar de a un usuario final individual. La aplicación usa la cuenta de servicio para llamar a la API de Google del servicio para que los usuarios no estén implicados directamente. Se recomienda no usar el acceso de administrador para la cuenta de servicio. Las cuentas de servicio representan la seguridad de nivel de servicio de los recursos (aplicación o máquina virtual), que puede venir determinado por los roles asignados a ellas. La inscripción de una cuenta de servicio con derechos de administración proporciona acceso total a la aplicación o a la máquina virtual asignadas. El titular del acceso a una cuenta de servicio puede realizar acciones críticas (como eliminar, actualizar o cambiar la configuración) sin intervención del usuario. Por este motivo, se recomienda que las cuentas de servicio no tengan derechos de administración.

Gravedad: media

Asegúrese de que haya receptores configurados para todas las entradas de registro.

Descripción: se recomienda crear un receptor que exporte copias de todas las entradas de registro. Esto puede ayudar a agregar los registros de varios proyectos y exportarlos a un sistema de Administración de eventos e información de seguridad (SIEM). Las entradas de registro se mantienen en el registro de Stackdriver. Para agregar los registros, expórtelos a un sistema SIEM. Para mantenerlos más largos, se recomienda configurar un receptor de registro. La exportación implica escribir un filtro que seleccione las entradas de registro que se van a exportar y elegir un destino en Cloud Storage, BigQuery o Cloud Pub/Sub. El filtro y el destino se mantienen en un objeto llamado receptor. Para asegurarse de que todas las entradas de registro se exportan a los receptores, asegúrese de que no haya ningún filtro configurado para un receptor. Se pueden crear receptores en proyectos, organizaciones, carpetas y cuentas de facturación.

Gravedad: baja

Asegúrese de que haya un filtro de métricas de registro y alertas para detectar los cambios hechos en la configuración de auditoría.

Descripción: los servicios de Google Cloud Platform (GCP) escriben entradas del registro de auditoría en los registros de actividad de administrador y acceso a datos. Las entradas ayudan a responder a las preguntas de "¿quién hizo qué, dónde y cuándo?" en proyectos de GCP. Cloud Audit Logging registra información que incluye la identidad del autor de la llamada API, la hora de la llamada API, la dirección IP de origen del autor de la llamada API, los parámetros de solicitud y los elementos de respuesta devueltos por los servicios de GCP. Cloud Audit Logging proporciona un historial de las llamadas API de GCP de una cuenta, incluidas las llamadas API realizadas mediante la consola, los SDK, las herramientas de la línea de comandos y otros servicios de GCP. Los registros de acceso a datos y actividad de administrador generados por el registro de auditoría en la nube permiten el análisis de seguridad, el seguimiento de cambios de recursos y la auditoría de cumplimiento. La configuración del filtro de métricas y las alertas para los cambios de configuración de auditoría garantiza que se mantenga el estado recomendado de configuración de auditoría para que todas las actividades del proyecto sean auditadas en cualquier momento dado.

Gravedad: baja

Asegúrese de que haya un filtro de métricas de registro y alertas para detectar los cambios hechos en el rol personalizado.

Descripción: se recomienda establecer un filtro de métricas y una alarma para los cambios en la creación, eliminación y actualización de las actividades de creación, eliminación y actualización de roles de Administración de identidades y acceso (IAM). Google Cloud IAM proporciona roles predefinidos que proporcionan acceso granular a recursos específicos de Google Cloud Platform y evitan el acceso no deseado a otros recursos. Sin embargo, para satisfacer las necesidades específicas de la organización, Cloud IAM también proporciona la capacidad de crear roles personalizados. Los propietarios y administradores de proyectos con el rol Administrador de roles de la organización o el rol Administrador de roles de IAM pueden crear roles personalizados. La supervisión de las actividades de creación, eliminación y actualización de roles ayudará a identificar cualquier rol con privilegios excesivos en las primeras fases.

Gravedad: baja

Asegúrese de que las claves externas/administradas por el usuario para las cuentas de servicio se cambien cada 90 días o menos.

Descripción: las claves de cuenta de servicio constan de un identificador de clave (Private_key_Id) y una clave privada, que se usan para firmar solicitudes mediante programación que los usuarios realizan a los servicios en la nube de Google accesibles para esa cuenta de servicio concreta. Se recomienda rotar regularmente todas las claves de cuenta de servicio. La rotación de claves de las cuentas de servicio reducirá la ventana de posibilidades para que se utilice una clave de acceso asociada a una cuenta en peligro o terminada. Las claves de la cuenta de servicio deben rotarse para asegurarse de que no se pueda acceder a los datos con una clave antigua que se haya perdido, descifrado o robado. Cada cuenta de servicio está asociada a un par de claves administrado por Google Cloud Platform (GCP). Se usa para la autenticación entre servicios dentro de GCP. Google rota las claves a diario. GCP proporciona la opción de crear uno o varios pares de claves administrados por el usuario (también llamados pares de claves externos) para su uso desde fuera de GCP (por ejemplo, para su uso con credenciales predeterminadas de aplicación). Cuando se crea un nuevo par de claves, se requiere que el usuario descargue la clave privada (que no se conserva en Google).

Con las claves externas, los usuarios son responsables de mantener la clave privada segura y otras operaciones de administración, como la rotación de claves. Las claves externas se pueden administrar mediante la API de IAM, la herramienta de la línea de comandos gcloud o la página Cuentas de servicio de la consola de Google Cloud Platform.

GCP facilita hasta 10 claves de cuenta de servicio externas por cuenta de servicio para facilitar la rotación de claves.

Gravedad: media

Las identidades sobreaprovisionadas de GCP solo deben tener los permisos necesarios (versión preliminar)

Descripción: una identidad activa sobreaprovisionada es una identidad que tiene acceso a privilegios que no han usado. Las identidades activas sobreaprovisionadas, especialmente para las cuentas no humanas que tienen acciones y responsabilidades muy definidas, pueden aumentar el radio de explosión en caso de que un usuario, una clave o un recurso pongan en peligro El principio de privilegios mínimos indica que un recurso solo debe tener acceso a los recursos exactos que necesita para funcionar. Este principio se desarrolló para abordar el riesgo de que las identidades comprometidas concedan a un atacante acceso a una amplia gama de recursos.

El panel web de GKE debe estar deshabilitado.

Descripción: esta recomendación evalúa el campo kubernetesDashboard de la propiedad addonsConfig para el par clave-valor, "disabled": false.

Gravedad: alta

La autorización heredada debe estar deshabilitada en los clústeres de GKE.

Descripción: esta recomendación evalúa la propiedad legacyAbac de un clúster para el par clave-valor, "enabled": true.

Gravedad: alta

Se deben revocar los permisos de identidades inactivas en el proyecto de GCP.

Descripción: Microsoft Defender for Cloud detectó una identidad que no ha realizado ninguna acción en ningún recurso dentro del proyecto de GCP en los últimos 45 días. Se recomienda revocar permisos de identidades inactivas para reducir la superficie expuesta a ataques del entorno en la nube.

Gravedad: media

El rol IAM de Redis no debe asignarse en el nivel de organización o carpeta.

Descripción: esta recomendación evalúa la directiva de permiso de IAM en metadatos de recursos para roles asignados por entidades de seguridad/redis.admin, roles/redis.editor, roles/redis.viewer en el nivel de organización o carpeta.

Gravedad: alta

Las cuentas de servicio deben tener acceso restringido al proyecto en un clúster.

Descripción: esta recomendación evalúa la propiedad config de un grupo de nodos para comprobar si no se especifica ninguna cuenta de servicio o si se usa la cuenta de servicio predeterminada.

Gravedad: alta

Los usuarios deben tener acceso con privilegios mínimos con roles de IAM detallados.

Descripción: esta recomendación evalúa la directiva de IAM en los metadatos de recursos para las entidades de seguridad asignadas a roles, propietarios, roles, escritor o lector.

Gravedad: alta

Las super identidades del entorno de GCP deben quitarse (versión preliminar)

Descripción: una super identity tiene un conjunto eficaz de permisos. Los superadministradores son identidades humanas o de carga de trabajo que tienen acceso a todos los permisos y a todos los recursos. Pueden crear y modificar opciones de configuración en un servicio, agregar o quitar identidades, así como acceder o incluso eliminar datos. Estas identidades no supervisadas presentan un riesgo significativo de uso indebido de permisos si se infringen.

Gravedad: alta

Contenido relacionado

• Más información sobre las recomendaciones de seguridad
• Revisión de las recomendaciones de seguridad