Curso de ciberseguridad - Nam

Vista previa del material en texto

Curso de Ciberseguridad 
Descripción del modelo de responsabilidad compartida 
En organizaciones que solo ejecutan hardware y software local, la organización es un 100 % 
responsable de la implementación de la seguridad y el cumplimiento. Con los servicios basados en la 
nube, esa responsabilidad se comparte entre el cliente y el proveedor de la nube. 
El modelo de responsabilidad compartida identifica qué tareas de seguridad administra el proveedor 
de la nube y qué tareas de seguridad administra usted como cliente. Igualmente, las 
responsabilidades varían en función de dónde se hospede la carga de trabajo: 
• Software como servicio (SaaS) 
• Plataforma como servicio (PaaS) 
• Infraestructura como servicio (IaaS) 
• Centro de datos local 
El modelo de responsabilidad compartida hace que las responsabilidades resulten claras. Cuando las 
organizaciones realizan migraciones a la nube, algunas responsabilidades se transfieren al proveedor 
de la nube y otras a la organización del cliente. 
En el diagrama siguiente se muestran las áreas de responsabilidad entre el cliente y el proveedor de 
la nube, en función de dónde se encuentran los datos. 
 
• Centros de datos locales. En un centro de datos local, usted es el responsable de todo, 
desde la seguridad física hasta el cifrado de la información confidencial. 
• Infraestructura como servicio (IaaS). De todos los servicios en la nube, IaaS requiere que el 
cliente en la nube se encargue de la mayor parte de la administración. Con IaaS, se usa la 
infraestructura informática del proveedor de la nube. El cliente en la nube no es responsable 
de los componentes físicos, como los equipos y la red, ni de la seguridad física del centro de 
datos. Sin embargo, el cliente en la nube sigue siendo responsable de los componentes de 
software, como los sistemas operativos, los controles de red, las aplicaciones y la protección 
de datos. 
• Plataforma como servicio (PaaS). PaaS proporciona un entorno para compilar, probar e 
implementar aplicaciones de software. El objetivo de PaaS es ayudarle a crear una aplicación 
rápidamente sin tener que administrar la infraestructura subyacente. Con PaaS, el 
proveedor de la nube administra el hardware y los sistemas operativos, y el cliente es 
responsable de las aplicaciones y los datos. 
• Software como servicio (SaaS). El proveedor en la nube se encarga de hospedar y 
administrar SaaS para el cliente. Normalmente, esto se licencia a través de una suscripción 
mensual o anual. Microsoft 365, Skype y Dynamics CRM Online son ejemplos del software de 
SaaS. El cliente en la nube solo debe administrar el mínimo de SaaS. Asimismo, el proveedor 
de la nube es responsable de administrar todo, excepto los datos, los dispositivos, las 
cuentas y las identidades. 
En cuanto a todos los tipos de implementación en la nube, usted es el propietario de sus datos e 
identidades como cliente de la nube. Asimismo, es responsable de proteger la seguridad de los 
datos, las identidades y los recursos locales. 
En resumen, las responsabilidades que siempre retiene la organización del cliente incluyen: 
• La información y los datos. 
• Los dispositivos (móviles y equipos). 
• Las cuentas e identidades. 
La ventaja del modelo de responsabilidad compartida es que las organizaciones tienen claras sus 
responsabilidades y las del proveedor de la nube. 
Descripción de la defensa en profundidad 
La defensa en profundidad usa un enfoque por capas para la seguridad, en lugar de depender de un 
solo perímetro. Una estrategia de defensa en profundidad usa una serie de mecanismos para 
ralentizar el avance de un ataque. Cada capa proporciona protección de modo que, si se infringe una 
de ellas, una capa posterior impedirá que un atacante obtenga acceso no autorizado a los datos. 
Los niveles de seguridad de ejemplo pueden incluir: 
• La seguridad física, como limitar el acceso a un centro de datos solo al personal autorizado. 
• Controles de seguridad de identidad y acceso, como la autenticación multifactor o el acceso 
basado en condiciones, para controlar el acceso a la infraestructura y el control de cambios. 
• La seguridad perimetral de la red corporativa incluye la protección frente a ataques de 
denegación de servicio distribuido (DDoS) para filtrar los ataques a gran escala antes de que 
puedan causar una denegación de servicio para los usuarios. 
• Seguridad de red, como la segmentación de red y los controles de acceso a la red, para 
limitar la comunicación entre los recursos. 
• Seguridad de capa de proceso, como la protección del acceso a las máquinas virtuales, ya 
sea de forma local o en la nube, cerrando determinados puertos. 
• Seguridad de capa de aplicación, que garantiza que las aplicaciones sean seguras y estén 
libres de vulnerabilidades de seguridad. 
• Seguridad de capa de datos que incluye controles para administrar el acceso a los datos 
empresariales y de clientes, y el cifrado para proteger los datos. 
 
Confidencialidad, integridad, disponibilidad (CIA) 
Como se ha descrito anteriormente, una estrategia de defensa en profundidad usa una serie de 
mecanismos para ralentizar el avance de un ataque. Todos los distintos mecanismos (tecnologías, 
procesos y formación) son elementos de una estrategia de ciberseguridad, cuyos objetivos incluyen 
garantizar la confidencialidad, la integridad y la disponibilidad, a los que se suele hacer referencia 
como CIA, por sus siglas en inglés. 
 
• La confidencialidad se refiere a la necesidad de conservar datos confidenciales, como 
información de clientes, contraseñas o datos financieros. Puede cifrar los datos para 
mantener la confidencialidad, pero también debe mantener la confidencialidad de las claves 
de cifrado. La confidencialidad es la parte más visible de la seguridad; gracias a ella, 
podemos ver claramente la necesidad de mantener la confidencialidad de los datos 
privados, las claves, las contraseñas y otros secretos. 
• La integridad indica la necesidad de mantener los datos o mensajes correctos. Cuando envíe 
un mensaje de correo electrónico, probablemente quiera asegurarse de que el mensaje 
recibido sea el mismo que el mensaje enviado. Al almacenar datos en una base de datos, 
quiere asegurarse también de que los datos que recupera son los mismos que los datos 
almacenados. El cifrado de datos hace que este proceso sea confidencial, pero debe ser 
capaz de descifrarlo para obtener el mismo contenido que antes del cifrado. La integridad 
consiste en tener la confianza de que los datos no se han alterado ni modificado. 
• La disponibilidad se refiere a poner los datos a disposición de los usuarios cuando los 
necesiten. Es importante para la organización mantener seguros los datos de los clientes, 
pero al mismo tiempo también debe estar disponible para los empleados que trabajan con 
los clientes. Aunque puede ser más seguro almacenar los datos en un formato cifrado, los 
empleados necesitan obtener acceso a los datos descifrados. 
Aunque los objetivos de una estrategia de ciberseguridad son preservar la confidencialidad, la 
integridad y la disponibilidad de sistemas, redes, aplicaciones y datos, los ciberdelincuentes 
pretenden interrumpir estos objetivos. La cartera de Microsoft incluye las soluciones y tecnologías 
para permitir a las organizaciones cumplir el triple objetivo CIA. 
Descripción del modelo de Confianza cero 
La confianza cero presupone que todo está en una red abierta y que no es de confianza, incluso los 
recursos detrás de los firewalls de la red corporativa. El modelo de confianza cero funciona con el 
principio de "no confiar en nadie y comprobarlo todo". 
La capacidad de los atacantes para eludir los controles de acceso convencionales está acabando con 
cualquier ilusión de que las estrategias de seguridad tradicionales son suficientes. Por lo tanto, al no 
confiar en la integridad de la red corporativa, se refuerza la seguridad. 
En la práctica,esto significa que ya no asumimos que una contraseña es suficiente para validar a un 
usuario, sino que agregamos la autenticación multifactor para proporcionar comprobaciones 
adicionales. En lugar de conceder acceso a todos los dispositivos de la red corporativa, solo se 
permite el acceso de los usuarios a las aplicaciones o a los datos específicos que necesiten. 
En este vídeo se muestra la metodología de confianza cero: 
Principios de GUID de confianza cero 
El modelo de confianza cero tiene tres principios que guían y respaldan el modo de implementar la 
seguridad. Son los siguientes: la comprobación de forma explícita, el acceso con privilegios mínimos 
y asumir infracciones de seguridad. 
• Comprobación de forma explícita. Autentique y autorice siempre el contenido en función de 
los puntos de datos disponibles, como la identidad del usuario, la ubicación, el dispositivo, el 
servicio o la carga de trabajo, la clasificación de los datos y las anomalías. 
• Acceso con privilegios mínimos. Limite el acceso de los usuarios con acceso Just-in-Time y 
Just-Enough Access (JIT/JEA), LAS directivas de adaptación basadas en riesgos y LA 
protección de datos para proteger los datos y la productividad. 
• Asumir infracciones de seguridad. Acceda al segmento mediante la red, el usuario, los 
dispositivos y la aplicación. Use el cifrado para proteger los datos y el análisis para obtener 
visibilidad, detectar amenazas y mejorar la seguridad. 
Seis pilares básicos 
En el modelo de confianza cero, todos los elementos funcionan juntos para proporcionar seguridad 
de un extremo a otro. Estos seis elementos son los pilares básicos del modelo de confianza cero: 
• Las identidades pueden ser usuarios, servicios o dispositivos. Cuando una identidad intenta 
obtener acceso a un recurso, debe comprobarse mediante la autenticación sólida y seguir 
los principios de acceso con privilegios mínimos. 
• Los dispositivos crean una superficie de ataque de gran tamaño a medida que los datos 
fluyen desde los dispositivos hasta las cargas de trabajo locales y en la nube. La supervisión 
del estado y el cumplimiento de los dispositivos es un aspecto importante de la seguridad. 
• Las aplicaciones son la manera en que se consumen los datos. Esto incluye la detección de 
todas las aplicaciones que se usan, lo que a veces se denomina Shadow IT, ya que no todas 
las aplicaciones se administran de forma centralizada. Este pilar también incluye la 
administración de permisos y acceso. 
• Los datos se deben clasificar, etiquetar y cifrar en función de sus atributos. En última 
instancia, los esfuerzos de seguridad están relacionados con la protección de los datos y 
garantizan que permanecen seguros cuando salen de los dispositivos, las aplicaciones, la 
infraestructura y las redes que controla la organización. 
• La infraestructura, ya sea local o en la nube, representa un vector de amenazas. Para 
mejorar la seguridad, debe evaluar la versión, la configuración y el acceso JIT, y usar la 
telemetría para detectar ataques y anomalías. Esto le permite bloquear o marcar 
automáticamente el comportamiento de riesgo y tomar medidas de protección. 
• Las redes deben segmentarse, incluida la microsegmentación en la red más profunda. 
Asimismo, es necesario emplear la protección contra amenazas en tiempo real, el cifrado, la 
supervisión y el análisis de un extremo a otro. 
 
