Cuando era más joven y algo menos reacio a los riesgos, montaba motocicletas. Mi regla era simple: “todo el equipo, todo el tiempo”. Ni siquiera cabalgaría hasta el final de mi calle sin un casco, guantes y ropa resistente a la abrasión. Esto fue una gran molestia, a menudo era incómodo y me hacía parecer tonto, pero (para mí, de todos modos) los beneficios de seguridad valieron la pena. Ser constante en la aplicación de protección era la mejor manera de mantenerse a salvo.
Lo mismo ocurre con los diseños de seguridad de confianza cero. Implementar la confianza cero en el mundo es una gran molestia, a menudo incómodo y con frecuencia tonto, además, puede ser costoso. Al mismo tiempo, acercarse a un modelo de confianza cero ayuda a fortalecer su red de manera significativa, y es posible que ya tenga muchas de las herramientas y técnicas que necesita disponibles sin mucho costo adicional.
Una definición funcional de confianza cero
Stephen Paul Marsh acuñó el término “confianza cero” hace casi 30 años. El concepto subyacente a los modelos de confianza cero ha tardado tanto en echar raíces en el mercado, pero se remontan a antes: una suposición fundamental del protocolo Kerberos que subyace en la autenticación de Active Directory es que no se puede confiar en la red. El modelo de confianza cero amplía esa falta de confianza al decir, básicamente, «no solo no puedes confiar en la red, sino que esos dispositivos en ella probablemente también sean sospechosos».
Si transfiere este concepto a una red empresarial típica, significa que los dispositivos y los usuarios deben autenticarse por separado, y que el acceso a los recursos rara vez (o nunca) debe otorgarse en función de una concesión de acceso anterior. También significa asumir que todos los dispositivos y terminales no son de confianza. En otras palabras, se parece mucho a la Internet moderna, más particularmente a la implementación moderna de Microsoft 365. Por ejemplo, considere una VPN tradicional que permite que un dispositivo conectado vaya a cualquier parte de una red corporativa: una vez que el usuario proporciona las credenciales, su dispositivo (que puede estar infectado con malware o comprometido) actúa como si estuviera conectado a la red corporativa. El usuario y el dispositivo son libres de enviar tráfico a cualquier parte de la red corporativa.
Ahora compare ese enfoque con el uso de algo como Azure AD Application Proxy, donde un usuario conectado debe autenticarse en el servicio (lo que significa que las políticas de acceso condicional y MFA se pueden aplicar fácilmente), y luego se puede aplicar un conjunto separado de controles para limitar el acceso del usuario. acceso a una aplicación específica, o incluso a partes de una aplicación. Hay una gran diferencia de alcance entre estos dos enfoques.
El Centro Nacional de Seguridad Cibernética del Reino Unido tiene una definición bastante buena de los principios detrás de las arquitecturas de red de confianza cero:
- Fuente sólida única de identidad de usuario: en Microsoft 365, esto obviamente lo proporciona Azure AD.
- Autenticación de usuarios: todos los servicios incluidos en Microsoft 365 dependen de Azure AD para la autenticación de usuarios.
- Autenticación de máquinas: aunque Azure AD o AD local permiten la autenticación de dispositivos, esto no es obligatorio.
- Contexto adicional, como el cumplimiento de políticas y el estado del dispositivo: este es uno de los mayores beneficios de usar Intune, pero habrá algún contexto adicional disponible incluso si no lo usa.
- Políticas de autorización para acceder a una aplicación: las políticas de acceso condicional de Azure AD son la forma principal de implementar este aspecto.
- Políticas de control de acceso dentro de una aplicación: Microsoft ya tiene políticas integrales de control de acceso integradas en las propias aplicaciones de Microsoft 365.
lo que ya tienes
Con solo revisar la lista anterior, es evidente que Microsoft ya ha hecho parte del trabajo preliminar para ayudarlo a implementar un modelo de confianza cero en su arrendatario de Microsoft 365: de manera predeterminada, el servicio asume que todos los dispositivos no son confiables (¡y no confiables!), y por supuesto, autenticarse en un punto final de servicio por sí solo no le da rienda suelta a toda la red de Microsoft. (Proporcionan inicio de sesión único para que no tenga que volver a autenticarse mientras pasa de Outlook a Teams a Planner).
Aunque no necesariamente ve estas capacidades en acción, Microsoft también aplica políticas de seguridad para decidir cuándo requerir la autenticación multifactor o cuándo etiquetar un intento de inicio de sesión como riesgoso en función del contexto adicional (¿desde dónde inició sesión el usuario? ¿Se sabe que esta cuenta está comprometida?)
El conjunto predeterminado de estas características de 365 proporciona uno de los beneficios clave de una arquitectura de confianza cero: un atacante que compromete un dispositivo o cuenta de Microsoft 365 no obtiene automáticamente una forma fácil de moverse lateralmente y comprometer otra cuenta o dispositivo. (a menos que, es decir, el atacante logre comprometer una cuenta con privilegios elevados, ¡pero esa es una clase separada de problemas para resolver!)
Ampliación de su alcance de confianza cero
Por supuesto, Microsoft estará encantado de venderle un montón de licencias para todos sus productos para ayudarlo a implementar su visión de confianza cero. Si bien este podría ser un gran objetivo a largo plazo para usted (¡o podría no serlo!), puede lograr un progreso significativo sin enviar a Microsoft una gran parte de su presupuesto de TI.
Primero, considere si se beneficiaría del uso de la autenticación de máquina a través de la unión a un dominio de Azure AD. Esto le permite reducir o eliminar el uso de cuentas locales y garantizar que todos los usuarios y dispositivos se autentiquen mutuamente, una parte clave del diseño de confianza cero.
En segundo lugar, bastan unos minutos para revisar los permisos de control de acceso y las asignaciones de funciones en la mayoría de los inquilinos. Este es un tiempo bien invertido, y es algo que debe hacer con regularidad. Estrictamente hablando, este no es un problema relacionado con la confianza cero, pero de poco sirve que Microsoft implemente un amplio conjunto de controles de acceso a las aplicaciones si no audita regularmente quién tiene permisos para qué datos.
En tercer lugar, agregar un contexto de autenticación adicional suele ser muy útil como una forma de mejorar su seguridad. Eso comienza con el uso de MFA (¡por supuesto!) pero se extiende para incorporar la ubicación, el uso de la aplicación y otros factores. Parte del contexto disponible para usted puede requerir la compra de licencias de Azure AD Premium P2, pero es posible que no necesite licencias para todos los usuarios.
Cuarto, como hemos discutido repetidamente aquí en Practice 365, las políticas de acceso condicional le brindan un excelente conjunto de herramientas para aplicar políticas de autorización para el acceso a la aplicación. La planificación y el estudio cuidadosos, y un poco de experimentación juiciosa, lo ayudarán a determinar qué condiciones, subvenciones y excepciones específicas de la póliza tienen más sentido para su entorno.
La buena noticia es que Microsoft tiene un gran interés en ayudar a sus clientes a mantenerse seguros: las infracciones de seguridad les cuestan dinero y arruinan la confianza cuidadosamente cultivada que han construido desde los albores de la iniciativa Trustworthy Computing. Por ese motivo, puede esperar que sigan proporcionando los componentes básicos que necesitará para implementar la confianza cero. Pero es su responsabilidad aprovechar estas herramientas.
