En este documento, se describen las implementaciones a nivel de acceso y se proporcionan recomendaciones para iniciar la aplicación del perímetro de servicio según las listas de entidades permitidas.
Cuando completes una ejecución de prueba de carga de trabajo, deberás identificar una lista de direcciones IP y de identidades que debes agregar a una lista de entidades permitidas. Además, es posible que algunas cargas de trabajo necesiten una lista de entidades permitidas basada en el dispositivo. Para otorgar acceso controlado a recursos de Google Cloud protegidos, puedes usar los niveles de acceso a los Controles del servicio de VPC. Algunas formas prácticas de implementar los niveles de acceso se basan en la dirección IP, la identidad o el dispositivo.
Para obtener más información, consulta Acceso adaptado al contexto con reglas de entrada.
Otorga acceso según la IP de origen
Solo puedes usar rangos CIDR de IP pública en los niveles de acceso para las listas de entidades permitidas basadas en IP. Debido a que este método permite todas las APIs protegidas de este rango, el entorno detrás de estas IPs debe ser confiable y estar controlado. Una situación típica de uso para esta lista de entidades permitidas es permitir el acceso perimetral desde las redes locales. En el siguiente diagrama, se muestra cómo una lista de entidades permitidas basada en IP bloquea y permite el acceso perimetral:
En el diagrama anterior, una identidad válida intentó acceder al perímetro. Los intentos de acceso se rechazan cuando se originan en cualquier dirección IP de Internet. Sin embargo, se permite el acceso cuando se origina en las direcciones IP públicas corporativas.
Una variación de esta situación se da cuando permites el acceso al perímetro desde
los recursos privados implementados en un proyecto o en una organización diferente. En este caso
de uso, se requiere una puerta de enlace de Cloud NAT en el proyecto de origen.
Cloud NAT
se integra con el Acceso privado a Google,
lo que habilita automáticamente este acceso en la subred del recurso
y mantiene el tráfico a las APIs y los servicios de Google de forma interna, en lugar de enrutarlo
a Internet con la dirección IP externa de la puerta de enlace de Cloud NAT.
Como el tráfico se enruta en la red interna de Google, el
campo RequestMetadata.caller_ip del objeto AuditLog se oculta y
se reemplaza por gce-internal-ip. Para permitir el acceso al perímetro en este caso, debes
configurar una regla de entrada que permita el acceso según otros atributos, como
el proyecto o la cuenta de servicio, en lugar de configurar un nivel de acceso basado
en la dirección IP de origen externa.
Otorga acceso en función de la identidad del emisor
Para implementar una lista de entidades permitidas basada en la identidad, debes agregar las cuentas de servicio y los administradores avanzados de la organización a una lista de permisos. El perímetro está abierto para estas identidades desde cualquier dirección IP, por lo que debes asegurarte de que las identidades estén bien protegidas. También debes asegurarte de evitar la creación de claves para las cuentas de servicio que agregaste a una lista de entidades permitidas. No es común agregar identidades de los usuarios a una lista de entidades permitidas en un perímetro (no se pueden agregar grupos a ella).
Se puede acceder a los recursos del perímetro con las VMs de ese perímetro, desde redes locales confiables o dispositivos de confianza. Te recomendamos que uses Cloud Workstations para acceder a los recursos de los perímetros, ya que los Controles del servicio de VPC no son compatibles con Cloud Shell.
Califica en función de los atributos del dispositivo emisor
La confianza del dispositivo, también llamada extremo confiable, se basa en tener un usuario válido de la organización que haya accedido a un navegador Chrome o a una Chromebook. La confianza se aplica al acceso a la sesión en el SO. Por ejemplo, un usuario de Windows que accedió y ejecuta una sesión de Chrome (no es necesario que el navegador esté abierto) puede llamar de forma correcta a los comandos de gcloud CLI en las APIs del perímetro protegido. Sin embargo, una sesión de usuario de Windows diferente en la misma máquina no puede llamar a los comandos en las APIs del perímetro protegido.
Las siguientes condiciones del dispositivo son útiles para establecer su confianza:
ChromeOS verificado es una condición criptográficamente segura que indica que un usuario válido de una organización accedió a una Chromebook iniciada de forma segura. Se trata de una condición de confianza de nivel 1 recomendada.
Requiere la aprobación del administrador para el acceso del dispositivo. Esto permite que los administradores de Cloud Identity aprueben cada dispositivo antes de que se otorgue acceso. De forma predeterminada, los dispositivos se aprueban automáticamente si accede un usuario válido dentro de la organización. Sin embargo, te recomendamos que desactives la opción de aprobación automática.
Requiere que el dispositivo propiedad de la empresa dependa del agente de Chrome que recupera el número de serie del SO, que, por lo general, proviene del BIOS. Este número debe coincidir con los números de serie existentes que ingresaste en Cloud Identity.
Debido a que el número de serie no está autorizado en dispositivos que no son de ChromeOS, es posible que un usuario con privilegios de administrador elevados pueda falsificarlo. Te recomendamos que uses esta condición solo como una verificación de nivel 2.
Para obtener un seguimiento de muestra en el que se otorga acceso controlado según las condiciones que se analizan en la lista anterior, consulta la plantilla de integración de los Controles del servicio de VPC: lista de entidades permitidas (PDF).
Iniciar aplicación de política
Luego de diseñar la lista de entidades permitidas y actualizar los niveles de acceso, te recomendamos que ejecutes las cargas de trabajo para confirmar que no hay incumplimientos. Si las cargas de trabajo se ejecutan sin incumplimientos, puedes iniciar la aplicación de los Controles del servicio de VPC sin afectar las aplicaciones.
Cuando planifiques la aplicación de los controles de servicio de VPC, incluye lo siguiente:
- Selecciona una fecha de aplicación de los controles y comunícala a todos los equipos relacionados.
- Asegúrate de que los equipos de operaciones de seguridad y respuesta ante incidentes estén al tanto de la implementación. Además, deberás verificar que las personas con los permisos adecuados inspeccionen los registros y aprueben las listas de entidades permitidas adicionales, si es necesario.
- Asegúrate de que el equipo de respuesta pueda abrir un caso de asistencia de Google Cloud, en caso de que surjan preguntas o problemas.
- Crea o modifica los niveles de acceso y perímetro con herramientas de automatización como Terraform. No es recomendable que realices estas tareas de forma manual.
Cuando inicias la aplicación de los controles de servicio de VPC, empieza por trasladar proyectos asociados con una sola carga de trabajo desde el perímetro de ejecución de prueba hasta el perímetro real. Asegúrate de dejar tiempo suficiente para que la aplicación se ejecute con éxito mientras observas los registros de incumplimiento. Repite este proceso para las demás cargas de trabajo, una a la vez.
Para mostrar los incumplimientos bloqueados, configura un receptor de registros agregado que envíe los registros de auditoría de todos los proyectos del perímetro a BigQuery. Luego, ejecuta la siguiente consulta:
SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
WHERE JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') is null #exclude logs from a dry-run perimeter
¿Qué sigue?
- Obtén más información para permitir el acceso a recursos protegidos desde fuera del perímetro.
- Obtén información para incluir en una ficha, actualizar y borrar perímetros de servicio.