Una estrategia de seguridad que emplea los tres principios del modelo de Confianza cero en los seis 
pilares fundamentales ayuda a las empresas a ofrecer y aplicar la seguridad en toda su organización. 
Descripción del cifrado y el código hash 
Una manera de mitigar las amenazas de ciberseguridad más comunes es cifrar datos confidenciales o 
valiosos. El cifrado es el proceso para hacer que los datos aparezcan ilegibles e inútiles para visores 
no autorizados. Para usar o leer los datos cifrados, es necesario descifrarlos, lo que exige el uso de 
una clave secreta. 
Hay dos tipos de cifrado de nivel superior: simétrico y asimétrico. El cifrado simétrico usa la misma 
clave para cifrar y descifrar los datos. El cifrado asimétrico usa un par de claves pública y privada. 
Cualquiera de las claves puede cifrar los datos, pero no se puede usar una sola clave para descifrar 
los datos cifrados. Para descifrarlos se necesita la otra clave emparejada. El cifrado asimétrico se usa 
para cosas como el acceso a sitios en Internet mediante el protocolo HTTPS y las soluciones de firma 
de datos electrónicas. El cifrado puede proteger los datos en reposo o en tránsito. 
 
Cifrado de datos en reposo 
Los datos en reposo son los datos que se almacenan en un dispositivo físico, como un servidor. 
Pueden estar almacenados en una base de datos o en una cuenta de almacenamiento, pero, 
independientemente de dónde estén almacenados, el cifrado de datos en reposo garantiza que los 
datos no se puedan leer sin las claves y los secretos necesarios para descifrarlos. 
Si un atacante obtuviera una unidad de disco duro con datos cifrados, pero no tuviera acceso a las 
claves de cifrado, no podría leer los datos. 
Cifrado de datos en tránsito 
Los datos en tránsito son los que se están moviendo de una ubicación a otra, por ejemplo, por 
Internet o a través de una red privada. La transferencia segura se puede controlar mediante varias 
capas diferentes. Esto se puede hacer mediante el cifrado de los datos en el nivel de aplicación antes 
de enviarlos a través de una red. HTTPS es un ejemplo de cifrado en tránsito. 
El cifrado de datos en tránsito protege los datos de observadores externos y proporciona un 
mecanismo para transmitirlos que limita el riesgo de exposición. 
Cifrado de datos en uso 
Un caso de uso común para el cifrado de datos en uso conlleva proteger los datos en un 
almacenamiento no persistente, como la RAM o la memoria caché de CPU. Esto se puede lograr 
mediante tecnologías que crean un enclave (como si fuera una caja fuerte con llave) que protege los 
datos y los mantiene cifrados mientras la CPU los procesa. 
Aplicación de algoritmo hash 
El hash utiliza un algoritmo para convertir el texto en un valor hash de longitud fija único 
denominado hash. Cada vez que se aplica un algoritmo hash al mismo texto mediante el mismo 
algoritmo, se genera el mismo valor hash. Ese hash se puede usar como identificador único de los 
datos asociados. 
El hash es diferente del cifrado, ya que no usa claves, y el valor al que se aplica el algoritmo hash no 
se descifra posteriormente en el original. 
El hash se usa para almacenar contraseñas. Cuando un usuario escribe su contraseña, el mismo 
algoritmo que creó el hash almacenado crea un hash de la contraseña escrita. A continuación, se 
compara con la versión hash almacenada de la contraseña. Si coinciden, es que el usuario ha escrito 
correctamente la contraseña. Esto es más seguro que el almacenamiento de contraseñas de texto 
sin formato, pero los hackers también conocen los algoritmos hash. Dado que las funciones hash son 
deterministas (esto es, la misma entrada produce el mismo resultado), los hackers pueden usar los 
ataques de diccionario por fuerza bruta mediante el hash de las contraseñas. Por cada hash 
coincidente, obtienen la contraseña real. Para reducir este riesgo, a menudo las contraseñas se 
"cifran con sal". Esto hace referencia a que se agrega un valor aleatorio de longitud fija a la entrada 
de las funciones hash para crear valores hash únicos para la misma entrada. 
 
Descripción de los conceptos de cumplimiento 
Los datos son más importantes que nunca. Las organizaciones, las instituciones y sociedades enteras 
generan datos y dependen de ellos para que funcionar correctamente día a día. La gran escala de 
datos generados y la creciente dependencia de ellos significa que la privacidad y la protección de 
esos datos se han vuelto fundamentales. A medida que las organizaciones e instituciones mueven 
sus datos a las nubesdel proveedor de servicios, con centros de datos de todo el mundo, entran en 
juego consideraciones adicionales. 
Los organismos gubernamentales y los grupos del sector han aprobado reglamentos para ayudar a 
proteger y controlar el uso de los datos. Desde la información personal y financiera hasta la 
protección de datos y la privacidad, las organizaciones pueden tener la responsabilidad de cumplir 
decenas de reglamentos. A continuación se enumeran algunos conceptos y términos importantes 
relacionados con el cumplimiento de los datos. 
• Residencia de datos: cuando se trata de cumplimiento, los reglamentos de residencia de 
datos rigen las ubicaciones físicas donde se pueden almacenar los datos y cómo y cuándo se 
pueden transferir, procesar o acceder a escala internacional. Estos reglamentos pueden 
variar significativamente en función de la jurisdicción. 
• Soberanía de datos: otra consideración importante es la soberanía de los datos, el concepto 
de que los datos, especialmente los datos personales, están sujetos a las leyes y los 
reglamentos del país o la región donde se recopilan, conservan o procesan físicamente. Esto 
puede agregar una capa de complejidad cuando se trata de cumplimiento porque se puede 
recopilar el mismo fragmento de datos en una ubicación, almacenarse en otra y procesarse 
en otra, por lo que estaría sujeto a las leyes de diferentes regiones o países. 
• Privacidad de los datos: proporcionar avisos y ser transparentes sobre la recopilación, el 
procesamiento, el uso y el uso compartido de los datos personales constituyen los principios 
fundamentales de las leyes y los reglamentos sobre privacidad. "Datos personales" hace 
referencia a cualquier información relativa a una persona física identificada o identificable. 
Las leyes sobre privacidad antes hacían referencia a "DCP" o "información de identificación 
personal", pero las leyes han ampliado la definición a cualquier dato que esté directamente 
vinculado o que se pueda vincular indirectamente a una persona. Las organizaciones están 
sujetas a una multitud de leyes, reglamentos, códigos de conducta, estándares específicos 
del sector y estándares de cumplimiento que rigen la privacidad de los datos y, por tanto, 
deben operar conforme a ellos. 
En la mayoría de los casos, las leyes y los reglamentos no determinan ni prescriben las tecnologías 
específicas que las organizaciones deben usar para proteger los datos. Dejan a discreción de una 
organización identificar las tecnologías, las operaciones y otras medidas de protección de datos 
apropiadas que cumplan la normativa. 
Definición de autenticación y autorización 
Autenticación 
La autenticación es el proceso de demostrar que una persona es quien dice ser. Cuando alguien 
compra un artículo con una tarjeta de crédito, es posible que tenga que mostrar una forma adicional 
de identificación. De esta manera, demuestra que es la persona cuyo nombre aparece en la tarjeta. 
En este ejemplo, el usuario puede mostrar el DNI, que sirve como forma de autenticación y verifica 
su identidad. 
Si desea acceder a un equipo o un dispositivo, se encontrará con un tipo de autenticación similar. Es 
posible que se le pida que escriba un nombre de usuario y una contraseña. El nombre de usuario 
indica quién es, pero no es suficiente por sí solo para concederle acceso. Cuando lo combina con la 
contraseña, que solo usted debe conocer, obtiene acceso a los sistemas. El nombre de usuario y la 
contraseña, juntos, son una forma de autenticación. A veces, la autenticación se abrevia como 
AuthN. 
Autorización 
Cuando autentique a un usuario, tendrá que decidir adónde puede ir y qué se le permite ver y tocar. 
Este proceso se denomina autorización. 
Supongamos que quiere pasar la noche en un hotel. Lo primero que hará es ir a la recepción para 
iniciar el "proceso de autenticación". Una vez que el recepcionista haya comprobado quién es, le 
dará una tarjeta-llave y ya podrá dirigirse a su habitación. Piense en la tarjeta-llave como el proceso 
de autorización. La tarjeta-llave solo le permitirá abrir las puertas y los ascensores a los que puede 
acceder, como la puerta de su habitación. 
En términos de ciberseguridad, la autorización determina el nivel de acceso o los permisos de una 
persona autenticada a los datos y los recursos. A veces, la autorización se abrevia como AuthZ. 
Definición de identidad como perímetro de seguridad principal 
La colaboración digital ha cambiado. Los empleados y asociados ahora necesitan colaborar y acceder 
a los recursos de la organización desde cualquier lugar, en cualquier dispositivo y sin que ello afecte 
a su productividad. También se ha producido una aceleración en el número de personas que 
trabajan desde casa. 
La seguridad de la empresa debe adaptarse a esta nueva realidad. El perímetro de seguridad ya no 
se puede ver como la red local. Ahora se extiende a: 
• Aplicaciones SaaS para cargas de trabajo críticas para la empresa que se pueden hospedar 
fuera de la red corporativa. 
• Los dispositivos personales que los empleados usan para tener acceso a los recursos 
corporativos (BYOD o Bring Your Own Device) mientras trabajan desde casa. 
• Los dispositivos no administrados que usan los asociados o clientes al interactuar con los 
datos corporativos o colaborar con los empleados 
• Internet de las cosas, conocido como dispositivos IoT, instalado en la red corporativa y 
dentro de las ubicaciones de los clientes. 
El modelo de seguridad tradicional basado en el perímetro ya no es suficiente. La identidad se ha 
convertido en el nuevo perímetro de seguridad que permite a las organizaciones proteger sus 
recursos. 
Pero ¿qué significa una identidad? Una identidad es el conjunto de aspectos que definen o 
caracterizan a alguien o algo. Por ejemplo, la identidad de una persona incluye la información que 
usa para autenticarse, como su nombre de usuario y contraseña, y su nivel de autorización. 
Una identidad puede estar asociada a un usuario, una aplicación, un dispositivo o cualquier otra 
cosa. 
 
