Capítulo 4. Gestión de identidades y accesos

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

La gestión de identidades y accesos (IAM) es quizá el conjunto más importante de controles de seguridad. En las brechas que afectan a aplicaciones web, las credenciales perdidas o robadas han sido la herramienta más utilizada por los atacantes durante varios años seguidos.¹ Si los atacantes tienen credenciales válidas para entrar en tu sistema, ¡todos los parches y cortafuegos del mundo no les mantendrán fuera!

A menudo se habla de la gestión de la identidad y del acceso a la vez, pero es importante entender que son conceptos distintos:

Una identidad es la forma en que una persona (o automatización) se representa en el sistema.² El proceso de verificar que la entidad que realiza una solicitud es realmente el propietario de la identidad se denomina autenticación (a menudo abreviado como "authn").
La gestión del acceso consiste en permitir que las identidades realicen las tareas que necesitan realizar (y, en un entorno de mínimos privilegios, sólo las tareas que necesitan realizar). El proceso de comprobar qué privilegios debe tener una identidad se denomina autorización (a menudo abreviado como "authz").

Autenticación es demostrar que eres quien dices ser. En el mundo físico, esto puede adoptar la forma de presentar un documento de identidad, expedido por una autoridad de confianza y con tu foto. Cualquiera puede inspeccionar esa credencial, mirarte y decidir si cree que eres quien dices ser. Por ejemplo, si llegas a una base militar y presentas tu carné de conducir, estás intentando autenticarte ante el guardia. El guardia puede decidir creerte, o puede decidir que has presentado el carné de conducir de otra persona o que ha sido falsificado, o puede decirte que la base sólo acepta carnés militares y no carnés de conducir.

La autorización se refiere a la capacidad de realizar una determinada acción, y generalmente depende primero de la autentificación (saber quién es alguien). Por ejemplo, el guardia de la base puede decir: "Sí, creo que eres quien dices ser, pero no se te permite entrar en esta base". O puede que te dejen entrar, pero no te permitan acceder a la mayoría de los edificios una vez dentro.

En seguridad informática, a menudo confundimos estos dos conceptos. Por ejemplo, podemos crear una identidad para alguien (con credenciales asociadas, como una contraseña) y luego permitir implícitamente que cualquiera con una identidad válida acceda a todos los datos del sistema. O podemos revocar el acceso de alguien borrando la identidad de la persona; eso funciona, pero es como romper su carné de conducir en lugar de simplemente denegarle el acceso. Aunque estas soluciones pueden ser apropiadas en algunos casos, es importante entender la distinción. ¿Es realmente apropiado autorizar a todos los usuarios el acceso total al sistema? ¿Y si tienes que dar una identidad a alguien ajeno a la organización para permitirle acceder a alguna otra área del sistema, ese usuario también obtendrá automáticamente acceso a los recursos internos?

Ten en cuenta que los conceptos (y las analogías) pueden complicarse muy rápidamente. Por ejemplo, imagina un sistema en el que, en lugar de mostrar tu carné en todas partes, sacas una tarjeta de acceso que muestras a los demás, y una tarjeta de actualización que sólo tienes que mostrar al emisor de la tarjeta. La credencial de acceso te autentica ante todo el mundo, pero sólo funciona durante un día, después del cual tienes que ir a la oficina de credenciales y mostrar la credencial de actualización para obtener una nueva credencial de acceso. Cada sitio en el que presentas tu tarjeta de acceso verifica la firma en ella para asegurarse de que es válida, y luego llama a una autoridad central para preguntar si estás en la lista para acceder a ese recurso. Esto es similar a la forma en que funcionan algunos sistemas de acceso informático, aunque afortunadamente tu navegador y los sistemas que te prestan servicio se ocupan de estos detalles por ti.

Un principio importante en la gestión de identidades y accesos, así como en otros ámbitos de la seguridad, es reducir al mínimo el número de organizaciones y personas en las que tienes que confiar. Por ejemplo, salvo en los casos en que funcione el cifrado de conocimiento cero³ tendrás que confiar en los procesos de autenticación y autorización de tu proveedor de la nube para evitar que tus datos sean vistos por personas no autorizadas. Tienes que aceptar el riesgo de que si tu proveedor se ve completamente comprometido, tus datos también lo estarán. Sin embargo, como ya has decidido confiar en el proveedor de la nube, quieres evitar confiar en otras personas u organizaciones si puedes aprovechar esa confianza existente sin incurrir en riesgos adicionales.⁴ Piensa en ello como si pagaras una cuota de admisión; una vez que has pagado la "cuota" de confiar en una organización concreta, debes aprovecharla al máximo para evitar introducir riesgos adicionales en el sistema.

Diferencias con la TI tradicional

En los entornos informáticos tradicionales, la gestión del acceso suele realizarse en parte mediante controles de acceso físico (quién puede entrar en el edificio) o controles de acceso a la red (quién puede conectarse a la red de forma remota). Por ejemplo, puedes contar con un cortafuegos perimetral como segunda capa de protección si despides a un administrador y olvidas revocar su acceso a uno de los servidores.

Es importante señalar que, incluso en un entorno sin nube, éste suele ser un nivel de seguridad muy débil: ¿estás seguro de que los controles de acceso de todos tus puertos Ethernet, puntos de acceso inalámbricos y puntos finales VPN resistirán incluso un ataque casual? En la mayoría de las organizaciones, alguien podría pedir ir al baño y enchufar un dispositivo de acceso remoto de 5 dólares a un puerto Ethernet por el camino, o robar credenciales inalámbricas o de VPN para entrar sin ni siquiera poner un pie en las instalaciones. La posibilidad de que a una persona determinada le roben sus credenciales puede ser pequeña, pero las probabilidades generales de tener personas no autorizadas en la red aumentan rápidamente a medida que añades más y más personas al entorno.⁵ Esto es doblemente cierto en los entornos de nube, donde todo el acceso es remoto y las probabilidades son aún mayores de que tengas personas no autorizadas en una red supuestamente segura.

En los entornos tradicionales, el control de acceso a veces se realiza simplemente revocando toda la identidad de un usuario, de modo que ya no pueda iniciar ninguna sesión. Pero cuando se utilizan entornos en la nube, a menudo esto no soluciona todo el problema. Por comodidad, muchos servicios proporcionan tokens de autenticación de larga duración que seguirán funcionando incluso sin la posibilidad de iniciar una nueva sesión. A menos que tengas cuidado de tener una alimentación "offboarding" que notifique a las aplicaciones cuando alguien se va para que la aplicación pueda revocar todo el acceso, la gente puede retener el acceso a cosas que no pretendías. Por ejemplo, si utilizas un servicio de correo web, ¿cuándo fue la última vez que tecleaste tu contraseña de correo web? Cambiar tu contraseña o impedirte utilizar la página de inicio de sesión no serviría de nada si los proveedores de correo web no revocaran también los tokens de acceso almacenados en las cookies de tu navegador durante una operación de cambio de contraseña.

Hay muchos ejemplos de filtraciones de datos causadas por dejar buckets de Amazon S3 abiertos al acceso público. Si se tratara de recursos compartidos de archivos dejados abiertos a cualquier persona de la empresa detrás de un cortafuegos corporativo, es posible que un atacante o investigador en Internet no los hubiera encontrado. (En cualquier organización de un tamaño razonable, es casi seguro que hay malos actores en la red interna que podrían haber robado esa información, tal vez sin ser detectados, pero la probabilidad de ataque es mayor cuando está orientada a Internet).

La idea que subyace a estos ejemplos es que muchas organizaciones se dan cuenta de que han vivido con controles IAM poco estrictos en sus instalaciones, y necesitan mejorarlos significativamente para la nube. Afortunadamente, hay servicios disponibles para facilitar esta tarea.

Ciclo de vida de la identidad y el acceso

Mucha gente comete el error de pensar que IAM es sólo autenticación y autorización. Aunque ambas son muy importantes, la IAM también incluye otras partes del ciclo de vida de la identidad. En el ejemplo anterior sobre el intento de entrar en una base militar, asumimos que tú, el solicitante, ya tenías una identidad (tu carné de conducir), pero ¿cómo la conseguiste? ¿Y quién puso tu nombre en la lista de personas autorizadas a entrar en la base?

Muchas organizaciones gestionan esto de forma deficiente. Solicitar una identidad puede hacerse llamando o enviando un mensaje a un administrador, que aprueba y crea la identidad sin guardar ningún registro de ello. Esto puede funcionar bien en organizaciones realmente pequeñas o en entornos de bajo riesgo, pero muchas veces necesitas un sistema que registre cuándo alguien solicita acceso, cómo se autentificó el solicitante y quién aprobó la nueva identidad o el acceso.

Aún más importante es el backend del ciclo de vida. Necesitas un sistema que compruebe automáticamente cada cierto tiempo si la identidad y el acceso de un usuario siguen siendo necesarios. Tal vez la persona haya dejado la empresa, o se haya trasladado a otro departamento, y ya no deba tener acceso. (O peor aún, ¡imagínate tener la desagradable tarea de despedir a alguien, y darte cuenta un mes después de que, debido a un error humano, esa persona sigue teniendo acceso a un sistema importante!)

Hay muchas versiones diferentes de diagramas de ciclo de vida IAM, con distintos grados de detalle en los pasos. El de la Figura 4-1 muestra el número mínimo de pasos, y aborda tanto la creación como la eliminación de identidades, junto con la creación y eliminación de reglas de acceso para esas identidades. La identidad y el acceso pueden ser gestionados por sistemas diferentes o por el mismo sistema, pero los pasos son similares.

Ten en cuenta que no necesitas necesariamente un sofisticado sistema automatizado para aplicar cada uno de estos pasos. En un entorno con pocos solicitantes y pocos aprobadores, un proceso mayoritariamente manual puede funcionar bien, siempre que se aplique de forma coherente y haya comprobaciones para evitar que un solo error humano cause problemas. En el momento de escribir estas líneas, la mayoría de los sistemas automatizados para gestionar todo el ciclo de vida (a menudo denominados sistemas de gobierno de identidades) están orientados a las grandes empresas; suelen ser caros y difíciles de implantar. Sin embargo, hay una tendencia creciente a proporcionar estas soluciones de gobierno en la nube como otros servicios. A menudo se incluyen como parte de otros servicios de identidad y acceso, por lo que incluso las organizaciones más pequeñas podrán beneficiarse de ellas.

