Controles de base empresarial seguros

Usa la restricción booleana automaticIamGrantsForDefaultServiceAccounts para inhabilitar las asignaciones de roles automáticas cuando los servicios de Google Cloud crean automáticamente cuentas de servicio predeterminadas con roles demasiado permisivos.

De forma predeterminada, algunos sistemas otorgan permisos demasiado amplios a las cuentas automatizadas, lo que representa un riesgo potencial para la seguridad. Por ejemplo, si no aplicas esta restricción y creas una cuenta de servicio predeterminada, a la cuenta de servicio se le otorga automáticamente el rol de Editor (roles/editor) en tu proyecto. Si un atacante vulnera una sola parte del sistema, podría obtener el control de todo el proyecto. Esta restricción inhabilita esos permisos automáticos de alto nivel, lo que obliga a adoptar un enfoque más seguro y deliberado en el que solo se otorgan los permisos mínimos necesarios.

Usa la restricción booleana iam.disableServiceAccountKeyCreation para inhabilitar la creación de claves de cuentas de servicio externas. Esta restricción te permite controlar el uso de credenciales a largo plazo no administradas para las cuentas de servicio. Cuando se establece esta restricción, no puedes crear credenciales administradas por el usuario para las cuentas de servicio en los proyectos afectados por la restricción.

Usa la restricción booleana iam.disableServiceAccountKeyUpload para inhabilitar la carga de claves públicas externas a las cuentas de servicio. Cuando se establece esta restricción, los usuarios no pueden subir claves públicas a cuentas de servicio en proyectos afectados por la restricción.

Google recomienda usar las llaves de seguridad Titan para la verificación en 2 pasos (2SV) en las cuentas de administrador avanzado. Sin embargo, para los casos de uso en los que esto no es posible, te recomendamos que uses otra llave de seguridad como alternativa.

Aplicar la verificación en 2 pasos (2SV) para una unidad organizativa (UO) específica o para toda la organización Te recomendamos que crees una UO para los administradores avanzados y que apliques la 2SV en esa UO.

No tener un solo administrador avanzado o administrador de la organización Crea una o más cuentas de administrador secundario (hasta 20). Un solo administrador avanzado o administrador de la organización puede generar situaciones de bloqueo. Esta situación también conlleva un mayor riesgo, ya que una persona puede realizar cambios que alteren la plataforma, posiblemente sin supervisión.

Las etiquetas proporcionan una forma de crear anotaciones para los recursos y, en algunos casos, permitir o rechazar políticas de forma condicional en función de si un recurso tiene una etiqueta específica. Usa etiquetas y la aplicación condicional de políticas para obtener un control detallado de toda la jerarquía de tus recursos.

Usa los registros de auditoría de Cloud para supervisar la actividad de alto riesgo, como las cuentas a las que se otorgan roles de alto riesgo, como administrador de la organización y administrador avanzado. Configura alertas para este tipo de actividad.

Para evitar otorgar acceso excesivo a Google Cloud, bloquea el acceso a Cloud Shell para las cuentas de usuario administradas de Cloud Identity.