Cuatro pilares de una infraestructura de identidad 
La identidad es un concepto que abarca todo un entorno, por lo que las organizaciones deben 
pensar en ello en general. Hay una colección de procesos, tecnologías y directivas para administrar 
identidades digitales y controlar cómo se usan para tener acceso a los recursos. Pueden organizarse 
en cuatro pilares fundamentales que las organizaciones deben tener en cuenta al crear una 
infraestructura de identidad. 
• Administración. La administración consiste en la creación y la administración o gobernanza 
de identidades para los usuarios, dispositivos y servicios. Como administrador, puede 
administrar cómo y en qué circunstancias pueden cambiar las características de las 
identidades (se pueden crear, actualizar y eliminar). 
• Autenticación. El pilar de autenticación indica cuánto necesita saber un sistema de TI sobre 
una identidad para tener pruebas suficientes de que realmente son quienes dicen ser. 
Implica el acto de solicitar a un usuario credenciales legítimas. 
• Autorización. El pilar de autorización trata sobre el procesamiento de los datos de identidad 
entrante para determinar el nivel de acceso de una persona o servicio autenticado dentro de 
la aplicación o servicio al que quiere obtener acceso. 
• Auditoría. El pilar de auditoría consiste en realizar un seguimiento de quién realiza qué, 
cuándo, dónde y cómo. La auditoría incluye la creación de informes, alertas y gobernanza de 
identidades en profundidad. 
Direccionar cada uno de estos cuatro pilares es clave para una solución completa y sólida de 
identidad y control de acceso. 
Descripción del rol del proveedor de identidades 
Autenticación moderna es un término genérico para los métodos de autenticación y autorización 
entre un cliente, como un portátil o un teléfono, y un servidor, como un sitio web o una aplicación. 
En elcentro de la autenticación moderna está el rol del proveedor de identidades. Un proveedor de 
identidades crea, mantiene y administra la información de identidad al tiempo que proporciona 
servicios de autenticación, autorización y auditoría. 
Con la autenticación moderna, quien proporciona todos los servicios, incluidos todos los servicios de 
autenticación, es un proveedor de identidades central. El proveedor de identidades almacena y 
administra de forma centralizada la información que se usa para autenticar el usuario en el servidor. 
Con un proveedor de identidades central, las organizaciones pueden establecer directivas de 
autenticación y autorización, supervisar el comportamiento de los usuarios, identificar actividades 
sospechosas y reducir los ataques malintencionados. 
Vea este vídeo para obtener más información sobre la autenticación moderna y cómo funciona con 
un proveedor de identidades central. 
Como se ve en el vídeo, gracias a la autenticación moderna, el cliente se comunica con el proveedor 
de identidades mediante la asignación de una identidad que se puede autenticar. Cuando se ha 
comprobado la identidad (que puede ser un usuario o una aplicación), el proveedor de identidades 
emite un token de seguridad que el cliente envía al servidor. 
El servidor valida el token de seguridad a través de su relación de confianza con el proveedor de 
identidades. Mediante el uso del token de seguridad y la información que contiene, el usuario o la 
aplicación accede a los recursos necesarios en el servidor. En este escenario, el proveedor de 
identidades almacena y administra el token y la información que contiene. El proveedor de 
identidades centralizado proporciona el servicio de autenticación. 
Microsoft Azure Active Directory es un ejemplo de un proveedor de identidades basado en la nube. 
Otros ejemplos son Twitter, Google, Amazon, LinkedIn y GitHub. 
Inicio de sesión único 
Otra funcionalidad fundamental de un proveedor de identidades y "autenticación moderna" es la 
compatibilidad con el inicio de sesión único (SSO). Con el SSO, el usuario inicia sesión una vez y esa 
credencial se usa para tener acceso a varias aplicaciones o recursos. A la acción de configurar el SSO 
para que funcione entre varios proveedores de identidades se le conoce como federación. 
 
 
 
 
 
Descripción del concepto de servicios de directorio y Active Directory 
En el contexto de una red de equipos, un directorio es una estructura jerárquica que almacena 
información acerca de los objetos de la red. Un servicio de directorio almacena los datos del 
directorio y los pone a disposición de los usuarios de red, los administradores, los servicios y las 
aplicaciones. 
Active Directory (AD) es un conjunto de servicios de directorio desarrollados por Microsoft como 
parte de Windows 2000 para redes locales basadas en dominio. El servicio más conocido de este tipo 
es Active Directory Domain Services (AD DS). Almacena información sobre los miembros del 
dominio, incluidos los dispositivos y los usuarios, comprueba sus credenciales y define sus derechos 
de acceso. Un servidor que ejecuta AD DS es un controlador de dominio. 
AD DS es un componente central de las organizaciones con una infraestructura de TI local. AD DS 
ofrece a las organizaciones la capacidad de administrar varios sistemas y componentes de la 
infraestructura local mediante una única identidad por usuario. Sin embargo, AD DS no es 
compatible de forma nativa con los dispositivos móviles, las aplicaciones SaaS o las aplicaciones de 
línea de negocio que requieren métodos de autenticación moderna. 
El crecimiento de Cloud Services, las aplicaciones SaaS y los dispositivos personales que se usan en el 
trabajo, ha dado como resultado la necesidad de la autenticación moderna y una evolución de las 
soluciones de identidad basadas en Active Directory. 
Azure Active Directory es la siguiente evolución de las soluciones de administración de identidad y 
acceso. Proporciona a las organizaciones una solución de identidad como servicio (IDaaS) para todas 
sus aplicaciones en la nube y en el entorno local. En este curso, nos centraremos en Azure AD, el 
proveedor de identidades basado en la nube de Microsoft. 
Para obtener más información sobre las diferencias entre los conceptos de Active Directory y Azure 
Active Directory, consulte la sección Más información de la unidad de resumen y recursos que 
redirige a la documentación 
Descripción del concepto de federación 
La federación permite el acceso a los servicios a través de los límites de la organización o del 
dominio mediante el establecimiento de relaciones de confianza entre el proveedor de identidades 
del dominio correspondiente. Con la federación, no es necesario que un usuario mantenga un 
nombre de usuario y una contraseña diferentes al acceder a los recursos de otros dominios. 
 
