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 en función de las listas de entidades permitidas.
Cuando completes una ejecución de prueba de carga de trabajo, identifica una lista de direcciones IP y de identidades que debes agregar a una lista de entidades permitidas. También es posible que algunas cargas de trabajo necesiten una lista de permisos 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 de CIDR de IP públicas en los niveles de acceso de las listas de entidades permitidas basadas en IP. Dado que este método permite APIs protegidas de este rango de IP, el entorno detrás de estas IP confiables y controlados. Una situación típica de uso para esta lista de permisos es permitir el acceso perimetral desde las redes locales. En el siguiente diagrama, se muestra cómo un bloqueo de lista de permiso basado en IP 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 es cuando permites el acceso perimetral desde recursos privados implementados en una organización o un proyecto diferente. En este caso de uso, se requiere una puerta de enlace de Cloud NAT en el proyecto de origen.
Cloud NAT tiene una integración con el Acceso privado a Google que habilita automáticamente el Acceso privado a Google en la subred del recurso y mantiene el tráfico a las APIs y los servicios de Google interno, 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 dentro de la red interna de Google, el
El campo RequestMetadata.caller_ip del objeto AuditLog se oculta como
gce-internal-ip Para permitir el acceso al perímetro en este caso, debes configurar una regla de entrada para permitir el acceso en función de otros atributos, como el proyecto o la cuenta de servicio, en lugar de configurar un nivel de acceso en función de 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, agrega cuentas de servicio y administradores avanzados de la organización a una lista de entidades permitidas. 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 permisos. No es común agregar identidades de los usuarios a una lista de entidades permitidas (los grupos no pueden agregarse a esta ) en un perímetro.
Se puede acceder a los recursos dentro del perímetro a través de VMs dentro desde redes locales confiables o dispositivos de confianza. Mié recomienda usar Cloud Workstations para acceder recursos dentro de los perímetros porque los Controles del servicio de VPC no son compatibles Cloud Shell.
Califica en función de los atributos del dispositivo emisor
La confianza del dispositivo, también llamada extremo de confianza, se basa en tener un usuario de la organización válido que haya accedido a un navegador Chrome o a una Chromebook. La confianza se aplica al acceso a la sesión del 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 CLI de gcloud en las API de perímetro protegido. Sin embargo, una sesión de usuario de Windows diferente en la misma máquina no puede llamar a comandos en las API 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. Esta es una condición de confianza de nivel 1 recomendada.
Requiere la aprobación del administrador para el acceso del dispositivo: 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, 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.
Dado 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 falsificar el número de serie. Te recomendamos usar 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.
Inicia la aplicación forzosa
Después de diseñar la lista de entidades permitidas y actualizar los niveles de acceso, te recomendamos que vuelvas a ejecutar 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, incluye lo siguiente:
- Selecciona una fecha de aplicación y hazla saber a todos los equipos relacionados.
- Garantizar que las operaciones de seguridad y los equipos de respuesta ante incidentes estén al tanto la implementación. Además, asegúrate de que las personas con acceso inspeccionan registros y aprueban listas de entidades permitidas adicionales, si es necesario.
- Garantizar que el equipo de respuesta a la situación pueda abrir una cuenta de Google Cloud caso de asistencia técnica, en caso de que surja alguna pregunta o problema.
- 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 forzosa, comienza 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 correctamente mientras observas los registros de incumplimiento. Repite el proceso para las demás cargas de trabajo, una a la vez.
Para detectar incumplimientos bloqueados, configura un receptor de registros agregado que envíe registros de auditoría para 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?
- Aprende a permitir el acceso a recursos protegidos desde fuera del perímetro.
- Aprende a enumerar, actualizar y borrar perímetros de servicio.