Ten en cuenta también que los procesos y servicios utilizados pueden diferir considerablemente, dependiendo de quiénes sean las entidades. Los tipos de gestión de identidades y accesos utilizados para dar a tus empleados acceso a tu proveedor de nube y a tus aplicaciones internas difieren considerablemente de los utilizados para conceder a tus clientes acceso de usuario final a tus aplicaciones. Distinguiré entre estos dos casos generales en la siguiente discusión.

Consejo

No te olvides de las identidades de las cosas no humanas del sistema, como las aplicaciones. También hay que gestionarlas, igual que las identidades humanas. Muchos equipos hacen un gran trabajo controlando el acceso de las personas, pero tienen controles muy laxos sobre lo que la automatización está autorizada a hacer.

Repasemos cada uno de estos pasos. El proceso comienza cuando alguien o algo realiza una solicitud. Puede ser el jefe de un empleado recién contratado, o alguna automatización como tu sistema de RRHH.

Solicita

El ciclo de vida comienza cuando una entidad realiza una solicitud de gestión de identidad o de acceso. Normalmente, esta entidad debe autenticarse de algún modo. Dentro de tu organización, no quieres solicitudes de acceso anónimas, aunque en algunos casos la autenticación puede ser tan sencilla como que alguien reconozca visual o auditivamente a la persona.

Cuando proporciona acceso al público en general -por ejemplo, para una aplicación web-, a menudo quieres vincularlo a alguna otra identidad, como una dirección de correo electrónico existente o un número de teléfono móvil.

Las peticiones más comunes son:

Crear una identidad (y a menudo conceder implícitamente a esa identidad al menos un nivel básico de acceso).
Elimina una identidad, si la entidad ya no necesita autenticarse en ningún sitio.
Conceder acceso a una identidad existente, por ejemplo, a un nuevo sistema.
Revocar el acceso de una identidad existente.

En los entornos de nube, el proceso de solicitud suele producirse "fuera de banda", utilizando un proceso de solicitud dentro de tu organización que aún no implica al sistema IAM de la nube.

Aprueba

En algunos casos, es aceptable aprobar implícitamente el acceso. Por ejemplo, al conceder acceso a una aplicación web de acceso público, a menudo se aprueba automáticamente a cualquier persona que solicite acceso, siempre que cumpla determinados requisitos. Estos requisitos pueden ser de naturaleza antifraude, como proporcionar un número de móvil o una dirección de correo electrónico válidos, facilitar un número de tarjeta de crédito válido, rellenar un CAPTCHA o un formulario "No soy un robot", o no proceder de una ubicación anónima como un proveedor de VPN de usuario final o un nodo de salida Tor conocido.

Sin embargo, dentro de una organización, la mayoría de las solicitudes de acceso deben ser aprobadas explícitamente. En muchos casos, dos aprobaciones son razonables: por ejemplo, la del supervisor inmediato del usuario, así como la del propietario del sistema al que se solicita acceso. Lo importante es que el aprobador o aprobadores estén en condiciones de saber si el acceso solicitado es razonable y necesario. También se trata de un proceso interno de tu equipo, que suele tener lugar sin interacción con tus proveedores de la nube.

Crear, Eliminar, Conceder o Revocar

Tras la aprobación, la acción real de crear una identidad, eliminar una identidad, conceder acceso o revocar el acceso puede producirse automáticamente. Por ejemplo, el sistema de solicitud/aprobación puede utilizar las API del proveedor de la nube para crear la identidad o conceder el acceso.

En otros casos, esto puede generar un ticket, un correo electrónico u otra notificación que requiera que una persona realice una acción manual. Por ejemplo, un administrador puede tener que entrar en el portal de la nube para crear la nueva identidad y concederle un determinado nivel de acceso. La automatización es preferible, sobre todo para los elementos solicitados con frecuencia, para reducir la posibilidad de error humano.

Autenticación

Hasta ahora, gran parte de lo que se ha discutido no es realmente diferente de la gestión de accesos en entornos locales: antes de que exista una identidad, tienes que solicitarla y disponer de un proceso para crearla. Sin embargo, la autenticación es donde los entornos en la nube empiezan a diferir debido a los muchos servicios de identidad disponibles.

Es importante distinguir entre el almacén de identidades, que es la base de datos que contiene todas las identidades, y el protocolo utilizado para autenticar a los usuarios y verificar sus identidades, que puede ser OpenID, SAML, LDAP u otros.

Hay diferentes servicios en la nube disponibles para ayudar, dependiendo de quién se esté autenticando:

Autenticar a los empleados de tu organización con tus proveedores en la nube entra dentro de la autenticación de empresa a empresa (B2B), y el servicio en la nube suele denominarse algo así como "IAM en la nube".
Autenticar a los clientes de tu organización con tus propias aplicaciones que se ejecutan en la nube suele denominarse autenticación de empresa a consumidor (B2C), y el servicio en la nube suele llamarse algo así como "IAM de cliente" o "CIAM".
Autenticar a los empleados de tu organización con tus propias aplicaciones suele denominarse autenticación de empresa a empleado (B2E); puede utilizar los mismos servicios que la autenticación B2C o llamarse algo así como "Identidad de la plantilla".

Identidades IAM en la nube

La mayoría de los proveedores de la nube ofrecen servicios de IAM que deben utilizarse al acceder a sus servicios en la nube. Suelen estar disponibles sin coste adicional. Te permiten tener una ubicación central para gestionar las identidades de los administradores de la nube en tu organización, junto con el acceso que has concedido a esas identidades a todos los servicios que ofrece el proveedor de la nube.

Esto puede ser de gran ayuda. Si utilizas docenas o cientos de servicios de un proveedor de la nube, puede ser difícil hacerse una buena idea de qué nivel de acceso tiene una persona determinada si tienes que ir por separado a cada servicio. También puede ser difícil asegurarte de que has revocado todo su acceso cuando esa persona abandona tu organización. Revocar el acceso es especialmente importante, ¡dado que muchos de estos servicios pueden utilizarse directamente desde Internet!

La Tabla 4-1 enumera algunos ejemplos de servicios de identidad para autenticar a tus administradores de la nube con los servicios del proveedor de la nube.

Tabla 4-1. Servicios de identidad de proveedores en la nube
Proveedor	Servicio de identidad en la nube
Servicios web de Amazon	AWS IAM
Microsoft Azure	Directorio Activo Azure
Plataforma en la nube de Google	IAM en la nube
Nube de IBM	IAM en la nube

De empresa a consumidor y de empresa a empleado

Además de las identidades que tu organización utiliza para acceder a los servicios del proveedor de la nube, puede que también necesites gestionar las identidades de tus usuarios finales, ya sean clientes externos o tus propios empleados.

Aunque puedes hacer tú mismo la gestión de la identidad del cliente simplemente creando filas en una base de datos con contraseñas, esto no suele ser una experiencia ideal para tus usuarios finales, que tendrán que hacer malabarismos con otro nombre de usuario y contraseña. Además, hay importantes trampas de seguridad que debes evitar al verificar las contraseñas, como se describe en "Contraseñas, frases de contraseña y claves API". Hay dos opciones mejores:

Utiliza un servicio de identidad existente. Puede ser un servicio de identidad interno para tus empleados o los de tus clientes. Para los usuarios finales, también puede ser un servicio externo como Facebook, Google o LinkedIn. Esto requiere que confíes en ese servicio de identidad para que autentique correctamente a los usuarios por ti. También hace que tu asociación con el servicio de identidad sea obvia para tus usuarios finales cuando inician sesión, lo que no siempre es deseable.
Utiliza identidades de cliente específicas para tu aplicación, y utiliza un servicio en la nube para gestionar estas identidades de cliente. Los usuarios siguen teniendo otra credencial con la que lidiar, pero al menos no tienes que verificar la credencial.

Los nombres de estas ofertas de Identidad como Servicio (IDaaS) no siempre dejan claro lo que hacen. La Tabla 4-2 enumera algunos ejemplos de los principales proveedores de infraestructuras en la nube, así como de terceros proveedores. Hay muchos proveedores externos en este ámbito y cambian a menudo, por lo que no se trata de una recomendación de ningúnproveedor en particular. Para los casos de empresa a empleado, la mayoría de estos servicios IDaaS también pueden utilizar tu almacén de información de empleados, como tu directorio interno.

Tabla 4-2. Sistemas de gestión de identidad
Proveedor	Servicios en la nube de gestión de identidades de clientes y trabajadores
Servicios web de Amazon	Amazon Cognito
Microsoft Azure	Azure Active Directory B2C
Plataforma en la nube de Google	Plataforma de Identidad
Nube de IBM	ID de la aplicación
Okta	Nube de identidades de clientes, Nube de identidades de trabajadores
Ping	PingOne para clientes, PingOne para trabajadores

Nota

Ten en cuenta que, tanto si creas identidades tú mismo como si utilizas un servicio en la nube, cualquier información de identificación personal que recopiles o proceses puede estar sujeta a requisitos normativos como el GDPR de la UE.

Autenticación multifactor

La autenticación multifactor es una de las mejores formas de protegerse contra credenciales débiles o robadas, y si se aplica correctamente sólo supondrá una pequeña carga adicional para los usuarios. La mayoría de los servicios de identidad que aparecen en la Tabla 4-2 admiten laautenticación multifactor.

Como antecedentes, los distintos factores de autenticación se definen comúnmente como:

Algo que ya sabes. Las contraseñas son los ejemplos más conocidos, pero los números de identificación personal (PIN) -que, a diferencia de una contraseña, sólo pueden utilizarse en combinación con un dispositivo específico que tengas- son cada vez más populares.
Algo que tengas. Por ejemplo, una tarjeta de acceso, un teléfono móvil o un dato que no sea práctico memorizar, como una clave privada generada aleatoriamente.
Algo que eres. Por ejemplo, tu huella dactilar, tu cara o tu patrón retiniano.

Como su nombre indica, la autenticación multifactor implica utilizar más de uno de estos factores para la autenticación. Utilizar dos del mismo factor, como dos contraseñas diferentes, no ayuda mucho, ¡porque se podría utilizar el mismo ataque para obtener ambas contraseñas! La implementación más común es la autenticación de dos factores (2FA), que utiliza algo que sabes (como una contraseña) y algo que tienes (como tu teléfono móvil).