La manera simplificada de considerar este escenario de federación es la siguiente: 
• El sitio web, en el dominio A, usa los servicios de autenticación del proveedor de identidades 
A (IdP-A). 
• El usuario, en el dominio B, se autentica con el proveedor de identidades B (IdP-B). 
• IdP-A tiene una relación de confianza configurada con IdP-B. 
• Cuando el usuario, que desea acceder al sitio web, proporciona sus credenciales, el sitio web 
confía en el usuario y permite el acceso. Este acceso se permite debido a la confianza que ya 
se ha establecido entre los dos proveedores de identidades. 
Con la federación, la confianza no siempre es bidireccional. Aunque IdP-A puede confiar en IdP-B y 
permitir que el usuario del dominio B tenga acceso al sitio web del dominio A, lo contrario no es 
cierto, a menos que se configure la relación de confianza. 
Un ejemplo común de federación en la práctica es cuando un usuario inicia sesión en un sitio de 
terceros con su cuenta de redes sociales, como Twitter. En este escenario, Twitter es un proveedor 
de identidades y el sitio de terceros podría estar usando otro proveedor de identidades, como Azure 
AD. Hay una relación de confianza entre Azure AD y Twitter 
Descripción de Azure Active Directory 
Microsoft Azure Active Directory (Azure AD), parte de Microsoft Entra, es el servicio de 
administración de identidades y acceso basado en la nube de Microsoft. Las organizaciones usan 
Azure AD para permitir que sus empleados, invitados y otros usuarios inicien sesión y tengan acceso 
a los recursos que necesitan, incluidos: 
• Recursos internos, como las aplicaciones de la red corporativa y la intranet, junto con todas 
las aplicaciones en la nube que haya desarrollado su propia organización. 
• Servicios externos, como Microsoft Office 365, Azure Portal y cualquier aplicación SaaS que 
use su organización. 
Azure AD simplifica la forma en que las organizaciones administran la autorización y el acceso, ya 
que proporciona un sistema de identidad único para sus aplicaciones locales y en la nube. 
Igualmente, Azure AD se puede sincronizar con la instancia de Active Directory local existente, con 
otros servicios de directorio o se puede usar como un servicio independiente. 
Azure AD también permite a las organizaciones habilitar de manera segura el uso de dispositivos 
personales, como dispositivos móviles y tabletas, y permitir la colaboración con clientes y asociados 
comerciales. 
 
Los administradores de TI usan Azure AD para controlar el acceso a los recursos y a las aplicaciones 
corporativas, en función de los requisitos empresariales. También puede configurarse para requerir 
la autenticación multifactor cuando el usuario intenta acceder a recursos importantes de la 
organización. Además, Azure AD se puede usar para automatizar el aprovisionamiento de usuarios 
entre una instancia de Windows Server AD existente y aplicaciones en la nube, incluyendo Microsoft 
365. Por último, Azure AD proporciona herramientas eficaces que le ayudarán a proteger 
automáticamente las identidadesy credenciales de los usuarios y a cumplir los requisitos de 
gobernanza de acceso de la empresa. 
Los desarrolladores usan Azure AD como un enfoque basado en estándares para agregar el inicio de 
sesión único (SSO) a sus aplicaciones, de modo que los usuarios puedan iniciar sesión con 
credenciales ya existentes. Asimismo, Azure AD también proporciona varias API que permiten que 
los desarrolladores creen experiencias de aplicación personalizadas que usen los datos existentes de 
la organización. 
Los suscriptores de servicios de Azure, Microsoft 365 o Dynamics 365 tienen acceso automático a 
Azure AD. Los usuarios de estos servicios pueden sacar provecho de los servicios de Azure AD 
incluidos y también pueden mejorar su implementación de Azure AD mediante la actualización a 
licencias Premium de Azure AD. 
Descripción de las ediciones de Azure AD disponibles 
Azure AD está disponible en cuatro ediciones: gratuita, aplicaciones de Office 365, Premium P1 y 
Premium P2. 
Azure Active Directory Free. La versión gratuita le permite administrar usuarios y crear grupos, 
sincronizarse con la instancia local de Active Directory, crear informes básicos, configurar el cambio 
de contraseña de autoservicio para usuarios en la nube y habilitar el inicio de sesión único en Azure, 
Microsoft 365 y muchas otras aplicaciones populares de SaaS. La edición gratuita se incluye con las 
suscripciones a Office 365, Azure, Dynamics 365, Intune y Power Platform. 
Aplicaciones de Office 365. La edición de Aplicaciones de Office 365 le permite hacer todo lo que se 
incluye en la versión gratuita, más la opción de restablecer la contraseña de autoservicio para 
usuarios en la nube y la reescritura de dispositivos, que ofrece una sincronización bidireccional entre 
directorios locales y Azure AD. La edición de Aplicaciones de Office 365 de Azure Active Directory se 
incluye en las suscripciones a Office 365 E1, E3, E5, F1 y F3. 
Azure Active Directory Premium P1. La edición Premium P1 incluye todas las características de las 
ediciones Gratis y Aplicaciones de Office 365. También admite la administración avanzada, como 
grupos dinámicos, administración de grupos de autoservicio, Microsoft Identity Manager (un 
conjunto de administración local de identidades y acceso) y funcionalidades de reescritura en la 
nube, que permiten el restablecimiento de contraseña de autoservicio a los usuarios locales. 
Azure Active Directory Premium P2. La versión P2 le ofrece todas las características de la edición 
Premium P1 y Azure Active Directory Identity Protection para facilitar el acceso condicional basado 
en riesgos a las aplicaciones y a los datos críticos de la empresa. Asimismo, la edición P2 también le 
proporciona la instancia de Privileged Identity Management que le permitirá detectar, restringir y 
supervisar a los administradores y su acceso a los recursos y proporcionar acceso de tipo "Just-in-
Time" cuando sea necesario. 
Para obtener más información sobre cada una de las ediciones, visite la página de precios de Azure 
Active Directory. 
También hay una opción para las licencias de característicasde "Pago por uso". Puede obtener otras 
licencias de características por separado, como la opción Negocio a cliente (B2C) de Azure Active 
Directory. B2C puede ayudarle a proporcionar soluciones de administración de acceso y de identidad 
para las aplicaciones orientadas al cliente. Para más información, consulte Documentación de Azure 
Active Directory B2C. 
Descripción de los tipos de identidad de Azure AD 
Azure AD administra distintos tipos de identidades: usuarios, entidades de servicio, identidades 
administradas y dispositivos. En esta unidad, se detallará cada tipo de identidad de Azure AD. 
Usuario 
Una identidad de usuario es una representación de algo que se administra mediante Azure AD. Los 
empleados e invitados se representan como usuarios en Azure AD. Si tiene varios usuarios con las 
mismas necesidades de acceso, puede crear un grupo. Los grupos se usan para conceder permisos 
de acceso a todos los miembros del grupo, en lugar de tener que asignar derechos de acceso 
individualmente. 
La colaboración de negocio a negocio (B2B) de Azure AD es una característica de External Identities e 
incluye una funcionalidad para agregar usuarios invitados. Gracias a la colaboración B2B, una 
organización puede compartir aplicaciones y servicios de forma segura con usuarios invitados de 
otra organización. 
En la siguiente guía interactiva, agregará un nuevo usuario a Azure Active Directory. Seleccione la 
imagen siguiente para empezar y siga las indicaciones que aparecen en pantalla. 
https://learn.microsoft.com/es-es/azure/active-directory/identity-protection/overview-identity-protection
https://learn.microsoft.com/es-es/azure/active-directory/privileged-identity-management/pim-getting-started
https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing
https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing
https://learn.microsoft.com/es-es/azure/active-directory-b2c/
https://learn.microsoft.com/es-es/azure/active-directory-b2c/
 
Entidad de servicio 
Una entidad de servicio es, básicamente, una identidad para una aplicación. Para que una aplicación 
delegue su identidad y funciones de acceso a Azure AD, primero se debe registrar con Azure AD a fin 
de habilitar su integración. Una vez que se registra, se crea una entidad de servicio en cada inquilino 
de Azure AD donde se usa la aplicación. La entidad de servicio habilita características básicas como la 
autenticación y autorización de la aplicación en los recursos protegidos por el inquilino de Azure AD. 
Para que las entidades de servicio puedan acceder a los recursos protegidos por el inquilino de Azure 
AD, los desarrolladores de aplicaciones deben administrar y proteger las credenciales. 
Identidad administrada 
Las identidades administradas son un tipo de entidad de servicio que se administran de forma 
automática en Azure AD y eliminan la necesidad de que los desarrolladores administren las 
credenciales. Las identidades administradas proporcionan una identidad para que la usen las 
aplicaciones al conectarse a recursos de Azure compatibles con la autenticación de Azure AD, sin 
costo adicional. 
 
