Glosario: Gestión de Identidad y Control de Acceso

1. Gestión de usuarios
1.1 IAM: Identity Access Management
La IAM, Gestión de Identidades (GdI) o Gestión de Identidades y Accesos es un término
genérico empleado para describir los procesos internos de una organización, cuyo principal
objetivo es gestionar las cuentas de usuarios y los recursos de la red corporativa, incluyendo
los derechos de acceso para organizaciones, usuarios, aplicaciones y sistemas, así como los
recursos a los que estos usuarios tienen acceso dentro del mismos sistema.
Al nivel más básico, la IAM implica que usuarios pueden hacer el qué dentro de una red, con
que dispositivos y bajo qué circunstancias. Este proceso consta de 3 etapas: Identificación,
establece la identidad del usuario (¿quién eres?), autenticación, verificar que el usuario es
quien dice ser (¿cómo lo demuestras?) y autorización/control de acceso, determinar a qué
recursos puede acceder o que acciones puede realizar el usuario según los privilegios
asociados a este.
La autenticación del usuario y sus derechos de acceso a una red son elementos claves de la
IAM. Para ello, el software de IAM se compone de una serie de funcionalidades que
permiten al usuario simplificar todos los procedimientos relacionados con estos procesos.
Algunas funcionalidades serían:
 Aprovisionamiento automático de cuentas de usuario
 Autoservicio
 Flujos de autorización (Workflow)
 Gestión de contraseñas
 Control de accesos basado en roles (Role-Based Access Control – RBAC)
¿Cómo funciona?
La gestión de la identidad se centra principalmente en la autenticación, mientras que la
gestión del acceso tiene como objetivo la autorización. La gestión de identidad determina si
un usuario tiene acceso a los sistemas, pero además también establece el nivel de acceso y
los permisos que tiene un usuario en dicho sistema.
Por ejemplo, un usuario puede tener autorización para acceder a un sistema, pero tener
restricciones a la hora de visualizar algunas de sus componentes. El objetivo principal de la
gestión de identidades es garantizar que solamente los usuarios autenticados tengan acceso
a las aplicaciones, sistemas o entornos de TI específicos para los que tienen autorización.
1.2 SCIM
El System for Cross-domain Identity Management (SCIM) es un estándar abierto que
permite la automatización del aprovisionamiento de usuarios. Surge en 2011 al quedar claro
que la tecnología del futuro estaría basada en la nube.
SCIM comunica datos de identidad de usuario entre proveedores de identidad (como
empresas con múltiples usuarios individuales) y proveedores de servicios que requieren
información de identidad de usuario (como aplicaciones SaaS empresariales).
En resumen, el SCIM logra que los datos del usuario sean más seguros y simplifica la
experiencia del usuario mediante la automatización del proceso de gestión de los ciclos de
vida de las identidades de usuario.
Según crece una compañía, y experimenta la rotación de empleados, el número de cuentas
de usuario se incrementa exponencialmente. Existen cuentas para todo, desde la gestión de
relaciones con los clientes hasta la colaboración en equipo. Las solicitudes para agregar y
eliminar usuarios, cambiar permisos y agregar nuevos tipos de cuentas consumen un valioso
tiempo del departamento de TI.
Con SCIM, las identidades de usuario pueden ser creadas directamente con herramientas, o
importadas de sistemas externos como softwares de HR o Directorios Activos. Como es un
estándar, la información del usuario se almacena consistentemente y puede ser comunicada
como de la misma manera entre aplicaciones. Esto facilita que los departamentos de IT
puedan automatizar el proceso de provisionamiento /desprovisionamiento al mismo tiempo
que tienen un único sistema para gestionar los permisos y grupos de usuarios.
Al mismo tiempo, muchos de los riesgos de seguridad a los que se enfrentan las empresas
se reducen al adoptar SCIM. Al no necesitar que los empleados inicien sesión en cada una
de sus cuentas individualmente, las empresas pueden garantizar el cumplimiento de las
políticas de seguridad. Esto reduce los riesgos asociados a aquellos empleados que utilizan
la misma contraseña en diferentes herramientas y aplicaciones. A medida que los equipos
desarrollan nuevos workflows y adoptan nuevas aplicaciones, las empresas pueden
mantenerse al tanto de dichos cambios sin temor a perder el rastro de las cuentas.
Finalmente cabe destacar que SCIM hace uso de una API REST(HTTP) estandarizada y con
datos en formato JSON o XML.

1.3 Flujo de autorización (Workflow)

