Active Directory (AD) se encuentra entre las piezas de software m\u00e1s antiguas que a\u00fan se utilizan en el entorno de producci\u00f3n y se pueden encontrar en la mayor\u00eda de las organizaciones en la actualidad. Esto es a pesar del hecho de que sus brechas de seguridad hist\u00f3ricas nunca se han modificado. Por ejemplo, debido a su incapacidad para aplicar cualquier medida de seguridad m\u00e1s all\u00e1 de verificar una coincidencia de contrase\u00f1a y nombre de usuario, AD (as\u00ed como los recursos que administra) est\u00e1 peligrosamente expuesto al uso de credenciales comprometidas. Adem\u00e1s, esta exposici\u00f3n no se limita al entorno local. La pr\u00e1ctica com\u00fan de sincronizar contrase\u00f1as entre AD y el proveedor de identidad en la nube significa que cualquier infracci\u00f3n de AD tambi\u00e9n es un riesgo potencial para el entorno SaaS.<\/p>\n
En este art\u00edculo, exploraremos las debilidades de seguridad inherentes de AD y examinaremos su alcance e impacto potencial. Luego, aprenderemos c\u00f3mo la plataforma de protecci\u00f3n de identidad unificada de Silverfort puede abordar estas debilidades desde la ra\u00edz y proporcionar a las organizaciones que usan AD la capacidad de recuperaci\u00f3n que necesitan para frustrar las amenazas de identidad y mitigar los riesgos de las cuentas de usuario comprometidas.<\/p>\n
\u00bfQu\u00e9 nube? Por qu\u00e9 AD seguir\u00e1 siendo parte del entorno h\u00edbrido<\/strong><\/h2>\nSi bien la computaci\u00f3n en la nube ha desencadenado un cambio tect\u00f3nico en la TI, no ha reemplazado por completo el entorno local, sino que vive junto a \u00e9l. La ruta pragm\u00e1tica que la mayor\u00eda de las organizaciones ha elegido es mantener un entorno h\u00edbrido, donde el acceso de los usuarios a SaaS y los recursos web es administrado por un proveedor de identidad dedicado, mientras que AD a\u00fan administra los recursos locales. <\/p>\n
Desde el punto de vista de las operaciones, esta estrategia es razonable ya que existen m\u00faltiples recursos que se pueden migrar a la nube o intercambiar con aplicaciones SaaS. Sin embargo, es importante tener en cuenta que este enfoque significa que las debilidades de seguridad ignoradas durante mucho tiempo de AD todav\u00eda est\u00e1n en general.<\/p>\n
\nPara obtener m\u00e1s informaci\u00f3n sobre c\u00f3mo Silverfort aborda las debilidades en su postura de seguridad de identidad, consulte nuestro recurso, Silverfort MFA: Proteger a los desprotegidos<\/b><\/a>.<\/p>\n<\/div>\nTal\u00f3n de Aquiles de AD: Incapaz de detectar y prevenir intentos de acceso malicioso utilizando credenciales comprometidas<\/strong><\/h2>\nCuando un usuario inicia una solicitud de acceso, AD solo sabe c\u00f3mo hacer una cosa: verificar si el nombre de usuario y la contrase\u00f1a coinciden. Si no lo hacen, AD bloquea el acceso; si lo hacen, se concede el acceso. Pero, \u00bfqu\u00e9 puede hacer AD si el nombre de usuario y la contrase\u00f1a coinciden pero est\u00e1n siendo utilizados por un adversario que los obtuvo? Desafortunadamente, la respuesta es absolutamente nada. <\/p>\n
Por extra\u00f1o que parezca, desde la perspectiva de AD no hay diferencia entre un usuario leg\u00edtimo que proporcione el nombre de usuario y la contrase\u00f1a correctos y un adversario malicioso que haga lo mismo. A ambos se les concede el mismo acceso.<\/p>\n
Entonces, \u00bfpor qu\u00e9 el MFA tradicional no puede resolver este problema?<\/strong><\/h2>\nEn este punto, es posible que se pregunte por qu\u00e9 MFA no se puede agregar simplemente al proceso de autenticaci\u00f3n de AD, como se hace con las aplicaciones SaaS. La respuesta, desafortunadamente, es que no es tan simple. AD y sus protocolos de autenticaci\u00f3n (NTLM y Kerberos) se crearon y dise\u00f1aron hace m\u00e1s de dos d\u00e9cadas, mucho antes de que existiera MFA. Como resultado, a diferencia de los protocolos de autenticaci\u00f3n modernos que usan las aplicaciones SaaS, no pueden admitir MFA en absoluto. Tampoco hay planes de Microsoft para abrir estos protocolos y reescribirlos para que tengan esta capacidad. <\/p>\n
Esto significa que volvimos al punto de partida, donde un atacante que usa credenciales comprometidas en un entorno de AD puede conectarse literalmente a cualquier estaci\u00f3n de trabajo, servidor o aplicaci\u00f3n que desee, sin medidas de seguridad que lo impidan. <\/p>\n
Una infracci\u00f3n de AD AD allana el camino del adversario hacia sus recursos en la nube <\/strong><\/h2>\nLo que muchas partes interesadas en la seguridad suelen olvidar es que los entornos locales y en la nube est\u00e1n entrelazados. De hecho, muchos atacantes que buscan acceder a las aplicaciones SaaS optan por acceder a ellas a trav\u00e9s de un compromiso del entorno local, en lugar de atacarlas directamente a trav\u00e9s de un navegador. El patr\u00f3n com\u00fan de este tipo de ataque es obtener el control del punto final de un empleado mediante la ingenier\u00eda social y, una vez all\u00ed, esforzarse por comprometer los nombres de usuario y las contrase\u00f1as para usarlos para el acceso malicioso a las aplicaciones SaaS. Alternativamente, si hay un servidor de federaci\u00f3n, los adversarios pueden simplemente comprometerlo como lo har\u00edan con cualquier otro recurso local y obtener acceso SaaS desde all\u00ed. <\/p>\n
De una forma u otra, es importante darse cuenta de que cuando hablamos de brechas de seguridad de AD, esto no significa que solo el entorno administrado por AD est\u00e1 en riesgo, sino todo el entorno h\u00edbrido con todos sus usuarios y recursos.<\/p>\n
Silverfort Unified Identity Protection: supere las brechas de AD con protecci\u00f3n en tiempo real<\/strong><\/h2>\nSilverfort ha sido pionera en la primera plataforma dise\u00f1ada espec\u00edficamente para proteger contra amenazas de identidad, en tiempo real, haciendo uso de credenciales comprometidas para acceder a recursos espec\u00edficos. Silverfort proporciona monitoreo continuo, an\u00e1lisis de riesgos y aplicaci\u00f3n activa de pol\u00edticas en cada solicitud de acceso y autenticaci\u00f3n entrante realizada por cualquier usuario a cualquier recurso, tanto en las instalaciones como en la nube.<\/p>\n
De esta manera, Silverfort puede resolver las brechas de seguridad de AD en su ra\u00edz a trav\u00e9s de una integraci\u00f3n con el flujo de autenticaci\u00f3n nativo de AD, asumiendo as\u00ed el papel de decidir para AD si se puede confiar plenamente en un usuario al acceder a un recurso o no.<\/p>\n
Protecci\u00f3n AD de Silverfort: una capa de protecci\u00f3n contra amenazas integrada de forma nativa en el flujo de autenticaci\u00f3n de AD<\/strong><\/h2>\nAs\u00ed es como funciona:<\/p>\n
\n- Un usuario quiere acceder a un recurso e inicia una solicitud de acceso a AD.<\/li>\n
- AD, en lugar de decidir por s\u00ed mismo si otorgar o denegar el acceso en funci\u00f3n de la coincidencia de la contrase\u00f1a, reenv\u00eda esta solicitud de acceso a Silverfort.<\/li>\n
- Silverfort recibe la solicitud de acceso y la analiza utilizando un motor de IA de varias capas, al mismo tiempo que eval\u00faa la solicitud frente a pol\u00edticas de acceso preconfiguradas.<\/li>\n
- Si el an\u00e1lisis revela un supuesto compromiso, Silverfort se conecta a un servicio MFA para desafiar al usuario a verificar su identidad. <\/li>\n
- El servicio MFA env\u00eda el mensaje al usuario y devuelve su respuesta a Silverfort.<\/li>\n
- Seg\u00fan la respuesta de MFA, Silverfort le indica a AD si debe bloquear o permitir el acceso.<\/li>\n
- AD bloquea o permite el acceso seg\u00fan las instrucciones de Silverfort.<\/li>\n<\/ol>\n
Tecnolog\u00eda sin agente y sin proxy, independiente de todos los protocolos y m\u00e9todos de acceso<\/strong><\/h2>\nComo puede ver, esta capacidad \u00fanica de recibir todos los intentos de acceso en tiempo real desde AD permite a Silverfort agregar las capacidades de MFA y an\u00e1lisis de riesgos que faltan en el flujo de autenticaci\u00f3n de AD. Adem\u00e1s, debido a que Silverfort se encuentra detr\u00e1s de AD y obtiene el 100 % de sus solicitudes de autenticaci\u00f3n, esto elimina la necesidad de instalar agentes MFA en recursos individuales o colocar un proxy frente a ellos. Tambi\u00e9n significa que no importa qu\u00e9 protocolo se use o si es compatible con MFA. Siempre que se lleve a cabo una autenticaci\u00f3n en AD, AD la reenviar\u00e1 a Silverfort y se implementar\u00e1 la protecci\u00f3n.<\/p>\n
\u00bfQuieres saber m\u00e1s sobre Protecci\u00f3n AD de Silverfort<\/a>?<\/b> Programe una llamada con uno de nuestros expertos.<\/em><\/p>\n<\/p>\n
Para obtener m\u00e1s informaci\u00f3n sobre c\u00f3mo Silverfort aborda las debilidades en su postura de seguridad de identidad, consulte nuestro recurso, Silverfort MFA: Proteger a los desprotegidos<\/b><\/a>.<\/p>\n<\/div>\n Cuando un usuario inicia una solicitud de acceso, AD solo sabe c\u00f3mo hacer una cosa: verificar si el nombre de usuario y la contrase\u00f1a coinciden. Si no lo hacen, AD bloquea el acceso; si lo hacen, se concede el acceso. Pero, \u00bfqu\u00e9 puede hacer AD si el nombre de usuario y la contrase\u00f1a coinciden pero est\u00e1n siendo utilizados por un adversario que los obtuvo? Desafortunadamente, la respuesta es absolutamente nada. <\/p>\n Por extra\u00f1o que parezca, desde la perspectiva de AD no hay diferencia entre un usuario leg\u00edtimo que proporcione el nombre de usuario y la contrase\u00f1a correctos y un adversario malicioso que haga lo mismo. A ambos se les concede el mismo acceso.<\/p>\n En este punto, es posible que se pregunte por qu\u00e9 MFA no se puede agregar simplemente al proceso de autenticaci\u00f3n de AD, como se hace con las aplicaciones SaaS. La respuesta, desafortunadamente, es que no es tan simple. AD y sus protocolos de autenticaci\u00f3n (NTLM y Kerberos) se crearon y dise\u00f1aron hace m\u00e1s de dos d\u00e9cadas, mucho antes de que existiera MFA. Como resultado, a diferencia de los protocolos de autenticaci\u00f3n modernos que usan las aplicaciones SaaS, no pueden admitir MFA en absoluto. Tampoco hay planes de Microsoft para abrir estos protocolos y reescribirlos para que tengan esta capacidad. <\/p>\n Esto significa que volvimos al punto de partida, donde un atacante que usa credenciales comprometidas en un entorno de AD puede conectarse literalmente a cualquier estaci\u00f3n de trabajo, servidor o aplicaci\u00f3n que desee, sin medidas de seguridad que lo impidan. <\/p>\n Lo que muchas partes interesadas en la seguridad suelen olvidar es que los entornos locales y en la nube est\u00e1n entrelazados. De hecho, muchos atacantes que buscan acceder a las aplicaciones SaaS optan por acceder a ellas a trav\u00e9s de un compromiso del entorno local, en lugar de atacarlas directamente a trav\u00e9s de un navegador. El patr\u00f3n com\u00fan de este tipo de ataque es obtener el control del punto final de un empleado mediante la ingenier\u00eda social y, una vez all\u00ed, esforzarse por comprometer los nombres de usuario y las contrase\u00f1as para usarlos para el acceso malicioso a las aplicaciones SaaS. Alternativamente, si hay un servidor de federaci\u00f3n, los adversarios pueden simplemente comprometerlo como lo har\u00edan con cualquier otro recurso local y obtener acceso SaaS desde all\u00ed. <\/p>\n De una forma u otra, es importante darse cuenta de que cuando hablamos de brechas de seguridad de AD, esto no significa que solo el entorno administrado por AD est\u00e1 en riesgo, sino todo el entorno h\u00edbrido con todos sus usuarios y recursos.<\/p>\n Silverfort ha sido pionera en la primera plataforma dise\u00f1ada espec\u00edficamente para proteger contra amenazas de identidad, en tiempo real, haciendo uso de credenciales comprometidas para acceder a recursos espec\u00edficos. Silverfort proporciona monitoreo continuo, an\u00e1lisis de riesgos y aplicaci\u00f3n activa de pol\u00edticas en cada solicitud de acceso y autenticaci\u00f3n entrante realizada por cualquier usuario a cualquier recurso, tanto en las instalaciones como en la nube.<\/p>\n De esta manera, Silverfort puede resolver las brechas de seguridad de AD en su ra\u00edz a trav\u00e9s de una integraci\u00f3n con el flujo de autenticaci\u00f3n nativo de AD, asumiendo as\u00ed el papel de decidir para AD si se puede confiar plenamente en un usuario al acceder a un recurso o no.<\/p>\n As\u00ed es como funciona:<\/p>\n Como puede ver, esta capacidad \u00fanica de recibir todos los intentos de acceso en tiempo real desde AD permite a Silverfort agregar las capacidades de MFA y an\u00e1lisis de riesgos que faltan en el flujo de autenticaci\u00f3n de AD. Adem\u00e1s, debido a que Silverfort se encuentra detr\u00e1s de AD y obtiene el 100 % de sus solicitudes de autenticaci\u00f3n, esto elimina la necesidad de instalar agentes MFA en recursos individuales o colocar un proxy frente a ellos. Tambi\u00e9n significa que no importa qu\u00e9 protocolo se use o si es compatible con MFA. Siempre que se lleve a cabo una autenticaci\u00f3n en AD, AD la reenviar\u00e1 a Silverfort y se implementar\u00e1 la protecci\u00f3n.<\/p>\n \u00bfQuieres saber m\u00e1s sobre Protecci\u00f3n AD de Silverfort<\/a>?<\/b> Programe una llamada con uno de nuestros expertos.<\/em><\/p>\n <\/p>\nTal\u00f3n de Aquiles de AD: Incapaz de detectar y prevenir intentos de acceso malicioso utilizando credenciales comprometidas<\/strong><\/h2>\n
Entonces, \u00bfpor qu\u00e9 el MFA tradicional no puede resolver este problema?<\/strong><\/h2>\n
Una infracci\u00f3n de AD AD allana el camino del adversario hacia sus recursos en la nube <\/strong><\/h2>\n
Silverfort Unified Identity Protection: supere las brechas de AD con protecci\u00f3n en tiempo real<\/strong><\/h2>\n
Protecci\u00f3n AD de Silverfort: una capa de protecci\u00f3n contra amenazas integrada de forma nativa en el flujo de autenticaci\u00f3n de AD<\/strong><\/h2>\n
\n
Tecnolog\u00eda sin agente y sin proxy, independiente de todos los protocolos y m\u00e9todos de acceso<\/strong><\/h2>\n