Para obtener una lista de los servicios de Azure que admiten identidades administradas, consulte la 
sección Más información de la unidad Resumen y recursos. 
Hay dos tipos de identidades administradas: asignadas por el sistema y asignadas por el usuario. 
Asignadas por el sistema. Algunos servicios de Azure permiten habilitar una identidad administrada 
directamente en una instancia de servicio. Cuando se habilita una identidad administrada asignada 
por el sistema, se crea una identidad en Azure AD que está vinculada al ciclo de vida de esa instancia 
de servicio. Por tanto, cuando se elimina el recurso, Azure elimina automáticamente la identidad. 
Por diseño, solo ese recurso de Azure puede usar esta identidad para solicitar tokens de Azure AD. 
Asignadas por el usuario. También es posible crear una identidad administrada como un recurso 
independiente de Azure. Una vez que se crea una identidad administrada asignada por el usuario, 
puede asignarla a una o varias instancias de un servicio de Azure. En el caso de las identidades 
administradas asignadas por el usuario, la identidad se administra independientemente de los 
recursos que la utilicen. 
En la tabla siguiente se resumen las diferencias entre las identidades administradas asignadas por el 
sistema y las que están asignadas por el usuario: 
Propiedad 
Identidad administrada 
asignada por el sistema 
Identidad administrada 
asignada por el usuario 
Creación 
Se crea como parte de un 
recurso de Azure (por ejemplo, 
una máquina virtual de Azure 
o Azure App Service). 
Se crea como un recurso de 
Azure independiente. 
Ciclo de vida 
Se comparte el ciclode vida 
con el recurso de Azure. Si se 
elimina el recurso principal, se 
elimina también la identidad 
administrada. 
Ciclo de vida independiente. 
Se debe eliminar 
explícitamente. 
Uso compartido de recursos 
de Azure 
No se puede compartir. Está 
asociada a un único recurso de 
Azure. 
Se puede compartir. Una 
identidad administrada 
asignada por el usuario se 
puede asociar a más de un 
recurso de Azure. 
Casos de uso comunes 
Cargas de trabajo que contiene 
un único recurso de Azure. 
Cargas de trabajo para las que 
necesita identidades 
independientes, como una 
aplicación que se ejecuta en 
una sola máquina virtual. 
Cargas de trabajo que se 
ejecutan en varios recursos y 
que pueden compartir una 
única identidad. Cargas de 
trabajo que necesitan 
autorización previa para un 
recurso seguro como parte de 
un flujo de aprovisionamiento. 
Cargas de trabajo donde los 
recursos se reciclan con 
frecuencia, pero los permisos 
deben permanecer 
coherentes. Por ejemplo, una 
carga de trabajo en la que 
varias máquinas virtuales 
tienen que acceder al mismo 
recurso. 
Dispositivo 
Un dispositivo es un producto de hardware, como los dispositivos móviles, los equipos portátiles, los 
servidores o las impresoras. Una identidad de dispositivo proporciona a los administradores 
información que pueden usar al tomar decisiones de acceso o configuración. Hay varias formas de 
configurar las identidades de dispositivo en Azure AD. 
• Dispositivos registrados en Azure AD. El objetivo de los dispositivos registrados en Azure AD 
es proporcionar a los usuarios la compatibilidad con escenarios Bring Your Own Device 
(BYOD) o de dispositivos móviles. En estos escenarios, el usuario puede acceder a los 
recursos de la organización con un dispositivo personal. Los dispositivos registrados en Azure 
AD se registran sin necesidad de que una cuenta de la organización inicie sesión en el 
dispositivo. Los sistemas operativos compatibles con los dispositivos registrados de Azure AD 
incluyen Windows 10 y versiones posteriores, iOS, Android y macOS. 
• Unido a Azure AD. Un dispositivo unido a Azure AD es el que se une mediante una cuenta de 
la organización, que luego se usa para iniciar sesión en el dispositivo. Los dispositivos unidos 
a Azure AD suelen ser propiedad de la organización. Los sistemas operativos compatibles 
con dispositivos unidos a Azure AD incluyen Windows 10 o versiones posteriores (excepto 
Home Edition) y máquinas virtuales con Windows Server 2019 que se ejecutan en Azure. 
• Dispositivos unidos a Azure AD híbrido. Las organizaciones con implementaciones locales 
de Active Directory existentes se pueden beneficiar de algunas de las funcionalidades 
proporcionadas por Azure AD mediante la implementación de dispositivos unidos a Azure 
AD híbrido. Estos dispositivos están unidos a la instancia local de Active Directory y Azure AD 
exige que la cuenta de la organización inicie sesión en el dispositivo. 
El registro y la unión de dispositivos a Azure AD proporciona a los usuarios el inicio de sesión único 
(SSO) a los recursos en la nube. Además, los dispositivos que están unidos a Azure AD se benefician 
de la experiencia de inicio de sesión único en los recursos y aplicaciones que dependen de la 
instancia de Active Directory local. 
Los administradores de TI pueden usar herramientas como Microsoft Intune, un servicio basado en 
la nube que se centra en la administración de dispositivos móviles (MDM) y la administración de 
aplicaciones móviles (MAM), para controlar cómo se usan los dispositivos de una organización. 
Consulte Microsoft Intune para obtener más información. 
Descripción de los tipos de identidades externas 
Hoy en día el mundo se mueve gracias a la colaboración y al trabajo con personas tanto dentro como 
fuera de su organización. Esto significa que a veces necesitará proporcionar acceso a las aplicaciones 
o a los datos de su organización a usuarios externos. 
Azure AD External Identities es un conjunto de capacidades que permiten a las organizaciones 
permitir el acceso a usuarios externos, como clientes o asociados. Los clientes, asociados y otros 
usuarios invitados pueden "traer sus propias identidades" para iniciar sesión. 
Esta capacidad para los usuarios externos se habilita a través de la compatibilidad de Azure AD con 
proveedores de identidades externos como otros inquilinos de Azure AD, Facebook, Google o 
proveedores de identidades de empresa. Los administradores pueden configurar la federación con 
proveedores de identidades para que los usuarios externos puedan iniciar sesión con sus cuentas 
empresariales o sociales existentes, en lugar de crear una nueva cuenta solo para la aplicación. 
Existen dos identidades externas de Azure AD External Identities: B2B y B2C. 
• La colaboración B2B le permite compartir sus aplicaciones y recursos con usuarios externos. 
• En cambio, B2C es una solución de administración de identidades para aplicaciones de 
consumidor que están orientadas al cliente. 
https://learn.microsoft.com/es-es/mem/intune/fundamentals/what-is-intune
Colaboración B2B 
La colaboración B2B le permite compartir las aplicaciones y los servicios de la organización con 
usuarios invitados de otras organizaciones, a la vez que mantiene el control sobre sus propios datos. 
La colaboración B2B usa un proceso de invitación y canje. También puede habilitar los flujos de 
usuario de registro de autoservicio para permitir que los usuarios externos se suscriban a 
aplicaciones o recursos por sí mismos. Una vez que el usuario externo ha canjeado su invitación o ha 
completado el registro, se representa en el mismo directorio que los empleados, pero con un tipo de 
usuario de invitado. Como invitado, ahora puede acceder a los recursos con sus credenciales. 
Los usuarios invitados pueden administrarse de la misma manera que los empleados, se pueden 
agregar a los mismos grupos, etc. Con B2B, se admite el inicio de sesión único en todas las 
aplicaciones conectadas a Azure AD. 
Administración de acceso de B2C 
Azure AD B2C es una solución de administración de acceso de identidades de cliente (CIAM). Azure 
AD B2C permite a los usuarios externos iniciar sesión con sus identidades de cuenta de redes 
sociales, de empresa o locales preferidas, para obtener un inicio de sesión único en las aplicaciones. 
Azure AD B2C admite millones de usuarios y miles de millones de autenticaciones al día. Asimismo, 
se encarga del escalado y la seguridad de la plataforma de autenticación, de la supervisión y del 
control automático de amenazas, como la denegación del servicio, la difusión de contraseñas o los 
ataques por fuerza bruta. 
Gracias a Azure AD B2C, los usuarios externos se administran en el directorio de Azure AD B2C, de 
forma independiente del directorio de asociados y empleados de la organización. Igualmente, se 
admite el inicio de sesión único para aplicaciones que sean propiedad de los clientes dentro del 
inquilino de Azure AD B2C. 
Azure AD B2C es una solución de autenticación que puede personalizar con su marca para que se 
fusione con sus aplicaciones web y móviles. 
 
Azure AD External Identities es una característica de las ediciones de Azure AD Premium P1 y P2, y 
los precios se basan en función de los usuarios activos mensuales. Para obtener más información, 
consulte Precios de Azure AD. 
Descripción del concepto de identidad híbrida 
Muchas organizaciones son una combinación de aplicaciones locales y en la nube. 
Independientemente de si una aplicación está hospedada en el entorno local o en la nube, los 
usuarios esperan y exigen un acceso sencillo. Las soluciones de identidad de Microsoft abarcan 
funcionalidades locales y basadas en la nube. Estas soluciones crean una identidad de usuario común 
para la autenticación y autorización en todos los recursos, independientemente de la ubicación. A 
esto lo llamamos identidad híbrida. 
Una consideración importante para las organizacionesque operan en un entorno mixto en la nube y 
local (modelo híbrido) consiste en determinar el método de autenticación adecuado para su solución 
de Azure AD. Es una decisión importante en el recorrido de una organización a la nube y sobre cómo 
los usuarios iniciarán sesión y accederán a las aplicaciones. Es la base de la infraestructura de TI 
moderna de la organización sobre la que las organizaciones crearán su solución de seguridad, 
identidad y administración de acceso mediante Azure AD. Por último, una vez que se establece un 
método de autenticación, resulta más difícil de cambiar porque puede interrumpir la experiencia de 
inicio de sesión de los usuarios. En lo que respecta a la autenticación de identidades híbridas, 
Microsoft ofrece varias maneras de autenticarse. 
• Sincronización de hash de contraseña de Azure AD. 
https://azure.microsoft.com/pricing/details/active-directory/external-identities/
• Autenticación transferida de Azure AD 
• Autenticación federada 
Estas opciones de autenticación híbrida, descritas a continuación, necesitan una instancia local de 
Active Directory. Además, se necesita Azure AD Connect, una aplicación de Microsoft local que se 
ejecuta en un servidor y actúa como puente entre Azure AD y la instancia local de Active Directory. 
 