Un Flujo de autorización es la secuencia entera de procesos por los que discurre un
proyecto desde su inicio hasta su compleción. Así pues, entendemos por Flujos de
autorización de IAM a aquellas secuencias de procesos que una compañía ha establecido
para gestionar las identidades a través de toda la organización.
Un flujo de autorización de IAM empieza con la incorporación del usuario al sistema y el
aprovisionamiento de los recursos necesarios, la gestión de la identidad a lo largo de toda su
estancia en la compañía (o directorio), y – por último – la eliminación de su identidad y el
desaprovisionamiento de acceso a todos los recursos necesarios.

1.4 Provisión
El aprovisionamiento es el proceso de coordinar la creación, mantenimiento y desactivación
de objetos/cuentas de usuarios (los cuales consiste en identificador, descriptor/nombre,
email, teléfono, información organizacional, pass…). Los servicios de provisionamiento
pueden incluir correo electrónico, inclusión en un directorio de usuarios publicado, acceso a
una base de datos, acceso a una red o mainframe, etc
Existen diferentes formas de aprovisionamiento:
Aprovisionamiento de acceso discreto
A menudo utilizado en pequeñas y medianas empresas, este enfoque permite que un
administrador de red decida a qué aplicaciones y datos pueden acceder los usuarios finales.
Aprovisionamiento de acceso de autoservicio
Por lo general, este enfoque se utiliza para ayudar a reducir la carga de trabajo de un
administrador. Permite a los usuarios participar en algunos aspectos del proceso de
aprovisionamiento, como solicitar una cuenta y contraseñas.
Aprovisionamiento de cuentas basado en flujo de trabajo (Workflow)
Se requieren las aprobaciones de los responsables designados antes de otorgar acceso al
usuario a una aplicación o datos. Por ejemplo, el acceso a las finanzas requeriría la
aprobación del director financiero de la empresa.
Aprovisionamiento automático de cuentas
Con este método, todas las cuentas se agregan de la misma manera a través de una interfaz
de aplicación de administración centralizada. Esto agiliza el proceso de agregar y administrar
credenciales de usuario y proporciona a los administradores la forma más precisa de
rastrear quién tiene acceso a qué aplicaciones y fuentes de datos específicas. Aunque los
procesos de administración de identidades y aprovisionamiento son los mismos, la
extensión y el tipo de aprovisionamiento puede variar mucho entre los diferentes usuarios
(por ejemplo, pacientes, médicos, clientes y socios).

1.5 Ciclo de vida de credenciales

2. Repositorio de usuarios
2.1 Domain Controller, Directorio Activo (AD)
Un Domain Controller o controlador de dominio (DC) es un servidor que responde a las
demandas de autenticación de seguridad para una red de ordenadores de un dominio dado.
Es un servidor en una red que se responsabiliza de permitir el acceso del host a los recursos
del dominio. Autentica a los usuarios, almacena la información de las cuentas de usuario y
hace cumplir las políticas de seguridad para un dominio dado. Está implementado
principalmente en entornos con Microsoft Windows, siendo la pieza central del servicio
Windows Active Directory (AD),
Una vez que el controlador de dominio autentifica a un usuario, se devuelve al cliente una
ficha especial (token) de autenticación, de manera que el usuario no necesitará volver a
iniciar sesión para acceder a otros recursos en dicho dominio, ya que el usuario se considera
autentificado en el dominio (SSO).
Active Directory (AD) es un servicio de directorio para uso en entorno Windows Server. Se
trata de una estructura de base de datos distribuida y jerárquica que comparte información
de infraestructura para localizar, proteger, administrar y organizar los recursos del equipo y
de la red, como archivos, usuarios, grupos, periféricos y dispositivos de red.
Active Directory es el servicio de directorio propietario de Microsoft para su uso en redes de
dominio de Windows. Cuenta con funciones de autenticación y autorización y proporciona
un marco de trabajo para otros servicios similares. Básicamente, el directorio consiste en
una base de datos LDAP que contiene objetos en red. Active Directory utiliza el sistema
operativo Windows Server.
La tecnología de Active Directory se basa en varios protocolos de red, entre los cuales
destacan LDAP, DHCP, KERBEROS y DNS. Esto significa que Active Directory funciona como
una especie de base de datos, en la cual se van almacenando en tiempo real, datos sobre la
identificación de los usuarios que forman parte de una red de ordenadores. Todos estos
datos quedan bajo un elemento central de control.
Cada uno de los usuarios que forman parte de la base de datos de Active Directory
está identificado por una serie de atributos, algunos de los más importantes son el nombre,
los apellidos y el correo electrónico. Active Directory asignará este usuario a un grupo, cuyos
privilegios están limitados.
De esta forma, cuando el usuario inicie la sesión con sus credenciales, será identificado de
inmediato por Active Directory. Tras ello, será Active Directory quien verifique las
credenciales del usuario y envié a su ordenador la información relativa a dicho usuario.
Una vez que todo lo anterior se haya completado, el usuario verá que su ordenador arranca
de forma normal, teniendo acceso a todos sus documentos, imágenes, y demás archivos a
los que tiene permitido el acceso. Active Directory también determinará si el usuario
puede acceder a otros recursos en línea, como una impresora o un fax.
Elementos que lo forman
 AD DS: base de datos con información de objetos (users, grupos, pcs, sites…) de
