En este documento, se describe el proceso recomendado para configurar y aplicar Protección de los Controles del servicio de VPC en tu organización de Google Cloud.
La habilitación descuidada de los Controles del servicio de VPC puede causar problemas con las aplicaciones existentes y podría provocar una interrupción del servicio. Te recomendamos que planifiques con cuidado y dar tiempo suficiente para recopilar datos, realizar pruebas y y analizar los registros de incumplimientos. Asegúrate de que los interesados de tu El equipo de operaciones de Controles del servicio de VPC y tu equipo de aplicaciones están disponibles para la tarea.
Para cada carga de trabajo o aplicación que incorpores a los Controles del servicio de VPC, debes repetir el proceso de habilitación.
Coordina la comunicación
A menudo, el equipo de seguridad de red o habilitación de la nube lidera esfuerzo de habilitación de los Controles del servicio de VPC. Te recomendamos que tengas un persona que crea y realiza un seguimiento de las reuniones multidisciplinarias y documenta la acción elementos. Tus equipos colaboran sobre lo siguiente:
- Patrones de acceso a las API de Google Cloud
- Identificación de incumplimientos del perímetro de servicio
- Permite el acceso al perímetro
Al igual que con los firewalls de red convencionales, la intención es identificar y permitir los flujos necesarios para el funcionamiento eficaz de negocios legítimos de las cargas de trabajo.
Patrones de acceso a documentos y casos de uso
Para comenzar el proceso de habilitación, identifica y documenta de manera clara todos los patrones de acceso válidos. Los patrones de acceso son tipos repetibles de interacciones entre elementos fuera y dentro del perímetro. Los siguientes son algunos patrones de acceso comunes:
- Patrones de acceso a datos: Los servicios fuera del perímetro almacenan o recuperan. los datos que residen en el perímetro.
- Patrones de acceso a recursos:
- Los usuarios acceden a los proyectos en el perímetro a través de la consola de Google Cloud.
- Las herramientas o los servicios de terceros administran y acceden a los recursos dentro del perímetro.
- Los servicios o recursos dentro del perímetro acceden a las API de Google.
- Patrones de acceso a extremos:
- Los usuarios acceden a los recursos dentro del perímetro desde un dispositivo que administra tu organización.
- Los recursos locales se comunican con los recursos dentro del perímetro.
Después de identificar los patrones de acceso para una carga de trabajo, identifica tus casos de uso y los clasifica en uno de los patrones de acceso de la lista anterior. Estos son algunos casos de uso comunes:
- Los administradores de Cloud administran proyectos que forman parte de un perímetro.
- Los servicios de automatización como Terraform, Jenkins y Microsoft Azure DevOps que residen fuera del perímetro administran la implementación de recursos dentro del perímetro.
- Los servicios de administración de configuración, como Ansible, Chef o Puppet, que están fuera del perímetro, administran la implementación y la configuración de software en recursos ubicados dentro del perímetro.
- La supervisión de la seguridad y la aplicación de servicios como Forseti o SIEM que residen fuera del perímetro consumen datos o aplican las políticas de seguridad en un recurso dentro del perímetro.
En cada caso de uso, documenta lo siguiente:
- El patrón de acceso
- Los actores que pueden activar el caso de uso
- Condiciones que activan el caso de uso
- Si el caso de uso es un patrón de acceso válido y se debe permitir
- Suposiciones respecto del caso de uso
Para obtener un patrón de acceso y una herramienta de seguimiento de casos de uso de muestra, consulta la plantilla de integración de los Controles del servicio de VPC: casos de uso.
Realiza entrevistas
Realiza entrevistas con tus equipos de cargas de trabajo para analizar los patrones de acceso y los casos de uso que recopilas de las plantillas de comunicación anteriores. Los siguientes son ejemplos de preguntas que puedes hacer durante estas entrevistas:
¿Tus casos de uso son una primera prioridad para tener en cuenta en la habilitación de los Controles del servicio de VPC? Te recomendamos que solo consideres cargas de trabajo de primera prioridad para la habilitación inicial e integrar otras, y menos esenciales después de proteger los recursos fundamentales de la empresa.
¿Puedes completar una ejecución integral de todos los casos de uso? Debes hacer esto a fin de activar todos las situaciones de perímetro posibles que puedes analizar por completo y confirmar que la aplicación funcionará correctamente después de que apliques el perímetro.
¿Cuánto tiempo se tarda en ejecutar la ejecución de casos de uso?
¿Estás planificando algún cambio importante para esta carga de trabajo que podría entrar en conflicto con la habilitación de los Controles del servicio de VPC? Las características de la carga de trabajo deben estar en un estado estable antes de habilitar los Controles del servicio de VPC.
Prepara una ejecución de prueba
El modo de ejecución de prueba reduce la complejidad de probar la aplicación de los Controles del servicio de VPC para identificar infracciones sin interrupción en las aplicaciones. Configuras una ejecución de prueba como un perímetro independiente que registra todas las infracciones, pero no realiza ningún bloqueo. Puedes ejecutar cargas de trabajo mientras se encuentran en el perímetro de ejecución de prueba y generar registros de incumplimiento para analizar.
Para preparar el entorno de ejecución de prueba, sigue estos pasos:
- Identifica todos los proyectos calificados para formar parte del perímetro y completa el caso de uso y el proceso de entrevista para esos proyectos.
- Crea un perímetro de prueba de validación y agregar todos los proyectos.
- En el perímetro de servicio de los Controles del servicio de VPC, en Servicios restringidos > Servicios para proteger, agrega todos los servicios compatibles.
Crea un receptor de registros agregado que envía todos los registros a BigQuery, o crea receptor de registros para cada proyecto que envía los registros de prueba de validación a una BigQuery de tu conjunto de datos. Para consultar estos mensajes de registro y, también, identificar los incumplimientos en los Controles del servicio de VPC, puedes usar una búsqueda de SQL.
Para crear un receptor de registros que incluya todos los registros relevantes de los Controles del servicio de VPC mensajes, usa el siguiente filtro:
logName="projects/$PROJECT/logs/cloudaudit.googleapis.com%2Fpolicy"
Para obtener la máxima seguridad, no permitas el acceso a servicios no compatibles. Configura tu perímetro de modo que solo los servicios restringidos funcionen en él. Para ello, configura la lista de servicios accesibles para
RESTRICTED-SERVICES
Si ya tienes una lista de IP públicas, identidades, dispositivos de confianza, proyectos o redes de VPC permitidos, agrégalos a una regla de entrada o a un nivel de acceso según corresponda en el perímetro de ejecución de prueba. Permitir flujos legítimos conocidos ayuda a reducir la cantidad de registros de infracciones y permite que los revisores se enfoquen en eventos prácticos.
Verifica que ninguna de las VPC de los proyectos tenga una ruta de salida a Internet o la VIP privada.
Verifica que todas las VPC tengan el DNS
*.googleapis.com
que apunte arestricted.googleapis.com
.
Ejecuta casos de uso
En un momento acordado, pídele al equipo de tu aplicación que ejecute su carga de trabajo del proyecto en el perímetro de ejecución de prueba. Asegúrate de tener una cobertura completa de todo el código que pueda llamar a las API de Google. Cuando finaliza la ejecución de prueba, tu el equipo de revisión puede realizar el análisis del registro de incumplimientos.
Analiza los incumplimientos
Los registros de incumplimiento que se detectan durante la ejecución de prueba contienen la mayor parte de la información que necesitas para determinar si un incumplimiento de la aplicación requiere alguna acción, como agregar identidades o direcciones IP a la lista de entidades permitidas del perímetro. Los datos de incumplimiento se almacenan en la tabla de BigQuery cloudaudit_googleapis_com_policy
.
Los siguientes son los elementos principales para analizar el incumplimiento:
- El servicio y el método de la API protegidos que se llaman.
- El proyecto dentro del perímetro que hubiera bloqueado la solicitud.
- El correo electrónico de la identidad que llama a la API protegida.
- La dirección IP del emisor de la llamada.
- El tipo de incumplimiento.
En el siguiente ejemplo, se muestra una consulta de BigQuery que muestra todos los detalles de la infracción:
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') = "true" #ensure these are dry-run logs
Consulta los incumplimientos relevantes
Las siguientes estrategias pueden ayudarlo a identificar las infracciones relevantes:
Agrega un calificador de marca de tiempo para el período cuando cada aplicación ejecutó su caso de uso:
WHERE receiveTimestamp >'2020-07-23 19:53:48.241317 UTC'
Agrega un filtro para la convención de nombres de identidades de cargas de trabajo o de proyectos:
WHERE where resource.labels.project_id like '%APPLICATION_NAME%'
Revisa los registros de incumplimiento
Cuando revises los registros de las incumplimiento, determina si ocurren los siguientes casos:
- ¿Se espera que la identidad (correo electrónico) invoque las API protegidas?
- ¿El emisor debe poder invocar la API desde fuera del perímetro?
En función de los criterios anteriores, determina si necesitas permitir que la identidad, el dispositivo, la dirección IP, el rango de CIDR, el proyecto o la red accedan al perímetro desde afuera.
Algunas entradas podrían tener una dirección IP private
. Esto indica que la llamada provino de la red de Google, ya sea mediante los servicios de Google o una VPC en un proyecto fuera del perímetro. En el caso de los servicios de Google, como los escritores de receptores de registros, debes agregar la cuenta de servicio de Google a una lista de permisos.
Las entradas sin correos electrónicos se deben a las siguientes razones: Ocultamiento de los Registros de auditoría de Cloud para las operaciones de solo lectura que se rechazaron debido a la falta de IAM permisos. En esos casos, puedes usar la dirección IP y los nombres de recursos para comprender el origen del intento de acceso. Este tipo de intento de acceso puede un acceso accidental de un usuario ajeno a su organización Por ejemplo, un usuario que escribe mal un bucket con un nombre similar.
Si ves un tipo de incumplimiento de SERVICE_NOT_ALLOWED_FROM_VPC
, la carga de trabajo podría estar usando un servicio que es compatible con los Controles del servicio de VPC, pero que no se agregó a la lista de APIs protegidas. Por ejemplo, si IAM causó una infracción de este tipo, el administrador debe agregar IAM a la lista de servicios accesibles ejecutando el siguiente comando de Google Cloud CLI:
gcloud access-context-manager perimeters update perimeter_test \
--add-vpc-allowed-services=RESTRICTED-SERVICES,IAM.googleapis.com \
--policy=1234567890
Puedes crear un panel de Looker Studio para revisar los incumplimientos. Para obtener más información, consulta Supervisa los incumplimientos de los Controles del servicio de VPC en tu organización de Google Cloud con Looker Studio. Looker Studio antes se conocía como Data Studio.
¿Qué sigue?
- Obtén más información sobre los perímetros de servicio.
- Obtén más información para crear un perímetro de servicio.