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, 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 CIDR de IP pública en los niveles de acceso para las listas de permisos basadas en IP. Dado que este método permite todas las APIs protegidas de este rango de IP, el entorno detrás de estas IP debe ser de confianza y estar controlado. 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.
Otorga acceso en función de la identidad del emisor
Para implementar una lista entidades permitidas basada en la identidad, agrega cuentas de servicio y 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 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 del perímetro, desde redes locales de confianza o desde dispositivos de confianza. Recomendamos usar Cloud Workstations para acceder a los recursos dentro 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 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 la confianza del dispositivo:
Chrome OS 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.
Debido a que el número de serie no es 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. Recomendamos usar esta condición solo como 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.
- Asegúrate de que los equipos de operaciones de seguridad y respuesta ante incidentes estén al tanto de la implementación. Además, asegúrate de 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 a la situación pueda abrir un caso de asistencia de Google Cloud si surge 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 los incumplimientos bloqueados, configura un receptor de registros agregados que envíe 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 los recursos protegidos desde fuera del perímetro.
- Aprende a enumerar, actualizar y borrar perímetros de servicio.