Nota

2FA no requiere que uno de los factores sea una contraseña. Los inicios de sesión sin contraseña que tienen dos factores (como un dispositivo físico que tengas y tu huella dactilar para desbloquear el dispositivo) pueden ser considerablemente más seguros y cómodos que la autenticación con contraseña.

La 2FA debería ser la opción por defecto para la mayoría de los accesos; si se aplica correctamente, requiere muy poco esfuerzo adicional para la mayoría de los usuarios. Es absolutamente necesario que utilices 2FA en cualquier lugar donde el impacto de la pérdida o robo de credenciales sea alto, como para cualquier acceso privilegiado, acceso para leer o modificar datos sensibles, o acceso a sistemas como el correo electrónico que pueda aprovecharse para restablecer otras contraseñas. Por ejemplo, si gestionas un sitio bancario, puedes decidir que el impacto es bajo si alguien es capaz de leer el saldo bancario de un usuario, pero alto (con 2FA obligatorio) si alguien intenta transferir dinero. Exigir autenticación adicional para actividades de mayor riesgo se denomina autenticación escalonada.

Si gestionas un entorno en la nube, el acceso administrativo no autorizado al portal de la nube o a las API supone un riesgo muy alto para ti, porque un atacante con ese acceso normalmente puede aprovecharlo para comprometer todos tus datos. Debes activar la autenticación de dos factores para este tipo de acceso; la mayoría de los proveedores de la nube lo admiten de forma nativa. Alternativamente, si utilizas el inicio de sesión único (SSO) , del que hablamos en "Inicio de sesión único", es posible que tu proveedor de SSO ya realice la 2FA por ti.

Muchos servicios ofrecen varios métodos de autenticación. Los métodos más comunes son:

Contraseñas y frases de contraseña (algo que sepas): Una contraseña no está vinculada a un dispositivo concreto, y funcionará desde cualquier lugar. Los problemas con las contraseñas son abundantes y bien conocidos: muchas personas eligen contraseñas que se utilizan habitualmente y están sujetas a ataques de diccionario, o son lo suficientemente simples y cortas como para ser descifradas con ataques de fuerza bruta, o se reutilizan en múltiples servicios, de modo que comprometer un servicio proporciona al atacante la contraseña de otro (que puede descubrirse mediante ataques de relleno de credenciales). Ya es hora de dejar de utilizarlas, pero el cambio es difícil.
PINs (algo que sepas): A primera vista, puede parecer que los PIN son peores que las contraseñas, porque suelen ser más sencillos, pero lo importante de los PIN es que sólo son útiles cuando se asocian a un dispositivo físico específico. Alguien que adivine tu PIN sin tener el dispositivo asociado (normalmente un teléfono móvil, un ordenador portátil o una llave de seguridad de hardware) no puede acceder a él, lo que hace que un ataque con éxito sea mucho más difícil.
Mensajes de texto SMS a un dispositivo móvil (algo que tengas): Este método ha caído en desgracia debido a la facilidad para robar el número de teléfono de alguien (mediante la clonación de la SIM o la portabilidad del número) o interceptar el mensaje, por lo que las nuevas implementaciones no deberían utilizarlo, y las implementaciones existentes deberían cambiar a otro método. Esto requiere acceso a la red celular para recibir los mensajes de texto.
Contraseñas de un solo uso basadas en el tiempo, o TOTPs (algo que tú tienes): Este método requiere proporcionar al dispositivo móvil un "secreto" inicial (normalmente transferido mediante un código de barras 2D). El secreto es una fórmula para calcular una contraseña de un solo uso cada minuto aproximadamente. La contraseña de un solo uso sólo debe guardarse durante uno o dos minutos, pero el secreto inicial puede permitir que cualquier dispositivo genere contraseñas válidas, por lo que debe destruirse o guardarse en un lugar físicamente seguro después de su uso. Una vez transferido el secreto inicial, el dispositivo móvil no necesita acceso a la red, sólo un reloj sincronizado. El principal inconveniente es que los TOTP son menos cómodos para los usuarios y son "phishables", lo que significa que un atacante que te engañe introduciendo tanto la contraseña como el código de acceso en un sitio falso puede obtener acceso.
Contraseñas de un solo uso basadas en hash, o HOTP (algo que tú tienes): Son similares a los TOTP en ventajas e inconvenientes, pero utilizan un contador en lugar de la hora, por lo que no requieren un reloj sincronizado. Sin embargo, pueden desincronizarse si se generan demasiados códigos y no se utilizan.
Notificaciones push a un dispositivo móvil (algo que tengas): Con este método, una aplicación cliente ya autenticada en un dispositivo móvil establece una conexión con un servidor, que "devuelve" un código de un solo uso o pide permiso. Esto es seguro siempre que la autenticación de la aplicación cliente ya autenticada sea segura, pero requiere que el dispositivo móvil tenga acceso a la red. El principal inconveniente es que un atacante puede ser capaz de engañar al usuario para que diga que sí, ya sea con un sitio de falsificación inteligente o fatigando al usuario con muchas peticiones.
Lectores de huellas dactilares, lectores faciales y lectores de retina (algo que tú eres): Aunque estos métodos biométricos son a menudo engañables con el suficiente esfuerzo (creando réplicas de dedos o caras u ojos), las implementaciones siguen mejorando y son lo suficientemente buenas como factor único para cumplir la mayoría de los requisitos de seguridad.
Un dispositivo de hardware, como uno que cumpla los estándares FIDO Universal 2nd Factor (U2F) o FIDO2 (algo que tengas): FIDO U2F es sólo un segundo factor de autenticación, generalmente utilizado con una contraseña, mientras que FIDO2 puede funcionar como un dispositivo multifactor combinado para permitir la autenticación sin contraseña. Los dispositivos FIDO2 también se denominan passkeys. Ésta es, con diferencia, la mejor opción, porque la llave de paso sabe con qué aplicación está hablando y no puede ser engañada por sitios falsos. Al principio, sólo estaban disponibles como claves de seguridad de hardware independientes, pero ahora la tecnología está integrada en la mayoría de los ordenadores portátiles y dispositivos móviles. Es probable que el uso de este tipo de autenticación se convierta en omnipresente en un futuro próximo, integrado en los teléfonos inteligentes y en tecnologías para llevar puestas, como relojes y anillos. Un dispositivo FIDO2 puede desbloquearse con un PIN o un factor biométrico, que combina dos factores en un solo dispositivo para una autenticación muy fuerte, resistente a la suplantación de identidad y sin contraseña.

Advertencia

Ten en cuenta que muchos de estos métodos para verificar "algo que tienes" son vulnerables a los ataques sociales, ¡como llamar al usuario con falsos pretextos y pedirle el código de acceso de un solo uso! Incluso las formas más fuertes de autenticación, como FIDO2, pueden ser objeto de ataques de degradación si el usuario va a un sitio falso que dice: "Eso no funcionó, por favor, prueba un método diferente (más débil)". Además de implantar la autenticación multifactor, debes proporcionar una formación mínima a los usuarios para ayudarles a reconocer los ataques habituales.

Todos los principales proveedores de la nube ofrecen formas de implementar la autenticación multifactor, aunque Google utiliza el término más amigable "Verificación en 2 pasos".

Contraseñas, frases de contraseña y claves API

Si utilizas la autenticación multifactor, las contraseñas o frases de contraseña ya no son tu única línea de defensa. Dicho esto, a menos que hayas pasado a un modelo totalmente sin contraseñas, sigue siendo importante elegir buenas contraseñas. Esto suele ser aún más cierto en entornos en la nube, porque en muchos casos un atacante puede adivinar las contraseñas directamente a través de Internet desde cualquier parte del mundo.

"Frase de contraseña" es sólo un término para una contraseña más larga y segura, así que aquí utilizaré el término más genérico "contraseña". Aunque hay muchos consejos y debates sobre las buenas contraseñas, mis recomendaciones para elegir contraseñas son sencillas:

Nunca reutilices contraseñas a menos que realmente no te importe que un usuario no autorizado acceda a los recursos protegidos por esa contraseña. Por ejemplo, podrías utilizar la misma contraseña en una docena de sistemas de foros porque realmente no te importa que alguien publique como tú en alguno o en todos esos foros. (Pero incluso en ese caso, sigue existiendo cierto riesgo de que el usuario pueda aprovechar de algún modo ese acceso para restablecer otras contraseñas, por lo que es mejor no reutilizar contraseñas en absoluto). Cuando escribas una contraseña en un sitio, debes suponer que los administradores del sitio son malintencionados y utilizarán la contraseña que les has proporcionado para entrar en otros sitios.
No reutilizar las contraseñas significa que acabarás teniendo un montón de contraseñas, así que utiliza un monedero de contraseñas de confianza para llevar un registro de ellas. Guarda copias de cualquier contraseña maestra o clave de recuperación en un lugar físicamente seguro, como una buena caja fuerte o una caja de seguridad bancaria.
Para contraseñas que no necesites recordar (por ejemplo, que puedas copiar y pegar de tu monedero de contraseñas), utiliza un generador aleatorio seguro. Veinte caracteres es un buen objetivo, aunque puedes encontrar algunos sistemasque no acepten tantos caracteres; para ellos, utiliza un conjunto de caracteres lo más variado posible.⁶
Para las contraseñas que necesites recordar, como la contraseña de tu monedero de contraseñas, crea una contraseña Diceware de seis palabras⁷ y pon el mismo carácter no alfabético, como un signo de dólar, un signo igual o una coma, entre cada palabra. No dudes en regenerar la contraseña unas cuantas veces hasta que encuentres una sobre la que puedas construir algún tipo de historia tonta que te ayude a recordarla. Así será fácil de memorizar rápidamente y casi imposible de adivinar para un atacante. El único inconveniente es que se tarda un rato en escribirla, ¡así que no querrás tener que teclearla constantemente!