Con el acceso adaptado al contexto, puedes crear políticas de seguridad detalladas para el control de acceso a las aplicaciones en función de atributos, como la identidad del usuario, la ubicación, el estado de seguridad del dispositivo y la dirección IP. Te recomendamos que uses el Acceso adaptado al contexto para restringir el acceso a la Google Cloud consola (https://console.cloud.google.com/) y a la Consola del administrador de Google (https://admin.cloud.google.com).

Google Cloud admite varias versiones del protocolo TLS. Para cumplir con los requisitos de cumplimiento, es posible que desees rechazar las solicitudes de protocolo de enlace de los clientes que usan versiones anteriores de TLS.

Para configurar este control, usa la restricción de política de la organización Restrict TLS Versions (gcp.restrictTLSVersion). Puedes aplicar esta restricción a organizaciones, carpetas o proyectos en la jerarquía de recursos. La restricción Restrict TLS Versions usa una lista de bloqueo, que rechaza valores explícitos y permite todos los demás. Se produce un error si intentas usar una lista de entidades permitidas.

Debido al comportamiento de la evaluación de la jerarquía de políticas de la organización, la restricción de la versión de TLS se aplica al nodo de recursos especificado y a todas sus carpetas y proyectos (elementos secundarios). Por ejemplo, si rechazas la versión 1.0 de TLS para una organización, también se rechazará para todos los elementos secundarios que desciendan de esa organización.

Puedes anular la restricción de la versión de TLS heredada actualizando la política de la organización en un recurso secundario. Por ejemplo, si tu política de la organización rechaza TLS 1.0 a nivel de la organización, puedes quitar la restricción para una carpeta secundaria estableciendo una política de la organización independiente en esa carpeta. Si la carpeta tiene elementos secundarios, la política de la carpeta también se aplicará a cada recurso secundario debido a la herencia de políticas.

Para restringir aún más la versión de TLS solo a TLS 1.3, puedes configurar esta política para que también restrinja la versión de TLS 1.2. Debes implementar este control en las aplicaciones que alojes dentro de Google Cloud. Por ejemplo, a nivel de la organización, establece lo siguiente:

["TLS_VERSION_1","TLS_VERSION_1.1","TLS_VERSION_1.2"]

Asegúrate de que solo se permitan identidades de tu organización en tu entorno de Google Cloud . Usa la restricción de política de la organización Uso compartido restringido al dominio (iam.allowedPolicyMemberDomains) o iam.managed.allowedPolicyMembers para definir uno o más IDs de cliente de Cloud Identity o Google Workspace cuyas principales se pueden agregar a las políticas de Identity and Access Management (IAM).

Estas restricciones ayudan a evitar que los empleados otorguen acceso a cuentas externas que no están bajo el control de tu organización y que no cumplen con tus políticas de seguridad para la autenticación de varios factores (MFA) o la administración de contraseñas. Este control es fundamental para evitar el acceso no autorizado, ya que garantiza que solo se puedan usar identidades corporativas administradas y de confianza.

La restricción gcp.restrictServiceUsage garantiza que solo se utilicen los servicios Google Cloud aprobados en los lugares correctos. Por ejemplo, una carpeta de producción o altamente sensible tiene una pequeña lista de servicios Google Cloud que están aprobados para almacenar datos. Una carpeta de zona de pruebas podría tener una lista más grande de servicios y controles de seguridad de los datos acompañantes para ayudar a evitar el robo de datos. El valor es específico para tus sistemas y coincide con tu lista aprobada de servicios y dependencias para carpetas y proyectos específicos.

Esta restricción permite que tu organización cree una lista de servicios aprobados, lo que ayuda a evitar que los empleados usen servicios no verificados.

La restricción de ubicación del recurso (gcp.resourceLocations) garantiza que solo se usen las Google Cloud regiones aprobadas para almacenar datos. El valor es específico para tus sistemas y coincide con la lista de regiones aprobadas de tu organización para la residencia de datos.

Esta restricción permite que tu organización aplique que tus recursos y datos solo se creen y guarden en regiones geográficas específicas aprobadas.

La restricción booleana compute.skipDefaultNetworkCreation omite la creación de la red predeterminada y los recursos relacionados cuando se crean proyectos Google Cloud .

La red predeterminada es una red de nube privada virtual (VPC) de modo automático con reglas de firewall IPv4 propagadas previamente para permitir rutas de comunicación internas. En general, esta configuración no es una postura de seguridad recomendada para los entornos de producción.

Las extensiones de seguridad del sistema de nombres de dominio (DNSSEC) son una función del sistema de nombres de dominio (DNS) que autentica las respuestas para búsquedas de nombres de dominio. No proporciona protección de la privacidad para esas búsquedas, pero evita que los atacantes manipulen o envenenen las respuestas a las solicitudes de DNS.

En Cloud DNS, habilita DNSSEC en los siguientes lugares:

• Zona del DNS
• Dominio de nivel superior (TLD)
• Resolución de DNS

Para cada perímetro de servicio, confirma en la consola de Google Cloud que el tipo de perímetro esté establecido como regular.

Para cada perímetro de servicio, usa Access Context Manager para confirmar que el perímetro protege la API.

La restricción booleana compute.setNewProjectDefaultToZonalDNSOnly te permite establecer la configuración del DNS interno para que los proyectos nuevos usen solo el DNS zonal, ya que ofrece mayor confiabilidad en comparación con las zonas individuales, porque aísla las fallas en el registro DNS.

Si usas Cloud Identity, comparte los registros de auditoría de Cloud Identity con Google Cloud.

Por lo general, los registros de auditoría de actividad del administrador de Google Workspace o Cloud Identity se administran y ven en la Consola del administrador de Google, por separado de los registros en tu Google Cloud entorno. Estos registros contienen información relevante para tu Google Cloud entorno, como los eventos de acceso de los usuarios.

Te recomendamos que compartas los registros de auditoría de Cloud Identity con tu entorno de Google Cloud para administrar de forma centralizada los registros de todas las fuentes.

Los servicios deGoogle Cloud escriben entradas de registro de auditoría para responder quién hizo qué, dónde y cuándo con los recursos de Google Cloud .

Habilita el registro de auditoría a nivel de la organización. Puedes configurar el registro con la canalización que usas para configurar la organización de Google Cloud .

Los registros de flujo de VPC registran una muestra de los flujos de red que envían y reciben las instancias de VM, incluidas las que se usan como nodos de Google Kubernetes Engine (GKE). Por lo general, la muestra es del 50% o menos de los flujos de red de VPC.

Cuando habilitas los registros de flujo de VPC, se habilita el registro en todas las VMs de una subred. Sin embargo, puedes reducir la cantidad de información que se escribe en el registro.

Habilita los registros de flujo de VPC para cada subred de VPC. Puedes configurar el registro con una canalización que uses para crear un proyecto.

De forma predeterminada, las reglas de firewall no escriben registros automáticamente.El registro de reglas de firewall te permite inspeccionar, verificar y analizar los efectos de tus reglas de firewall. Por ejemplo, puedes determinar si una regla de firewall diseñada para denegar tráfico está funcionando según lo previsto. El registro también es útil si quieres determinar cuántas conexiones se ven afectadas por una regla de firewall determinada.

Habilita el registro para cada regla de firewall. Puedes configurar el registro con una canalización que uses para crear un firewall.

De forma predeterminada, Google Cloud habilita la auditoría de la actividad clave del administrador para las cuentas con privilegios y no permite que nadie la inhabilite.

Los registros de auditoría de actividad del administrador contienen entradas de registro para las llamadas a la API y otras acciones que modifican la configuración o los metadatos de los recursos. Por ejemplo, registran en qué momento los usuarios crean instancias de VM o cambian los permisos de IAM.

Los registros de auditoría de actividad del administrador contienen entradas de registro para la creación, modificación y eliminación de restricciones de políticas de la organización a nivel de la organización, la carpeta y el proyecto.

Los registros de auditoría de actividad del administrador se escriben siempre; no puedes configurarlos, excluirlos ni inhabilitarlos. Incluso si inhabilitas la API de Cloud Logging, los registros de auditoría de actividad del administrador se seguirán generando.

Recomendamos que tu organización configure políticas y procedimientos para supervisar estas alertas, y generar acciones o alertas según las políticas de acceso de tu empresa para supervisar las actividades del administrador.

Suscríbete a las notificaciones de boletines de seguridad para los servicios de Google Cloud y recibir alertas sobre vulnerabilidades y medidas de mitigación.

Cuando hay boletines de seguridad disponibles que son relevantes para tu servicio Google Cloud (como GKE), el servicio puede publicar notificaciones sobre esos eventos como mensajes en los temas de Pub/Sub que configures. Puedes recibir estas notificaciones en una suscripción de Pub/Sub, integrarlas a servicios de terceros y filtrar por los tipos de notificaciones que deseas recibir.

Para hacer un seguimiento de quién accedió a los datos en tu entorno de Google Cloud , habilita los registros de auditoría de acceso a los datos. Estos registros graban las llamadas a la API que leen, crean o modifican datos del usuario, así como las llamadas a la API que leen la configuración de los recursos.

Te recomendamos que habilites los registros de auditoría de acceso a los datos para los modelos de IA generativa y los datos sensibles, de modo que puedas auditar quién leyó la información. Para usar los registros de auditoría de acceso a los datos, debes configurar tu propia lógica de detección personalizada para actividades específicas, como los accesos de administrador avanzado.

El volumen de los registros de auditoría de acceso a los datos puede ser grande. Habilitar los registros de acceso a los datos podría generar cargos en tu Google Cloud proyecto por el uso de registros adicionales.

Crea presupuestos de Facturación de Cloud para supervisar todos tus Google Cloud cargos en un solo lugar y evitar sorpresas en tu factura. Después de establecer un importe del presupuesto, configura reglas de límite de alertas de presupuesto para cada proyecto y activa las notificaciones por correo electrónico. Estas notificaciones te ayudan a hacer un seguimiento de tus gastos en relación con tu presupuesto. También puedes usar los presupuestos de Facturación de Cloud para automatizar las respuestas de control de costos.

Los registros estándar te muestran lo que hacen los usuarios de tu organización, pero los registros de Transparencia de acceso muestran lo que hace el personal de asistencia de Google cuando accede a la cuenta. Por lo general, este acceso solo se produce en respuesta a una solicitud de asistencia. Los registros de Transparencia de acceso proporcionan un registro de auditoría completo y verificable de todo el acceso, lo que es fundamental para cumplir con los estrictos requisitos de cumplimiento y administración de datos.

Puedes habilitar la Transparencia de acceso a nivel de la organización.

Para realizar un análisis de facturación más detallado, puedes exportar Google Cloud los datos de facturación a BigQuery o a un archivo JSON. Por ejemplo, puedes exportar automáticamente datos detallados, como el uso, las estimaciones de costos y los precios, durante todo el día a un conjunto de datos de BigQuery que especifiques. Luego, puedes acceder a los datos de la Facturación de Cloud desde BigQuery para realizar un análisis detallado o usar una herramienta como Data Studio para visualizar los datos.

Todos los datos en Google Cloud se encriptan en reposo de forma predeterminada con algoritmos aprobados por el NIST.

Asegúrate de que Cloud Key Management Service (Cloud KMS) solo use algoritmos aprobados por el NIST para almacenar claves sensibles en el entorno. Este control garantiza el uso seguro de las claves solo con algoritmos y seguridad aprobados por el NIST. El campo CryptoKeyVersionAlgorithm es una lista de entidades permitidas proporcionada.

Quita los algoritmos que no cumplan con las políticas de tu organización.

Establece el propósito de las claves de Cloud KMS en ENCRYPT_DECRYPT para que las claves solo se usen para encriptar y desencriptar datos. Este control bloquea otras funciones, como la firma, y garantiza que las claves solo se usen para el propósito previsto. Si usas claves para otras funciones, valida esos casos de uso y considera crear claves adicionales.

El nivel de protección indica cómo se realizan las operaciones criptográficas. Después de crear una clave de encriptación administrada por el cliente (CMEK), no puedes cambiar el nivel de protección. Los niveles de protección admitidos son los siguientes:

• SOFTWARE: Las operaciones criptográficas se realizan en software.
• HSM: Las operaciones criptográficas se realizan en un módulo de seguridad de hardware (HSM).
• EXTERNO: Las operaciones criptográficas se realizan con una clave almacenada en un administrador de claves externo que se conecta a Google Cloud a través de Internet. Se limita a la encriptación simétrica y la firma asimétrica.
• EXTERNAL_VPC: Las operaciones criptográficas se realizan con una clave almacenada en un administrador de claves externo que está conectado a Google Cloud a través de una red de nube privada virtual (VPC). Se limita a la encriptación simétrica y la firma asimétrica.

Asegúrate de que el período de rotación de tus claves de Cloud KMS esté establecido en 90 días. Una práctica recomendada general es rotar las claves de seguridad a intervalos regulares. Este control aplica la rotación de claves para las claves que se crean con los servicios de HSM.

Cuando crees este período de rotación, también crea políticas y procedimientos adecuados para manejar de forma segura la creación, eliminación y modificación del material de claves, de modo que puedas proteger tu información y garantizar la disponibilidad. Asegúrate de que este período cumpla con las políticas corporativas de rotación de claves.

Usa la restricción de la política de la organización Restringe qué proyectos pueden proporcionar claves criptográficas de KMS para CMEK (gcp.restrictCmekCryptoKeyProjects) para definir qué proyectos pueden almacenar claves de encriptación administradas por el cliente (CMEK). Esta restricción te permite centralizar la administración y el control de las claves de encriptación. Cuando una clave seleccionada no cumple con esta restricción, falla la creación del recurso.

Para modificar esta restricción, los administradores necesitan el rol de IAM de Administrador de políticas de la organización (roles/orgpolicy.policyAdmin).

Si deseas agregar una segunda capa de protección, como la opción de usar tu propia clave, cambia esta restricción para que represente los nombres de las claves de la CMEK habilitada.

Detalles del producto:

• En Gemini Enterprise Agent Platform, almacenas tus claves en el proyecto KEY PROJECTS.

Si necesitas más control sobre las operaciones de clave que el que permite Google-owned and Google-managed encryption keys , puedes usar claves de encriptación administradas por el cliente (CMEK). Estas claves se crean y administran con Cloud KMS. Almacena las claves como claves de software, en un clúster de HSM o en un sistema externo de administración de claves.

Los índices de encriptación y desencriptación de Cloud KMS están sujetos a cuotas.

Detalles específicos de Cloud Storage

En Cloud Storage, usa CMEK en objetos individuales o configura tus buckets de Cloud Storage para usar una CMEK de forma predeterminada en todos los objetos nuevos que se agreguen a un bucket. Cuando se usa una CMEK, Cloud Storage encripta un objeto con la clave en el momento en el que se almacena en un bucket, y Cloud Storage lo desencripta automáticamente cuando el objeto se entrega a los solicitantes.

Las siguientes restricciones se aplican cuando se usan CMEK con Cloud Storage:

• No puedes encriptar un objeto con una CMEK cuando actualizas los metadatos del objeto. Incluye la clave como parte de una reescritura del objeto en su lugar.
• Tu Cloud Storage usa el comando de actualización de objetos para establecer claves de encriptación en los objetos, pero el comando reescribe el objeto como parte de la solicitud.
• Debes crear el llavero de claves de Cloud KMS en la misma ubicación que los datos que deseas encriptar. Por ejemplo, si tu bucket está ubicado en us-east1, cualquier llavero de claves usado para encriptar objetos en ese bucket también debe crearse en us-east1.
• Para la mayoría de las regiones dobles, debes crear el llavero de claves de Cloud KMS en la multirregión asociada. Por ejemplo, si tu bucket está ubicado en el par us-east1, us-west1, cualquier llavero de claves usado para encriptar objetos en ese bucket debe crearse en la multirregión de EE.UU.
• Para las regiones dobles predefinidas asia1, eur4 y nam4, debes crear el llavero de claves en la misma región doble predefinida.
• La suma de comprobación CRC32C y el hash MD5 de los objetos encriptados con CMEK no se muestran cuando se enumeran objetos con la API de JSON.
• Usar herramientas como Cloud Storage para realizar solicitudes GET de metadatos adicionales en cada objeto de encriptación para recuperar la información de CRC32C y MD5 puede hacer que la lista sea mucho más corta. Cloud Storage no puede usar la parte de desencriptación de las claves asimétricas almacenadas en Cloud KMS para desencriptar automáticamente objetos relevantes de la misma manera que las CMEK.