Prácticas recomendadas de seguridad de Azure AD
El Directorio Activo Azure es el servicio en la nube de gestión de identidades y acceso de Microsoft. Permite a los usuarios acceso a datos y aplicaciones como Office 365, Exchange online, OneDrive, etc.
Cada vez más organizaciones están migrando sus datos desde entornos AD on-premise hacia Azure AD para beneficiarse de las ventajas que las plataformas basadas en la nube ofrecen.
No obstante, Azure AD y el Directorio Activo on-premise funcionan de forma diferente y, aunque diseñados para un mismo fin, generan preocupaciones de seguridad distintas con sus consiguientes prácticas recomendadas.
A continuación, ofrecemos algunas de las áreas de enfoque para asegurarse de que el entorno de Azure AD sea seguro.
Microsoft Secure Score se encuentra dentro del centro de seguridad de Microsoft 365 y proporciona a las empresas una puntuación que indica su posición global de seguridad e indica si necesitan mejorar sus medidas.
Las empresas pueden monitorizar esta puntuación y tomar las medidas recomendadas por Microsoft, que se encuentran en la pestaña de ‘Improvement Actions’. Las recomendaciones se organizan en tres grupos, Identidad, Dispositivos y App, y cada grupo tiene su respectiva puntuación.
Además de una gráfica de tendencias, que muestra cómo ha cambiado la puntuación en el tiempo, también hay una gráfica que muestra cómo se compara la puntuación con Directorios Activos de un tamaño similar y en el mismo sector.
El modelo de seguridad de confianza cero es particularmente relevante cuando se utilizan plataformas en la nube para almacenar y procesar datos sensibles, ya que el modelo tradicional de seguridad perimetral no es compatible con entornos distribuidos remotos.
En el modelo de confianza cero, toda la actividad se considera maliciosa hasta demostrar lo contrario. Todos los usuarios, dispositivos y procesos deben demostrar su legitimidad cuando acceden a sistemas o recursos críticos.
Una parte importante de este modelo es el “principio de privilegios mínimos” (PoLP, por sus siglas en inglés), que implica que los usuarios sólo tienen acceso a los recursos específicos que necesitan para desempeñar sus funciones. Para imponer este acceso en Azure AD, sólo los administradores pueden crear y gestionar grupos de seguridad, incluyendo los grupos en Office 365.
Los administradores deben revisar todos los usuarios invitados y restringir sus privilegios en consecuencia, que incluye asegurarse de que sólo los administradores puedan aceptar usuarios invitados. La gestión de grupos Self-service se debe de deshabilitar para usuarios no administradores y también ha de restringirse la instalación de aplicaciones de terceros.
La implementación de PoLP se puede hacer a través del control basado en roles (Azure RBAC). Asignar usuarios a roles con acceso restringido ayuda a evitar confusiones que posibiliten que un usuario reciba un acceso más amplio del que realmente necesita
Como en cualquier sistema MFA, Azure puede solicitar dos o más de los siguientes factores: algo que sabes, algo que tienes y algo que eres. Con Azure AD hay diferentes métodos de verificación para elegir, incluyendo la aplicación Microsoft Authenticator, tokens de hardware OATH, SMS y llamadas de voz.
Para activar la autenticación multifactorial en Azure AD primero hay que crear una política de acceso condicional que defina las condiciones que la autenticación multifactorial ha de seguir. Después se deberá asignar esta política a los usuarios y deshabilitar la autenticación “Legacy”.
Azure Information Protection (AIP) extiende la funcionalidad de etiquetado y clasificación de Microsoft 365. La clasificación de los datos es una parte bastante importante de la seguridad de éstos, ya que permite a los administradores hacer un seguimiento de los documentos sensibles que tienen y de dónde se encuentran.
Además, el escáner on-premise de AIP ofrece a los administradores la posibilidad de escanear los repositorios de ficheros on-premise en busca de datos sensibles y de clasificarlos consecuentemente.
Los informes de auditoría de Azure AD proporcionan a los administradores información sobre el estado de su AD, que incluyen datos sobre actividades de inicio de sesión, uso de aplicaciones y cualquier cambio que se haya realizado y que pueda afectar a recursos sensibles.
Ofrecen un resumen de los cambios relacionados con los usuarios, grupos, roles, aplicaciones y políticas, además de informar a los administradores de aquellos usuarios que hayan sido marcados (“flagged”).
La consola de informes suministra información adicional como la fecha, hora, categoría, nombre, iniciador y estatus del evento además del servicio que registró el evento.
El simulador de ataques de Microsoft, que se encuentra en Threat management>Attack Simulator, dentro del centro de Seguridad y Compliance, permite a los administradores lanzar campañas de spear-phishing para identificar cualquier área de debilidad.
Se pueden lanzar dos tipos de campañas spear-phishing. La primera es un mensaje donde se les pide a los usuarios hacer clic sobre una URL y, tras hacer clic, se les pide que entreguen sus credenciales y luego se les redirige a una página, predeterminada o personalizada, que principalmente les advierte que no hagan clic en enlaces sospechosos.
La segunda campaña se entrega en forma de un archivo adjunto .docx o .pdf que contiene un mensaje de advertencia e información sobre cómo identificar archivos adjuntos sospechosos.
Para crear una campaña spear-phishing has de pertenecer a uno de los grupos de Organization Management o Security Administrator y debes tener la autenticación multifactor habilitada en tu cuenta.
Como se suele decir, no es una cuestión de si se va a producir una brecha de datos, sino de cuándo. Este pensamiento puede servir como piedra angular para la estrategia de seguridad.
Un enfoque de confianza cero garantizará que siempre se verifique la autenticidad de todos los usuarios y dispositivos antes de que se les permita acceder a recursos críticos. Debes asegurarte de saber exactamente qué datos sensibles tienes, dónde se encuentran y quién tiene (y debería tener) acceso.
Siempre que sea posible, se ha de habilitar la autenticación multifactor y procurar que los usuarios tengan acceso sólo a aquellos recursos absolutamente necesarios para cumplir su función. Necesitarás tanta visibilidad como sea posible de cuándo se producen cambios en “Qué, quién, dónde y cuándo” que afecten a los datos sensibles y los administradores deberían de recibir alertas en tiempo real de cualquier actividad sospechosa.
Por último, deberías contar con un plan de respuesta a incidentes (IRP) de eficacia probada para asegurarte de que puedes identificar, contener y erradicar brechas de datos de forma rápida y eficaz.
Si quieres ver cómo Lepide puede ayudar a las organizaciones a mejorar la seguridad de Directorio Activo de Azure, puedes ponerte en contacto con nosotros para obtener más información o para solicitarnos una versión de prueba y comprobarlo tú mismo.