un dominio.
 Domain Controller: Máquina donde corre el servidor de Windows y está alojada
el directorio activo. Cerebro del dominio.
 AD: Protocolo para acceder a los servicios del directorio (símil a LDAP).
Estructura jerárquica del árbol
 Bosque
 Dominio
 Subdominio
 Unidad Organizativa
 Objetos (users, grupos, pcs, sites…)
 Políticas / directivas
Las políticas / directivas son reglas para definir configuraciones, permisos para usuarios o
máquinas en una red de Windows. Pueden ser locales (gpedit.msc) o globales (Group Policy
Object; gpmc.msc) que se aplican a equipos (solo afecta a ese equipo) o usuarios (solo
afecta al usuario independiente del equipo). En caso de existir una política sobre un objeto
se aplica la más restrictiva: GPO linked to OU, GPO linked to Domain, GPO linked to Site,
local Group Policy.

2.2 Protocolo LDAP – Oracle OUD

Protocolo cliente/servidor de la capa de aplicación que permite acceder, leer (importar),
editar (exportar) (usando LDIF como formato de intercambio de datos) y describir cómo
representar información de directorios (BBDD con información de usuarios como user/pass,
certificados, información de contacto) distribuidos en redes IP. Originalmente fue creado
como fronted del Protocolo de Acceso a Directorios X.500. Por otro lado, el servicio de
directorio es una aplicación que almacena de forma jerárquica y organiza la información de
usuarios y, a su vez, gestiona la autenticación de los accesos de usuarios a recursos de forma
segura. LDAP define 4 modelos:
Modelo de información o datos (DM)
Define como se representa la información de un sistema que habilita LDAP. La información
se representa mediante entradas, la cual pertenece a una o más clases. Cada entrada posee
un identificador único (nombre distinguido, DN). Cada entrada consta de un conjunto de
atributos los cuales tiene uno o varios valores.

 Modelo de designación (naming): Define el esquema de nombres de objetos

 Modelo funcional: Define lo relativo a las operaciones de lectura, escritura y
búsqueda.
 Modelo de seguridad: Define un marco para proteger la información del directorio
de accesos no autorizados.
LDAP es orientado a conexión (por lo que usa TCP como protocolo de transporte):
1. Cliente abre sesión con servidor en el puerto 389.
2. En LDAPv3 se hace uso de la extensión de TLS para mantener una conexión segura
cliente/servidor gracias a la petición startTLS
3. Autenticación simple (binding): cliente suministra DN/clave y server comprueba.
4. Cliente envía petición de solicitud (puede enviar las que quiera sin recibir respuesta)
5. Server envía respuesta (puede enviar respuestas no solicitadas).
6. Cliente cierra sesión. (unbind)
Tipo de peticiones que puede hacer el cliente
1. Consulta: search (busca entradas en el directorio) y compare (compara entradas con
atributos)
2. Actualización de entradas del directorio: add/delete/modify/modify dm
3. Autenticación y control: bind/unbid/abandon/extended

2.3 Bases de datos

