Weblog de seguridad en línea de Google: Cómo Google adoptó BeyondCorp

Introducción

Esta es la tercera publicación de una serie de cuatro, en la que nos propusimos volver a visitar varios BeyondCorp temas y compartir lecciones aprendidas a lo largo de la ruta de implementación interna en Google.
los Primer comentario en esta serie se centró en proporcionar el contexto necesario para la forma en que Google adoptó BeyondCorp, la implementación de Google del modelo de seguridad de confianza cero. los segunda publicación centrado en la gestión de dispositivos: cómo decidimos si se debe confiar o no en un dispositivo y por qué es necesaria esa distinción. Esta publicación presenta el concepto de acceso escalonado, su importancia, cómo lo implementamos y cómo abordamos los desafíos de resolución de problemas asociados.

Arquitectura de alto nivel para BeyondCorp

¿Qué es el acceso escalonado?

En un sistema de certificado de cliente tradicional, los certificados solo se otorgan a dispositivos confiables. Google usó este enfoque inicialmente ya que simplificó drásticamente la confianza del dispositivo. Con dicho sistema, se puede confiar en cualquier dispositivo con un certificado válido. A intervalos predefinidos, los clientes prueban que se puede confiar en ellos y se emite un nuevo certificado. Por lo normal, es un proceso liviano y existen muchos productos disponibles para implementar flujos que cumplen con este principio.

Sin embargo, hay una serie de desafíos con esta configuración:

  • No todos los dispositivos necesitan el mismo nivel de protección de seguridad (por ejemplo, dispositivos con problemas no estándar, plataformas más antiguas necesarias para las pruebas, BYOD, and so forth.).
  • Estos sistemas no permiten fácilmente el acceso matizado basado en una postura de seguridad cambiante.
  • Estos sistemas tienden a evaluar un dispositivo en función de un único conjunto de criterios, independientemente de si los dispositivos requieren acceso a datos altamente confidenciales (por ejemplo, finanzas corporativas) o datos mucho menos confidenciales (por ejemplo, un tablero de instrumentos que se muestra en un espacio público).

El próximo desafío introducido por los sistemas tradicionales es el requisito inherente de que un dispositivo debe cumplir con sus requisitos de seguridad antes de que pueda obtener un certificado. Esto parece razonable en el papel, pero desafortunadamente significa que la infraestructura de certificados existente no se puede usar para ayudar al aprovisionamiento de dispositivos. Esto implica que debe tener una infraestructura adicional para iniciar un dispositivo en un estado confiable.

El desafío más importante es la gran cantidad de tiempo entre las evaluaciones de confianza. Si solo instala un nuevo certificado una vez al año, esto significa que puede tomar todo un año antes de que pueda volver a certificar un dispositivo. Por lo tanto, cualquier nuevo requisito que desee agregar a la flota puede demorar hasta un año antes de que esté totalmente vigente. Por otro lado, si requiere que los certificados se instalen mensualmente o diariamente, ha impuesto una carga significativa a sus usuarios y / o private de soporte, ya que se ven obligados a pasar por el proceso de emisión de la certificación con mucha más frecuencia, lo que puede ser tiempo Consumidor y frustrante. Además, si se determina que un dispositivo no cumple con la política de seguridad, la única opción es eliminar todo acceso revocando el certificado, en lugar de degradar el acceso, lo que puede crear una situación frustrante de todo o nada para el usuario.

El acceso escalonado intenta abordar todos estos desafíos, por lo que decidimos adoptarlo. En este nuevo modelo, los certificados se utilizan simplemente para proporcionar la identidad del dispositivo, en lugar de actuar como prueba de confianza. Las decisiones de confianza se toman luego por un sistema separado que puede modificarse sin interferir con el proceso de emisión del certificado o su validez. Mover la evaluación de confianza fuera de banda de la emisión del certificado nos permite sortear los desafíos identificados anteriormente en el sistema tradicional. A continuación hay tres formas en que el acceso por niveles ayuda a abordar estas inquietudes.

Diferentes niveles de acceso para diferentes estados de seguridad.

Al separar la confianza de la identidad, podemos definir niveles infinitos de confianza, si así lo deseamos. En cualquier momento, podemos definir un nuevo nivel de confianza, o ajustar los requisitos de nivel de confianza existentes, y reevaluar el cumplimiento de un dispositivo. Este es el corazón del sistema de acceso escalonado. Nos proporciona la flexibilidad para definir diferentes criterios de confianza del dispositivo para aplicaciones de baja sensibilidad de aquellos utilizados para aplicaciones de alta confianza.