Las claves API son muy similares a las contraseñas, pero están diseñadas para ser utilizadas por la automatización, no por las personas. Por esa razón, no puedes utilizar la autenticación multifactor con las claves API, y deben ser largas cadenas aleatorias, como se indica en el punto 3 de la lista anterior. A diferencia de la mayoría de las identidades de usuario, en las que tienes un ID de usuario público y una contraseña privada, normalmente sólo tienes una clave API privada que le dice al sistema quién eres y también te autentica.

Verificar contraseñas

También es posible que te encarguen verificar las contraseñas de los usuarios, lo que puede ser mucho más complicado de lo que parece. ¡Evita esta tarea si es posible!

La forma más sencilla de verificar las contraseñas es almacenar una lista de los usuarios y contraseñas y luego comprobar si la contraseña introducida coincide con la de la lista. Sin embargo, ésta es una muy mala idea, porque si alguien consigue acceder a tu lista, ¡tiene todo lo que necesita para suplantar a todos los usuarios de la lista!

Un método mucho mejor es no almacenar las contraseñas en sí, sino almacenar algo que pueda utilizarse para verificar las contraseñas. Esto se implementa utilizando un hash unidireccional, que es algo que puedes derivar con una función si tienes la contraseña, pero que no se puede utilizar para volver atrás y obtener la contraseña. Sin embargo, el diablo está en los detalles: si utilizas la función incorrecta o los parámetros incorrectos para la función, las contraseñas pueden obtenerse fácilmente ("crackearse") mediante un ataque de fuerza bruta, adivinando muchas contraseñas posibles. Los algoritmos hash perfectamente buenos, como SHA-256, son terribles para los hashes de contraseñas porque son rápidos de calcular, por diseño.

En el momento de escribir esto, los hashes de contraseñas deben almacenarse utilizando las funciones scrypt, bcrypt, PBKDF2 o Argon2 con parámetros razonables. Las recomendaciones sobre funciones y parámetros cambian con el tiempo, a medida que el hardware de craqueo se vuelve más sofisticado y se descubren puntos débiles en los algoritmos de hashing, por lo que debes reevaluar tus elecciones al menos una vez al año. Cuando cambies los algoritmos o los parámetros, todas las nuevas contraseñas utilizarán los nuevos métodos, pero por diseño no hay forma de convertir los hashes antiguos en hashes nuevos. Si hay una necesidad urgente de cambiar (como la evidencia de una brecha que podría haber accedido a los hashes de las contraseñas), debes restablecer todas las contraseñas de los usuariosinmediatamente.

Aunque almacenes hashes de forma segura, debes disponer de un mecanismo de comprobación para evitar que los usuarios utilicen contraseñas realmente fáciles de adivinar, como abc123 o Fall2018. Los atacantes utilizan cada vez más técnicas como la "pulverización de contraseñas", en la que prueban una contraseña fácil en cientos o miles de ID a la vez. Esto a menudo no activa ninguna alarma porque aparece como un único inicio de sesión fallido para cada ID. También debes monitorizar muchos fallos procedentes de un mismo sitio, lo que suele ser indicativo de ataques de relleno de credenciales, en los que un atacante obtiene una lista de contraseñas de un sitio y las prueba en otros.

Para los servicios y aplicaciones en la nube, utiliza una identidad federada de otro proveedor o un servicio en la nube de IAM de consumidor/empleado cuando sea posible. Para el acceso a nivel de sistema, utiliza autenticación basada en claves o autenticación centralizada con comprobación de la fortaleza de la contraseña. No almacenes ni verifiques tú mismo los hashes de las contraseñas, a menos que no existauna buenaalternativa.

Identificaciones compartidas

Los ID compartidos son identidades para las que más de una persona tiene la contraseña u otras credenciales, como la cuenta raíz o de administrador integrada en un sistema. Éstas pueden ser difíciles de manejar bien en entornos en la nube, al igual que en los locales.

Siempre que sea posible, cada usuario o herramienta debe tener su propio ID que no sea utilizado por nadie ni por nada más. Muchos sistemas permiten a los usuarios asumir un rol privilegiado o un ID separado con mayores privilegios para algunas actividades, como por ejemplo utilizando sudo en sistemas tipo Unix. Cuando necesites utilizar ID compartidos, tienes que poder saber exactamente qué persona (o herramienta automatizada) utilizó el ID para cualquier acceso.

Si tienes que compartir un ID, como el de root, el sistema en el que estás utilizando el ID compartido no tiene forma de distinguir quién lo estaba utilizando. Eso significa que necesitas tener un proceso y unas herramientas independientes para comprobar las credenciales compartidas y luego cambiarlas cuando se vuelvan a comprobar. Este utillaje suele denominarse sistema de gestión de accesos privilegiados (PAM) o de gestión de identidades privilegiadas (PIM), y también puederealizar otras funciones, como grabar la sesión o prohibir el uso de algunos comandos.

Identidad Federada

La identidad federada es un concepto, no una tecnología específica. Significa que puedes tener identidades en dos sistemas diferentes, y los administradores de esos sistemas pueden acordar utilizar tecnologías que vinculen esas identidades entre sí, de modo que no tengas que crear manualmente cuentas separadas en cada sistema. Desde tu perspectiva como usuario, sólo tienes una única identidad.

En la práctica, esto suele significar que tanto la empresa A como la empresa B utilizan tu dirección de correo electrónico corporativa, como user@company-a.com, como tu identidad, y la empresa B delega en la empresa A para autenticarte realmente. La empresa A te devolverá una aserción o token con su sello de aprobación: "Sí, efectivamente se trata de user@company-a.com; lo he verificado, aquí está mi firma para demostrar que soy yo, y ya has aceptado que confiarás en mí para autenticar a los usuarios con identificadores que terminen en @empresa-a.com".

Inicio de sesión único

El inicio de sesión único (SSO) es un conjunto de implementaciones tecnológicas que se basan en el concepto de identidad federada.

En los malos tiempos, cada sitio web tenía un nombre de usuario y una contraseña distintos. Eso suponía un montón de contraseñas para los usuarios. El resultado predecible es que los usuarios suelen reutilizar la misma contraseña en varios sitios, lo que significa que la contraseña del usuario sólo está tan bien protegida como el sitio más débil.

Entra el SSO. La idea es que, en lugar de que un sitio web solicite el ID y la contraseña de un usuario, el sitio web redirija al usuario a un proveedor de identidad (IdP) centralizado en el que confíe. (Ten en cuenta que el proveedor de identidad puede ni siquiera formar parte de la mismaorganización; el único requisito es que el sitio web confíe en él). El IdP hará el trabajo de autenticar al usuario, a través de medios como un nombre de usuario y una contraseña, y es de esperar que un factor de autorización adicional. A continuación, enviará al usuario de vuelta al sitio web original con la prueba de que ha verificado al usuario. En algunos casos, la IdP también enviará información (como la pertenencia a un grupo) que el sitio web puede utilizar para tomar decisiones sobre la autorización, como si se debe permitir la entrada del usuario como usuario normal, como administrador o no.

En su mayor parte, el SSO sólo funciona para sitios web y aplicaciones móviles, aunque esto está empezando a cambiar. Puede que necesites un protocolo diferente (como LDAP, Kerberos, TACACS+ o RADIUS) para realizar la autenticación centralizada de activos no web, como dispositivos de red o sistemas operativos.

¡Rara vez se encuentra algo que sea a la vez más fácil para los usuarios y ofrezca mayor seguridad! Los usuarios sólo tienen que recordar un conjunto de credenciales, y como estas credenciales sólo las ve el proveedor de identidad (y no ninguno de los sitios individuales), un compromiso de esos sitios no comprometerá las credenciales del usuario. Además, tu proveedor de SSO puede implementar controles que sigan otros principios de confianza cero, como comprobar si se está utilizando un dispositivo no gestionado o desactualizado, o si las credenciales del usuario se están utilizando desde dos países diferentes al mismo tiempo. Estos tipos de controles son muy difíciles de implementar individualmente en cada aplicación.

El único inconveniente del SSO es que es ligeramente más difícil de implantar para un sitio web que los mecanismos de autenticación deficientes, como la comparación con una contraseña de texto plano o una contraseña con hash inseguro en una base de datos.

SAML y OIDC

En el momento de escribir estas líneas, el Lenguaje de Marcado de Aserción de Seguridad (SAML -la abreviatura rima con "camello"-) y OpenID Connect (OIDC) son las tecnologías SSO más comunes. Aunque los resultados finales son similares, los mecanismos que utilizan son algo diferentes.

La versión actual de SAML es la 2.0, y existe desde 2005. Es una de las tecnologías de SSO más comunes, sobre todo para las grandes aplicaciones empresariales. Aunque hay muchas explicaciones detalladas sobre el funcionamiento de SAML, aquí tienes una versión muy simplificada:

Diriges tu navegador a una página web a la que quieres acceder (llamada proveedor de servicios o SP).
La página web del SP dice: "Oye, no tienes una cookie SAML, así que no sé quién eres. Ve aquí a esta página web del proveedor de identidad y obtén una", y te redirige.
Vas al IdP e inicias sesión utilizando tu nombre de usuario, contraseña y, con suerte, un segundo factor, o un método sin contraseña.
Cuando el IdP se asegura de que realmente eres tú, proporciona a tu navegador una cookie con una "aserción" XML firmada criptográficamente que dice: "Soy el proveedor de identidad y este usuario está autenticado", y luego te redirige de vuelta.
Tu navegador web devuelve esa cookie a la primera página web (SP). La SP verifica la firma criptográfica y dice: "Has conseguido convencer al IdP de tu identidad, así que eso me basta. Adelante".

Después de haber iniciado sesión una vez, todo esto ocurre automáticamente durante un tiempo hasta que esos documentos de afirmación caducan, momento en el que tienes que volver a iniciar sesión en el IdP.

Algo importante a tener en cuenta es que nunca hubo comunicación directa entre la página web inicial y el proveedor de identidad: tu navegador hizo todo el trabajo duro para llevar la información de un lugar a otro. Eso puede ser importante en algunos casos en los que las comunicaciones de red están restringidas.

Ten en cuenta también que SAML sólo proporciona información de identidad, por diseño. Si estás autorizado o no a iniciar sesión o a realizar otras acciones es una cuestión diferente, aunque algunas implementaciones de SAML pasan información adicional junto con la aserción (como la pertenencia a un grupo) que puede ser utilizada por la aplicación para tomardecisiones de autorización.