Una base de datos es una recopilación organizada de información o datos estructurados,
que normalmente se almacena de forma electrónica en un sistema informático.
Normalmente, una base de datos está controlada por un sistema de gestión de bases de
datos (DBMS). En conjunto, los datos y el DBMS, junto con las aplicaciones asociadas a ellos,
reciben el nombre de sistema de bases de datos, abreviado normalmente a simplemente
base de datos.
Los datos de los tipos más comunes de bases de datos en funcionamiento actualmente se
suelen utilizar como estructuras de filas y columnas en una serie de tablas para aumentar la
eficacia del procesamiento y la consulta de datos. Así, se puede acceder, gestionar,
modificar, actualizar, controlar y organizar fácilmente los datos. La mayoría de las bases de
datos utilizan un lenguaje de consulta estructurada (SQL.) para escribir y consultar datos.
Aunque se parezcan a una hoja de Excel, se diferencian en que las bases de datos permiten
que muchos usuarios accedan y consulten los datos de forma rápida y segura al mismo
tiempo mediante una lógica y un lenguaje mucho más complejos.
Algunos de los tipos de bases de datos que he encontrado interesantes son las siguientes:
Base de datos distribuida
Una base de datos distribuida consta de dos o más archivos que se encuentran en sitios
diferentes. La base de datos puede almacenarse en varios ordenadores, ubicarse en la
misma ubicación física o repartirse en diferentes redes.
Base de datos en la nube
Una base de datos en la nube es una recopilación de datos, estructurados o no
estructurados, que reside en una plataforma de cloud computing privada, pública o híbrida.
Existen dos tipos de modelos de bases de datos en la nube: tradicional y base de
datos como servicio (DBaaS). Con DBaaS, un proveedor de servicios realiza las tareas
administrativas y el mantenimiento.
Bases de datos de autogestión
El tipo de base de datos más nuevo e innovador, las bases de datos de autogestión (también
conocidas como bases de datos autónomas) están basadas en la nube y utilizan el machine
learning para automatizar el ajuste de la base de datos, la seguridad, las copias de
seguridad, las actualizaciones y otras tareas de gestión rutinarias que tradicionalmente
realizan los administradores de bases de datos.

2.4 /etc/passwd
El archivo /etc/passwd almacena información esencial, que se requiere durante el inicio de
sesión en Linux. En otras palabras, almacena información de la cuenta del usuario.
El contenido del fichero /etc/passwd determina quien puede acceder al sistema de manera
legítima y que se puede hacer una vez dentro del sistema. Este fichero es la primera línea de
defensa del sistema contra accesos no deseados. Debe de mantenerse escrupulosamente y
libre de errores y fallos de seguridad. En él tenemos registrados las cuentas de usuario, así
como las claves de accesos y privilegios.
Una línea ejemplo en este fichero:
usuario1:FXWUuZ.vwXttg:500:501:usuario pepito:/home/usuario1:/bin/bash
Los diferentes campos (7) están separados por dos puntos (:) y el significado de los mismos
es el siguiente:

usuario1: Nombre de la cuenta (Login)

FXWUuZ.vwXt Clave de acceso encriptada

tg: (password)

500: UID de esta cuenta

501: GID del grupo principal al que

pertenece la cuenta

usuario Nombre del usuario

 pepito:

/home/usuario1: Directorio de trabajo de usuario1

/bin/bash: Interprete de comando (shell) de

usuario pepito

2.5 Usuarios locales

Las cuentas de usuario locales se almacenan localmente en el servidor. A estas cuentas se les
pueden asignar derechos y permisos en un servidor en particular, pero solo en ese
servidor. Las cuentas de usuario locales son entidades de seguridad que se usan para proteger
y administrar el acceso a los recursos de un servidor miembro o independiente de los
servicios o usuarios.

2.6 Usuarios privilegiados

Este tipo de usuario cuentan con los permisos más elevados de un sistema. Estos usuarios
tendrán permisos de lectura, escritura y ejecución sobre cualquier aplicación del sistema y
además pueden añadir/eliminar usuarios, a diferencia de los usuarios locales que tienen
permisos limitados por motivos de seguridad.

2.7 Usuarios externos

Son usuarios dentro de una organización que tienen acceso a conocimiento interno y
confidencial de la misma.
Para gestionar usuarios externos a una organización, se requiere una relación de confianza
entre ambas. Esta puede darse mediante una Federación: acuerdo entre dos entidades en el
que la entidad que proporciona acceso confiaría en la entidad que requiere acceso. Por
ejemplo, si la "Compañía A" confía en la "Compañía B" y permite el acceso a los empleados
de la "Compañía B" en función de su necesidad de tener acceso a los datos o sistemas de la
"Compañía A“. La autenticación y autorización de estos usuarios externos puede llevarse a
cabo mediante tecnologías como Azure AD B2B.

2.8 Usuarios internos

Son usuarios ajenos a una organización, como clientes o proveedores. Por ejemplo, a veces
es posible estar trabajando en un proyecto común con otra organización a la que se
requiere dar acceso a información a algunos de sus usuarios.