Resolviendo el desafío de bootstrapping

Múltiples estados de confianza nos permiten usar el sistema para iniciar una instalación del sistema operativo. Ahora podemos permitir el acceso a los servicios de arranque (configuración y administración de parches) basados ​​únicamente en si somos propietarios del dispositivo. Esto permite el aprovisionamiento de redes no confiables, lo que nos permite reemplazar las comprobaciones tradicionales basadas en IP.

Frecuencia configurable de evaluaciones de confianza

La frecuencia de la evaluación de confianza del dispositivo es independiente de la emisión del certificado en una configuración de acceso escalonado. Esto significa que puede evaluar la confianza con la frecuencia que considere necesaria. Los cambios en las definiciones de confianza pueden reflejarse inmediatamente en toda la flota. Los cambios en la postura del dispositivo pueden impactar de manera related inmediatamente en la confianza.

Debemos tener en cuenta que la capacidad del sistema para eliminar rápidamente la confianza de los dispositivos puede ser un arma de doble filo. Si hay errores en las definiciones o evaluaciones de confianza, esto también puede eliminar rápidamente la confianza de los dispositivos «buenos». Debe tener la capacidad de probar adecuadamente los cambios de política para mitigar el radio de explosión de este tipo de errores, e idealmente cambios canarios en subconjuntos de la flota durante un período de cocción. El monitoreo constante también es crítico. Un error en su sistema de evaluación de confianza puede hacer que comience a evaluar mal la confianza. Es aconsejable agregar alarmas si el sistema comienza a perder (o aumentar) la confianza de demasiadas máquinas a la vez. La sección de solución de problemas a continuación proporciona técnicas adicionales para ayudar a minimizar el impacto de la lógica de confianza mal configurada.

¿Cómo definimos los niveles de acceso?

El concepto básico de niveles es relativamente sencillo: el acceso a los datos aumenta a medida que aumenta el endurecimiento de la seguridad del dispositivo. Estos niveles son útiles para el manage de acceso de grano grueso de los dispositivos del cliente, lo que hemos encontrado que es suficiente en la mayoría de los casos. En Google, permitimos al usuario elegir el nivel de dispositivo que le permite sopesar las necesidades de acceso con los requisitos y políticas de seguridad. Si un usuario necesita acceder a más datos corporativos, puede que tenga que aceptar más restricciones de configuración del dispositivo. Si un usuario desea más control sobre su dispositivo y menos restricciones, pero no necesita acceso a recursos de mayor riesgo, puede elegir un nivel con menos acceso a los datos corporativos. Para obtener más información sobre las propiedades de una plataforma confiable que puede medir, visite nuestro documento sobre Mantener una flota saludable.

Sabíamos que este modelo funcionaría en principio, pero no sabíamos cuántos niveles de acceso deberíamos definir. Como se describió anteriormente, el modelo anterior solo tenía dos niveles: confiable y no confiable. Sabíamos que queríamos más que eso para permitir la acumulación de confianza como mínimo, pero no sabíamos el número great. Más niveles permiten especificar listas de regulate de acceso con mayor fidelidad a costa de confusión para los propietarios de servicios, ingenieros de seguridad y la foundation de empleados más amplia por igual.

En Google, inicialmente admitimos cuatro niveles distintos que van desde acceso no confiable hasta acceso altamente privilegiado. Los extremos son fáciles de entender: los dispositivos no confiables solo deben acceder a los datos que ya son públicos, mientras que los dispositivos de acceso altamente privilegiado tienen mayores privilegios internos. Los dos niveles intermedios permitieron a los propietarios de sistemas diseñar sus sistemas teniendo en cuenta el modelo de acceso por niveles. Ciertas acciones sensibles requerían un dispositivo de acceso altamente privilegiado, mientras que las partes menos sensibles del sistema podían alcanzarse con dispositivos menos confiables. Este modelo de acceso degradado nos pareció genial para los expertos en seguridad. Desafortunadamente, los empleados no pudieron determinar qué nivel deberían elegir para garantizar que pudieran acceder a todos los sistemas que necesitaban. Al remaining, determinamos que el nivel medio adicional condujo a una intensa confusión sin mucho beneficio.

