Controles de base empresarial seguros

Usa la restricción booleana automaticIamGrantsForDefaultServiceAccounts para inhabilitar las asignaciones de roles automáticas cuando los servicios de Cloud de Confiance by S3NS 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 posible riesgo de seguridad. Por ejemplo, si no aplicas esta restricción y creas una cuenta de servicio predeterminada, se le otorgará 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.

Usa Privileged Access Manager para administrar el acceso con privilegios. Para todos los demás accesos, usa grupos de acceso, permite que las membresías de los grupos venzan automáticamente y, luego, implementa un flujo de trabajo de aprobación para las membresías de los grupos.

Usar el modelo de privilegio mínimo te permite proporcionar acceso solo cuando sea necesario y a los recursos que se necesiten. El uso de roles prediseñados simplifica el uso y reduce la expansión causada por los roles personalizados, por lo que no tienes que preocuparte por administrar el ciclo de vida de los roles.

Decide cuál será tu fuente de información para aprovisionar identidades de usuarios administradas. Los patrones incluyen la creación de identidades de usuario en Cloud Identity, la sincronización de identidades desde un proveedor de identidad existente o el uso de la federación de identidades de personal.

Exige contraseñas seguras y únicas para todas las cuentas de usuario. Considera usar un administrador de contraseñas. Las credenciales débiles o inexistentes son un patrón común que los usuarios maliciosos pueden explotar fácilmente.

Usa roles de Identity and Access Management (IAM) basados en las funciones laborales para asignar permisos a los usuarios. Las funciones laborales son roles predefinidos que permiten a los administradores proporcionar un conjunto de permisos que se limita a una función laboral, lo que mejora la productividad y reduce las idas y vueltas para solicitar permisos. Para alinearte mejor con los requisitos de tu organización, puedes crear roles personalizados basados en roles predefinidos.

Establece políticas para toda la organización para evitar que se agreguen miembros externos a los Grupos de Google.

De forma predeterminada, las cuentas de usuario externas se pueden agregar a los grupos en Cloud Identity. Te recomendamos que configures el uso compartido para que los propietarios de grupos no puedan agregar miembros externos.

Ten en cuenta que esta restricción no se aplica a la cuenta de administrador avanzado ni a otros administradores delegados con permisos de administrador de Grupos de Google. Debido a que la federación de tu proveedor de identidad se ejecuta con privilegios de administrador, la configuración de uso compartido de grupos no se aplica a esta sincronización de grupo. Te recomendamos que revises los controles en el proveedor de identidad y el mecanismo de sincronización para asegurarte de que los miembros que no son de dominio se agreguen a grupos o que apliques restricciones de grupo.

Establece la duración de la sesión para que los servicios de Cloud de Confiance by S3NS vencen al menos una vez al día. Dejar una cuenta abierta durante un período prolongado es un riesgo de seguridad. Aplicar una duración máxima de la sesión finaliza automáticamente la sesión después de un tiempo determinado, lo que obliga a un nuevo acceso seguro.

Esta práctica reduce la oportunidad de que un usuario malicioso use una contraseña robada y garantiza que el acceso se vuelva a verificar periódicamente.

En el caso de los clientes nuevos, se aplica automáticamente una duración de sesión predeterminada de 16 horas. Es posible que los clientes que crearon su organización de Cloud de Confiance by S3NS antes de 2023 tengan un parámetro de configuración predeterminado para no requerir nunca la reautenticación. Revisa este parámetro de configuración para asegurarte de tener una política de reautenticación con una duración de sesión que esté entre 1 y 24 horas. La política de reautenticación invalida el token de actualización y obliga al usuario a volver a autenticar gcloud CLI con regularidad mediante su contraseña o llave de seguridad.

La duración de la sesión para los servicios de Cloud de Confiance by S3NS es un parámetro de configuración distinto de la duración de la sesión para los servicios de Google, que controla las sesiones web de acceso a todos los servicios de Google Workspace, pero no controla la reautenticación para Cloud de Confiance by S3NS . Cloud de Confiance by S3NSSi usas los servicios de Google Workspace, establece la duración de la sesión para ambos.

No permitas cuentas personales no administradas. Consolida las cuentas personales no administradas y considera una solución para evitar la creación de más cuentas personales no administradas con tu dominio.

Las cuentas personales no administradas no se rigen por los procesos de incorporación, traslado y baja (JML), por lo que existe el riesgo de que un empleado siga teniendo acceso a tus recursos después de dejar su trabajo. Estas cuentas también se consideran externas en relación con los controles, como el uso compartido restringido del dominio.