2.9 Usuarios personales

 Aquellos usuarios administrados por personas humanas. Un ejemplo de ellos puede ser la
cuenta de superusuario en Linux o una cuenta administrativa de un dominio de Windows.

2.10 Usuarios no personales

Aquellos usuarios que no están administrados por personas humanas, sino que son
administradas por apps o máquinas. Por ejemplo, aquellas cuentas de usuario que hagan
uso de claves para acceder a servicios remotos como ssh de forma automatizada o cuentas
de servicio que una app utiliza para interactuar con el sistema operativo.

2.11 Gestores/Clientes

Gestores: Un gestor es todo usuario que no es un cliente final. Estos

pueden ser:
•Gestores internos o colaboradores
•Gestores Distribuidores (trabajan en las tiendas)
•Gestores instaladores (trabaja a través del portal de instalación).
Dentro de la organización estos tienen asociados roles organizativos
(árbol jerárquico del que cuelgan dentro de la empresa) y funcionales
(área o departamento al que pertenecen).
Clientes: Usuarios clientes del segmento masivo y grandes cuentas. Son
divididos en:
•Customer: cliente dado de alta
•Prospect: cliente dudoso
•User: cliente que hace uso de un servicio, pero no es el titular

3. Autenticación
3.1 Federated Identity Management (FIM)
La FIM es un sistema que permite a los usuarios de empresas diferentes usar el mismo
método de verificación para acceder a aplicaciones y otros recursos.
Con FIM, cada empresa mantiene su propio sistema de GdI pero están interconectadas a
través de un tercer ente, el ID Provider (IDP), que almacena las credenciales y sirve como
mecanismo de confianza. Una vez que se ha establecido dicho vínculo de confianza, se
ejecuta de tal manera que cuando los usuarios de diferentes empresas se autentican en la
FIM, automáticamente se les da acceso a todos los recursos que han sido vinculados en ella
sin necesidad de volver a identificarse.
A menudo, las empresas asociadas en FIM transmiten dichas autorizaciones basadas en
estándares XML como lo es el Security Assertion Markup Language (SAML). Estos
intercambios permiten al usuario tener experiencias como la de Single Sign-On (SSO).
Podríamos decir así, que FIM facilita recursos como el SSO.
Algunos de los ejemplos de FIM más conocidos: OpenID, OAuth y Shibboleth.

3.2 Estándares de Autenticación

3.2.1 Flujos OpenIdConnect –API GateWay (Broadcom)
OpenID es un estándar abierto de autenticación descentralizado, con el que un usuario
puede identificarse en una página web a través de una URL que puede ser verificado por
cualquier servidor que soporte OpenID. Este es utilizado por más de mil millones de
cuentas, incluidas las de Google, WordPress y PayPal. La última versión del sistema se
llama OpenID Connect (OIDC) y es una combinación de OpenID y el protocolo OAuth 2.0.
Al igual que en SAML, es un estándar de autenticación que permite la integración del
proceso de Single Sign-On, el usuario necesita una cuenta de OpenID, que le
proporciona el llamado proveedor de identidad (IDP) de OpenID (como puede ser
Google). Con esta cuenta (o la dirección URL asociada), el usuario inicia sesión en todos
los sitios web que también son compatibles con el OpenID. Durante el proceso,
el proveedor de identidad de confianza transmite un token al sitio web correspondiente
que sirve para probar la identidad del usuario.
En sentido figurado, se podría comparar el SSO mediante OpenID con un viaje en el que
hay que cruzar una frontera: el viajero (usuario) utiliza un pasaporte que le da un
gobierno (el proveedor de identidad) y que el país de destino (el sitio web) considera
fiable. De esta manera, el pasaporte sirve para verificar la identidad del viajero. Un buen
ejemplo de este sistema es el botón de “Iniciar sesión con Facebook” que aparece en
muchos sitios web.
OpenID Connect soporta los siguientes flujos de autenticación:
Flujo Implícito
El flujo implícito es necesario para aplicaciones y sitios web que no tienen lógica de
back-end en el servidor web, y todo lo que es pasado entre la aplicación o el sitio web y
el IDP se puede ver en el navegador web mediante herramientas de desarrollo. En el
flujo implícito, se utiliza un esquema de clave pública / privada (JSON Web Key o JWK)
para cifrar o firmar los detalles del usuario. Cuando registre su aplicación cliente con el
IdP (OneLogin), recibirá una identificación de cliente y un secreto de cliente. En un flujo
implícito, el secreto del cliente nunca debe exponerse.
Flujo Básico (o de autenticación)
El flujo básico o de autenticaciónes una opción para las aplicaciones que tienen una
lógica de servidor web que permite la comunicación de back-end con el IdP (OneLogin).
Funciona como un flujo OAuth tradicional de tres patas y da como resultado un token de
acceso OAuth tradicional que se devuelve en secreto a la aplicación web a través de
llamadas realizadas en el back-end. En este flujo, en lugar de transmitir los detalles del
usuario, el proveedor envía un código especial de un solo uso que el servicio web back-
end puede intercambiar por un token de acceso OAuth. Este intercambio debe incluir la
identificación del cliente y el secreto del cliente además del código, al igual que un flujo
tradicional de OAuth 2.0. Es más seguro que el flujo implícito, porque los tokens no son
visibles a través del navegador y la aplicación cliente también se puede autenticar.

