En este documento se describen las implementaciones a nivel de acceso y se ofrecen recomendaciones para iniciar la aplicación de perímetros de servicio en función de listas de elementos permitidos.
Cuando completas una ejecución de prueba de cargas de trabajo, identificas una lista de direcciones IP e identidades que debes añadir a una lista de permitidas. También puede que algunas cargas de trabajo necesiten una lista de permitidos basada en dispositivos. Para conceder acceso controlado a recursos protegidos, puedes usar niveles de acceso de Controles de Servicio de VPC. Google Cloud Algunas formas prácticas de implementar niveles de acceso se basan en la dirección IP, la identidad o el dispositivo.
Para obtener más información, consulta el artículo Acceso contextual con reglas de entrada.
Conceder acceso en función de la IP de origen
Solo puedes usar intervalos CIDR de IP públicas en los niveles de acceso de las listas de permitidas basadas en IP. Como este método permite todas las APIs protegidas de este intervalo de IPs, el entorno que hay detrás de estas IPs debe ser de confianza y estar controlado. Un caso de uso habitual de esta lista de permitidos es permitir el acceso perimetral desde redes locales. En el siguiente diagrama se muestra cómo una lista de permitidos basada en IPs bloquea y permite el acceso al perímetro:
En el diagrama anterior, una identidad válida intenta acceder al perímetro. Los intentos de acceso se rechazan cuando proceden de cualquier dirección IP de Internet. Sin embargo, se permite el acceso cuando se obtiene de las direcciones IP públicas de la empresa.
Una variante de esta situación es cuando permites el acceso al perímetro desde recursos privados implementados en otro proyecto u organización. En este caso de uso, se necesita una pasarela de Cloud NAT en el proyecto de origen.
Cloud NAT se integra con Acceso privado de Google para habilitar automáticamente esta función en la subred del recurso y mantener el tráfico a las APIs y los servicios de Google de forma interna, en lugar de enrutarlo a Internet mediante 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 muestra como gce-internal-ip. Para permitir el acceso al perímetro en este caso, debes configurar una regla de entrada que permita el acceso en función de 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.
Conceder acceso en función de la identidad de la persona que llama
Para implementar una lista de permitidos basada en identidades, añade cuentas de servicio y superadministradores de la organización a una lista de permitidos. El perímetro está abierto para estas identidades desde cualquier dirección IP, por lo que debes asegurarte de que estén bien protegidas. También debes asegurarte de no generar claves para las cuentas de servicio que hayas añadido a una lista de permitidas. No es habitual añadir identidades de usuario a una lista de permitidos (los grupos no se pueden añadir a una lista de permitidos) en un perímetro.
Se puede acceder a los recursos que se encuentran dentro del perímetro a través de las VMs que están dentro del perímetro, desde redes on-premise de confianza o desde dispositivos de confianza. Te recomendamos que uses estaciones de trabajo en la nube para acceder a los recursos de los perímetros, ya que Controles de Servicio de VPC no es compatible con Cloud Shell.
Habilitar el acceso en función de los atributos del dispositivo de la persona que llama
La confianza del dispositivo, también llamada endpoint de confianza, se basa en que un usuario de la organización válido haya iniciado sesión en el navegador Chrome o en un Chromebook. La confianza se aplica a la sesión iniciada del SO. Por ejemplo, un usuario de Windows que haya iniciado sesión y esté ejecutando una sesión de Chrome (no es necesario que el navegador esté abierto) puede llamar correctamente a comandos de la CLI de gcloud en APIs de perímetro protegidas. Sin embargo, una sesión de usuario de Windows diferente en el mismo ordenador no puede llamar a comandos en las APIs de perímetro protegido.
Las siguientes condiciones de los dispositivos son útiles para establecer la confianza en los dispositivos:
Chrome OS verificado es una condición altamente segura y verificada criptográficamente que indica que un usuario válido de la organización ha iniciado sesión en un Chromebook que se ha iniciado de forma segura. Esta es una condición de confianza de nivel 1 recomendada.
Requerir que un administrador apruebe el acceso de los dispositivos permite a los administradores de Cloud Identity aprobar cada dispositivo antes de concederle acceso. De forma predeterminada, los dispositivos se aprueban automáticamente si tienen la sesión iniciada de un usuario de la organización válido. Sin embargo, te recomendamos que desactives la opción de aprobación automática.
Requerir dispositivo propiedad de la empresa se basa en que el agente de Chrome obtenga el número de serie del sistema operativo, que suele proceder de la BIOS. Este número debe coincidir con los números de serie que ya haya introducido en Cloud Identity.
Como el número de serie no es una fuente fiable en los dispositivos que no tienen ChromeOS, un usuario con privilegios de administrador elevados podría falsificarlo. Te recomendamos que uses esta condición solo como comprobación de nivel 2.
Para ver un ejemplo de hoja de seguimiento para conceder acceso controlado en función de las condiciones descritas en la lista anterior, consulta la plantilla de incorporación de Controles de Servicio de VPC: lista de permitidos (PDF).
Iniciar la aplicación obligatoria
Después de diseñar la lista de permitidos y actualizar los niveles de acceso, te recomendamos que vuelvas a ejecutar las cargas de trabajo para confirmar que no hay ninguna infracción. Si las cargas de trabajo se ejecutan sin infracciones, puedes iniciar la aplicación de Controles de Servicio de VPC sin que afecte a las aplicaciones.
Cuando planifiques la aplicación, incluye lo siguiente:
- Elige una fecha de implementación y comunícala a todos los equipos relacionados.
- Asegúrate de que los equipos de operaciones de seguridad y de respuesta ante incidentes conozcan la implementación. Además, asegúrate de que las personas con los permisos adecuados inspeccionen los registros y aprueben listas de permitidos adicionales, si es necesario.
- Asegúrate de que el equipo de respuesta ante emergencias pueda abrir un Google Cloud caso de asistencia si surge alguna duda o problema.
- Crea o modifica perímetros y niveles de acceso con herramientas de automatización como Terraform. No recomendamos realizar estas tareas manualmente.
Cuando inicies la aplicación, empieza por mover los proyectos asociados a una sola carga de trabajo del perímetro de prueba al perímetro activo. Asegúrate de dejar tiempo para que la aplicación se ejecute correctamente mientras observas los registros de infracciones. Repite el proceso con las cargas de trabajo restantes de una en una.
Para mostrar las infracciones bloqueadas, configura un sumidero de registro agregado que envíe los registros de auditoría de todos los proyectos del perímetro a BigQuery. Después, 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
Siguientes pasos
- Consulta cómo permitir el acceso a recursos protegidos desde fuera del perímetro.
- Consulta cómo listar, actualizar y eliminar perímetros de servicio.