Sincronización de hash de contraseña de Azure AD. La sincronización de hash de contraseña de 
Azure AD es la manera más sencilla de habilitar la autenticación para los objetos de directorio local 
en Azure AD. Los usuarios pueden iniciar sesión en los servicios de Azure AD con el mismo nombre 
de usuario y la misma contraseña que usan para hacerlo en su instancia local de Active Directory. 
Azure AD controla el proceso de inicio de sesión de los usuarios. 
El servicio de dominio de Active Directory (AD DS) almacena contraseñas en forma de 
representación de valor de hash de la contraseña de usuario real. Con la sincronización de hash de 
contraseñas de Azure AD, el hash de contraseña se extrae de la instancia local de Active Directory 
mediante Azure AD Connect. Se aplica seguridad adicional al hash de contraseña y, después, se 
sincroniza con el servicio de autenticación de Azure Active Directory. Cuando un usuario intenta 
iniciar sesión en Azure AD y escribe su contraseña, la contraseña se ejecuta con el mismo algoritmo 
de hash y seguridad adicional que se ha aplicado a la versión almacenada en Azure AD, como parte 
de la sincronización. Si el resultado coincide con el valor de hash almacenado en Azure AD, el usuario 
ha escrito la contraseña correcta y se autentica. 
Con la sincronización de hash de contraseña, Azure AD Connect garantiza que el hash de contraseña 
se sincronice entre la instancia local de Active Directory y Azure AD. Esto permite que la 
autenticación del usuario se realice en Azure AD, y no en la propia instancia de Active Directory de la 
organización. Una ventaja de este enfoque es que la sincronización de hash de contraseña 
proporciona autenticación en la nube de alta disponibilidad. Los usuarios locales pueden 
autenticarse con Azure AD para acceder a aplicaciones basadas en la nube, incluso si la instancia 
local de Active Directory deja de funcionar. 
 
Autenticación de paso a través de Azure AD. La autenticación transferida de Azure AD permite a los 
usuarios iniciar sesión en aplicaciones locales y basadas en la nube con las mismas contraseñas, 
como la sincronización de hash de contraseña. Pero una diferencia clave es que cuando los usuarios 
inician sesión con la autenticación transferida de Azure AD, las contraseñas se validan directamente 
en la instancia local de Active Directory. La validación de las contraseñas no se produce en la nube. 
Esto puede ser un factor importante para las organizaciones que quieran aplicar sus directivas de 
seguridad y contraseñas de Active Directory locales. 
La autenticación transferida de Azure AD también usa Azure AD Connect, pero tiene el requisito 
adicional de ejecutar uno o varios agentes de autenticación. Estos agentes actúan como 
intermediario entre Azure AD y la instancia local de Active Directory en el proceso de autenticación 
de los usuarios. 
Cuando un usuario intenta acceder a una aplicación en la que todavía no ha iniciado sesión, se le 
redirigirá a la página de inicio de sesión de Azure AD para que escriba su nombre de usuario y 
contraseña. Azure AD cifrará la contraseña de usuario con la clave pública del Agente de 
autenticación. El Agente de autenticación local recupera el nombre de usuario y la contraseña 
cifrada de Azure AD, descifra la contraseña con su clave privada y valida el nombre de usuario y la 
contraseña en Active Directory. Active Directory evalúa la solicitud y proporciona una respuesta 
(correcto, error, contraseña expirada o usuario bloqueado) al agente, que luego se lo notifica a 
Azure AD. Si la respuesta indica que el proceso se ha realizado correctamente, Azure AD responderá 
con la autenticación del usuario. 
El uso de agentes de autenticación que se ejecutan en un servidor significa que se necesita una 
superficie de infraestructura mayor, en comparación con la sincronización de hash de contraseña. 
Además, como la autenticación transferida se valida en la instancia local de Active Directory con 
dependencia de agentes de autenticación que se ejecutan en servidores, se debe tener en cuenta el 
software distribuido, redundante y el hardware para proporcionar solicitudes de inicio de sesión de 
alta disponibilidad. De lo contrario, si el centro de datos sufre una interrupción, la autenticación en 
los servicios de Microsoft 365 ya no sería posible. 
 
Autenticación federada. La federación se recomienda como autenticación para las organizaciones 
que tienen características avanzadas que no se admiten actualmente en Azure AD, incluido el inicio 
de sesión con tarjetas inteligentes o certificados, con un servidor local de autenticación multifactor 
(MFA) o mediante una solución de autenticación de terceros. 
En la autenticación federada, Azure AD delega el proceso de autenticación a un sistema 
independiente de autenticación de confianza como, por ejemplo, una instancia local de Servicios de 
federación de Active Directory (AD FS), para validar la contraseña del usuario. Este método de inicio 
de sesión garantiza que toda la autenticación de usuarios tiene lugar de forma local. 
La autenticación federada usa Azure AD Connect, pero también necesita servidores adicionales para 
admitir la federación, lo que da lugar a una superficie de infraestructura mayor. 
Las organizaciones que deciden usar la federación con Servicios de federación de Active Directory 
(AD FS) tienen la posibilidad de configurar la sincronización de hash de contraseña como copia de 
seguridad en caso de error en la infraestructura de AD FS. 
 
Describir los métodos de autenticación de Azure AD 
 
 
Completado 100 XP 
 
 
 
• 10 minutos 
• 
 
Una de las principales características de una plataforma de identidad es comprobar, o autenticar, las 
credenciales cuando un usuario inicia sesión en un dispositivo, una aplicación o un servicio. Azure AD 
ofrece distintos métodos de autenticación. 
Contraseñas 
Las contraseñas son la forma más común de autenticación, pero tienen muchos problemas, 
especialmente si se usan en la autenticación de un solo factor, donde solo se usa una forma de 
autenticación. Si son bastante fáciles de recordar, un hacker podrá vulnerarlas fácilmente. Las 
contraseñas seguras que no son fáciles de atacar son difíciles de recordar, y afectan a la 
productividad de los usuarios cuando las olvidan. 
El uso de contraseñas debe complementarse o reemplazarse por métodos de autenticación más 
seguros disponibles en Azure AD. 
 
Teléfono 
Azure AD admite dos opciones para la autenticación basada en teléfono. 
• Autenticación basada en SMS. El servicio de mensajes cortos (SMS) usado en la mensajería 
de texto del dispositivomóvil se puede usar como forma principal de autenticación. Con el 
inicio de sesión basado en SMS, los usuarios no necesitan conocer un nombre de usuario y 
una contraseña para acceder a las aplicaciones y servicios. En su lugar, el usuario escribe su 
número de teléfono móvil registrado, recibe un mensaje de texto con un código de 
verificación, y escribe el código en la interfaz de inicio de sesión. 
• Los usuarios también pueden optar por comprobar su identidad a través de la mensajería de 
texto SMS en un teléfono móvil, como forma secundaria de autenticación durante el 
autoservicio de restablecimiento de contraseña (SSPR) o Azure AD Multi-Factor 
Authentication. Por ejemplo, los usuarios pueden complementar su contraseña mediante la 
mensajería de texto SMS. Se envía un SMS al número de teléfono móvil con un código de 
verificación. Para completar el proceso de inicio de sesión, el código de verificación 
entregado debe introducirse en la interfaz de inicio de sesión. 
• Comprobación por llamada de voz. Los usuarios pueden usar llamadas de voz como forma 
secundaria de autenticación, para comprobar su identidad, durante el autoservicio de 
restablecimiento de contraseña (SSPR) o Azure AD Multi-Factor Authentication. Con la 
verificación por llamada telefónica, se hace una llamada de voz automatizada al número de 
teléfono registrado por el usuario. Para completar el proceso de inicio de sesión, se le pide al 
usuario que presione # en el teclado. Las llamadas de voz no se admiten como una forma 
principal de autenticación en Azure AD. 
OATH 
OATH (Open Authentication) es un estándar abierto que especifica cómo se generan los códigos de 
contraseña de un solo uso y duración definida (TOTP). Los códigos de contraseña de un solo uso se 
pueden usar para autenticar a un usuario. Los TOTP de OATH se implementan mediante software o 
hardware para generar los códigos. 
• Los tokens de software OATH suelen ser aplicaciones. Azure AD genera la clave secreta, o 
valor de inicialización, que se introduce en la aplicación y se usa para generar cada OTP. 
• Los tokens de hardware OATH TOTP (compatibles con la versión preliminar pública) son 
dispositivos de hardware pequeños que parecen un fob de clave que muestra un código que 
se actualiza cada 30 o 60 segundos. Los tokens de hardware TOTP de OATH suelen incluir 
una clave secreta, o valor de inicialización, programada previamente en el token. Estas 
claves y otra información específica de cada token deben introducirse en Azure AD y, a 
continuación, activarse para su uso por parte de los usuarios finales. 
Los tokens de hardware y software OATH solo se admiten como formas secundarias de 
autenticación en Azure AD para comprobar una identidad durante el autoservicio de 
restablecimiento de contraseña (SSPR) o Azure AD Multi-Factor Authentication. 
Autenticación sin contraseñas 
En muchas organizaciones, el objetivo final es eliminar el uso de contraseñas como parte de los 
eventos de inicio de sesión. Cuando un usuario inicia sesión con un método sin contraseña, las 
credenciales se proporcionan mediante el uso de métodos como la información biométrica en 
Windows Hello para empresas o una clave de seguridad FIDO2. Un atacante no puede duplicar 
fácilmente estos métodos de autenticación. 
Azure AD ofrece formas de autenticación nativa sin contraseña con el fin de simplificar la experiencia 
de inicio de sesión de los usuarios y reducir el riesgo de ataques. 
En el vídeo siguiente se explica el problema de las contraseñas y por qué es tan importante la 
autenticación sin contraseña. 
Windows Hello para empresas 
Windows Hello para empresas reemplaza las contraseñas con una autenticación de dos factores 
sólida en dispositivos. Esta autenticación en dos fases es una combinación de una clave o un 
certificado vinculado a un dispositivo y algo que la persona conoce (un PIN) o algo que la persona es 
(biometría). La entrada de PIN y el gesto biométrico desencadenan el uso de la clave privada para 
firmar criptográficamente los datos que se envían al proveedor de identidades. El proveedor de 
identidades comprueba la identidad del usuario y autentica al usuario. 
Windows Hello para empresas ayuda a protegerse contra el robo de credenciales, ya que un 
atacante debe tener tanto el dispositivo como la información biométrica o el PIN, lo que dificulta el 
acceso sin el conocimiento del empleado. 
Como método de autenticación sin contraseña, Windows Hello para empresas actúa como forma 
principal de autenticación. Además, Windows Hello para empresas se puede usar como forma 
secundaria de autenticación para comprobar una identidad durante la autenticación multifactor. 
FIDO2 
Fast Identity Online (FIDO) es un estándar abierto para la autenticación sin contraseña. FIDO permite 
a los usuarios y a las organizaciones aprovechar el estándar para iniciar sesión en sus recursos 
mediante una clave de seguridad externa o una clave de plataforma integrada en un dispositivo, lo 
que elimina la necesidad de usar usuario y contraseña. 
FIDO2 es el estándar más reciente que incorpora el estándar de autenticación web (WebAuthn) y es 
compatible con Azure AD. Las claves de seguridad FIDO2 son un método de autenticación sin 
contraseña basado en estándares que no permite la suplantación de identidad y que puede venir en 
cualquier factor de forma. Estas claves de seguridad FIDO2 suelen ser dispositivos USB, pero también 
pueden ser dispositivos basados en Bluetooth o comunicación de campo cercano (NFC), que se usan 
para la transferencia de datos inalámbricas de corto alcance. Con un dispositivo de hardware que 
controla la autenticación, se aumenta la seguridad de una cuenta, ya que no hay ninguna contraseña 
que pueda quedar expuesta ni adivinarse. 
Con las claves de seguridad FIDO2, los usuarios pueden iniciar sesión en dispositivos Windows 10 
unidos a Azure AD o Azure AD híbrido y lograr el inicio de sesión único en sus recursos de nube y 
locales. Los usuarios también pueden iniciar sesión en exploradores compatibles. Las claves de 
seguridad FIDO2 son una excelente opción para las empresas que son muy conscientes de la 
seguridad o tienen escenarios o empleados que no quieren o no pueden usar su teléfono como un 
segundo factor. 
Como método de autenticación sin contraseña, FIDO2 actúa como forma principal de autenticación. 
Además, FIDO2 se puede usar como forma secundaria de autenticación para comprobar una 
identidad durante la autenticación multifactor. 
Aplicación Microsoft Authenticator 
Como método de autenticación sin contraseña, la aplicación Microsoft Authenticator se puede usar 
como forma principal de autenticación para iniciar sesión en cualquier cuenta de Azure AD o como 
opción de verificación adicional durante el autoservicio de restablecimiento de contraseña (SSPR) o 
Azure AD eventos de Multi-Factor Authentication. 
Para usar Microsoft Authenticator, un usuario debe descargar la aplicación de teléfono desde 
Microsoft Store y registrar su cuenta. Microsoft Authenticator está disponible para Android e iOS. 
Con la información de inicio de sesión, la aplicación Authenticator convierte cualquier teléfono 
Android o iOS en una credencial segura sin contraseña. Para iniciar sesión en su cuenta de Azure AD, 
un usuario escribe su nombre de usuario, coincide con un número mostrado en la pantalla en el que 
se encuentra en su teléfono y, a continuación, usa su biométrica o PIN para confirmar. 
 