3.2.2 SAML – SiteMinder

SAML (Security Assertion Markup Language) es un estándar de código abierto basado en
XML que permite el intercambio de información, tanto de autenticación como de
autorización entre las diferentes partes que intervienen en el proceso, como lo son un
proveedor de identidad (IdP) y un proveedor de servicios (SP) mediante mensajes HTTP
que encapsulan peticiones/respuestas SAML. Es usado en federaciones de identidad, es
decir, conjunto de entidades que comparte tecnologías y estandares que permiten
transmitir información de identidad de un usuario de manera segura facilitando la
autenticacion y control de acceso entre diferentes dominios.
Un ejemplo de caso de uso es Eduroam, una iniciativa de las universidades europeas que
permite dar acceso a red a los usuarios dentro de sus propios campus y de los campus
de las instituciones participantes.

Así, el IdP será el encargado de llevar a cabo el proceso de autenticación en SAML, es

decir, el proceso por el cual ser verifica la identidad del usuario (mediante contraseña,
autenticación de dos factores, etc.) que quiere acceder a un determinado servicio, y
además proporcionará información de usuario al SP. Por otro lado, el SP será el
encargado de consumir la información de usuario proporcionada por el IdP y llevar a
cabo el control de acceso/autorización del usuario autenticado para acceder al servicio.
SAML una solución que permite la integración de servicios como el Single Sign-On y
web-SSO, similar al enfoque de SSO, pero trabaja solamente con apps y recursos
accedidos vía web. Este último hace uso de un agente web que recibe peticiones y
comprueba políticas.
Este protocolo tiene dos modos de inicio:
-SP Initiated:

-IdP Initiated:

Nosotros Utilizamos SiteMinder de Broadcom como Identity Provider (IdP)

Aunque ambos protocolos sirven para la autenticación y la implementación del Single
Sign – On, estos tienen diferentes ámbitos de aplicación:
 - OpenID Connect se basa en el protocolo OAuth 2.0 y utiliza un token web JSON
(JWT), también llamado ID token, para estandarizar áreas que OAuth 2.0 deja en
abierto, como son los scopes. Está especialmente enfocado a la autenticación del
usuario y es ampliamente empleado para facilitar el acceso del usuario a webs de
consumo y aplicaciones móviles.
- SAML es independiente de OAuth, dependiendo en el intercambio de mensajes para
autenticar en formato XML SAML, en oposición a JWT. Tiene un uso más común en
el entorno empresarial, dónde facilita al usuario a conectarse a diversas aplicaciones
utilizando SSO.

3.3 Single Sign-On (SSO) – Plug-In SR en web server / Siteminder

(Broadcom)
El SSO es una manera de acceder a múltiples aplicaciones interrelacionadas, aunque
independientes, con las que el usuario solo tiene que iniciar sesión una única vez en lugar de
introducir los datos de acceso individuales de cada software. Debido a su facilidad de uso,
los servicios de single sign on se utilizan tanto en el ámbito privado (aplicaciones web y
nubes privadas) como en el profesional (aplicaciones internas de empresa y portales en
Intranet).
Por norma general, el proceso consta de las siguientes fases:
I. El usuario inicia sesión una vez en el dispositivo.
II. Automáticamente, puede acceder a todos los ordenadores y servicios (incluida la
nube) para los cuales haya obtenido autorización local, siempre y cuando siga
utilizando el mismo dispositivo.
III. En cuanto el usuario cierra la sesión en el dispositivo, se cancelan todos los derechos
de acceso. Esto puede ocurrir al final de un plazo de tiempo programado, si el
usuario apaga el equipo o si ejecuta manualmente el single sign-out o single sign off.