OpenID Connect es una capa de autenticación mucho más reciente, finalizada en 2014, sobre OAuth 2.0. Utiliza tokens web JSON (JWT, a veces pronunciado "jots") en lugar de XML, y emplea una terminología algo diferente ("parte de confianza" se suele utilizar en OIDC frente a "proveedor de servicios" en SAML, por ejemplo).

OIDC ofrece tanto Flujos de Código de Autorización (para aplicaciones web tradicionales) como Flujos Implícitos (para aplicaciones implementadas utilizando JavaScript en el lado del cliente). Aunque existen numerosas diferencias con SAML, los resultados finales son similares en el sentido de que la aplicación con la que te autentificas nunca ve tu contraseña real, y no tienes que volver a autenticarte para cada aplicación.

Algunos servicios pueden recibir solicitudes de aplicaciones compatibles con OIDC y "traducirlas" a solicitudes a un IdP SAML. En las grandes organizaciones, es muy común que se utilicen ambos estándares, y la mayoría de los IdP son compatibles con ambos.

SSO con aplicaciones heredadas

¿Qué pasa si quieres proporcionar un inicio de sesión único a una aplicación heredada que no lo admite? Una opción es poner algo delante de la aplicación que gestione las solicitudes SSO y luego le diga a la aplicación heredada quiénes son los usuarios.

La aplicación heredada confiará en este servicio frontend (a menudo un proxy inverso) para realizar la autenticación, pero es muy importante que no acepte conexiones de ninguna otra cosa. A veces se necesitan técnicas como ésta cuando se traslada una aplicación existente a la nube, hasta que la aplicación pueda reelaborarse para permitir el SSO de forma nativa. Muchos de los proveedores de Identidad como Servicio enumerados anteriormente también ofrecen formas de habilitar el SSO en aplicaciones heredadas.

Metadatos de instancia y documentos de identidad

Como se ha mencionado anteriormente en este capítulo, a menudo asumimos que la automatización, como un programa que se ejecuta en un sistema, ya tiene asignada una identidad y una forma de probar esa identidad. Por ejemplo, si pongo en marcha un nuevo sistema, puedo crear un nombre de usuario y una contraseña para que ese sistema los utilice y proporcionar ese nombre de usuario y esa contraseña al sistema como parte del proceso de creación. Sin embargo, en muchos entornos de nube, hay formas más sencillas.

Un proceso que se ejecuta en un sistema concreto puede ponerse en contacto con un punto final bien conocido que le dirá todo sobre el sistema en el que se está ejecutando, y el proceso también proporcionará una forma firmada criptográficamente de demostrar la identidad de ese sistema. Los detalles exactos difieren de un proveedor a otro, pero conceptualmente se parece a la Figura 4-2.

Sin embargo, esto no es infalible, ya que cualquier proceso del sistema puede solicitar estos metadatos, independientemente de su nivel de privilegio en el sistema. Esto significa que o bien tienes que poner sólo procesos del mismo nivel de confianza en el sistema, o bien tomar medidas para bloquear los procesos con menos privilegios para que no asuman la identidad de todo el sistema. Esto puede ser especialmente preocupante en entornos de contenedores, donde cualquier contenedor de un sistema anfitrión podría solicitar el documento de identidad y luego hacerse pasar por ese sistema anfitrión. En casos como éste, necesitas bloquear los contenedores para que no lleguen alservicio de metadatos.

Este sistema también requiere que el servicio en la nube reconozca el tipo concreto de documento y firma que utiliza el servicio de metadatos. ¡Ojalá hubiera un formato estándar para estos documentos y firmas, de modo que el servicio en la nube pudiera elegir confiar en contenedores creados en un clúster concreto o en máquinas virtuales creadas en una cuenta en la nube específica! Entra SPIFFE, que es un método estándar para permitir que una carga de trabajo (que puede ser un contenedor, una máquina virtual, una aplicación multinodo, etc.) se autentique con otra cosa. SPIRE es una implementación de referencia de la especificación SPIFFE. En el momento de escribir esto, SPIFFE no se utiliza ampliamente, pero es probable que, con el tiempo, ella o una especificación similar elimine el uso generalizado de claves API estáticas para la autenticación. En lugar de configurar el sistema para que confíe en cualquiera que obtenga la clave de la API, lo configurarás para que sólo confíe en aquellas cargas de trabajo que puedan mostrar una identificación válida y que estén en tu lista de cosas en las que confiar.

Si puedes utilizar documentos de identidad, entonces no necesitas hacer tanta gestión de secretos. Como carga de trabajo, puedo hacer una simple petición y que me den los secretos que necesito para acceder a otros recursos, y luego olvidar los secretos y volver a pedirlos si los necesito más adelante. Sin embargo, dado que los documentos de identidad aún no son de uso generalizado, y que muchos tipos de recursos aún no los aceptan, necesitarás algunas herramientas y técnicas para gestionar secretos. Las veremos a continuación.

Gestión de secretos

Antes he hablado de las contraseñas principalmente en el contexto de una persona que se autentica con un sistema. Los usuarios administrativos y los usuarios finales han tenido técnicas de gestión de secretos desde que existen los secretos, desde las buenas (carteras de contraseñas y cajas fuertes físicas) hasta las realmente malas (la omnipresente nota Post-it en el monitor o bajo el teclado). Aunque el término gestión de secretos se aplica generalmente siempre que tengas un secreto que recordar, suele utilizarse más específicamente para referirse a los secretos que utiliza un sistema para hablar con otro.

Por ejemplo, veamos el caso en el que un servidor de aplicaciones necesita hablar con un servidor de base de datos. Está claro que aquí no se puede utilizar la autenticación multifactor; ¡el servidor de aplicaciones no tiene una clave de seguridad de hardware ni una huella dactilar!⁸ Esto significa que debes tener mucho cuidado con las credenciales de autenticación para las conexiones entre sistemas, porque pueden ser tu única línea de defensa de autenticación.

Las credenciales de autenticación de sistema a sistema pueden implicar una contraseña, una clave API, un token criptográfico o un par de claves pública/privada. Todas estas soluciones tienen algo que debe mantenerse en secreto. Nos referimos a todas estas cosas simplemente como secretos, y la gestión de secretos consiste en ponerlos a disposición de la entidad que los necesita, y de nadie más. (Además, puede que tengas elementos no relacionados con la autenticación que deban mantenerse en secreto, como las claves de encriptación; aunque técnicamente también son secretos, suelen tratarse más específicamente en la gestión de claves de encriptación).

Los secretos son cosas peligrosas que deben manejarse con cuidado. He aquí algunos principios para la gestión de secretos:

Los secretos deben ser fáciles de cambiar a intervalos regulares y siempre que haya alguna razón para pensar que pueden haberse filtrado. Si cambiar el secreto significa que tienes que desmontar la aplicación y cambiarlo manualmente en muchos sitios, eso es un problema.
Los secretos deben estar siempre encriptados en reposo y en movimiento, y sólo deben distribuirse a los sistemas tras la autenticación y autorización adecuadas.
Si es posible, ningún humano debe conocer los secretos: ni los desarrolladores que escriben el código, ni los operadores que pueden ver el sistema en funcionamiento, nadie. A menudo esto no es posible, ¡pero al menos deberíamos esforzarnos por minimizar el número de personas que conocen los secretos!
El sistema que almacena y reparte los secretos debe estar bien protegido. Si pones todos los secretos en una cámara acorazada y luego repartes las llaves de la cámara a docenas de personas, eso es un problema.
Los secretos deben ser tan inútiles para un atacante como sea posible, permitiendo al mismo tiempo que el sistema funcione. Esto es, de nuevo, un caso de mínimo privilegio; intenta no mantener secretos que ofrezcan las llaves del reino, como proporcionar acceso de root a todos los sistemas, sino tener secretos limitados, como un secreto que permita el acceso de sólo lectura a una base de datos específica.
Todos los accesos y cambios a los secretos deben registrarse.

Incluso las organizaciones que hacen un gran trabajo con la autenticación y la autorización suelen pasar por alto la gestión de secretos. Por ejemplo, puedes hacer un gran trabajo controlando qué personas tienen identificaciones personales con acceso a una base de datos, pero ¿cuántas personas conocen la contraseña que utiliza el servidor de aplicaciones para hablar con la base de datos? ¿Se cambia con regularidad, e inmediatamente si alguien abandona el equipo? En el peor de los casos, esta contraseña está en el código del servidor de aplicaciones y registrada en algún repositorio público, como GitHub.⁹

Ha habido muchas brechas resultantes de almacenar accidentalmente secretos, como claves de API de AWS, en el código fuente. El código necesita las credenciales para funcionar cuando se implementa, pero poner secretos directamente en el código fuente (o en el repositorio de código fuente como parte de un archivo de configuración) es una muy mala idea, por dos razones:

Es probable que el repositorio de código fuente no se diseñara principalmente para mantener la información en secreto. Su función principal es proteger la integridad delcódigo fuente, evitando modificaciones no autorizadas para insertar una puerta trasera, por ejemplo. En muchos casos, puede mostrar el código fuente a todo el mundo por defecto como parte de una iniciativa de codificación social.
Aunque el repositorio de código fuente sea perfectamente seguro, es muy poco probable que todo el que tenga acceso al código fuente esté también autorizado a ver los secretos utilizados en el entorno de producción.

La solución más obvia es sacar los secretos del código fuente y colocarlos en otro lugar, como en un lugar seguro de tus herramientas de implementación o en un servidor de secretos dedicado.

En la mayoría de los casos, la implementación de una aplicación constará de tres piezas que se unen:

El código de la aplicación
La configuración de esta implementación concreta
Los secretos necesarios para esta implementación concreta

Almacenar las tres cosas juntas es una muy mala idea, como ya se ha comentado. Tener la configuración y los secretos juntos también suele ser una mala idea, porque los sistemas diseñados para guardar datos de configuración pueden no estar diseñados adecuadamente para mantener esos datos en secreto.

Echemos un vistazo a cuatro enfoques razonables de la gestión de secretos, que van desde mínimamente seguros a altamente seguros.

