Cómo Google adoptó BeyondCorp

Google comenzó como una empresa basada en la net y, a medida que maduró en la era moderna, la mayoría de las aplicaciones comerciales internas se desarrollaron con un enfoque basado primero en la world wide web. Estas aplicaciones se alojaron en una arquitectura interna comparable a la de nuestros servicios externos, con la excepción de que solo se podía acceder a ellas en las redes de oficinas corporativas. Por lo tanto, la identificación de los servicios que BeyondCorp debe controlar se hizo más fácil para nosotros debido al hecho de que la mayoría de los servicios internos ya estaban correctamente inventariados y alojados a través de soluciones estándar y centrales. La migración, en muchos casos, fue tan simple como un cambio de DNS. Los sistemas sólidos de inventario de activos de TI y el mantenimiento son críticos para migrar a un modelo de seguridad de confianza cero.

El cumplimiento de las políticas de acceso de confianza cero comenzó con los servicios que determinamos que no se verían significativamente afectados por el cambio en los requisitos de acceso. Para la mayoría de los servicios, los requisitos podrían reunirse a través del análisis de registro de acceso típico o mediante consultas con los propietarios del servicio. Los servicios que no podían abrirse fácilmente por los requisitos predeterminados de ACL requerían que los propietarios de servicios desarrollaran grupos de acceso estrictos y / o eliminaran flujos de trabajo riesgosos antes de que pudieran migrarse.

¿Qué haces con los servicios que son incompatibles con los ideales de BeyondCorp?

Es posible que no siempre sea posible cerrar una aplicación con la solución de confianza cero preferida. Los servicios que no se pueden bloquear fácilmente generalmente se dividen en estas categorías:

• Tipo 1: «Protocolos no proxables», p. tráfico no HTTP / HTTPS.
• Tipo 2: requisitos de baja latencia o tráfico localizado de alto rendimiento.
• Tipo 3: Redes de acceso administrativo y de emergencia.

El primer paso típico para encontrar una solución para estos casos es encontrar una manera de eliminar por completo la necesidad de ese servicio. En muchos casos, esto fue posible al desaprobar o reemplazar sistemas que no podían hacerse compatibles con la implementación de BeyondCorp.

Cuando esa no era una opción, descubrimos que ninguna solución única funcionaría para todos los requisitos críticos:

• Las soluciones para el tráfico «Tipo 1» generalmente han implicado el mantenimiento de un túnel especializado para el cliente que impone enérgicamente las decisiones de autenticación y autorización en el cliente y el extremo del servidor de la conexión. Este suele ser un tráfico de tipo cliente / servidor que es very similar al tráfico HTTP en que la conectividad suele ser multipunto a punto.
• Las soluciones a los problemas de «Tipo 2» generalmente se basan en mover los recursos informáticos compatibles con BeyondCorp localmente o desarrollar una solución estrechamente integrada con el equipo de acceso a la red para reenviar selectivamente el tráfico «community» sin abrir permanentemente los agujeros de la pink.
• En cuanto al «Tipo 3», sería perfect eliminar completamente todas las redes internas privilegiadas. Sin embargo, la realidad es que es possible que siempre se requiera una red privilegiada para mantener la red en sí y también para proporcionar acceso de emergencia durante las interrupciones.

Cabe señalar que el tráfico de servidor a servidor en entornos de centros de datos de producción seguros no depende necesariamente de BeyondCorp, aunque muchos sistemas se integran independientemente, debido a los beneficios de diseño orientado a servicios que BeyondCorp proporciona inherentemente.

¿Cómo priorizas el gating?

La priorización comienza identificando todos los servicios a los que actualmente se puede acceder solo a través del acceso IP interno y migrando los servicios más críticos a BeyondCorp, mientras se trabaja para reducir lentamente los permisos a través de procesos de administración de excepciones. La criticidad del servicio también puede depender del número y tipo de usuarios, la sensibilidad de los datos manejados, los riesgos de seguridad y privacidad habilitados por el servicio.

Logística de migración

La mayoría de los servicios requieren pruebas de integración con el proxy BeyondCorp. Se alentó a los equipos de servicio a defender los servicios de «prueba» que se utilizaron para probar la funcionalidad detrás del proxy BeyondCorp. La mayoría de los servicios que realizaron su propio handle de acceso fueron reconfigurados para confiar en BeyondCorp para toda la autenticación y autorización de usuarios / grupos. Se ha alentado a los equipos de servicio a desarrollar sus propios controles de acceso discrecional «específicos» en los servicios aprovechando los datos de sesión proporcionados por el proxy BeyondCorp.

Inventario: es fácil pasar por alto la importancia de mantener un buen inventario de servicios, dispositivos, propietarios y excepciones de seguridad. El viaje a un mundo de BeyondCorp debería comenzar resolviendo desafíos organizacionales al administrar y mantener la calidad de los datos en los sistemas de inventario. En resumen, saber cómo funciona un servicio, quién debe acceder a él y qué lo hace aceptable son los principios centrales de la administración de BeyondCorp. El command de acceso de grano fino es muy complicado cuando falta esta información.

Protocolos heredados: la mayoría de las grandes empresas inevitablemente necesitarán admitir flujos de trabajo y protocolos que no se puedan migrar a un mundo BeyondCorp (en un período de tiempo razonable). La gestión de excepciones y el inventario de servicios se vuelven cruciales en esta etapa mientras las partes interesadas desarrollan soluciones.

La iniciativa BeyondCorp no sería sostenible a escala de Google sin la participación de varios equipos de Ingeniería de Confiabilidad del Sitio (SRE) en los sistemas de inventario, la infraestructura de BeyondCorp y las soluciones del lado del cliente. La capacidad de lograr con éxito la adopción generalizada de cambios tan grandes puede verse obstaculizada por problemas de fiabilidad percibidos (o en algunos casos, reales). Comprender los flujos de trabajo de los usuarios que podrían verse afectados, trabajar con las partes interesadas clave y garantizar que la transición sea fluida y sin problemas para todos los usuarios ayuda a proteger contra la reacción violenta y evita que los usuarios encuentren soluciones indeseables. Al aplicar nuestro prácticas de ingeniería de confiabilidad, esos equipos ayudaron a garantizar que todos los componentes de nuestra implementación tengan objetivos de disponibilidad y latencia, robustez operativa, etcetera. Estos son compatibles con nuestras necesidades comerciales y experiencias de usuario previstas.

Ponga a los empleados en regulate tanto como sea posible

Los empleados cubren una amplia gama de funciones de trabajo con diferentes requisitos de tecnología y herramientas. Además de comunicar los cambios a nuestros empleados de manera temprana, les brindamos soluciones de autoservicio para manejar excepciones o abordar problemas que afectan sus dispositivos. Al poner a nuestros empleados en command, ayudamos a garantizar que los mecanismos de seguridad no se interpongan en su camino, ayudando con la aceptación y los procesos de escala.