3.4 Multifactor – Advance Authentication (PUMBA)

La autenticación multi factor o multifactor authentication (MFA) es un sistema de seguridad
que requiere más de un método de autenticación de categorías independientes de
credenciales para verificar la identidad de un usuario para conectarse a un sistema o realizar
otra acción. La MFA combina dos o más credenciales independientes, como pueden ser lo
que solamente el usuario sabe (la contraseña), lo que el usuario tiene (un token de
seguridad) y lo que el usuario es (verificación biométrica).
El objetivo de MFA es crear una defensa por capas y hacer más difícil el acceso a la red o
recursos a una persona sin autorización.
En el pasado, los sistemas MFA dependían de la autenticación en dos factores o 2-Factor
Authentication (2FA), añadiendo en la actualidad una capa más de seguridad.
3.5 RADIUS (Cisco ISE)
Remote Authentication Dial-In User service es un protocolo que permite gestionar la
autenticación, autorización y contabilidad (sistema AAA, Authentication, Authorization y
Accounting) de usuarios remotos sobre un determinado recurso. Utiliza el protocolo de
transporte UDP y generalmente usa el puerto 1812. Hace uso de cifrado solo para compartir
la contraseña entre cliente y servidor, el resto de información va en texto plano. Combina el
proceso de autenticación y autorización.
-Autenticación: Proceso mediante el cual se determina que un usuario es quien dice ser,
generalmente mediante usuario/pass o certificados digitales, y por tanto se le concede
permiso para acceder a un determinado recurso. Otros métodos soportados por RADIUS
son: Uso de protocolos PAP (Password Authentication Protocol) y CHAP (Challenge
Handshake Authentication Protocol) generalmente usados por los ISP (Internet Service
Provider) accesibles vía PPP (Point-to-point Protocol) para dar servicio de acceso a red (NAS,
Network Access Server) a usuarios, protocolo EAP (Extensible Authentication Protocol)
usado en redes inalámbricas (IEEE 802.1X), kerberos, LDAP…
-Autorización: Proceso mediante se concede acceso o no a servicios específicos a un
determinado usuario, puede hacer uso de políticas de control de acceso como ABAC y
soporta métodos de autorización como bases de datos LDAP, SQL o ficheros de
configuración internos.
-Contabilidad o registro: Proceso de seguimiento del consumo de recursos que realizan los
usuarios. Este registro incluye aspectos como la identidad del usuario, el servicio prestado,
tiempo de uso…
Cabe destacar que RADIUS está llamado a ser sustituido por DIAMETER, el cuál proporciona
también manejo de errores y comunicación entre dominios.
Ejemplo de uso del protocolo RADIUS sobre conexiones inalámbricas, concretamente, sobre
redes WLANs basadas en 802.1X.

3.6 TACACS
Terminal Access Controller Access Control System es un protocolo de autenticación remota
privativo de Cisco. Permite a un servidor de acceso remoto comunicarse con un servidor de
autenticación para determinar si un usuario tiene acceso o no. Utiliza el protocolo de
transporte TCP y usa el puerto 49. Este fue reemplazado por XTACACS y este, a su vez, por
TACACS+. Estos últimos incorporan la gestión AAA en procesos separados. A diferencia de
RADIUS, TACACS cifra toda la información intercambiada entre cliente y servidor, por lo que
 mejora a RADIUS en ese sentido. También soporta otros métodos de autenticación como
CHAP o kerberos.
A continuación, se muestra una comparativa entre los protocolos TACACS y RADIUS:

4. Autorización
4.1 Perfiles, Roles, Scopes
Perfiles: Un grupo de IAM es un conjunto de usuarios de IAM. Los grupos le permiten
especificar permisos para varios usuarios, lo que puede facilitar la administración de los
permisos para dichos usuarios. Por ejemplo, podría tener un grupo denominado Admins y
proporcionar a dicho grupo los tipos de permisos que los administradores suelen necesitar.
Un usuario de dicho grupo dispone automáticamente de los permisos que tiene asignados el
grupo. Si un usuario nuevo se une a su organización y necesita privilegios de administrador,
puede asignarle los permisos adecuados si lo agrega a dicho grupo. Asimismo, si una
persona cambia de trabajo dentro de su organización, en lugar de editar los permisos de
dicho usuario, puede eliminarlo de los grupos antiguos y agregarlo a los nuevos grupos
correspondientes.
Un grupo no es realmente una "identidad" de IAM, es simplemente una forma de asociar
políticas a varios usuarios al mismo tiempo.
Roles: Un rol de IAM es una identidad de IAM con permisos específicos que puede crear en
su cuenta. Un rol de IAM es similar a un usuario de IAM, ya que se trata de una identidad de
un sistema con políticas de permisos que determinan lo que la identidad puede hacer o no
en el sistema. Sin embargo, en lugar de asociarse exclusivamente a una persona, la
intención es que cualquier usuario pueda asumir un rol que necesite. Además, un rol no
tiene asociadas credenciales a largo plazo estándar, como una contraseña o claves de
acceso. En su lugar, cuando se asume un rol, este proporciona credenciales de seguridad
temporales para la sesión de rol.
Puede utilizar roles para delegar el acceso a usuarios, aplicaciones o servicios que
normalmente no tendrían acceso a los recursos del sistema.