El primer enfoque consiste en utilizar los sistemas de gestión de la configuración y los sistemas de implementación existentes para almacenar secretos. Muchos sistemas populares hoy en día tienen cierta capacidad para guardar secretos además de los datos de configuración normales; por ejemplo, Ansible Vault y las bolsas de datos encriptados de Chef. Éste puede ser un enfoque razonable si la herramienta de implementación es cuidadosa con los secretos y, lo que es más importante, si el acceso al sistema de implementación y a las claves de cifrado está estrictamente controlado. Sin embargo, a menudo hay demasiadas personas que pueden leer los secretos. Además, cambiar los secretos suele requerir volver a desplegar el sistema, lo que puede resultar más difícil en algunos entornos.

El segundo enfoque consiste en utilizar un servidor de secretos. Con un servidor de secretos independiente, sólo necesitas una referencia al secreto en los datos de configuración y la capacidad de hablar con el servidor de secretos. En ese momento, el software de implementación o la aplicación pueden obtener el secreto autenticándose con el servidor de secretos mediante una contraseña del servidor de secretos... pero ya ves el problema, ¿verdad? Ahora tienes otro secreto (la contraseña del servidor de secretos) del que preocuparte.

Aunque imperfecto, este enfoque de lagestión de secretos sigue teniendo un valor considerable:

Las peticiones al servidor de secretos se pueden registrar, de modo que puedas detectar e impedir que un usuario o una implementación no autorizados accedan a los secretos. Esto se trata con más detalle en el Capítulo 7.
El servidor de secretos puede utilizar otras formas de determinar que la solicitud es legítima además de la contraseña, como el rango de direcciones IP que solicita el secreto. Como se explica en el Capítulo 6, la lista de direcciones IP permitidas no suele ser suficiente por sí misma, pero es un control secundario útil.
Puedes actualizar fácilmente los secretos más tarde, y todos tus sistemas que recuperen los secretos obtendrán los nuevos automáticamente.

El tercer enfoque tiene todas las ventajas de un servidor de secretos, pero utiliza un método de introducción seguro para reducir la probabilidad de que un atacante pueda conseguir las credenciales para acceder al servidor de secretos:

Tu herramienta de implementación se comunica con el servidor de secretos para obtener un secreto de un solo uso, que pasa a la aplicación.
A continuación, la aplicación lo cambia por el secreto real al servidor de secretos, y lo utiliza para obtener todos los demás secretos que necesita y mantenerlos en memoria. Si alguien ya ha utilizado el secreto de un solo uso, este paso fallará, y la aplicación puede enviar una alerta de que algo va mal.

Tu herramienta de implementación sigue necesitando un conjunto de credenciales estáticas para tu servidor de secretos, pero esto sólo le permite obtener claves de un solo uso y no ver los secretos directamente. (Si tu herramienta de implementación está completamente comprometida, entonces un atacante podría desplegar una copia falsa de una aplicación para leer los secretos, pero eso es más difícil que leer los secretos directamente y es más probable que se detecte).

El personal de operaciones no puede ver los secretos, ni las credenciales del servidor de secretos, sin técnicas más complicadas de raspado de memoria. Por ejemplo, en lugar de leer simplemente el secreto de un archivo de configuración, un operador deshonesto tendría que vaciar la memoria del sistema y buscar en ella el secreto, o conectar un depurador a un proceso para encontrar el secreto.

El cuarto enfoque, si está disponible, es aprovechar algunas ofertas incorporadas a tu plataforma en la nube por su proveedor para evitar el problema de las "tortugas hasta el fondo":

Algunos proveedores de la nube ofrecen metadatos de instancia o documentos de identidad a los sistemas aprovisionados en la nube. Tu aplicación puede recuperar este documento de identidad, que dirá algo así como: "Soy el servidor ABC. El proveedor de la nube firmó criptográficamente este documento por mí, lo que prueba mi identidad".
El servidor de secretos conoce entonces la identidad del servidor, así como metadatos como las etiquetas adjuntas al servidor. Puede utilizar esta información para autenticar y autorizar una aplicación que se ejecute en el servidor y proporcionarle el resto de secretos que necesita para funcionar. En el futuro, es posible que puedas utilizar el documento de identidad directamente con la mayoría de los servicios en la nube, ¡y no necesitespara nada el servidor de secretos!

Resumamos los cuatro enfoques razonables de la gestión de secretos:

El primer enfoque almacena los secretos sólo en el sistema de implementación, utilizando funciones diseñadas para guardar secretos, y controla estrictamente el acceso al sistema de implementación. Nadie ve los secretos por defecto, y sólo las personas autorizadas tienen la capacidad técnica de verlos o cambiarlos en el sistema de implementación.
El segundo enfoque consiste en utilizar un servidor de secretos para guardar los secretos. El servidor de implementación o la aplicación desplegada se ponen en contacto con el servidor de secretos para obtener los secretos necesarios y utilizarlos. En muchos casos, los secretos siguen siendo visibles en los archivos de configuración o en las variables de entorno de la aplicación en ejecución después de la implementación, por lo que el personal de operaciones puede ver fácilmente los secretos o las credenciales del servidor de secretos.
El tercer enfoque hace que el servidor de implementación sólo pueda obtener un token de un solo uso y pasarlo a la aplicación, que entonces recupera los secretos y los mantiene en memoria. Esto te protege de que se intercepten las credenciales al servidor de secretos o los propios secretos.
El cuarto enfoque aprovecha la propia plataforma de implementación como raíz de la confianza. Por ejemplo, un proveedor de IaaS entrega a las máquinas virtuales documentos de identidad firmados que el servidor de secretos puede utilizar para decidir qué secretos proporcionar a esa máquina virtual.

Hay varios productos y servicios disponibles para ayudarte a gestionar secretos. HashiCorp Vault y Keywhiz son productos independientes que pueden implementarse en las instalaciones o en la nube, y AWS Secrets Manager está disponible a través de un modelo como servicio .

Autorización

Una vez que has completado la fase de autenticación y sabes quiénes son tus usuarios, es hora de asegurarte de que están limitados a realizar sólo las acciones que se supone que deben realizar. Algunos ejemplos de autorización incluyen conceder permiso para acceder a una aplicación en absoluto, para acceder a una aplicación con acceso de escritura, para acceder a una parte de la red o para acceder a la consola de la nube.

Las aplicaciones de usuario final suelen gestionar ellas mismas la autorización. Por ejemplo, puede haber una fila o documento en la base de datos para cada usuario que enumere el nivel de acceso que tiene. Esto tiene cierto sentido, porque cada aplicación puede tener funciones específicas que autorizar, pero significa que tienes que visitar cada aplicación para ver todos los accesos que tiene un usuario.

Los conceptos más importantes que hay que recordar para la autorización son el mínimo privilegio y la separación de funciones. Como recordatorio, el mínimo privilegio significa que tus usuarios, sistemas o herramientas deben poder acceder sólo a lo que necesitan para hacer su trabajo, y nada más. En la práctica, esto suele significar que tienes una política de "denegación por defecto", de modo que a menos que autorices algo específicamente, no está permitido.

La separación (o segregación) de funciones procede en realidad del mundo de los controles financieros, donde pueden ser necesarias dos firmas para los cheques que superen un determinado importe. En el mundo de la seguridad en la nube, esto suele traducirse de forma más general en asegurarse de que ninguna persona pueda socavar por completo la seguridad de todo el entorno. Por ejemplo, alguien con la capacidad de realizar cambios en los sistemas no debería tener también la capacidad de alterar los registros de esos sistemas, ni la responsabilidad de revisar los registros de esos sistemas.

Para los servicios en la nube y las aplicaciones internas, la autorización centralizada es cada vez más popular.

Autorización centralizada

Los problemas de la antigua práctica ad hoc de dispersar las identidades por todas partes se han resuelto mediante las identidades federadas y el inicio de sesión único. Sin embargo, es posible que sigas teniendo registros de autorización dispersos por todas partes: cada aplicación puede mantener su propio registro de quién está autorizado a hacer qué en esa aplicación.

Puedes desautorizar a alguien por completo eliminando su identidad (suponiendo que los tokens de acceso persistente no lo mantengan autorizado durante un tiempo), pero ¿qué pasa con revocar sólo parte del acceso? La posibilidad de eliminar la identidad de alguien es importante, pero es una forma bastante torpe de gestionar el acceso. A menudo necesitas formas más precisas de gestionar el acceso. La autorización centralizada puede permitirte ver y controlar a qué tienen acceso tus usuarios en un único lugar.

En una aplicación tradicional, todo el trabajo de autorización se realizaba internamente en la aplicación. En el mundo de la autorización centralizada, las responsabilidades suelen repartirse entre la aplicación y el sistema de autorización centralizado. Hay más detalles en algunos sistemas, pero éstos son los componentes básicos:

Punto de Aplicación de la Política (PEP): Este punto se implementa en la aplicación, donde ésta controla el acceso. Si no tienes el acceso especificado en la política, el servicio o la aplicación no te permitirán realizar esa función. La aplicación comprueba el acceso pidiendo una decisión al Punto de Decisión de la Política.

Punto de Decisión Política (PDP): Este punto se implementa en el sistema de autorización centralizado. El PDP toma la información proporcionada por la aplicación (como la identidad y la función solicitada), consulta su política, y da a la aplicación su decisión sobre si se concede el acceso para esa función concreta.
Punto de Administración de Políticas (PAP): Este punto también se implementa en el sistema de autorización centralizado. Normalmente se trata de una interfaz de usuario web y una API asociada en la que puedes indicar al sistema de autorización centralizado quién tiene permiso para hacer qué.

La mayoría de los proveedores de la nube tienen una solución centralizada de gestión de acceso que sus servicios consultarán para tomar decisiones sobre el acceso, en lugar de tomarlas por sí mismos. Deberías utilizar estos mecanismos cuando estén disponibles, para poder ver en un solo lugar todos los accesos concedidos a un administrador concreto.

Funciones

Muchos proveedores de la nube ofrecen roles o perfiles de confianza, que son similares a los ID compartidos en el sentido de que asumes un rol, realizas acciones que ese rol permite y abandonas el rol. Esto difiere ligeramente de la definición tradicional de un rol, que es un conjunto de permisos o derechos concedidos a un usuario o grupo.