Asegúrate de que las cuentas de administrador avanzado estén separadas de las cuentas de usuario diarias. Las cuentas de administrador avanzado deben ser cuentas exclusivas que se usen solo cuando se realicen cambios importantes. Para aumentar la seguridad, activa la aprobación de varias partes para las acciones de administrador. Activar la aprobación de varias partes significa que dos administradores aprueban las acciones sensibles, lo que ayuda a evitar que los atacantes pongan en riesgo una cuenta de administrador y bloqueen a otros usuarios administradores.

Habilita la autenticación de varios factores (MFA), también conocida como autenticación en 2 pasos (2SV), para todos los usuarios de Cuentas de Google y Cloud Identity, no solo para los administradores avanzados. La MFA para administradores avanzados está habilitada de forma predeterminada. La MFA agrega otra capa de defensa porque las contraseñas por sí solas no suelen ser una medida de seguridad lo suficientemente sólida.

Quita los roles de creador de proyectos y creador de cuentas de facturación en todo el dominio que se otorgan de forma predeterminada a todos los miembros de una organización nueva.

Las organizaciones nuevas otorgan los roles de Creador de proyectos y Creador de cuentas de facturación a todas las identidades de usuario administradas en el dominio. Si bien estos roles son útiles para comenzar, esta configuración no está diseñada para entornos de producción. Permitir que proliferen las cuentas de facturación genera una mayor sobrecarga administrativa y tiene consecuencias técnicas cuando los servicios se dividen en varias cuentas de facturación. Permitir la creación de proyectos de formato libre puede generar proyectos que no se ajusten a tus convenciones de administración.

En cambio, quita estos roles y establece un proceso de creación de proyectos para solicitar proyectos nuevos y asociarlos con la facturación.

Si debes usar claves de cuentas de servicio, rótalas al menos una vez cada 90 días.

Un intervalo de rotación limita el tiempo que un atacante puede tener acceso al sistema. Sin un intervalo de rotación, el atacante tendrá acceso para siempre. Cuando sea posible, considera usar la federación de identidades para cargas de trabajo en lugar de las claves de cuenta de servicio.

Usa la federación de identidades para cargas de trabajo para permitir que los sistemas y las cargas de trabajo de CI/CD que se ejecutan en otras nubes se autentiquen en Cloud de Confiance by S3NS. La federación de identidades para cargas de trabajo permite que las cargas de trabajo que se ejecutan fuera de Cloud de Confiance se autentiquen sin necesidad de una clave de cuenta de servicio. Al evitar las claves de cuentas de servicio y otras credenciales de larga duración, la federación de identidades para cargas de trabajo puede ayudarte a reducir el riesgo de filtración de credenciales.

De forma predeterminada, la recuperación automática de la cuenta de administrador avanzado está desactivada para los clientes nuevos. Sin embargo, es posible que los clientes existentes tengan activado este parámetro de configuración. Desactivar este parámetro de configuración ayuda a mitigar el riesgo de que un teléfono vulnerado, un correo electrónico vulnerado o un ataque de ingeniería social puedan permitir que un atacante obtenga privilegios de administrador avanzado en tu entorno.

Planifica un proceso interno para que un administrador avanzado se comunique con otro administrador avanzado de tu organización si perdió el acceso a su cuenta y asegúrate de que todos los administradores avanzados estén familiarizados con el proceso para la recuperación con ayuda del equipo de asistencia.

Para desactivar la función, ve a la configuración de recuperación de la cuenta en la Consola del administrador de Google.

Establece el tiempo de espera de sesión inactiva en 15 minutos para los casos de uso sensibles. Los atacantes pueden usar las sesiones inactivas para robar credenciales.

Si es posible, proporciona llaves de seguridad de hardware a los administradores avanzados o administradores de la organización como segundo factor. Las cuentas de administrador avanzado son los objetivos más valiosos para los ataques sofisticados. Las llaves de seguridad de hardware proporcionan un alto nivel de protección porque son resistentes al phishing. Las llaves de seguridad de hardware son la defensa más sólida posible contra la apropiación de cuentas para tus administradores más importantes y se basan en tu política estándar de MFA.

Si usas un proveedor de identidad externo, configura la verificación posterior al SSO.