Scopes: Son los permisos asociados a roles o perfiles que representan lo que los usuarios
pertenecientes a estos roles/perfiles pueden hacer sobre un recurso mediante una API (por
ejemplo, leer o escribir sobre el recurso). Por ejemplo, si un usuario dentro del perfil becario
quiere acceder a una API de gestión como Google Calendar, pero solo tiene scope de
escritura/lectura, esta información será añadida en el access token del usuario de forma que
cuando se examine el scope se permitirá realizar o no la escritura/lectura sobre la API de
Google Calendar.
4.2 Políticas de control de acceso
4.2.1 DAC (Discretionary Access control)
Política de control de acceso a recursos basada en los propietarios y grupos a los que
pertenece un recurso, es decir, permite al dueño del recurso especificar que sujetos
pueden acceder a dicho recurso y con qué permisos (lectura, escritura, ejecución). El
control de acceso se realiza de forma descentralizada.
Una de las técnicas utilizadas para aplicar esa política de control de acceso es la matriz
de control de acceso:

ACL (columnas): Listas de control de acceso que determina los usuarios o grupos que
tienen acceso sobre un determinado objeto.
Capacidades (filas): Determina los permisos que un determinado usuario o grupo tiene
sobre varios objetos.

4.2.2 MAC (Mandatory Access Control)

En este caso será el sistema quien decida de una forma centralizada si una operación
sobre un objeto realizada por un usuario está permitida. Este se realiza comparando
unas etiquetas de seguridad (indican el nivel de criticidad del recurso) con
autorizaciones de seguridad (indican quien puede acceder al recurso). Desde el punto de
vista de la seguridad MAC es más completo ya que las decisiones de seguridad no
recaen sobre el propietario de un objeto, sino que será el sistema quien lo decida en
base a políticas de seguridad. Ejemplo: AppArmor en sistemas Linux permite asociar a
cada programa un perfil de seguridad que restrinja las capacidades de ese programa,
complementando así el modelo DAC con un modelo MAC.

4.2.3 RBAC (Rol-based Access Control)

 En este enfoque el control de acceso a los recursos estará determinado por el rol/grupo
al que pertenezca el usuario, por tanto, todos los usuarios que pertenezcan a un
determinando rol tendrán los mismos permisos de acceso, simplificando así la tarea del
administrador de seguridad. Un usuario puede pertenecer a distintos roles obteniendo
así los permisos de acceso asociados a cada rol.

4.2.4 ABAC (Attributed-base Access Control)

El control de acceso a los recursos está determinado por una colección de
atributos/características asociados al usuario (ID, organización, rol…), recursos
(propietario, fecha de creación…) y entorno (ubicación, hora de acceso…). Mejora a
RBAC ofreciendo mayor nivel de granularidad.

4.3 PAM (Privileged Access Management) – PIN (Broadcom) / CyberArk

La gestión del acceso con privilegios se refiere a la estrategia de control, supervisión,
protección y auditoria de las identidades y actividades con privilegios (humanas, como root,
domain controller… y no humanas, como claves ssh, cuentas de Apps…) dentro del entorno
IT de una organización.
Esta estrategia se basa en el principio de mínimo privilegio, es decir, los usuarios solo
reciben los permisos de acceso mínimos necesarios para realizar su función laboral. Entre
las principales actividades que se llevan acabo por el enfoque PAM se encuentran:
 Gestión de cuentas con privilegios
 Custodia y automatización del ciclo de vida de contraseñas
 Monitorización, aislamiento y supervisión de actividades realizadas
(proxy)
 Control de acceso de usuarios privilegiados en base a perfiles y
niveles de autorización
 Integración con SIEM para la trazabilidad de las cuentas