La principal diferencia entre los ID compartidos y los roles de proveedor de nube es que un ID compartido es una identidad independiente con credenciales fijas. Un rol de proveedor de la nube no es una identidad completa; es un estatus especial que adopta otra identidad que está autorizada a acceder a un rol, y a la que se le asignan credenciales temporales para acceder a ese rol.

El acceso basado en roles puede añadir una capa adicional de seguridad al exigir a los usuarios o servicios que asuman explícitamente un rol distinto para las operaciones más privilegiadas, siguiendo el principio del menor privilegio. La mayoría de las veces, el usuario no puede realizar esas actividades privilegiadas a menos que se ponga explícitamente el "sombrero" de rol y se lo quite cuando haya terminado. El sistema también puede registrar cada solicitud para asumir un rol, de modo que los administradores puedan determinar posteriormente quién tenía ese rol en un momento determinado y comparar esa información con las acciones en el sistema que tengan consecuencias para la seguridad.

Las personas no son las únicas entidades que pueden asumir roles. Algunos componentes (como las máquinas virtuales) pueden asumir un rol cuando se crean y realizar acciones utilizando los privilegios asignados a ese rol.

Funciones frente a grupos

Llegados a este punto, te preguntarás: "¿Cuál es la diferencia entre un rol y un grupo?". En sus formas más puras, éstas son las diferencias:

Un grupo es una colección de entidades, como los usuarios, sin ninguna información sobre qué autorizaciones se conceden a las entidades de ese grupo. El grupo VMAdminGroup puede contener a Chris y Barbara, pero no sabes qué pueden hacer.
Un rol es un conjunto de permisos que pueden concederse a usuarios, grupos u otras entidades, como las máquinas virtuales. Sin embargo, un rol "puro" no contiene intrínsecamente ninguna información sobre a quién se conceden esos permisos. Un rol llamado VMAdminRole puede concederte permiso para crear y eliminar máquinas virtuales, pero la definición del rol no te dice quién obtiene realmente esos permisos. En algunos casos, un rol se asigna permanentemente a determinados usuarios o grupos, y en otros, un usuario puede estar autorizado a "asumir" explícitamente un rol y abandonarlo cuando ya no lo necesite.

En la práctica, muchos roles también especifican los usuarios (o grupos) a los que se aplican, y en muchos casos la pertenencia a un grupo proporciona a los miembros del grupo un único conjunto permanente de permisos (un único rol). A menudo los términos se utilizan indistintamente, pero con algunos proveedores de la nube la distinción es importante (como con los grupos y roles de AWS IAM).

Revalida

En este punto, tus usuarios y la automatización deben tener identidades y estar autorizados a hacer sólo lo que necesitan. Debes asegurarte de que esto resiste la prueba del tiempo.

Como ya se ha dicho, el paso de revalidación es muy importante tanto en entornos tradicionales como en la nube, pero en los entornos en la nube puede que no tengas ningún control adicional (como el acceso físico al edificio o los controles de red) que te salve si te olvidas de revocar el acceso. Tienes que comprobar periódicamente cada autorización para asegurarte de que sigue siendo necesaria.

El primer tipo de revalidación es la revalidación automatizada basada en determinados parámetros. Por ejemplo, debes disponer de un sistema que introduzca automáticamente una solicitud para revocar todos los accesos cuando alguien abandone la organización. Ten en cuenta que eliminar simplemente la identidad del usuario puede no ser suficiente, porque el usuario puede tener credenciales almacenadas en caché, como tokens de acceso, que pueden utilizarse incluso sin poder iniciar sesión. En situaciones como ésta, necesitas un feed de offboarding, que es una lista de entidades cuyo acceso debe ser revocado. Cualquier sistema que entregue credenciales de larga duración, como tokens de acceso, debe procesar este feed de offboarding al menos diariamente y revocar inmediatamente el acceso de esas entidades.

El segundo tipo de revalidación requiere el juicio humano para determinar si una entidad concreta sigue necesitando acceso. En general, hay dos tipos de revalidación basada en el juicio:

Confirmación positiva: Esto es más fuerte: significa que el acceso se pierde a menos que alguien diga explícitamente: "Este acceso sigue siendo necesario".
Confirmación negativa: Esto es más débil: significa que el acceso se conserva a menos que alguien diga: "Este acceso ya no es necesario".

La confirmación negativa es adecuada para los niveles de autorización de menor impacto, pero para los tipos de acceso de gran impacto para la empresa, debes utilizar la confirmación positiva. Los inconvenientes de la confirmación positiva son que requiere más trabajo, y que el acceso puede revocarse accidentalmente si la solicitud no se procesa a tiempo (lo que puede causar problemas operativos).

El mayor riesgo que aborda la revalidación es que alguien que haya abandonado la organización (quizá en circunstancias polémicas) conserve el acceso a los sistemas. Pero además de esto, el acceso tiende a acumularse con el tiempo, como la basura en el cajón de los trastos de la cocina (ya sabes cuál). La revalidación elimina estos trastos.

Sin embargo, ten en cuenta que si es difícil obtener acceso, tus usuarios a menudo afirmarán que todavía necesitan acceso, aunque ya no lo necesiten. Tus esfuerzos de revalidación serán mucho más eficaces para podar el acceso innecesario si también tienes un proceso rápido y sencillo para conceder el acceso cuando sea necesario. Si eso no es posible, puede ser más eficaz revocar automáticamente el acceso si no se utiliza durante un determinado periodo de tiempo, en lugar de preguntar si sigue siendo necesario. Esto también tiene sus riesgos, ¡porque puedes encontrarte con que nadie disponible tiene acceso cuando se necesita!

Las ofertas de Identidad como Servicio en la Nube ofrecen cada vez más la gestión de todo el ciclo de vida de la identidad, además de los servicios de autenticación y autorización. En otras palabras, los proveedores están reconociendo la importancia del final de la relación, así como de su comienzo, y están ayudando a racionalizar y formalizar los finales.

¿Qué son todas estas herramientas?

Los nombres de las distintas herramientas de ayuda a la gestión de secretos e identidades pueden resultar confusos. Hay cierto desacuerdo sobre la denominación, y muchos productos realizan más de una función, pero aquí tienes una hoja de trucos con algunos de los nombres y funciones más comunes:

Un monedero de contraseñas es algo que los particulares utilizan para almacenar contraseñas de forma segura y rellenarlas automáticamente. Algunos programas de monederos de contraseñas también tienen la capacidad de compartir contraseñas con otros usuarios.
Una bóveda de credenciales, sistema de gestión de accesos privilegiados o sistema de gestión de identidades privilegiadas es un sistema que permite a los individuos (y a veces a la automatización) almacenar credenciales, verificarlas y utilizarlas. Uno de sus principales objetivos es garantizar la responsabilidad individual, de modo que se sepa qué entidad está utilizando una credencial en un momento dado. El sistema también puede realizar otras funciones, como descubrir cuentas privilegiadas existentes, registrar sesiones o controlar qué comandos se pueden emitir.
Un servicio de directorio mantiene una lista de usuarios y grupos, y suele tener una forma de autenticarlos. En la actualidad, los servicios de directorio suelen ser un componente de otrosproductos.
Un sistema de gestión de acceso a la identidad o proveedor de identidad es un sistema que puede realizar muchos de los tipos de autenticación tratados anteriormente, y que implementa protocolos de federación como SAML y OIDC.
Un sistema de gobierno de identidades es un sistema que gestiona las partes de solicitud, aprobación y revalidación del ciclo de vida; también puede tener otras funciones, como ayudarte a encontrar problemas de separación de funciones o a simplificar los roles.
Un sistema de gestión de secretos está orientado sobre todo a almacenar credenciales de forma segura para que las utilice la automatización, aunque también pueden utilizarlo los individuos. Suele formar parte de un canal de implementación que permite que la nueva implementación obtenga los secretos que necesita para funcionar.
Un sistema de gestión de claves de encriptación está orientado específicamente a los secretos que son las claves de encriptación, y también te permitirá realizar funciones como generar claves de forma segura y realizar funciones de envoltura/desenvoltura con las claves.
Un sistema de gestión de certificados está orientado específicamente a los certificados X.509; puede permitirte generarlos y firmarlos y notificarte cuando están a punto de caducar.

Ponerlo todo junto en la aplicación de ejemplo

¿Recuerdas nuestra sencilla aplicación web del Capítulo 1? Añadamos información sobre la gestión de identidades y accesos al diagrama, que ahora tiene el aspecto de la Figura 4-3. He eliminado todo el límite de confianza de la aplicación para simplificar el diagrama.A continuación se describen los pasos, muchos de los cuales constan de varias partes.

Por desgracia, ¡eso complicó bastante el diagrama! Veamos en detalle algunas de las nuevas interacciones:

El usuario final intenta acceder a la aplicación y se le aprueba automáticamente el acceso por tener una identidad válida y pasar opcionalmente algunas pruebas antifraude. El usuario inicia sesión con SSO, de modo que la identidad de la aplicación está federada con el proveedor de identidad externo del usuario, y la aplicación no tiene que validar contraseñas. Desde la perspectiva del usuario, está utilizando la misma identidad que en su empresa o en su red social favorita.
El administrador solicita acceso para administrar la aplicación, que es aprobada. A continuación, se autoriza al administrador en un sistema de autorización centralizado. La autorización puede tener lugar dentro del sistema IAM de la nube, o el sistema IAM de la nube puede estar configurado para pedir al propio sistema de autorización interno de la organización que realice la autorización.
El administrador se autentica con el servicio de IAM en la nube utilizando una contraseña segura y autenticación multifactor, y obtiene un token de acceso para darlo a cualquier otro servicio. De nuevo, opcionalmente, el servicio de IAM en la nube puede configurarse para enviar al usuario al sistema de autenticación interno de la organización.
El administrador hace peticiones a los servicios del proveedor de la nube, como crear una nueva máquina virtual o un contenedor. (Entre bastidores, el servicio VM de la nube pregunta al servicio IAM de la nube si el administrador está autorizado).
El administrador utiliza un servicio del proveedor de la nube para ejecutar comandos en las máquinas virtuales o contenedores según sea necesario. (Entre bastidores, el servicio "ejecutar comando" de la nube pregunta al servicio IAM de la nube si el administrador está autorizado a ejecutar ese comando en esa máquina virtual o contenedor). Si esta función no está disponible en un determinado proveedor de la nube, el administrador podría utilizar un método más tradicional, como SSH, con la máquina virtual utilizando el protocolo LDAP para autenticar y autorizar a los administradores contra un almacén de identidades. Ten en cuenta que, en un entorno de contenedores, puede que ni siquiera sea necesario ejecutar comandos para el mantenimiento y las actualizaciones normales, porque el administrador puede implementar un nuevo contenedor y eliminar el antiguo en lugar de realizar cambios en el contenedor existente.
Se utiliza un servicio de secretos para guardar la contraseña o clave API para que el servidor de aplicaciones acceda al sistema de base de datos. La Figura 4-3 muestra al servidor de aplicaciones obteniendo un documento de identidad del proveedor de la nube, accediendo directamente al servidor de secretos para obtener el secreto y accediendo a la base de datos. Si la base de datos acepta directamente el documento de identidad, ¡puede que ni siquiera necesites el servidor de secretos! El mismo proceso podría ocurrir para la autenticación entre el servidor web y el servidor de aplicaciones, pero sólo se muestra una interacción del servicio de secretos parasimplificar. El servicio de secretos puede ser gestionado por la organización, o puede ser una oferta como servicio de un proveedor en la nube.