Habilita una capa de control adicional según el análisis de riesgos de acceso de Google. Después de aplicar este parámetro de configuración, es posible que los usuarios vean desafíos de acceso adicionales basados en el riesgo durante el acceso si Google determina que el acceso de un usuario es sospechoso.

Habilita las políticas de límite de acceso de la entidad (PAB) para limitar el acceso de la entidad y ayudar a proteger contra el phishing y el robo de datos. Habilita una política de PAB para la organización y, así, evitar ataques de phishing externos. Los PAB mejoran la seguridad, ya que reducen el alcance de un ataque con una identidad vulnerada y ayudan a evitar ataques externos de phishing y otros ataques de exfiltración.

Las etiquetas proporcionan una forma de crear anotaciones para los recursos y, en algunos casos, permitir o denegar 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 les 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 Cloud de Confiance by S3NS, 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 Cloud de Confiance consola (https://console.cloud.google.com/) y a la Consola del administrador de Google (https://admin.cloud.google.com).

Cloud de Confiance 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 la 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 entidades denegadas, 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á en 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 Cloud de Confiance by S3NS. 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 Cloud de Confiance by S3NS . 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 usen tus servicios Cloud de Confiance by S3NS aprobados en los lugares correctos. Por ejemplo, una carpeta de producción o altamente sensible tiene una lista pequeña de Cloud de Confiance servicios que están aprobados para almacenar datos. Es posible que una carpeta de zona de pruebas tenga una lista más grande de servicios y controles de seguridad de los datos complementarios para ayudar a evitar el robo de datos. El valor es específico de 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 de recursos (gcp.resourceLocations) garantiza que solo se usen las regiones Cloud de Confiance by S3NS aprobadas para almacenar datos. El valor es específico de tus sistemas y coincide con la lista aprobada de regiones 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 Cloud de Confiance by S3NS .

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

Habilita el Acceso privado a Google en todas las subredes.

Habilita el acceso privado a servicios para crear una red privada entre los servicios de Cloud de Confiance by S3NS , como las redes heredadas de Google Cloud VMware Engine, y los productores de servicios, como Cloud SQL. El acceso privado a los servicios ayuda a evitar exponer innecesariamente las conexiones de red de cargas de trabajo a Internet.

Inhabilita la creación de subredes externas IPv6, a menos que sea específicamente necesario. Para reducir la superficie de ataque, considera inhabilitar IPv6 en los sistemas y las redes en los que no se administra o requiere de forma activa. Muchas organizaciones tienen controles de seguridad y supervisión avanzados para IPv4, pero es posible que sus herramientas y políticas no se extiendan por completo a IPv6, lo que puede crear un punto ciego importante para las amenazas. Ejecutar una red de pila doble también introduce complejidad operativa, ya que requiere configuraciones y conocimientos específicos para administrar y solucionar problemas de manera eficaz. Por lo tanto, si no tienes un factor comercial claro para IPv6, inhabilitarlo puede simplificar tu entorno y garantizar que todo el tráfico se filtre de manera coherente a través de tu postura de seguridad IPv4 establecida.

Limita el acceso a fuentes externas, ya que, de forma predeterminada, se permite todo el acceso saliente. Establece reglas de firewall específicas para los patrones de tráfico previstos que deben salir.

De forma predeterminada, a menudo se permite que los sistemas realicen conexiones salientes a Internet, lo que se puede considerar un riesgo de seguridad. Una política de bloqueo predeterminado bloquea el tráfico saliente y requiere que se creen reglas específicas solo para los destinos conocidos y necesarios.

Cuando sea posible, restringe el acceso entrante solo a recursos y rangos de recursos específicos. Si Identity-Aware Proxy (IAP) está configurado, establece las reglas de firewall entrantes de SSH y del Protocolo de escritorio remoto (RDP) en los rangos de IP de IAP como fuentes.

Las reglas de firewall permisivas de SSH y RDP permiten ataques de fuerza bruta. En su lugar, usa proxies que tengan reconocimiento de identidad Cloud de Confiance by S3NS (como IAP) para SSH y RDP.

Habilita los Controles del servicio de VPC como una capa adicional de protección para evitar la posible pérdida de datos.

Los Controles del servicio de VPC pueden ayudar a evitar el robo de datos, ya que crean perímetros de aislamiento alrededor de tus recursos en la nube, datos sensibles y redes.

El perímetro de servicio limita la utilidad de las credenciales vulneradas porque bloquea las solicitudes a servicios restringidos que se originan en extremos controlados por atacantes que están fuera de tu entorno.

En el caso de las aplicaciones que se exponen detrás de Cloud Load Balancing, usa las políticas predeterminadas de Google Cloud Armor o configura tus propias políticas para agregar protección de red de la capa 3 a la capa 7 para las aplicaciones o los servicios externos. Las políticas de seguridad de Cloud Armor ayudan a proteger tu aplicación, ya que proporcionan filtrado de capa 7. Estas políticas también revisan las solicitudes entrantes en busca de ataques web comunes o de otros atributos de capa 7 para bloquear el tráfico antes de que llegue a los servicios de backend con balanceo de cargas o los buckets de backend. Cada política de seguridad se compone de un conjunto de reglas que incluyen atributos de la capa 3 a la capa 7.

Para cada perímetro de servicio, confirma en la consola de Cloud de Confiance 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 de DNS interno para que los proyectos nuevos usen solo DNS zonal. Usa DNS zonal, ya que ofrece mayor confiabilidad en comparación con las zonas individuales, ya que aísla las fallas en el registro DNS .

Si usas Cloud Identity, comparte los registros de auditoría de Cloud Identity con Cloud de Confiance by S3NS.

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 entorno de Cloud de Confiance . Estos registros contienen información relevante para tu entorno de Cloud de Confiance , como los eventos de acceso del usuario.

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

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

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 Cloud de Confiance .

Los registros de flujo de VPC registran una muestra de 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, Cloud de Confiance 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 Cloud de Confiance by S3NS y recibir alertas sobre vulnerabilidades y medidas de mitigación.

Cuando hay boletines de seguridad disponibles que son relevantes para tu servicio Cloud de Confiance by S3NS (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.

Configura los contactos esenciales para asegurarte de que un alias de grupo o una lista de distribución supervisados reciban notificaciones importantes.

Usar una dirección de correo electrónico de grupo supervisada ayuda a garantizar que estas alertas urgentes se envíen a un equipo activo que pueda responder rápidamente.

Usa la función de anomalías en la facturación de Cloud Billing para hacer un seguimiento de los aumentos repentinos o las desviaciones en la inversión esperada.

Un aumento repentino e inesperado en la factura de la nube es un indicador principal de una vulneración de seguridad. A veces, los aumentos inesperados en la facturación se deben a atacantes que obtuvieron acceso y usan recursos para actividades no autorizadas.

Habilitar la detección de anomalías en la facturación proporciona un sistema de alerta temprana esencial para que puedas marcar automáticamente esta actividad sospechosa.

Crea un receptor de registros para exportar los registros de tu solución de supervisión de seguridad y establece el período de retención para satisfacer tus requisitos.

Los períodos de retención de registros predeterminados a menudo no son lo suficientemente largos como para cumplir con los requisitos de 1 a 7 años que exigen las reglamentaciones de cumplimiento, como PCI o HIPAA.

Crear un receptor de registros para exportarlos a una ubicación de almacenamiento a largo plazo es fundamental para cumplir con ciertas obligaciones legales y reglamentarias. Los receptores de registros también te permiten enviar registros a un sistema de supervisión de seguridad centralizado para la detección avanzada de amenazas.

Para hacer un seguimiento de quién accedió a los datos en tu entorno de Cloud de Confiance by S3NS , 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 para asegurarte de 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 Cloud de Confiance proyecto por el uso de registros adicionales.

Crea presupuestos de Facturación de Cloud para supervisar todos tus Cloud de Confiance by S3NS 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 Cloud de Confiance by S3NS 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 Cloud de Confiance 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, ya que solo se utilizan 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 Cloud de Confiance 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 Cloud de Confiance 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 controlar 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.

Crea una estrategia de administración de la encriptación con Cloud Key Management Service (Cloud KMS) con Autokey, Cloud External Key Manager (Cloud EKM) o ambos. Esta estrategia permite que tu organización use y administre sus propias claves de encriptación para cumplir con tus requisitos específicos. El uso de tus propias claves de encriptación proporciona un control detallado y auditable sobre el acceso a los datos, incluida la capacidad de bloquear de inmediato el acceso a los datos inhabilitando la clave.

Usa la restricción de la política de la organización Restringe los proyectos que pueden proporcionar CryptoKeys 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, almacena tus claves en el proyecto KEY PROJECTS.

Si necesitas más control sobre las operaciones de clave que el que permite Google Cloud-powered 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 enumeración 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.