En Keytos no tenemos reparos en decir “ponemos la barra alta” cuando se trata de seguridad de identidad. Como líder en el sector, de eso se trata realmente todo nuestro negocio. Proteger identidades y datos. En esta publicación, profundizaremos en nuestro enfoque riguroso para proteger nuestra infraestructura de nube basada en Entra ID para no solo alinearnos con los más altos estándares de la industria, sino también superarlos. …¿Mencioné que somos Compatibles con SOC2 y que nuestras herramientas son FIPS Inside Validated? Continúe leyendo si está interesado en saber cómo los ex ingenieros de seguridad en la nube de Microsoft bloquean su infraestructura.
Si bien Entra proporciona algunas funciones de seguridad de identidad, como acceso condicional e inicios de sesión riesgosos, ninguna cuenta es verdaderamente segura hasta que no hay absolutamente ninguna contraseña que robar. Para protegernos contra el robo o el compromiso de identidades, no utilizamos ninguna contraseña para todas nuestras cuentas de usuario, así como para las identidades de nuestras máquinas. Te sorprendería lo fácil que es lograrlo, pero como dicen, “con la herramienta adecuada, cualquier trabajo es fácil”. (o algo así)… Por eso sugerimos echar un vistazo a la mejor herramienta de incorporación sin contraseña para Azure, EZCMS. …¡Te sorprendería cuánto dinero ahorrarás! En el espíritu de “confianza cero”, asumiremos que no crees lo fácil que es en realidad. Dicho esto, eche un vistazo a cómo esta pequeña empresa se mudó en solo un par de días:
Si vamos directamente al tema, existen básicamente dos formas (principales) de lograr una verdadera autenticación de usuario sin contraseña dentro de su entorno Entra ID. Autenticación “Smartcard” (que en realidad es CBA) y FIDO2.
En Keytos, empleamos ambos métodos de autenticación, ya que consideramos que es el enfoque más práctico para nuestra organización. Déjame decirte por qué… Si bien FIDO2 ha sido el estándar de la industria desde hace bastante tiempo, todavía hay muchos casos (incluso en Entra ID) en los que no se acepta. Descubrimos que FIDO2 + CBA cubre todos los escenarios de autenticación que encontramos aquí en Keytos. Una vez más, muy fácil de configurar; simplemente consulte la mejor herramienta de incorporación sin contraseña para Entra, EZCMS.
Supongo que el 99,9% de la población general no es consciente de que las contraseñas siguen siendo el vector de ataque más riesgoso para las MÁQUINAS! Por lo tanto, para mantener seguros a nuestros preciosos bebés, hemos elegido utilizar Identidades de servicio administradas de Azure (MSI) estas identidades son identidades totalmente sin contraseña administradas por Microsoft, lo que facilita la autenticación con otros servicios de Microsoft.
En el caso algo improbable de que exista un escenario en el que los MSI no sean compatibles (autenticación entre inquilinos, aplicaciones hospedadas fuera de Azure como el servidor local de un cliente), utilizamos principales de servicio de Azure con autenticación basada en certificados. A diferencia de los MSI, o la autenticación regular basada en certificados, la autenticación para entidades principales de servicio requiere que registre cada certificado nuevo en Azure antes de poder usarlo. ¿Cree que las interrupciones relacionadas con la caducidad de los certificados serán un problema? ¡Piensa otra vez! Ofrecemos rotación automática para aplicaciones de Azure AD como parte de EZCA.
Como organización responsable de ejecutar servicios críticos para empresas de todo el mundo, estamos obligados contractualmente (y moralmente) a mantener el estándar de seguridad absoluto. En Keytos, nos esforzamos por ir MUCHO más allá de lo que se considera estándares de primer nivel siguiendo las mejores prácticas de identidad de Microsoft. Hemos creado nuestro propio inquilino de “Producción” aislado que tiene CERO conexión o confianza con nuestro inquilino “Corporativo”. ¿Qué significa eso? Si la cuenta corporativa de alguien se viera comprometida, el Phisher (malo digital) no obtendría acceso a los recursos de producción de Keytos. Agregar este aislamiento a nuestros recursos reduce exponencialmente el riesgo de un incidente y se adhiere a las mejores prácticas de confianza cero.
Ahora que hemos cubierto el aislamiento de identidad, que es un gran comienzo, echemos un vistazo a otro vector terriblemente vulnerable: los dispositivos. Los piratas informáticos continúan volviéndose cada vez más sofisticados en sus intentos y han comenzado a atacar organizaciones con malware. Básicamente, intentan robar sus credenciales o acceder a recursos usando su computadora. Para mitigar este riesgo, hemos implementado una versión moderna del modelo PAW de Microsoft. En lugar de aprovechar la tecnología local heredada, como los controladores de dominio, usamos Intune para administrar los dispositivos y acceso condicional a Azure para certificar el estado del dispositivo antes de iniciar sesión.
Algo en lo que no pensamos con suficiente frecuencia es: ¿todos deberían tener acceso a Producción todo el tiempo? Históricamente lo han hecho, pero sólo porque siempre ha sido así, ¿deberíamos seguir haciéndolo? Aunque tenemos mucha confianza en nuestra identidad segura y en la historia de nuestros dispositivos, también creemos que los humanos no deberían acceder a la producción a menos que sea necesario. Esto no solo mejora la seguridad, sino que al dificultar el acceso a la producción, también promueve buenas prácticas de ingeniería para la automatización de la implementación y funciones de autorreparación que mejoran nuestra confiabilidad y productividad. Para hacer cumplir esto, no hemos implementado ningún acceso permanente a la producción. Si un ingeniero necesita acceder a algún recurso de producción, debe solicitar acceso a los recursos a través de Microsoft PIM o a través de EZSSH para nuestros puntos finales de Linux.
En una respuesta directa al fortalecimiento de nuestra postura sobre la autenticación y el acceso a la producción, los piratas informáticos han decidido “moverse hacia la izquierda” en la cadena de suministro de software y tienen a GitHub en la mira. Para prevenir estos ataques y proteger nuestra infraestructura, extendemos nuestra identidad AAD ya segura a GitHub para SSO. Si bien este es un excelente primer paso para proteger nuestro código, solo protege contra acciones creadas en el sitio GitHub; sin embargo, como probablemente sepa, la mayoría de las actividades privilegiadas de git se realizan a través de SSH. Para proteger nuestro acceso SSH a GitHub, utilizamos EZGit, la primera autoridad de certificación SSH de GitHub. Esto les brinda a nuestros ingenieros acceso justo a tiempo al código, lo que garantiza que cada vez que insertan o extraen código, lo hacen desde una computadora que cumple con nuestras políticas de acceso condicional en Azure AD.
Dicho y considerado esto, la seguridad de DevOps no se detiene cuando se confirma el código. Necesitamos ser conscientes de que los ataques a la cadena de suministro van en aumento y cosas como comprometer los paquetes de compilación de código abierto utilizados por las acciones de GitHub son una de las formas en que eres vulnerable. Para proteger nuestros artefactos de este tipo de ataques, utilizamos harden-runner de Step Security para monitorear y bloquear estos ataques.
Siguiendo la mentalidad de “Assume Breach”, no podemos confiar simplemente en nuestras medidas de seguridad para proteger nuestra infraestructura. Debemos realizar un seguimiento constante para detectar cualquier anomalía. Además de utilizar las herramientas proporcionadas por Azure, como Sentinel y Azure Defender for Cloud, queríamos llevar nuestra seguridad al siguiente nivel y monitorear más eventos, es por eso que creamos CloudWatcher, una solución gratuita de monitoreo de código abierto que monitoreará cualquier ligero cambio en nuestro entorno Azure y alertará al Ingeniero de guardia si se detecta algún cambio. Como empresa de seguridad, también seguimos la recomendación de Google de monitorear los registros de transparencia de certificados con EZMonitor . Esto no solo nos protege contra alguien que cree certificados SSL para ataques de tipo man-in-the-middle, sino también contra otros ataques como el robo de dominio de Azure ataque.
Estos estrictos controles nos han permitido cumplir y superar los requisitos de cumplimiento de estándares respetados en todo el mundo, como SOC 2 tipo 2 y PCI nivel 4. Si tiene alguna pregunta sobre cómo protegemos nuestra infraestructura o cómo podemos ayudarle a proteger la suya, programe una llamada con nuestros expertos en seguridad y comience su viaje de confianza cero con Keytos.