Cuando un usuario elige Authenticator como método de autenticación secundario, para verificar su 
identidad, se envía una notificación push al teléfono o tableta. Si la notificación es legítima, el 
usuario selecciona Aprobar; de lo contrario, selecciona Denegar. 
 
Describir la autenticación multifactor (MFA) en Azure AD 
La autenticación multifactor requiere más de una forma de comprobación para demostrar que una 
identidad es legítima, como un dispositivo de confianzao una detección de huellas digitales. Esto 
implica que, aunque la contraseña de una identidad se haya puesto en peligro, un hacker no podrá 
acceder al recurso. 
La autenticación multifactor mejora drásticamente la seguridad de las identidades, a la vez que sigue 
siendo simple para los usuarios. El factor de autenticación adicional debe ser algo difícil de obtener o 
duplicar para un atacante. 
El funcionamiento de la autenticación multifactor de Azure Active Directory solicita lo siguiente: 
• Algo que sabe: normalmente una contraseña o un PIN y 
• Algo que tiene: como un dispositivo de confianza que no se duplica fácilmente; por ejemplo, 
un teléfono o una clave de hardware, o 
• Algo que forma parte de usted: información biométrica como una huella digital o una 
detección de rostro. 
Las solicitudes de comprobación de la autenticación multifactor están configuradas para formar 
parte del evento de inicio de sesión en Azure AD. Azure AD solicita y procesa automáticamente la 
autenticación multifactor, sin realizar cambios en las aplicaciones o servicios. Cuando un usuario 
inicia sesión, recibe una solicitud de autenticación multifactor y puede elegir una de las formas de 
verificación adicionales que haya registrado. 
Un administrador puede requerir ciertos métodos de comprobación, o el usuario puede acceder a la 
sección Mi cuenta para editar o agregar métodos de comprobación. 
Las siguientes formas adicionales de verificación, descritas en la unidad anterior, se pueden usar con 
la autenticación multifactor de Azure AD: 
• Aplicación Microsoft Authenticator 
• Windows Hello para empresas 
• Clave de seguridad FIDO2 
• Token de hardware OATH (versión preliminar) 
• Token de software OATH 
• sms 
• Llamada de voz 
 
Valores predeterminados de seguridad y autenticación multifactor 
Los valores predeterminados de seguridad son un conjunto de mecanismos de seguridad de 
identidad básicos recomendados por Microsoft. Cuando estén habilitadas, estas recomendaciones se 
aplicarán automáticamente en su organización. El objetivo es asegurarse de que todas las 
organizaciones gocen de un nivel básico de seguridad sin ningún costo adicional. Estos valores 
predeterminados habilitan algunas de las características y controles de seguridad más comunes, 
entre los que se incluyen los siguientes: 
• Aplicar el registro de autenticación multifactor de Azure Active Directory para todos los 
usuarios. 
• Forzar a los administradores a usar la autenticación multifactor. 
• Requerir a todos los usuarios que realicen la autenticación multifactor cuando sea necesario. 
Los valores predeterminados de seguridad son una excelente opción para las organizaciones que 
quieren aumentar su posición de seguridad, pero no saben por dónde empezar; o para las 
organizaciones que usan el nivel Gratis de licencias de Azure AD. Los valores predeterminados de 
seguridad podrían no ser adecuados para las organizaciones con licencias Premium de Azure AD, o 
con requisitos de seguridad más complejos. Para más información, visite ¿Cuáles son los valores de 
seguridad predeterminados? 
Descripción del autoservicio de restablecimiento de contraseña (SSPR) en Azure AD 
 
 
Completado 100 XP 
 
 
 
• 6 minutos 
• 
 