En nuestro modelo actual, la gran mayoría de los dispositivos se ajustan a uno de tres niveles distintos: acceso no confiable, acceso básico y acceso altamente privilegiado. En este modelo, los propietarios del sistema deben elegir la ruta más confiable si su sistema es más practical. Este requisito limita la delicadeza del sistema, pero lessen en gran medida la confusión de los empleados y fue clave para una adopción exitosa.

Además de los niveles, nuestro sistema puede proporcionar un contexto adicional para acceder a puertas de enlace y aplicaciones y servicios subyacentes. Esta información adicional es útil para proporcionar un regulate de acceso más fino y basado en el dispositivo. La imposición de restricciones de dispositivos adicionales en sistemas altamente sensibles, además de verificar el nivel de grano grueso, es una forma razonable de equilibrar la seguridad con las expectativas del usuario. Debido a que los sistemas altamente sensibles solo son utilizados por un subconjunto más pequeño de la población de empleados, según el rol y la necesidad, estas restricciones adicionales generalmente no son una fuente de confusión para el usuario. Con eso en mente, tenga en cuenta que este artículo solo cubre los controles basados ​​en dispositivos y no trata los controles específicos basados ​​en la identidad del usuario.

En el otro extremo del espectro, tenemos servicios de instalación / reparación de SO. Estos sistemas son necesarios para admitir el arranque de un dispositivo que, por diseño, aún no se adhiere al nivel de acceso básico. Como se describió anteriormente, utilizamos nuestros certificados como identidad del dispositivo, no como validación de confianza. En el caso de instalación del sistema operativo, no existen datos informados, pero podemos tomar decisiones de acceso en función de los datos de inventario asociados con la identidad de ese dispositivo. Esto nos permite garantizar que nuestro sistema operativo y los agentes de seguridad solo estén instalados en los dispositivos que poseemos y que esperamos que estén en uso. Una vez que el sistema operativo y los agentes de seguridad estén en funcionamiento, podemos usarlos para bloquear el dispositivo y demostrar que se encuentra en un estado digno de mayor confianza.

¿Cómo creamos reglas para implementar los niveles?

Los datos basados ​​en dispositivos son el corazón de BeyondCorp y el acceso por niveles. Evaluamos los niveles de confianza utilizando datos sobre cada dispositivo en Google para determinar su integridad de seguridad y nivel de nivel. Para obtener estos datos, creamos una tubería de inventario que agrega datos de varias fuentes de autoridad dentro de nuestra empresa para obtener una visión holística e integral de la postura de seguridad de un dispositivo. Por ejemplo, reunimos el inventario de activos prescritos de la compañía en un servicio y observamos los datos reportados por los agentes en los dispositivos en otros servicios. Todos estos datos se utilizan para determinar en qué nivel pertenece un dispositivo, y los niveles de confianza se vuelven a evaluar cada vez que se modifican los datos corporativos o se informan nuevos datos.

Las evaluaciones de nivel de confianza se realizan a través de «reglas», escritas por ingenieros de seguridad y sistemas. Por ejemplo, para que un dispositivo tenga acceso básico, tenemos una regla que verifica que esté ejecutando una versión y compilación aprobada del sistema operativo. Para que ese mismo dispositivo tenga acceso altamente privilegiado, necesitaría pasar varias reglas adicionales, como verificar que el dispositivo esté encriptado y contenga los últimos parches de seguridad. Las reglas existen en una estructura jerárquica, por lo que se pueden combinar varias reglas para crear un nivel. Los requisitos para los niveles en las plataformas de dispositivos pueden ser diferentes, por lo que hay una jerarquía separada para cada uno. Los ingenieros de seguridad trabajan en estrecha colaboración con los ingenieros de sistemas para determinar la información necesaria para proteger los dispositivos, como determinar los umbrales para la versión mínima requerida y la frecuencia del parche de seguridad.

Aplicación de reglas y experiencia del usuario

Para crear una buena experiencia de usuario, las reglas se crean y supervisan antes de que se apliquen. Por ejemplo, antes de exigir a todos los usuarios que actualicen su navegador Chrome, supervisamos cuántos usuarios perderán la confianza si se aplica esa regla. Los paneles controlan el impacto de las reglas en los Googlers durante períodos de 30 días. Esto permite a los equipos de seguridad y sistemas evaluar el impacto del cambio de reglas antes de que afecten a los usuarios finales.