Observa que cada vez que se cruza uno de los límites de confianza de nuestra aplicación, la entidad que cruza el límite de confianza debe estar autenticada y autorizada para poder realizar una acción. Hay otros límites de confianza fuera de la aplicación que no aparecen en la imagen, como los límites de confianza en torno a la nube y los sistemas de la organización.

Conclusión

Históricamente, muchas organizaciones han sido algo laxas con la gestión de identidades y accesos en entornos locales, y han confiado demasiado en otros controles (como la seguridad física y los controles de red). Sin embargo, la IAM es sumamente importante en los entornos en la nube. Aunque los conceptos son similares tanto en las implementaciones en la nube como en las locales, hay nuevas tecnologías y servicios en la nube que mejoran la seguridad y facilitan el trabajo.

En todo el ciclo de vida de la identidad y el acceso, es fácil olvidarse de los pasos de solicitud, aprobación y revalidación. Aunque pueden realizarse manualmente, muchas ofertas as-a-service que inicialmente sólo gestionaban los pasos de autenticación y autorización, ahora proporcionan flujos de trabajo también para el paso de aprobación, y esta tendencia se está acelerando.

Los sistemas de autenticación centralizados proporcionan a los administradores y usuarios finales una única identidad que se puede utilizar en muchas aplicaciones y servicios diferentes. Aunque existen desde hace tiempo en diferentes formas, son aún más necesarios en los entornos de nube, donde están disponibles por defecto. Dada la proliferación de sistemas y servicios en la nube, gestionar las identidades individualmente para cada sistema y servicio puede convertirse rápidamente en una pesadilla, salvo en las implementaciones más pequeñas. Las identidades antiguas y olvidadas pueden ser utilizadas por sus antiguos propietarios o por atacantes que buscan una forma fácil de entrar. Incluso con autenticación centralizada, debes utilizar buenas contraseñas y autenticación multifactor. Los administradores de la nube y los usuarios finales suelen autenticarse mediante sistemas diferentes.

Al igual que los sistemas de autenticación, los sistemas de autorización centralizados te permiten ver y modificar todo lo que una entidad está autorizada a hacer en un solo lugar. Esto puede facilitar la concesión y revalidación de accesos, y hacer más evidentes los conflictos de separación de funciones. Asegúrate de seguir los principios de mínimo privilegio y separación de funciones al autorizar tareas tanto a personas como a automatizaciones, y evita tener identidades y credenciales superpoderosas para el uso diario.

La gestión de secretos es un campo que está madurando rápidamente, en el que los secretos utilizados para el acceso de sistema a sistema se mantienen separados de otros datos de configuración y se manejan según principios estrictos de confidencialidad y auditoría. En algunos casos, la autenticación de sistema a sistema puede realizarse utilizando documentos de identidad, lo que puede reducir la necesidad de tener secretos mantenidos por separado. Las funciones de gestión de secretos están disponibles en los productos de gestión de configuración existentes, en los productos de servidor de secretos independientes y en las ofertas de nube como servicio.

Ahora que ya sabes cómo evitar una de las principales causas de las violaciones -la gestión insuficiente de identidades y accesos-, veamos otra de las principales causas, la gestión insuficiente de vulnerabilidades.

Ejercicios

¿Qué pasos se suelen utilizar en un ciclo de vida de gestión de accesos? Selecciona todas las que corresponda.
1. Solicitar acceso
2. Aprobar el acceso
3. Utiliza el acceso
4. Revalidar el acceso
¿Cuál de las siguientes afirmaciones sobre la autenticación es cierta?
1. La autenticación consiste en demostrar que eres quien dices ser.
2. La autenticación es todo lo que necesitas para acceder a una aplicación.
3. Las claves API pueden utilizarse para la autenticación multifactor.
4. La autenticación no es necesaria para las comunicaciones internas.
¿Cuál de las siguientes afirmaciones sobre la autorización es cierta? Selecciona todas las que corresponda.
1. La autorización consiste en que se te permita acceder a una aplicación concreta o realizar una acción determinada.
2. A menos que todo el mundo esté autorizado para una acción concreta, la autorización sólo es útil cuando se combina con la autenticación.
3. La autorización puede ser eficaz cuando está centralizada o descentralizada.
¿Cuál de las siguientes afirmaciones es cierta sobre los servicios de identidad en la nube? Selecciona todas las que corresponda.
1. Un servicio de identidad en la nube suele proporcionar un servicio central que puede autenticar a los usuarios.
2. Un servicio de identidad en la nube suele proporcionar un servicio central que puede autorizar a los usuarios.
3. Un servicio de identidad en la nube suele proporcionar un servicio central para almacenar secretos.
4. Los servicios de identidad en la nube se presentan en múltiples formas, como de empresa a consumidor y de empresa a empleado.

¿Cuál de las siguientes afirmaciones sobre la federación y el inicio de sesión único es cierta? Selecciona todas las que corresponda.
1. La federación y el inicio de sesión único son tecnologías diferentes que logran objetivos similares.
2. La identidad federada es el concepto de vincular identidades en dos sistemas diferentes.
3. El inicio de sesión único es una forma de utilizar identidades federadas.
4. El inicio de sesión único es más fácil para los usuarios, pero a menudo tiene como contrapartida una menor seguridad.

¹ Véase, por ejemplo, el Informe de investigaciones sobre violaciones de datos de Verizon.

² También está el proceso de verificar que una persona es quien dice ser antes de darle una identidad, lo que generalmente se denomina comprobación de identidad. De eso suelen encargarse los procesos corporativos de incorporación y los procesos de recuperación de contraseñas del servicio de asistencia, y normalmente no es responsabilidad de los usuarios de los servicios en la nube.

³ Cifrado de conocimiento cero significa que tu proveedor no tiene forma técnica de descifrar los datos, normalmente porque sólo envías los datos cifrados sin las claves. Esto limita drásticamente lo que el proveedor puede hacer, y es más adecuado para servicios de copia de seguridad en los que el proveedor sólo necesita retener muchos datos sin procesarlos.

⁴ Me gusta referirme bromeando a esto como el "principio de ya está jodido". Sin embargo, es bueno tener una forma de monitorear las acciones de tu proveedor, para detectar un posible compromiso.

⁵ Si tienes un 99,9% de seguridad de que no te robarán las credenciales de ningún usuario en un año, y tienes 1.000 usuarios, entonces sólo tienes un 36,7% de seguridad de que no te robarán las credenciales de ninguno de tus usuarios en un año. ¡Las probabilidades son divertidas!

⁶ Contraseña La fuerza suele medirse en "bits de entropía". Una explicación muy simplificada es que si das a un atacante toda la información posible sobre cómo se construye una contraseña, pero no la contraseña real, como "son 20 caracteres alfabéticos en mayúsculas", el número de bits de entropía es aproximadamente _log2(número de contraseñas posibles).

⁷ Diceware se basa en la idea de que a los humanos nos resulta mucho más fácil recordar frases que caracteres, y que casi todo el mundo puede encontrar algunos dados de seis caras. Puedes descargarte la lista de palabras Diceware, y luego tirar los dados para elegir al azar cinco o seis palabras de la lista. También hay páginas web que generan una frase de contraseña localmente para ti. El resultado es una contraseña extremadamente segura y fácil de recordar.

⁸ Algunas aplicaciones pueden recordar un secreto TOTP y utilizarlo para iniciar sesión junto con una contraseña, pero esto sólo suele hacerse en casos en los que una herramienta de pruebas se hace pasar por un usuario que inicia sesión. Si un atacante entra en esa aplicación, encontrará tanto la contraseña como el secreto TOTP en el mismo lugar, por lo que en esta situación el segundo factor no ayuda realmente desde el punto de vista de la seguridad.

⁹ En realidad existe un término común para los secretos que se encuentran en los repositorios públicos de GitHub: "GitHub dorks". Esto ha sido un problema tan extendido que GitHub ahora tiene formas de bloquear los envíos de código que contienen secretos.

Get Seguridad práctica en la nube, 2ª edición now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Seguridad práctica en la nube, 2ª edición by Chris Dotson

Capítulo 4. Gestión de identidades y accesos

Diferencias con la TI tradicional

Ciclo de vida de la identidad y el acceso

Figura 4-1. Ciclo de vida IAM

Consejo

Solicita

Aprueba

Crear, Eliminar, Conceder o Revocar

Autenticación

Identidades IAM en la nube

De empresa a consumidor y de empresa a empleado

Nota

Autenticación multifactor

Nota

Advertencia

Contraseñas, frases de contraseña y claves API

Identificaciones compartidas

Identidad Federada

Inicio de sesión único

SAML y OIDC

SSO con aplicaciones heredadas

Metadatos de instancia y documentos de identidad

Figura 4-2. Utilizar documentos de identidad

Gestión de secretos

Autorización

Autorización centralizada

Funciones

Revalida

Ponerlo todo junto en la aplicación de ejemplo

Figura 4-3. Ejemplo de diagrama de aplicación con IAM

Conclusión

Ejercicios

Don’t leave empty-handed

It’s yours, free.

Check it out now on O’Reilly