El autoservicio de restablecimiento de contraseña (SSPR) es una característica de Azure AD que 
permite a los usuarios cambiar o restablecer su contraseña, sin necesidad de que intervenga el 
administrador o el departamento de soporte técnico. 
Si la cuenta de un usuario está bloqueada o se ha olvidado de la contraseña, puede seguir la 
indicación para restablecerla y volver al trabajo. Esta capacidad reduce las llamadas al departamento 
de soporte técnico y la pérdida de productividad cuando un usuario no puede iniciar sesión en su 
dispositivo o en una aplicación. 
El autoservicio de restablecimiento de contraseña funciona en los siguientes escenarios: 
• Cambio de contraseña: el usuario conoce la contraseña, pero quiere cambiarla por una 
nueva. 
• Restablecimiento de contraseña: el usuario no puede iniciar sesión, por ejemplo, cuando ha 
olvidado la contraseña, y quiere restablecerla. 
• Desbloqueo de cuenta: el usuario no puede iniciar sesión porque su cuenta está bloqueada. 
Para usar el autoservicio de restablecimiento de contraseña, los usuarios deben cumplir lo siguiente: 
• Tener asignada una licencia de Azure AD. Consulte la sección Más información de la unidad 
de resumen y recursos para obtener un vínculo a los requisitos de licencia para el 
autoservicio de restablecimiento de contraseña de Azure Active Directory. 
• Estar habilitados para SSPR por un administrador. 
• Estar registrado con los métodos de autenticación que quieren usar. Se recomiendan dos o 
más métodos de autenticación en caso de que uno no esté disponible. 
Están disponibles los siguientes métodos de autenticación: 
• Notificación en aplicación móvil 
• Código de aplicación móvil 
• Email 
• Teléfono móvil 
• Teléfono del trabajo 
https://learn.microsoft.com/es-es/azure/active-directory/fundamentals/concept-fundamentals-security-defaults
https://learn.microsoft.com/es-es/azure/active-directory/fundamentals/concept-fundamentals-security-defaults
• Preguntas de seguridad 
Cuando los usuarios se registren en SSPR, se les pedirá que elijan los métodos de autenticación que 
usarán. Si optan por usar preguntas de seguridad, pueden elegir entre un conjunto de preguntas 
para que se muestren y, a continuación, proporcionar sus propias respuestas. Las preguntas de 
seguridad se pueden usar solo durante el proceso de autoservicio de restablecimiento de contraseña 
(SSPR) para confirmar quién es. Las preguntas de seguridad no se usan como método de 
autenticación durante un evento de inicio de sesión. Las cuentas de administrador no pueden usar 
preguntas de seguridad como método de verificación con SSPR. 
Nota 
De manera predeterminada, las cuentas de administrador están habilitadas para el autoservicio de 
restablecimiento de contraseña y deben usar dos métodos de autenticación para restablecer su 
contraseña, como una dirección de correo electrónico, una aplicación de autenticador o un número 
de teléfono. Los administradores no tienen la posibilidad de usar preguntas de seguridad. 
Cuando un usuario restablece su contraseña mediante el autoservicio de restablecimiento de 
contraseña, dicha contraseña también puede reescribirse en una instancia de Active Directory local. 
La reescritura de contraseñas permite a los usuarios usar sus credenciales actualizadas con las 
aplicaciones y dispositivos locales sin ninguna demora. 
Para mantener a los usuarios informados sobre la actividad de la cuenta, los administradores pueden 
configurar las notificaciones de correo electrónico que se enviarán cuando se produzca un evento de 
SSPR. Estas notificaciones pueden abarcar tanto las cuentas de usuario normales como las cuentas 
de administrador. En el caso de las cuentas de administrador, esta notificación ofrece una capa 
adicional de reconocimiento cuando se restablece la contraseña de una cuenta de administrador con 
privilegios mediante SSPR. Todos los administradores globales recibirán una notificación cuando se 
utilice SSPR en una cuenta de administrador. 
En esta guía interactiva, habilitará el autoservicio de restablecimiento de contraseña para los 
usuarios de Azure Active Directory. Seleccione la imagen siguiente para empezar y siga las 
indicaciones que aparecen en pantalla. 
Descripción de las funcionalidades de administración y protección de contraseñas de Azure AD 
es una característica de Azure AD que reduce el riesgo de que los usuarios establezcan contraseñas 
no seguras. La característica Protección de contraseñas de Azure AD detecta y bloquea las 
contraseñas no seguras conocidas y sus variantes;además, puede bloquear otros términos poco 
seguros específicamente para la organización. 
Con Protección con contraseñade Azure AD, se aplican automáticamente listas globales de 
contraseñas prohibidas a todos los usuarios de un inquilino de Azure AD. Para satisfacer sus 
necesidades empresariales y de seguridad, puede definir entradas en una lista personalizada de 
contraseñas prohibidas. Cuando los usuarios cambian o restablecen sus contraseñas, se consultan 
estas listas para exigir el uso de contraseñas seguras. 
Debe usar características adicionales, como la autenticación multifactor de Azure Active Directory y 
no confiar solo en las contraseñas seguras aplicadas por Protección de contraseñas de Azure AD. 
Lista global de contraseñas prohibidas 
Microsoft actualiza y aplica automáticamente una lista global de contraseñas prohibidas que incluye 
contraseñas no seguras conocidas. Esta lista la mantiene el equipo de Azure AD Identity Protection, 
que analiza los datos de telemetría de seguridad para buscar contraseñas poco seguras o vulneradas. 
Algunos ejemplos de contraseñas que podrían estar bloqueadas son P@$$w0rd o Passw0rd1 y todas 
sus variaciones. 
Las variaciones se crean mediante un algoritmo que transpone mayúsculas y minúsculas, así como 
letras a números; por ejemplo, "1" a "l". Las variaciones de Password1 pueden incluir a Passw0rd1, 
Pass0rd1 y otras. A continuación, estas contraseñas se comprueban y se agregan a la lista global de 
contraseñas prohibidas y se ponen a disposición de todos los usuarios de Azure AD. La lista global de 
contraseñas prohibidas se aplica automáticamente y no se puede deshabilitar. 
Si un usuario de Azure AD intenta usar como contraseña una de estas contraseñas no seguras, 
recibirá una notificación para elegir otra más segura. La lista global prohibida se crea a partir de 
ataques de difusión de contraseñas reales. Este enfoque mejora la seguridad y eficacia generales, y 
el algoritmo de validación de contraseñas también usa técnicas inteligentes de coincidencia 
aproximada que se usan para buscar cadenas que coincidan aproximadamente con un patrón. 
Protección de contraseñas de Azure AD detecta y bloquea de manera eficaz millones de las 
contraseñas poco seguras más comunes que se usan en su empresa. 
Listas personalizadas de contraseñas prohibidas 
Los administradores también pueden crear listas personalizadas de contraseñas prohibidas para 
satisfacer necesidades específicas de seguridad empresarial. La lista personalizada de contraseñas 
prohibidas impide el uso de contraseñas como el nombre o la ubicación de la organización. Las 
contraseñas agregadas a la lista personalizada de contraseñas prohibidas deben centrarse en 
términos específicos de la organización, como: 
• Nombres de marca 
• Nombres de producto 
• Ubicaciones, por ejemplo, la oficina central de la empresa 
• Términos internos específicos de la empresa 
• Abreviaturas que tienen un significado específico en la empresa 
La lista personalizada de contraseñas prohibidas se combina con la lista global de contraseñas 
prohibidas para bloquear las variaciones de todas las contraseñas. 
Las listas de contraseñas prohibidas son una característica de Azure AD Premium 1 o 2. 
Protección contra la difusión de contraseñas 
Protección con contraseña de Azure AD le ayuda a defenderse contra los ataques de difusión de 
contraseña. La mayoría de los ataques de difusión de contraseñas envían solo algunas de las 
contraseñas menos seguras conocidas en cada una de las cuentas de una empresa. Esta técnica 
permite al atacante buscar rápidamente una cuenta en peligro y evitar posibles umbrales de 
detección. 
Protección con contraseña de Azure AD bloquea de forma eficaz todas las contraseñas no seguras 
conocidas que se puedan usar en los ataques de difusión de contraseña. Esta protección se basa en 
los datos de telemetría de seguridad del mundo real que genera Azure AD, los cuales se usan para 
crear la lista global de contraseñas prohibidas. 
Seguridad híbrida 
Si busca seguridad híbrida, los administradores pueden integrar la Protección de contraseñas de 
Azure AD en un entorno de Active Directory local. Un componente instalado en el entorno local 
recibe la lista global de contraseñas prohibidas y las directivas personalizadas de protección de 
contraseñas de Azure AD. A continuación, los controladores de dominio las usan para procesar los 
eventos de cambio de contraseña. Este enfoque híbrido garantiza que, siempre que un usuario 
cambie su contraseña, se aplique la Protección de contraseñas de Azure AD. 
Aunque la protección de contraseñas mejora la seguridad de las contraseñas, debe seguir usando las 
características recomendadas, como la autenticación multifactor de Azure Active Directory. Las 
contraseñas por sí solas, incluso las seguras, no lo protegerán tanto como varias capas de seguridad. 
Descripción del acceso condicional en Azure AD 
El acceso condicional es una característica de Azure AD que proporciona una capa de seguridad 
adicional antes de permitir que los usuarios autenticados tengan acceso a los datos o a otros 
recursos. El acceso condicional se implementa a través de las directivas que se crean y administran 
en Azure AD. Una directiva de acceso condicional analiza las señales que incluyen el usuario, la 
ubicación, el dispositivo, la aplicación y el riesgo para automatizar las decisiones de autorización de 
acceso a los recursos (aplicaciones y datos). 
 
Es posible que una directiva de acceso condicional indique que si un usuario pertenece a un grupo 
determinado, se le pida que proporcione autenticación multifactor para iniciar sesión en una 
aplicación. 
Vea el vídeo para descubrir cómo funcionan las directivas de acceso condicional. 
Señales de acceso condicional 
Entre algunas de las señales comunes que puede tener en cuenta el acceso condicional al tomar una 
decisión sobre una directiva se pueden incluir las siguientes: 
• Pertenencia a grupo o usuario. Las directivas se pueden dirigir a todos los usuarios, grupos 
específicos de usuarios, roles de directorio o usuarios invitados externos, lo que proporciona 
a los administradores un control específico sobre el acceso. 
• Información de la ubicación con nombre. La información de ubicación con nombre se puede 
crear con intervalos IP y usarse al tomar decisiones relacionadas con las directivas. Además, 
los administradores pueden optar por bloquear o permitir el tráfico desde el intervalo IP de 
todo un país o una región. 
• Dispositivo. Se pueden usar los usuarios con dispositivos de plataformas específicas o 
marcados con un estado específico. 
• Aplicación. Los usuarios que intentan acceder a aplicaciones específicas pueden 
desencadenar distintas directivas de acceso condicional. 
• Detección de riesgo de inicio de sesión en tiempo real. La integración de señales con Azure 
AD Identity Protection permite que las directivas de acceso condicional identifiquen el 
comportamiento de riesgo de inicio de sesión, la probabilidad de que un inicio de sesión 
determinado o una solicitud de autenticación, no estén autorizados por el propietario de la 
identidad. Luego, las directivas pueden obligar a los usuarios a realizar cambios de 
contraseña o a usar la autenticación multifactor para reducir su nivel de riesgo, o a bloquear 
su acceso hasta que algún administrador lleve a cabo una acción manual. 
• Acciones o aplicaciones en la nube. Las aplicaciones o acciones en la nube pueden incluir o 
excluir las aplicaciones en la nube o acciones del usuario que estarán sujetas a la directiva. 
• Riesgo de usuario. En el caso de los clientes con acceso a Identity Protection, el riesgo del 
usuario se puede evaluar como parte de una directiva de acceso condicional. Un riesgo de 
usuario representa la probabilidad de que una identidad o cuenta determinada esté en 
peligro. El riesgo de los usuarios se puede configurar para una probabilidad alta, media o 
baja. 
Al crear una directiva de acceso condicional, los administradores pueden determinar qué