¿Existen razones objetivas para usar un usuario / contraseña dedicado en lugar de proveedores de identidad dentro de una organización grande?

Para la mayoría de las organizaciones, un sistema completo de identidad unificada es algo positivo. Usted preguntó si hay alguna razón para no hacer esto. Enumeraré algunas que pueden o no ser válidas en diferentes organizaciones:

1. El sistema no es compatible con el proveedor de identidad. Es posible que tenga un sistema de mainframe basado en terminal heredado que no es fácil vincular a AD. Hay muchos productos comerciales para vincular productos heredados con sistemas de identidad, aunque estos pueden ser costosos. De manera alternativa, puede tener sistemas basados en la nube (como Salesforce) con los que tiene dificultades para integrarse.

2. El sistema es sensible y no desea exponerlo en caso de una violación del sistema de identidad. Esto puede ser válido para un pequeño número de sistemas altamente sensibles, aunque este argumento se utiliza en exceso en entornos empresariales. Si su proveedor de identidad es AD, es probable que una violación de AD signifique una violación de todas las estaciones de trabajo que las personas usarían para administrar estos sistemas, por lo que la separación es poco más que un teatro de seguridad.

3. No se puede acceder al proveedor de identidad desde el sistema. Un ejemplo común es que los sistemas con acceso a Internet en una DMZ que están bloqueados por un firewall no pueden acceder al AD interno. He visto grandes organizaciones que crean un AD separado para los sistemas DMZ. Un problema similar puede ocurrir con los sistemas de desarrollo vs producción.

4. Algunos usuarios no forman parte del proveedor de identidad. El ejemplo clásico es cuando tienes unos pocos usuarios externos que acceden a un sistema interno. Puede lidiar con esto haciendo que el sistema admita múltiples métodos de autenticación, o permitiendo que los usuarios externos estén en su proveedor de identidad, con las restricciones correspondientes.

Si las dificultades de integrar un sistema con el proveedor de identidad merecen los beneficios es un acto de equilibrio. La mayoría de los administradores de TI aceptan que administrar una horda de credenciales es parte del trabajo.

En primer lugar, Active Directory es un protocolo propietario que puede no ser el más sencillo de usar fuera del mundo de Windows. Por esa razón, es común tener al menos 2 autenticaciones, una para el mundo de Windows y otra para otros sistemas (comúnmente Unix / Linux). Esto se puede hacer casi transparente para los usuarios siempre que uno de los proveedores de autenticación esté sincronizado en el otro.

Esto normalmente puede resolver la mayoría de las necesidades de autenticación. Lo que aún puede quedar son:

• software propietario que insiste en tener su propio sistema de autenticación privado. Es aún más común de lo que podríamos desear ...
• cuentas de sistema de bajo nivel (por ejemplo, raíz en un sistema Unix o cuenta dba en una base de datos). Si bien a las cuentas de usuario normales se les pueden otorgar privilegios o la posibilidad de obtenerlos a través de sudo, es común permitir el acceso administrativo local de bajo nivel para cuando las cosas van mal . Pero no debería ser una preocupación para los usuarios estándar.
• cuentas dev. En la fase de desarrollo, es posible que una aplicación no esté conectada a los principales proveedores de autenticación. Así que los desarrolladores y evaluadores tienen que usar cuentas dedicadas.

Esto es para casos aceptables . Pero todavía hay otra categoría: resolver un sistema SSO tiene un costo en términos de tiempo y dinero. Algunas organizaciones pueden optar por no ir allí porque piensan que no vale la pena o, a veces, porque no son conscientes de la posible ganancia. Solo en este último caso de uso, podría sugerir a su administrador directo que sería muy interesante, pero tendrá que encontrar un caso de uso real en el que ahorraría tiempo o evitaría errores. Todo el mundo lo hace puede no ser suficiente para convencer a un gran jefe ...

Active Directory es inseguro (por defecto)

Esto es un golpe en contra de ADFS porque se basa en AD, lo que requiere un esfuerzo para asegurarla adecuadamente.

Si está utilizando Active Directory, y especialmente si controla el acceso a sistemas críticos, debe diseñar su entorno para hacer frente a sus graves deficiencias de seguridad.

Como mínimo, debería estar implementando el diseño de bosque rojo de Microsoft en de acuerdo con su modelo de administración escalonada para mitigar el paso de hash (PtH), pass-the-ticket (PtT) y ataques de boletos dorados.

La federación es el futuro

Al tratar con usuarios externos, ADFS es muy superior a la creación de cuentas en su dominio o al establecimiento de confianzas de AD. Si puedes usar ADFS, absolutamente hazlo.

Dado que menciona específicamente Google Identity, se basan en OAUTH y OAUTH debe interactuar con ADFS .

Dado que ADFS es simplemente la implementación de un proveedor de identidad SAML por parte de Microsoft, debería ser más útil con el tiempo. En términos empresariales, SAML sigue siendo bastante nuevo, pero ha estado creciendo.

Se requieren varias cuentas

Los usuarios administrativos seguirán necesitando varias cuentas. Usted no puede eliminar razonablemente esa necesidad. Cualquier cuenta que pueda acceder a Internet no debe tener acceso privilegiado para administrar su infraestructura o realizar cambios en los entornos de desarrollo / prueba.

Es posible que aún puedas consolidar, incluso si los administradores deben tener 2-3 cuentas de AD individuales. Por ejemplo, tanto Oracle como MS SQL admiten la autenticación con credenciales de Windows, por lo que sus DBA y los desarrolladores ya no necesitarán cuentas de usuario / pase únicas en cada instancia.

Una de las cuestiones que plantearía sería la falta de acceso a los ataques en tiempo real del sistema de gestión de identidad. Por ejemplo, si alguien está atacando su servidor de administración de identidades y entra con éxito, puede actuar tan pronto como lo sepa. En el caso de alguien que comprometa a un proveedor de identidad de terceros, es posible que no sepa durante un par de meses cuándo y si deciden revelar la violación.

En primer lugar, es posible que ni siquiera me deseen que algunos sistemas tengan un sistema de "inicio de sesión único". En un comentario mencionaste bases de datos y otros sistemas. Como técnico, prefiero una clave SSH separada (protegida por contraseña) para conectarse a servidores, contraseñas para acceder a bases de datos, etc. Por lo tanto, la solución de un proveedor de identidad centralizado no es adecuada para todas las necesidades. Especialmente teniendo en cuenta que este enfoque agrega otro sistema (su proveedor de identidad) que debe ser accesible para poder autenticarse. Es muy probable que este sea el caso durante la mayor parte del tiempo, pero aún así, es un requisito a tener en cuenta.

Además, los sistemas deben ser capaces de trabajar con proveedores de identidad. Dudo que el acceso a una base de datos se pueda autorizar generalmente utilizando un proveedor de identidad en lugar de un nombre de usuario / contraseña. La migración de todos los sistemas para utilizar un proveedor de identidad puede (y seguramente lo hará) causar problemas que no esperaba. Tal vez nadie quiera invertir tiempo y dinero para cambiarlo, ya que el nombre de usuario / contraseña es ciertamente más fácil de implementar.

Suponiendo que los usuarios que escriben sus credenciales es el problema que está tratando de resolver, promovería el uso de los administradores de contraseñas (¿tal vez enviaré la imagen con el sistema operativo predeterminado?) una contraseña para gobernarlos a todos

Para ser claro, me gusta la idea de un proveedor de identidad centralizado. Esos son todos los puntos en contra, que se me ocurren ahora mismo. Cualquier adición es bienvenida (es una pregunta interesante).