Para proteger aún más la experiencia de los empleados, tenemos medidas llamadas períodos de gracia y excepciones. Los períodos de gracia proporcionan ventanas de una duración predefinida donde los dispositivos pueden violar las reglas, pero aún así mantener la confianza y el acceso, lo que proporciona un respaldo en caso de consecuencias inesperadas. Además, los períodos de gracia se pueden implementar rápida y fácilmente en toda la flota en caso de que se produzca una recuperación ante desastres. El otro mecanismo se llama excepciones. Las excepciones permiten a los autores de reglas crear reglas para la mayoría mientras que los ingenieros de seguridad pueden tomar decisiones matizadas en torno a procesos individuales más riesgosos. Por ejemplo, si tenemos un equipo de desarrolladores de Android especializados en la experiencia del usuario para una versión anterior de Android, se les puede otorgar una excepción para la regla de versión mínima.

¿Cómo simplificamos la resolución de problemas?

La resolución de problemas de acceso resulta desafiante en un sistema en el que muchos datos interactúan para crear confianza. Abordamos este problema de dos maneras. Primero, tenemos un sistema para proporcionar explicaciones breves y prácticas a los usuarios finales sobre cómo resolver los problemas por su cuenta. En segundo lugar, tenemos la capacidad de notificar a los usuarios cuando sus dispositivos han perdido la confianza o están a punto de perder la confianza. La combinación de estos esfuerzos mejora la experiencia del usuario de la solución de acceso escalonado y minimize el trabajo para aquellos que la respaldan.

Podemos proporcionar comentarios de autoservicio a los usuarios al integrar estrechamente la creación de la política de reglas con los pasos de resolución para esa política. En otras palabras, los ingenieros de seguridad que escriben políticas de reglas también son responsables de adjuntar pasos sobre cómo resolver el problema. Para ayudar aún más a los usuarios, el sistema de evaluación de reglas proporciona detalles sobre los datos específicos que causan la falla. Toda esta información se introduce en un sistema centralizado que genera explicaciones fáciles de usar, guiando a los usuarios a vehicle diagnosticarse y solucionar problemas sin la necesidad de soporte de TI. Del mismo modo, es posible que un técnico no pueda ver información de identificación individual sobre un usuario cuando ayuda a reparar el dispositivo. Estos casos son raros pero necesarios para proteger a las partes involucradas en estos escenarios. Tener un sistema de depuración centralizado ayuda a lidiar con todos estos matices, lo que nos permite proporcionar explicaciones detalladas y seguras a los usuarios finales de acuerdo con sus necesidades.

Los pasos de remediación se comunican a los usuarios de varias maneras. Antes de que un dispositivo pierda la confianza, aparecen ventanas emergentes de notificación que explican que una pérdida de acceso es inminente. Estas ventanas emergentes contienen instrucciones para el sistema de corrección para que el usuario pueda autodiagnosticarse y solucionar el problema. Esto evita el dolor del usuario al ofrecer soluciones antes de que el problema afecte al usuario. Las notificaciones premeditadas funcionan en conjunto con los períodos de gracia mencionados anteriormente, ya que proporcionamos una ventana en la que los usuarios pueden reparar sus dispositivos. Si el problema no se soluciona y el dispositivo deja de cumplir, todavía hay un camino claro sobre qué hacer. Por ejemplo, cuando un usuario intenta acceder a un recurso para el que no tiene permiso, aparece un enlace en la página de acceso denegado que lo dirige a los pasos de corrección relevantes. Esto proporciona comentarios rápidos y claros sobre cómo reparar su dispositivo y decrease el trabajo de los equipos de soporte de TI.

La próxima vez

En la próxima y última publicación de esta serie, analizaremos cómo migramos los servicios para que la arquitectura BeyondCorp de Google los proteja.

Mientras tanto, si desea obtener más información, puede consultar el Documentos de investigación de BeyondCorp. Además, comenzar a usar BeyondCorp ahora es más fácil usando soluciones de confianza cero de Google Cloud (acceso contextual) y otros proveedores empresariales.

Gracias a los editores de la serie de publicaciones del blog BeyondCorp, Puneet Goel (Gerente de Producto), Lior Tishbi (Gerente de Programa) y Justin McWilliams (Gerente de Ingeniería).

Enlace a la noticia initial