En este módulo, veremos las tres A de la seguridad,

a saber: autenticación, autorización y auditoría.

Veremos exactamente qué son,
cómo se relacionan entre sí,
y sus implementaciones y protocolos comunes.
Vamos a empezar con la autenticación
y, por extensión, la identificación.
Debes estar familiarizado con la autenticación
en la forma de problemas de nombre de usuario y contraseña al acceder a cosas como tu
correo electrónico.
Tomemos esto de ejemplo para mostrar
las diferencias entre identificación y autenticación.
La identificación es la idea de describir una entidad de forma única.
Por ejemplo, tu dirección de correo electrónico es tu identidad al acceder a él.
Pero ¿cómo haces para demostrar que eres quien dices ser?
Ese es el proceso que llamamos autenticación.
Al acceder a tu correo electrónico,
afirmas ser tu dirección de correo electrónico,
y proporcionas una contraseña asociada con la identidad para demostrar que eres tú,
o que al menos conoces la contraseña asociada con la cuenta de correo electrónico.
Bastante sencillo, ¿verdad?
Esto es claramente diferente de la autorización,
que se relaciona con los recursos a los que una identidad tiene acceso.
Estos dos conceptos se distinguen entre sí en el mundo de la seguridad
con los términos "authn" para autenticación y "authz" para autorización.
En nuestro ejemplo de acceso a la cuenta de correo electrónico
mediante autenticación con tu dirección de correo electrónico y contraseña,
tu identidad está autorizada para acceder a tu bandeja de entrada de correo electrónico,
pero no estás autorizado para acceder a la bandeja de entrada de nadie más.
Realmente no queremos que nadie más acceda a nuestra bandeja de entrada, ¿verdad?
Entonces, ¿qué podemos hacer para asegurarnos de que solo nosotros somos capaces
de identificar y autenticar como nuestra cuenta de correo electrónico?
Podríamos comenzar usando una contraseña segura.
Pero ¿qué constituye exactamente una contraseña segura?
Bueno, ¿qué piensas de la contraseña "ponies"?
¿La clasificarías como una contraseña segura? Espero que no.
Esa contraseña es súper corta,
solo tiene seis caracteres
y todos ellos son letras minúsculas.
Esta es una contraseña corta y simple,
que podría vulnerarse fácilmente a través de ataques de fuerza bruta o basados en
diccionario.
"Ponies" casi con seguridad estaría en un archivo de diccionario,
y seis caracteres no ofrecen un gran conjunto de posibilidades, por lo que un atacante lo
intentaría.
Podemos garantizar que una contraseña sea segura al hacerla más larga y compleja
agregándole números, letras mayúsculas,
y caracteres especiales como los de puntuación.
¿Qué opinas de la seguridad de esta contraseña?
Eso parece mucho más seguro, ¿no?
Agrega complejidad, lo que aumenta el conjunto de contraseñas posibles,
y tiene más de 10 caracteres.
¿Pero cuál de estas dos contraseñas crees que podrías recordar mañana?
Probablemente no la más segura, ¿verdad?
Esto resalta un concepto muy importante en seguridad.
A menudo hay una compensación entre la seguridad y la usabilidad.
En nuestro ejemplo de contraseñas,
la más fácil de usar y de memorizar es menos segura,
mientras que la contraseña más segura es mucho más difícil de recordar.
Este concepto se aplica a muchos otros temas de seguridad, no solo a las contraseñas.
Puedes pensar en la seguridad como en la mitigación de riesgos,
y en lo que se refiere a mitigar riesgos,
es imposible eliminar el riesgo por completo.
Lo mejor que puedes hacer es entender los riesgos que enfrentan tus sistemas,
tomar medidas para reducir esos riesgos y supervisarlos.
Míralo de esta manera:
el sistema informático más seguro es el que está desconectado de todo,
incluidas la red y la alimentación, y está bajo llave
en un búnker de hormigón a cientos de metros bajo tierra, al que nadie tiene acceso.
Si bien esta es una máquina increíblemente segura,
casi imposible de poner en riesgo,
básicamente es inútil, ya que está apagada y nadie puede acceder a ella.
Este es un ejemplo extremo de seguridad
en contraposición con usabilidad, pero entiendes a lo que me refiero.
De regreso a nuestro ejemplo de contraseña,
obviamente necesitamos encontrar algún tipo de equilibrio
en el que tengamos una contraseña razonablemente segura que también sea algo fácil de
memorizar.
¿Qué tal algo como esto?
Comenzamos con una frase corta, "Ilikeponies",
luego reemplazamos algunas letras con números
que se asemejan a las letras para facilitar la memorización.
También intercambiamos la S con la Z,
ya que suenan parecido, y agregamos algunos números como sufijo.
A primera vista, parece una contraseña muy compleja y difícil de memorizar,
pero es más sencilla que un ejemplo de contraseña aleatoria. Problema resuelto,
¿verdad?
Bueno, en realidad deberías desconfiar de este proceso de sustitución de números,
ya que es muy conocido por los atacantes y las herramientas de descifrado de
contraseñas. Como especialista
en soporte de TI, asegurarte de que tu organización use contraseñas seguras
y que practique una buena higiene de contraseñas es muy importante.
Literalmente, son las llaves del reino.
¿Entonces, qué debemos hacer? Adoptar buenas políticas de contraseñas
en una organización es clave para garantizar
que los empleados están protegiendo sus cuentas con contraseñas seguras.
Un buen sistema de política de contraseñas haría cumplir requisitos de longitud
y complejidad de caracteres, y comprobaría la presencia de palabras del diccionario,
lo que socavaría la seguridad de las contraseñas.
Las contraseñas nunca deben escribirse o grabarse en texto sin formato,
reutilizarse en diferentes cuentas o compartirse.
Reutilizar la contraseña es un riesgo
porque si la contraseña es puesta en riesgo en una cuenta,
otras cuentas que usen la misma contraseña también estarían en riesgo.
Compartir contraseñas también debería estar prohibido,
ya que esto socava la identidad de una cuenta
porque, ahora, alguien más tiene la capacidad de acceder como ese usuario.
Junto con requerir el uso de contraseñas seguras,
también se recomienda una política de rotación de contraseñas,
ya que protege contra posibles contraseñas en riesgo no detectadas.
Pero es importante que el período de rotación de contraseña no sea demasiado corto.
¿Por qué? El inconveniente de tener que cambiar las contraseñas muy a menudo
puede, en realidad, alentar un mal comportamiento de seguridad de los usuarios.
Supongamos que requieres que tu organización
cree contraseñas altamente complejas y que las cambie cada tres meses.
Es muy probable que un porcentaje significativo de usuarios
anote sus contraseñas en notas adhesivas o en sus teléfonos.
Un "no" gigante. A pesar de que la política está diseñada para aumentar la seguridad,
en realidad, tiene el efecto contrario debido a los inconvenientes que causa a sus
usuarios.
En el último video, aprendimos sobre la autenticación básica
en la forma de nombre de usuario/contraseña, a veces denominada autenticación de un
solo factor.
Pero hay otros mecanismos de autenticación más complejos y seguros.
Ten en cuenta la compensación de seguridad frente a usabilidad
a medida que vayamos viendo los diferentes tipos de autenticación multifactor.
La autenticación multifactor es un sistema en el que los usuarios
se autentican mediante la presentación de múltiples piezas de información u objetos.
Los diversos factores que componen
un sistema de autenticación multifactor se puede clasificar en tres tipos:
algo que sabes, algo que tienes y algo que eres.
De manera ideal, un sistema multifactor incorporará al menos dos de estos factores.
Algo que sabes sería algo como una contraseña
o un PIN para tu tarjeta bancaria o de cajero automático.
Algo que tienes sería una prenda física o token
como tu tarjeta bancaria o de cajero automático.
Algo que eres sería una pieza de datos biométricos,
como una huella digital o el escaneo del iris.
La premisa por detrás de la autenticación multifactor es que, para un atacante,
resultará mucho más difícil de robar o clonar múltiples factores de autenticación,
suponiendo que se usen diferentes tipos de ellos.
Si se usan múltiples contraseñas,
la seguridad no se ve reforzada por eso.
Esto es porque las contraseñas, por muchas que sean,
siguen siendo susceptibles a los ataques de suplantación de identidad o registro de
teclas.
Usar una contraseña junto con un token de seguridad cambia radicalmente el panorama.
Aun cuando la contraseña se vea en riesgo debido a un ataque de suplantación de
identidad,
el atacante también necesitaría robar o clonar
el token físico para poder acceder a la cuenta.
Y eso es mucho menos probable que suceda.
No volveremos a hablar de contraseñas aquí,
ya hablamos de ellas en detalle en la última sección.
Un resumen rápido:
los tokens físicos pueden tomar diferentes formas.
Los más comunes incluyen un dispositivo USB con un token secreto,
un dispositivo independiente que genera un token
o incluso una simple llave usada con una cerradura tradicional.
Un token físico comúnmente usado genera un token de corta duración,
por lo general, un número que se ingresa junto con un nombre de usuario y contraseña.
Este número toma el nombre común de contraseña por única vez (OTP),
ya que es de corta duración y tiene un valor en constante cambio.
Un ejemplo de esto es el token RSA SecurID.
Es un dispositivo pequeño, alimentado por batería, con una pantalla LCD,
que muestra una contraseña por única vez que se rota periódicamente.
Este es un token basado en el tiempo, lo que a veces se denomina TOTP,
y funciona mediante un valor de inicialización secreto
o valor generado aleatoriamente en el token, que está registrado con el servidor de
autenticación.
El valor de inicialización se usa
junto con la hora actual para generar una contraseña por única vez.
Ahora, mientras el usuario tenga posesión de su token
o pueda ver la pantalla del token,
puede iniciar sesión.
También debería señalar que el esquema requiere que el tiempo entre el token del
autenticador
y el servidor de autenticación esté relativamente sincronizado.
Esto generalmente se logra por medio del Protocolo de tiempo de red o NTP.
Un atacante tendría que robar el token físico
o clonarlo si puede robar el valor de inicialización secreto.
Dado que un token basado en el tiempo se sincroniza con el servidor por medio de la
hora,
lo que no es un secreto,
eso sería suficiente para que un atacante clonará un token.
También hay tokens basados en contador,
que utilizan un valor de inicialización secreto junto con el valor del contador secreto,
que se incrementa cada vez que se genera una contraseña por única vez en el
dispositivo.
El valor luego aumenta en el servidor después de la autenticación exitosa.
Esto es más seguro que los tokens basados en el tiempo por dos razones.
Primero, el atacante necesitaría recuperar el valor de inicialización y el valor del
contador.
En segundo lugar, el valor del contador también aumenta mientras está en uso.
Por lo tanto, un token clonado solo sería útil durante un corto período
antes de que el valor del contador cambie demasiado
y el token de clonación se desincronice del token real y del servidor.
Estos generadores de tokens pueden ser
dispositivos físicos especializados o pueden ser una app instalada
en un teléfono inteligente con la misma funcionalidad.
Otro método muy común para el manejo multifactor en la actualidad
es la entrega de tokens de contraseña por única vez mediante SMS.
Pero esto ha sido objeto de algunas críticas
debido a los ataques observados a través de este canal.
El problema que suscita la confianza en los SMS para transmitir
un factor de autenticación adicional
es que dependes de los procesos de seguridad del operador de telefonía móvil.
Los SMS no están encriptados ni son privados.
Y es posible que un atacante bien financiado los intercepte.
Peor aún, se han robado cuentas de códigos multifactor
basadas en SMS con solo llamar al proveedor de servicios móviles.
El atacante se hace pasar por el propietario de la línea de servicio
para redirigir las llamadas telefónicas y los SMS a un teléfono que él mismo controla.
Si el atacante ya vulneró la contraseña y puede recibir los SMS,
ahora tiene acceso completo a la cuenta.
Por supuesto, hay un compromiso de comodidad cuando usas un token físico.
Tienes que llevar otro dispositivo para autenticarte.
Si ese dispositivo se pierde o se daña,
el usuario no podrá autenticarse hasta que se reemplace el dispositivo.
Esto también requiere soporte adicional,
ya que los dispositivos fallarán, se perderán,
se agotarán sus baterías y se desincronizarán con el servidor.
Usar una app en un smartphone resuelve algunos de estos problemas,
pero aun así, se requiere algún tipo de soporte adicional y ocasiona incomodidad.
Cuando se le solicite iniciar sesión,
el usuario debe recoger un dispositivo o teléfono de su bolsillo
y transcribir manualmente los números en la página de autenticación.
Estas contraseñas generadas por única vez también son susceptibles
a ataques de suplantación de identidad de estilo intermediario.
A un usuario se lo puede engañar para que vaya
a una página de autenticación falsa mediante un correo electrónico de suplantación de
identidad.
Algo más o menos así:
"Su cuenta fue puesta en riesgo.
Por favor, acceda a su cuenta y cambie su contraseña inmediatamente".
Cuando la víctima ingresa sus credenciales en la página falsa,
incluida la contraseña por única vez,
el atacante tiene toda la información necesaria para hacerse cargo de la cuenta.
La otra categoría de autenticación multifactor es la biométrica,
que ha ganado popularidad en los últimos años,
en especial, en los dispositivos móviles.
La autenticación biométrica es el proceso que usa
características fisiológicas exclusivas de un individuo para identificarlo.
Al confirmar la firma biométrica,
el individuo queda autenticado.
Un uso muy común de esto en dispositivos móviles son los escáneres de huellas
digitales para desbloquear teléfonos.
Esto funciona mediante el registro de tus huellas digitales primero,
para lo que se utiliza un sensor óptico que captura imágenes del patrón único de tu
huella digital.
Así como las contraseñas nunca deben almacenarse en texto sin formato,
tampoco debe hacerse con los datos biométricos utilizados para la autenticación,
por lo tanto, del mismo modo, nunca se los almacenará directamente.
Esto es aún más importante para el manejo de datos biométricos.
A diferencia de las contraseñas, los datos biométricos son inherentes a una persona.
Por lo tanto, existen implicaciones de privacidad en caso de robo o fugas de datos
biométricos.
Las características biométricas también pueden ser dificilísimas de cambiar
en caso de que se vean en riesgo, a diferencia de las contraseñas.
Entonces, en lugar de almacenar directamente los datos de las huellas digitales,
los datos pasan a través de un algoritmo de hash y se almacena el hash único resultante.
Una ventaja de la autenticación biométrica sobre los sistemas basados en tokens o en el
conocimiento
es que es más confiable con el objeto de identificar a un individuo para la autenticación,
ya que las características biométricas, por lo general, no se comparten.
Por ejemplo, no puedes darle a tu amigo tus huellas digitales para que pueda acceder por
ti.
Bueno, espero que no de todos modos.
Pero a medida que las escuelas comienzan a introducir sistemas de registro de asistencia
basados en huellas digitales,
los estudiantes van encontrando maneras de engañar al sistema.
Están creando huellas digitales falsas usando cosas como pegamento,
lo que permite que, entre amigos, se marquen como presentes si llegan tarde o faltan a la
escuela.
Esto es más difícil de lograr que compartir una contraseña,
pero es un poco ingenioso que estos chicos piensen en ello.
Realmente hacen un esfuerzo adicional para evadir la escuela en estos días.
No es que consienta este comportamiento,
pero puedes leer más sobre esto justo después de este video.
Otros sistemas biométricos usan cosas como escaneos del iris,
reconocimiento facial, detección en puertas, incluso voz.
Microsoft desarrolló el sistema de autenticación biométrica para Windows 10,
llamado Windows Hello, que admite la identificación de huellas digitales,
identificación del iris y reconocimiento facial.
Usa dos cámaras,
una para color y otra para infrarrojo,
lo que permite la detección de profundidad.
De esta manera, no es posible engañar
al sistema mediante una copia impresa de la cara de un usuario autorizado.
Una evolución de los tokens físicos es U2F o Universal Second Factor.
Es un estándar desarrollado conjuntamente por Google,
Yubico y NXP Semiconductors.
El estándar finalizado para U2F está siendo alojado por la Alianza FIDO.
U2F incorpora un mecanismo de desafío-respuesta,
junto con criptografía de clave pública,
para implementar una solución de autenticación de segundo factor más segura y
cómoda.
A los tokens U2F se los denomina
llaves de seguridad y una amplia gama de fabricantes los ponen a disposición.
La compatibilidad para la autenticación U2F está integrada en los navegadores Chrome
y Opera,
y próximamente habrá compatibilidad nativa para Firefox.
Las llaves de seguridad son, básicamente, pequeños cripto procesadores
con almacenamiento seguro de claves asimétricas y ranuras adicionales para ejecutar
código incrustado.
Hagamos un rápido resumen de cómo funcionan exactamente las llaves de seguridad
y cómo es su mejora sobre una solución OTP.
El primer paso es el registro,
ya que la llave de seguridad debe estar registrada en un sitio o servicio.
En el momento del registro, la llave de seguridad.
genera un par de claves público-privadas únicas para ese sitio
y envía la clave pública al sitio para su registro.
También vincula la identidad del sitio con el par de claves.
Hay pares de claves únicos para cada sitio por razones de privacidad.
Si un sitio se ve en riesgo,
esto impide las referencias cruzadas de las claves públicas registradas
y la detección de puntos en común entre sitios basada en datos de registro.
Una vez registrado en el sitio,
la próxima vez que te soliciten que autentiques,
se te pedirá tu nombre de usuario y contraseña como de costumbre.
Pero luego, se te pedirá que toques tu llave de seguridad.
Cuando tocas físicamente la llave de seguridad,
eso constituye una pequeña comprobación de la presencia del usuario
para garantizar que el malware no pueda autenticarse en su nombre, sin su
conocimiento.
Este toque desbloqueará las claves privadas almacenadas en la llave de seguridad,
las que se usan para autenticar.
La autenticación ocurre como un proceso de desafío-respuesta
que protege contra los ataques por repetición.
Esto se debe a que un intruso no puede volver a usar la sesión de autenticación más
tarde
porque el desafío y la respuesta resultante
serán diferentes en cada sesión de autenticación.
Lo que sucede es que el sitio genera un desafío,
en esencia, algunos datos aleatorios, y lo envía al cliente que está intentando
autenticarse.
El cliente seleccionará la clave privada que coincida con el sitio
y usará esta llave para firmar el desafío y enviar los datos firmados.
El sitio ahora puede verificar la firma usando la clave pública que se registró
anteriormente.
Si la firma concuerda,
el usuario se autentica.
Desde una perspectiva de seguridad,
este es un diseño mucho más seguro que las OTP.
Esto se debe a que el flujo de autenticación está protegido contra ataques de
suplantación de identidad
debido a la naturaleza interactiva del proceso.
Si bien U2F no protege directamente contra ataques de intermediario,
la autenticación debe llevarse a cabo a través de una conexión TLS segura,
lo que proporcionaría protección contra este tipo de ataque.
Las llaves de seguridad también son resistentes a la clonación o falsificación,
porque tienen secretos exclusivos
incrustados en ellas y están protegidas contra manipulaciones.
Desde la perspectiva de la comodidad,
este es un flujo de autenticación mucho mejor en comparación con las OTP, ya que el
usuario
no tiene que transcribir manualmente una cadena de números en el cuadro de diálogo de
autenticación.
Todo lo que tiene que hacer es tocar su clave de seguridad. Bueno y sencillo.
Como especialista en soporte de TI,
puedes encontrar configuraciones de autenticación multifactor
cuyo soporte será tu responsabilidad.
Incluso podrías estar a cargo de implementar una de estas configuraciones.
Por lo tanto, es importante entender cómo ofrecen mayor protección de cuentas
junto con las opciones que están disponibles.

En la última sección, mencionamos los certificados de cliente como forma de

autenticación.
Como aprendimos anteriormente, los certificados son claves públicas que están
firmadas
por una autoridad de certificación, o CA, como signo de confianza.
Ya vimos los certificados de servidor TLS, pero también puede haber certificados de
cliente.
Estos funcionan de manera muy similar a los certificados de servidor,
pero son presentados por los clientes y permiten a los servidores autenticar y verificar
clientes.
Como especialista en soporte de TI, es importante que comprendas
los certificados de cliente y la autenticación basada en certificados,
ya que puedes encontrarte con ellos en el curso de tu carrera profesional.
No es raro que los sistemas VPN
o las configuraciones Wi-Fi empresariales usen certificados de autentificación de
cliente.
Entender cómo funcionan te ayudará a solucionar problemas.
Para emitir certificados de cliente, una organización debe establecer
y mantener una infraestructura de CA para emitir y firmar certificados.
Parte de la autenticación de certificados también implica que el cliente
autentique el servidor, lo que nos brinda autenticación mutua.
Esto es positivo, ya que el cliente puede verificar que se está comunicando
con el servidor de autenticación y no con un imitador.
En este caso, todos los clientes que están usando autenticación por certificados
también deberían tener el certificado de la CA en su tienda de certificados de confianza.
Esto establece la confianza con la CA y permite al cliente
verificar que está comunicándose con el servidor verdadero cuando intentar
autenticarse.
La autenticación del certificado es como presentar una identificación en el aeropuerto.
Muestras tu identificación o tu certificado para demostrar quién eres.
La identificación se verifica para ver si fue emitida por una autoridad
de confianza para el verificador.
¿Fue emitida por una entidad gubernamental o es una licencia de imitación de una
tienda de regalos?
Obviamente, una de esas identificaciones sería aceptada en el aeropuerto,
al igual que un certificado firmado por una CA de confianza.
Cuando estás en el aeropuerto,
también se debe verificar la fecha de expiración en tu identificación para asegurar que
sigue siendo válida.
Lo mismo se aplica a un certificado de autenticación,
aunque los certificados tienen dos fechas que se deben verificar:
"No válido antes de" y "No válido después de".
"No válido antes de" se verifica para ver si el certificado es válido aún,
ya que es posible que se emitan certificados para uso futuro.
"No válido después de" es una fecha de caducidad directa,
después de la cual el certificado ya no es válido.
Las autoridades aeroportuarias también tienen una lista de identificaciones específicas
que están marcadas.
Si tu identificación está en esa lista, entonces no te permitirán viajar en avión.
De manera similar, se verificará el certificado comparándolo con una lista de
revocaciones, o CRL.
Esta es una lista firmada, publicada por la CA,
que define certificados que han sido revocados explícitamente.
Un último paso que se realiza como parte del proceso de verificación del servidor de
autenticación
es demostrar la posesión de la clave privada correspondiente,
ya que el certificado es una clave pública firmada.
Si no demostramos la posesión, no hay nada que impida que un atacante
copie el certificado, ya que no se lo considera secreto, y pretenda ser su propietario.
Para evitar esto,
se verifica la posesión de la clave privada a través de un mecanismo de desafío y
respuesta.
Aquí es donde el servidor solicita un bit aleatorizado de datos que se firmará
por medio de la clave privada que corresponde a la clave pública presentada para la
autenticación.
Esto es similar al modo en que el aeropuerto comprueba la foto en tu identificación
para asegurarse de que te pareces a la persona en la foto y no te estás haciendo pasar por
ella.

LDAP, o Protocolo ligero de acceso a directorios, es un protocolo de estándar abierto

del sector
para acceder y hacer mantenimiento de servicios de directorio.
Cuando decimos servicios de directorio,
nos referimos a algo similar a un directorio telefónico o de correo electrónico.
Se lo usa más comúnmente como backend para autenticación de cuentas.
La especificación LDAP describe la estructura de datos del propio directorio
y define funciones para interactuar con el servicio, como realizar búsquedas
y modificar datos.
Puedes imaginar un directorio como una base de datos, pero con más detalles
o atributos que describen a las entidades que se encuentran en la base de datos.
La estructura de un directorio LDAP tiene una especie de diseño de árbol y está
optimizada
para la recuperación de datos más que para su escritura.
Piensa que es similar a una guía telefónica que se usa con más frecuencia
para buscar datos que para hacerles modificaciones.
Los directorios se pueden alojar en muchos servidores LDAP diferentes
para facilitar búsquedas más rápidas, y se mantienen sincronizados a través de la
replicación del directorio.
¿Qué tipo de datos se almacenan en una entrada de directorio, exactamente?
Al igual que en una libreta de direcciones, una entrada para un usuario particular
contendrá información perteneciente a esa cuenta de usuario, como su nombre y
apellido,
número de teléfono, ubicación del escritorio, dirección de correo electrónico, shell de
acceso y otros datos similares.
Junto con los atributos de objeto, la ubicación de una entrada en la estructura general de
datos
representará información relacionada con los objetos como relaciones
entre objetos.
Como LDAP usa una estructura de árbol llamada árbol de información de datos, los
objetos tendrán
un elemento principal y uno o más elementos secundarios que le pertenecen.
También puedes pensar en esto como un sistema de archivos
con un sistema de archivos raíz en las carpetas subsiguientes.
La carpeta a la que pertenece un objeto proporcionará información sobre ese objeto
debido a su relación con el objeto principal.
En lenguaje LDAP, a estas carpetas las llamamos unidades organizativas (OU).
Nos permiten agrupar objetos relacionados en unidades como personas o grupos
para distinguir entre cuentas de usuario individuales y grupos a los que pueden
pertenecer las cuentas.
Esta estructura de árbol también permite
la herencia y anidación de objetos, en la que los atributos o propiedades de un objeto
principal
puede ser heredados por los objetos secundarios en niveles inferiores del árbol.
Ahora, ya que es posible que las entradas del directorio compartan atributos,
debe haber un identificador único para cada entrada.
A esto lo llamamos nombre distinguido, o DN.
Volviendo a nuestra analogía del sistema de archivos,
puedes pensar en un DN como una ruta completa hacia un archivo en lugar de un
nombre de archivo.
Esto es porque puedes tener múltiples archivos con el mismo nombre de archivo
en un sistema de archivos.
Pero la ruta completa hacia el archivo describiría un archivo único.
Algunas de las operaciones más comunes que un cliente puede invocar para interactuar
con un servidor LDAP son Bind, que es cómo los clientes se autentican en el servidor;
StartTLS, que permite a un cliente comunicarse por medio de LDAP v3 sobre TLS;
Search, para realizar búsquedas y recuperación de registros;
Add/delete/modify, que son diversas operaciones para escribir datos en el directorio,
y Unbind, que cierra la conexión al servidor LDAP.
Hay muchas implementaciones de servidores LDAP,
como Active Directory de Microsoft y OpenLDAP para implementaciones de código
abierto.
RADIUS, o servicio de usuario de acceso telefónico de autenticación remota,
es un protocolo que proporciona servicios AAA para usuarios en una red.
Es un protocolo de uso muy común para administrar el acceso a redes internas,
redes Wi-Fi, servicios de correo electrónico y servicios de VPN.
Diseñado originalmente para transportar información de autenticación para usuarios de
acceso telefónico remoto,
evolucionó para transportar una amplia variedad
de protocolos de autenticación estándar como EAP, o Protocolo de autenticación
extensible.
Si bien es poco probable que estés a cargo
de configurar el servidor RADIUS como especialista de soporte de TI,
tal vez debas brindar soporte a clientes que se autentiquen en un servidor backend
RADIUS.
En tales casos, es bueno entender qué papel desempeña el servidor RADIUS
en esta situación de autenticación para estar mejor preparado
para solucionar problemas que puedan surgir.
Los clientes que desean autenticarse en un servidor RADIUS no interactúan
directamente con él.
En cambio, cuando un cliente quiera acceder a un recurso que está protegido,
presentará las credenciales de autenticación a un NAS,
o servidor de acceso a la red, que transmitirá las credenciales al servidor RADIUS.
Entonces, el servidor RADIUS verificará
las credenciales mediante un esquema de autenticación configurado.
Los servidores RADIUS pueden verificar la información de autenticación del usuario
almacenada en un archivo sin formato o se pueden conectar a fuentes externas como
bases de datos SQL,
LDAP, Kerberos o Active Directory.
Una vez que el servidor RADIUS evaluó la solicitud de autenticación del usuario,
responde con uno de tres mensajes: acceso rechazado,
desafío de acceso o acceso aceptado.
: agregado a la selección Presiona [CTRL + S] para guardar como nota.

Kerberos es un protocolo de autenticación de red que utiliza tickets para permitir que las
entidades
demuestren su identidad
por canales potencialmente inseguros para proporcionar autenticación mutua.
También usa encriptación simétrica
para proteger contra la intercepción de los mensajes del protocolo y de los ataques por
repetición.
El nombre Kerberos está tomado del mítico personaje griego del mismo nombre,
un perro guardián de tres cabezas que protege las puertas del Hades, el inframundo.
Parece una opción apropiada para un protocolo de autenticación, ¿no crees?
Kerberos fue desarrollado originalmente en el Instituto de Tecnología de Massachusetts
(MIT), en los EE. UU.
y se publicó en la década de 1980 como versión 4.
Años después, en 1993,
se publicó la versión 5.
Hoy Kerberos admite cifrado AES
y además implementa sumas de comprobación para garantizar la integridad y
confidencialidad de los datos.
Cuando se une a un dominio de Windows,
Windows 2000 y las versiones más nuevas usarán Kerberos como protocolo de
autenticación predeterminado.
Microsoft también implementó su propio servicio Kerberos
con algunas modificaciones al protocolo abierto, como la incorporación del cifrado de
flujo RC 4.
Anteriormente mencionamos los tickets, que son una especie de token que demuestran
tu identidad.
Se pueden usar para autenticar ante servicios protegidos por medio de Kerberos
o, en otras palabras, dentro del ámbito de Kerberos.
Los tickets de autenticación permiten a los usuarios autenticarse en servicios
sin necesidad de autenticación por nombre de usuario/contraseña para cada servicio
individual.
Un ticket expirará después de cierto tiempo,
pero tiene disposiciones para su renovación automática transparente.
Analicemos los detalles de cómo funciona el protocolo Kerberos.
Primero, un usuario que quiera autenticarse
ingresa su nombre de usuario y contraseña en su máquina cliente.
Su software de cliente Kerberos,
entonces, tomará la contraseña y generará una clave de encriptación simétrica a partir de
ella.
A continuación, el cliente envía un mensaje de texto sin formato al AS,
o servidor de autenticación, de Kerberos, que incluye el ID del usuario que se autentica.
La contraseña o la clave secreta derivada de la contraseña no se transmiten.
El AS usa el ID de usuario para verificar si hay una cuenta en la base de datos de
autenticación,
como un servidor de Active Directory.
Si es así, el AS generará la clave secreta
usando el hash de la contraseña almacenado en el servidor del centro de distribución de
claves.
El AS usará la clave secreta para cifrar y enviar
un mensaje que contiene la clave de sesión TGS del cliente.
Este es un uso de clave secreta
para encriptar las comunicaciones con el servicio de otorgamiento de tickets, o TGS,
que ya es conocido por el servidor de autenticación.
El AS también envía un segundo mensaje con un ticket de otorgamiento de tickets, o
TGT,
que se encripta usando la clave secreta del TGS.
El TGT tiene información como la identificación del cliente,
el período de validez del ticket, y la clave de sesión de servicio de otorgamiento y
aceptación de tickets.
El primer mensaje puede desencriptarse
con la clave secreta compartida obtenida a partir de la contraseña del usuario.
Luego proporciona la clave secreta que puede desencriptar
el segundo mensaje, lo que le otorga al cliente un TGT válido.
Ahora, el cliente tiene suficiente información para autenticarse con el servidor de
otorgamiento de tickets.
Dado que el cliente se autenticó y recibió un TGT válido,
puede usar este TGT
para solicitar acceso a servicios desde adentro del ámbito de Kerberos.
Esto se hace enviando un mensaje
al servicio de otorgamiento de tickets con el TGT encriptado
que se recibió del AS anteriormente,
junto con el nombre o la ID del servicio a la que el cliente solicita acceso.
El cliente también envía un mensaje que contiene un autenticador que incluye la ID de
cliente
y una marca de tiempo que está encriptada
con la clave de sesión de TGT del AS.
El servicio de otorgamiento de tickets desencripta
el TGT usando su propia clave secreta,
que le proporciona al servicio de otorgamiento de tickets
la clave de sesión del servicio de otorgamiento de tickets del cliente.
A continuación, usa la clave para desencriptar el mensaje del autenticador.
Luego, comprueba la ID de cliente de estos dos mensajes para asegurarse de que
coincidan.
Si lo hacen, envía dos mensajes al cliente.
El primero contiene el ticket del cliente al servidor, que contiene la ID de cliente,
la dirección del cliente, el período de validez,
y la clave de sesión cliente-servidor encriptada por medio de la clave secreta del
servicio.
El segundo mensaje contiene la clave de sesión cliente-servidor en sí
y se encripta usando la clave de sesión del servicio de otorgamiento de tickets del
cliente.
Finalmente, el cliente tiene suficiente información
para autenticarse en el servidor de servicio, o SS.
El cliente envía dos mensajes al SS.
El primer mensaje es el ticket encriptado del cliente al servidor
que se recibió desde el servicio de otorgamiento de tickets.
El segundo es un nuevo autenticador con la ID del cliente
y la marca de tiempo encriptada por medio de la clave de sesión cliente-servidor.
El SS desencripta el primer mensaje
usando su clave secreta, lo que le proporciona la clave de sesión cliente-servidor.
La clave luego se utiliza para desencriptar el segundo mensaje,
y este compara la ID de cliente
en el autenticador con la que está incluida en ticket del cliente al servidor.
Si estas ID coinciden,
entonces el SS envía un mensaje que contiene la marca de tiempo del autenticador
suministrado por el cliente, encriptada por medio de la clave de sesión cliente-servidor.
El cliente, a continuación, desencripta este mensaje
y verifica que la marca de tiempo sea correcta y autentica el servidor.
Si todo esto sucede correctamente, entonces el servidor
otorga acceso al servicio solicitado del lado del cliente.
¡Guau, está bien! ¿Pudiste seguirme?
Sé que eso fue mucho.
Kerberos ha recibido algunas críticas porque es un servicio monolítico único.
Esto crea un peligro de punto único de falla.
Si el servicio Kerberos se cae,
los nuevos usuarios no podrán autenticarse ni iniciar sesión.
Aparte de los problemas de disponibilidad,
si el servidor central de Kerberos se ve en riesgo,
el atacante podría hacerse pasar por cualquier usuario
mediante la generación de tickets Kerberos válidos para su cuenta de usuario.
Kerberos impone estrictos requisitos de tiempo
que requieren que los relojes del cliente y el servidor tengan una sincronización muy
ajustada,
de lo contrario, la autenticación fallará.
Esto se logra, en general, mediante el uso de NTP
para mantener ambas partes sincronizadas usando un servidor NTP.
El modelo de confianza de Kerberos también es problemático,
ya que requiere que clientes y servicios
tengan una confianza establecida en el servidor Kerberos para autenticarse usando
Kerberos.
Esto significa que no es posible que los usuarios se autentiquen
con Kerberos a partir de clientes desconocidos o no confiables.
por lo tanto, cosas como BYOD o "Traiga su propio dispositivo"
y la computación en la nube son incompatibles,
o, al menos, muy difícil de implementar de forma segura con la autenticación Kerberos.
Ahora bien, como especialista en soporte de TI,
tal vez te topes con la autenticación Kerberos,
en especial en entornos que ejecutan Microsoft Active Directory.
Entender cómo funciona el protocolo subyacente
te ayudará a solucionar problemas que puedan venir con él.
TACACS+, se pronuncia "TACACS plus",
significa "sistema de control de acceso del controlador de acceso a terminales - Plus".
Es un protocolo AAA desarrollado por Cisco que se lanzó como estándar abierto en
1993.
Reemplazó el antiguo protocolo TACACS desarrollado en 1984 para MILNET,
la red no clasificada para DARPA
que más tarde se convirtió en NIPRNet.
TACACS+ también tomó el lugar de XTACACS,
o TACACS extendido, que era una extensión de TACACS patentada por Cisco.
TACACS+ se usa principalmente para administración, autenticación,
autorización y auditoría de dispositivos, a diferencia de RADIUS,
que se usa principalmente para acceso a la red AAA.
Es importante destacar estas diferencias
en las características de lo que brindan estos servicios,
aunque las diferencias se relacionan principalmente con las partes
de autorización y auditoría más que con la autenticación.
Si bien es posible que no te encuentres
con una implementación de TACACS+ en el curso de tu carrera de soporte,
es algo de lo que debes estar al tanto.
TACACS+ se usa principalmente como sistema de autenticación para dispositivos de
infraestructura de red,
los que tienden a ser objetivos de alto valor para los atacantes.
Esto puede ser un argumento a favor de su implementación a medida que tu
organización crezca.
El inicio de sesión único, o SSO, es un concepto de autenticación
que permite que los usuarios se autentiquen una sola vez
para obtener acceso a una gran cantidad de servicios y aplicaciones diferentes.
Como no es necesario volver a autenticarse para cada servicio,
los usuarios no necesitan muchos conjuntos de nombres de usuario y contraseña
para una combinación de aplicaciones y servicios.
SSO se realiza mediante autenticación ante un servidor de autenticación central,
como un servidor LDAP.
Esto, a su vez, proporciona una cookie o token
que se puede usar para obtener acceso a las aplicaciones configuradas para usar SSO.
Kerberos es en realidad un buen ejemplo de un servicio de autenticación SSO.
El usuario se autenticaría ante el servicio Kerberos una vez,
lo que luego le concedería un ticket de otorgamiento de ticket
que se puede presentar ante el sistema de otorgamiento de tickets
en lugar de las credenciales tradicionales.
Así, el usuario puede ingresar las credenciales una vez y obtener acceso a una variedad
de servicios.
SSO es realmente conveniente.
Permite a los usuarios tener un conjunto de credenciales que otorgan acceso a muchos
servicios,
lo que hace menos probable que las contraseñas se escriban o almacenen de forma poco
segura.
Esto también debería reducir la sobrecarga
sobre el servicio de asistencia para contraseñas
y elimina el tiempo dedicado a volver a autenticarse a lo largo de la jornada laboral.
Entonces, ¿cuál es el inconveniente?
Bueno, un atacante que logra poner en riesgo una cuenta
tiene mucho más nivel de acceso en un esquema de SSO.
Las credenciales de usuario otorgarán acceso a todas las aplicaciones
y servicios a los que se les permite acceder a esa cuenta.
Por lo tanto, tenemos un gran motivo para usar
la autenticación multifactor junto con un esquema SSO.
Pero esto abre un nuevo canal de ataque:
el robo de cookies o tokens de sesión de SSO.
En lugar de apuntar a las credenciales directamente,
los atacantes pueden intentar robar los tokens de SSO,
lo que permitirá un amplio acceso, aunque sea por un corto tiempo.
El robo de estos tokens también permite que un atacante esquive las protecciones de
autenticación multifactor,
ya que el token de sesión permite el acceso
sin necesidad de autenticación completa hasta caducar.
Un ejemplo de un sistema SSO es OpenID,
un sistema de autenticación descentralizado.
Es un estándar abierto que permite a los sitios participantes, conocidos como usuarios
de confianza,
dar lugar a la autenticación de usuarios mediante un servicio de autenticación externo.
Esto permite que los sitios autoricen la autenticación
sin necesidad de que el propio sitio tenga infraestructura de autenticación,
la que puede ser difícil de implementar y mantener.
También permite a los usuarios acceder al sitio sin tener que crear una nueva cuenta,
lo que simplifica la gestión de acceso en una amplia variedad de sitios.
En su lugar, un usuario solo necesita tener una cuenta con un proveedor de identidad.
Para solicitar autenticación,
primero, un usuario de confianza busca al proveedor de OpenID,
luego establece un secreto compartido con el proveedor si no existe uno.
El secreto compartido se usará para validar los mensajes del proveedor de OpenID.
Luego, el usuario será redirigido o se le pedirá
que autentique en una nueva ventana a través del flujo de acceso del proveedor de
identidades.
Una vez autenticado, al usuario se le pedirá que confirme
si confía o no en el usuario de confianza.
Tras su confirmación, las credenciales se transmiten al usuario de confianza,
por lo general en la forma de un token,
no de credenciales de usuario reales,
lo que indica que el usuario ahora está autenticado ante el servicio.
Ahora es momento de un cuestionario de práctica de autenticación.

Autenticación
Puntos totales 13

1.

Pregunta 1

¿En qué se diferencia la autenticación de la autorización?

1 / 1 punto

Autenticación es verificar el acceso a un recurso; autorización es verificar una

identidad.

Autenticación es identificar un recurso; autorización es verificar el acceso a una

identidad.

Son exactamente lo mismo.

Autenticación es verificar una identidad; autorización es verificar el acceso a un

recurso.

Correcto

¡Exacto! Autenticación es demostrar que una entidad es quien dice ser, mientras que
autorización es determinar si a esa entidad se le permite o no acceder a los recursos.
2.

Pregunta 2

¿Cuáles son algunas características de una contraseña segura? Marca todas las que
correspondan.

0.75 / 1 punto

Contiene palabras del diccionario

Esto no debería estar seleccionado

No exactamente. No se recomienda incluir palabras del diccionario en una contraseña,

ya que son susceptibles a los ataques de diccionario.

Tiene al menos ocho caracteres

Correcto

¡Así es! Una contraseña segura debe contener una mezcla de tipos de caracteres y
minúsculas/mayúsculas; además debe ser relativamente larga, al menos de ocho
caracteres, pero de preferencia más.

Se utiliza en cuentas y sistemas

Incluye números y caracteres especiales.

Correcto

¡Así es! Una contraseña segura debe contener una mezcla de tipos de caracteres y
minúsculas/mayúsculas; además debe ser relativamente larga, al menos de ocho
caracteres, pero de preferencia más.

3.

Pregunta 3

En un esquema de autenticación multifactor, una contraseña puede considerarse como:

0 / 1 punto
algo que tú sabes

algo que tú tienes

algo que tú eres

algo que tú usas.

Incorrecto

No exactamente. La biometría como un factor de autenticación adicional es algo que tú

eres, mientras que las contraseñas son algo que tú sabes.

4.

Pregunta 4

¿Cuáles son algunos inconvenientes del uso de datos biométricos para la autenticación?
Marca todos los que correspondan.

0.5 / 1 punto

Hay posibles problemas de privacidad.

La autenticación biométrica es mucho más lenta que las alternativas.

La autenticación biométrica es difícil o imposible de cambiar si está en riesgo.

Correcto

¡Eso mismo! Si una característica biométrica, como tus huellas dactilares, se pone en
riesgo, tu opción para cambiar tu "contraseña" es usar un dedo diferente. Esto hace que
los cambios de "contraseña" sean limitados. Otros elementos biométricos, como los
escaneos de iris, no se pueden cambiar si están en riesgo. Si el material de autenticación
biométrica no se maneja de forma segura, después la información de identificación del
individuo puede filtrarse o alguien puede robarla.

La biometría es fácil de compartir.

Esto no debería estar seleccionado

No exactamente. Como la autenticación biométrica implica características únicas del

cuerpo de un individuo, no es sencillo compartir la autenticación biométrica con alguien
más. No puedes dejar que tu amigo tome prestadas tus huellas digitales.

5.

Pregunta 5

¿De qué manera son los tokens U2F más seguros que los generadores de OTP?

1 / 1 punto

Son más económicos.

Son resistentes a los ataques de suplantación de identidad (phishing).

Están protegidos por contraseña.

No pueden clonarse.

Correcto

¡Buen trabajo! Con generadores de contraseña por única vez, la contraseña por única
vez, junto con el nombre de usuario y la contraseña pueden robarse a través del
phishing. Por otro lado, no se puede robar la autenticación U2F mediante phishing, dado
el diseño de criptografía de clave pública del protocolo de autenticación.

6.

Pregunta 6
¿Qué elementos de un certificado se inspeccionan cuando se verifica dicho certificado?
Marca todos los que correspondan.

1 / 1 punto

Tamaño de la clave del certificado

Fecha "No es válido después de"

Correcto

¡Sí! Para comprobar un certificado, hay que revisar el periodo de validez junto con la
firma de la autoridad certificadora firmante, para garantizar que sea uno de confianza.

Confianza de la CA que firma

Correcto

¡Sí! Para comprobar un certificado, hay que revisar el periodo de validez junto con la
firma de la autoridad certificadora firmante, para garantizar que sea uno de confianza.

Fecha "No válido antes de"

Correcto

¡Sí! Para comprobar un certificado, hay que revisar el periodo de validez junto con la
firma de la autoridad certificadora firmante, para garantizar que sea uno de confianza.

7.

Pregunta 7

¿Qué significa CRL?

1 / 1 punto

Caramelo-frambuesa-limón
Oyente recursivo certificado

Lista de revocación de certificados

Lenguaje de grabación de certificado

Correcto

Buen trabajo. CRL significa "lista de revocación de certificados". Es una lista publicada
por una CA, que contiene los certificados emitidos por la CA que están explícitamente
revocados o invalidados.

8.

Pregunta 8

¿Cuáles son los nombres de entidades similares en las que un servidor de directorio
organiza las entidades

1 / 1 punto

Unidades organizativas

Clústeres (agrupaciones)

Árboles

Grupos

Correcto

¡Increíble! Los servidores de directorio tienen unidades organizativas (OU) que se usan
para agrupar entidades similares.

9.

Pregunta 9
Verdadero o falso: el servidor de acceso a la red maneja la autenticación real en un
esquema RADIUS.

1 / 1 punto

Verdadero

Falso

Correcto

Buen trabajo. El servidor de acceso a la red solo retransmite los mensajes de

autenticación entre el servidor RADIUS y el cliente; no hace una evaluación de
autenticación en sí.

10.

Pregunta 10

Verdadero o falso: los clientes se autentican directamente ante el servidor RADIUS

1 / 1 punto

Verdadero

Falso

Correcto

¡Correcto! Los clientes en realidad no interactúan directamente con el servidor

RADIUS; la autenticación se retransmite a través del servidor de acceso a la red.

11.

Pregunta 11

¿Qué emite el servidor de autenticación Kerberos para un cliente que se autentica

correctamente?

1 / 1 punto
Un certificado digital

Un ticket de otorgamiento de tickets.

Una clave de encriptación

Una contraseña maestra

Correcto

¡Exactamente! Una vez autenticado, un cliente Kerberos recibe un ticket de

otorgamiento de tickets (TGT) del servidor de autenticación. Este TGT puede
presentarse entonces al servicio de otorgamiento de tickets para que se le conceda
acceso a un recurso.

12.

Pregunta 12

¿Qué ventajas ofrece el inicio de sesión único? Marca todas las que correspondan.

1 / 1 punto

Proporciona autenticación encriptada.

Aplica la autenticación multifactor.

Reduce el número total de credenciales.

Correcto

¡Acertaste! SSO permite utilizar un conjunto de credenciales para acceder a varios

servicios en diversos sitios. Esto reduce el número total de credenciales que podrían
necesitarse de otro modo. La autenticación SSO también emite un token de
autenticación después de que un usuario se autentica mediante su nombre de usuario y
la contraseña. Este token, entonces, autentica automáticamente al usuario hasta que
expira. Así, los usuarios no tienen que volver a autenticarse varias veces durante un día
de trabajo.

Se reduce el tiempo dedicado a la autenticación.

Correcto

¡Acertaste! SSO permite utilizar un conjunto de credenciales para acceder a varios

servicios en diversos sitios. Esto reduce el número total de credenciales que podrían
necesitarse de otro modo. La autenticación SSO también emite un token de
autenticación después de que un usuario se autentica mediante su nombre de usuario y
la contraseña. Este token, entonces, autentica automáticamente al usuario hasta que
expira. Así, los usuarios no tienen que volver a autenticarse varias veces durante un día
de trabajo.

13.

Pregunta 13

¿Qué proporciona OpenID?

1 / 1 punto

Función hash criptográfica

Firmas digitales

Delegación de autenticación

Firma de certificado

Correcto

¡Sí! OpenID permite que la autenticación se delegue a un servicio de autenticación

externo.

[MÚSICA]
Cuando yo era niño, mis padres terminaron teniendo,
creo que era una Commodore 64, y me encantaba jugar videojuegos ahí.
Luego compraron un NES, un sistema de entretenimiento de Nintendo,
y terminé jugando muchísimo.
Cuando crecí un poco, tuvimos otra computadora y empecé a jugar
un juego llamado Morrowind, pero mi computadora no podía manejarlo muy bien en
verdad.
Y por eso es que terminé interesándome por las computadoras.
Tenía esta necesidad de jugar videojuegos y esa necesidad requería
que aprendiera a reparar la computadora y a hacerle cosas.
Seguí adelante por ese camino.
Comencé a jugar muchas cosas relacionadas con la seguridad al final de la secundaria
y al comienzo de la universidad, como Syberia.
Podías hacer algo llamado "r-poisoning", podías hacerte pasar
por el router de un sistema y entonces todo el mundo configuraría
un paquete para ti y podrías ver lo que estaba sucediendo en la red.
Nadie se preocupaba mucho por la seguridad en ese momento, era verdaderamente
abierta y libre,
y muchas cosas malas podían ocurrir.
Sentí que esto tenía que cambiar.
Con ese estado del mundo, necesitas gente para poder solucionarlo,
y sentí que era una buena manera de ayudar al mundo, básicamente.
Si estoy ahí, reparando estos agujeros y haciendo el mundo un poco mejor,
entonces, sentí que estaría un poco más satisfecho, tal vez me haría sentir bien, supongo.
[MÚSICA]

Antes hablamos de autenticación,

el primer componente de las tres A de la seguridad.
A continuación, vamos a hablar de autorización,
que suele estar íntimamente ligada a la autenticación.
Mientras que la autenticación se relaciona con verificar la identidad de un usuario,
la autorización se refiere a describir a qué cosas la cuenta del usuario
tiene o no tiene acceso.
Son componentes separados y distintos de AAA, con diferentes propósitos.
Un usuario puede autenticarse exitosamente ante un sistema mediante la presentación de
credenciales válidas.
Pero si el nombre de usuario con el que se autenticó
no está autorizado para acceder al sistema en cuestión, se le negará el acceso.
Antes, cuando hablamos de Kerberos, el usuario autenticaba
y recibía un ticket de otorgamiento de ticket.
Esto puede usarse para solicitar acceso a un servicio específico
enviando una solicitud al servicio de otorgamiento de tickets.
Es en este momento cuando la autorización entra en juego,
ya que el servicio de otorgamiento de tickets decidirá si al usuario
en cuestión se le permite acceder al servicio que solicita, o no.
Si no se le permite acceder al servicio o no tiene autorización para ello,
la solicitud será rechazada por el servicio de otorgamiento de tickets.
Si el usuario está autorizado, el servicio de otorgamiento de tickets
devolverá un ticket que autoriza al usuario a acceder al servicio.
Un estándar abierto muy popular para delegación de autorización y acceso
es OAuth, utilizado por empresas como Google, Facebook y Microsoft.
Veremos OAuth en el siguiente video.
OAuth es un estándar abierto que permite a los usuarios
otorgar a sitios web y aplicaciones de terceros
acceso a su información sin compartir credenciales de cuenta.
Esto se puede considerar como una forma de delegación de acceso
porque el acceso a la cuenta del usuario se está delegando a un tercero.
Esto se logra pidiéndole al usuario que confirme que está de acuerdo
con permitir el acceso de terceros a cierta información sobre su cuenta.
Por lo general, esta solicitud enumerará específicamente
qué clases de información o acceso se solicitan.
Tras la confirmación, el proveedor de identidad suministrará al tercero
un token que le da acceso a la información del usuario.
El tercero puede usar este token para acceder a los datos o servicios
ofrecidos por el proveedor de identidad directamente en nombre del usuario.
OAuth se usa comúnmente para otorgar acceso a aplicaciones de terceros
para las API ofrecidas por grandes compañías de Internet como Google, Microsoft y
Facebook.
Supongamos que quieres usar un sitio web externo de creación de memes.
Este sitio web te permite crear memes usando plantillas
y te da la opción de guardar tus creaciones y enviárselas por correo electrónico a tus
amigos.
En lugar de que el sitio envíe los correos electrónicos directamente,
lo que parecerá provenir de una dirección que tus amigos no reconocerían,
el sitio usa OAuth para obtener permiso
para enviar los memes usando tu cuenta de correo electrónico directamente.
Para ello, hace una solicitud de OAuth a tu proveedor de correo electrónico.
Una vez que apruebas esta solicitud,
el proveedor de correo electrónico emite un token de acceso para el sitio,
que le otorga al sitio acceso a tu cuenta de correo electrónico.
El token de acceso tendrá un alcance
que dice que solo se puede usar para acceder al correo electrónico,
no a otros servicios asociados a la cuenta.
Puede acceder al correo electrónico, pero no a los archivos guardados en la nube o al
calendario, por ejemplo.
Es importante que los usuarios presten atención a qué tercero
solicita acceso y a qué exactamente están otorgando acceso.
Los permisos de OAuth se pueden usar en ataques del tipo de suplantación de identidad
para obtener acceso a cuentas sin poner en riesgo las credenciales.
Esto funciona enviándoles a posibles víctimas correos electrónicos de suplantación de
identidad
que parecen legítimas solicitudes de autorización de OAuth
que solicitan al usuario que otorgue acceso a algunos aspectos de su cuenta a través de
OAuth.
Una vez que el usuario concede el acceso,
el atacante tiene acceso a la cuenta a través del token de autorización OAuth.
Esto se usó en un ataque de gusano basado en OAuth a principios de 2017.
Hubo una serie de correos electrónicos de suplantación de identidad que parecían
provenir
de un amigo o colega que quería compartir un documento de Google.
Al hacer clic en el vínculo para compartir,
a la víctima se le solicitaba que iniciara sesión y autorizará el acceso
para enviar documentos y contactos por correo electrónico para algún servicio de
terceros,
que solo se identificaba con el nombre "Google Apps".
Pero en realidad era un servicio malicioso que enviaría correos electrónicos
a los contactos desde su cuenta de correo electrónico, la que perpetró el ataque.
En caso de que quieras leer más al respecto,
incluí un vínculo en la próxima lectura.
Es importante distinguir entre OAuth y OpenID.
OAuth es específicamente un sistema de autorización y OpenID es un sistema de
autenticación,
aunque por lo general se usan juntos.
OpenID Connect es una capa de autenticación desarrollada sobre OAuth 2.0,
diseñada para mejorar OpenID y para integrarse mejor con las autorizaciones de OAuth.
Dado que TACACS+ es un sistema AAA completo,
también maneja la autorización junto con la autenticación.
Esto se hace una vez que un usuario se autentica, permitiendo o invalidando
el acceso a la cuenta de usuario para ejecutar ciertos comandos o acceder a ciertos
dispositivos.
Esto no solo te permite autorizar el acceso de admin a los usuarios que administran
dispositivos,
sino también permitir un acceso menos privilegiado a otros usuarios cuando es
necesario.
Veamos un ejemplo. Como tus equipos de redes son responsables
de configurar y mantener tus conmutadores de red,
tus routers y otros tipos de infraestructura,
les darías acceso de administrador a tu red y equipos.
Mientras tanto, a tu equipo de soporte puedes darle
acceso limitado de solo lectura, ya que no necesita
poder hacer modificaciones para cambiar configuraciones en sus tareas.
El acceso de solo lectura es suficiente para que puedan solucionar problemas.
El resto de las cuentas de usuario no tendrían acceso en absoluto
ni se les permitiría conectarse a la infraestructura de redes.
Por lo tanto, los sistemas AAA más sofisticados o configurables
pueden incluso permite un mayor refinamiento de la autorización al nivel de comando.
Esto te da mucha más flexibilidad en cómo otorgas acceso
a usuarios o grupos específicos en tu organización.
RADIUS también te permite autorizar el acceso a la red.
Por ejemplo, tal vez desees permitir que algunos usuarios
tengan acceso a Wi-Fi y VPN mientras que otros pueden no necesitarlo.
Cuando se autentican en el servidor RADIUS,
si la autenticación tiene éxito,
el servidor RADIUS devuelve la información de configuración al servidor de acceso a
la red.
Esto incluye autorizaciones que especifican
a qué servicios de red se le permite acceder al usuario.
Una lista de control de acceso, o ACL,
es una forma de definir permisos o autorizaciones para objetos.
El caso más común que puedes encontrar tiene que ver con los permisos del sistema de
archivos.
Un sistema de archivos tendría una ACL,
que es una tabla o base de datos con una lista de entradas que especifican derechos de
acceso
para individuos o grupos a diversos objetos
en el sistema de archivos, como carpetas, archivos o programas.
Estos permisos de acceso individuales por objeto
se denominan entradas de control de acceso y forman la ACL.
Las entradas individuales pueden definir permisos que controlan
si un usuario o grupo pueden o no leer,
escribir o ejecutar objetos.
Las ACL también se usan ampliamente en la seguridad de la red
para aplicar controles de acceso a routers, conmutadores y firewalls.
Las ACL de red se usan para restringir y controlar
el acceso a servicios alojados que se ejecutan en hosts ubicadas en tu red.
Pueden definirse ACL de red para tráfico entrante y saliente.
También se las puede usar para restringir el acceso externo a los sistemas y limitar el
tráfico saliente
para hacer cumplir políticas o impedir transferencias de datos salientes no autorizadas.
Veremos las ACL de red en mayor profundidad
en lecciones futuras, cuando hablemos de la seguridad de la red con más detalle.
Por último, si bien no menos importante,
está la última A de las tres A de la seguridad: la de auditoría.
Esto significa mantener registros de los recursos y servicios
a los que tus usuarios acceden o de lo que hicieron cuando usaban tus sistemas.
Un componente crítico de esto es la auditoría,
que implica revisar estos registros para garantizar que no haya nada fuera de lo común.
Si estamos viendo y registrando el uso de nuestros sistemas,
pero nunca comprobamos en verdad los datos de uso,
eso no es muy útil.
Entonces, ¿qué es exactamente lo que registran los sistemas de conteo?
Bueno, eso depende del propósito y la intención del sistema.
Por ejemplo, un servidor TACACS+
estaría más preocupado por mantener un registro de la autenticación de usuarios,
ante qué sistemas se autenticaron,
y qué comandos ejecutaron durante su sesión.
Esto es porque TACACS+
es un sistema AAA de dispositivo de acceso que administra
quién tiene acceso a tus dispositivos de red y qué hacen en ellos.
El sistema AAA de Cisco admite la auditoría de los comandos individuales que se
ejecutan,
la conexión desde y hacia los dispositivos de red,
los comandos que se ejecutan en modo privilegiado,
y los servicios de red y detalles del sistema, como recargas de configuración o reinicios.
RADIUS rastreará detalles como la duración de la sesión,
la ubicación del cliente y el ancho de banda
o demás recursos utilizados durante la sesión.
Esto se debe a que RADIUS es un sistema AAA de acceso a la red.
Por lo tanto, rastrea los detalles sobre acceso y uso de la red.
La auditoría RADIUS se inicia con el envío, por parte del servidor de acceso a la red
(NAS),
de un paquete de solicitud de auditoría
al servidor de auditoría, que contiene un registro de eventos que debe asentarse.
Esto inicia la sesión de auditoría en el servidor.
El servidor responde con una respuesta de auditoría que indica que se recibió el
mensaje.
El NAS seguirá enviando mensajes periódicos de auditoría
con estadísticas de la sesión hasta que se recibe un paquete de finalización de auditoría.
Los ISP pueden usar la auditoría de RADIUS a fines de facturación
porque registra la duración de una sesión y la cantidad de datos enviados y recibidos por
el usuario.
Estos datos también se pueden utilizar para imponer cuotas de datos o tiempo,
limitar la duración de las sesiones
o restringir la cantidad de datos que se pueden enviar o recibir.
Pero esta información de auditoría no está detallada
y no contendrá detalles de lo que hizo exactamente el usuario durante la sesión.
No se registra información como los sitios web visitados o los protocolos empleados.
Otras utilidades de registro que veremos más adelante satisfacen ese caso de uso.
¡Guau! Muy bien. Vimos mucho material en este módulo.
¡Buen trabajo! Tómate tu tiempo para repasar cualquier cosa que haya sido un poco
pesada.
Cuando estés listo, tenemos un proyecto para ti que te pondrá a prueba con los
conceptos
del sistema de autenticación, autorización y auditoría.
Cuando termines, puedes pasar al siguiente video,
en el que estudiaremos la seguridad, la supervisión y el registro de la red.

Autorización y contabilidad
Puntos totales 3

1.

Pregunta 1

¿Qué papel desempeña la autorización?

1 / 1 punto

Determina si una entidad tiene acceso a un recurso o no.

Verifica la identidad de una entidad.

Verifica las contraseñas.

Proporciona encriptación segura.

Correcto

¡Increíble! La autorización tiene que ver con el hecho de si un usuario o cuenta tiene
permitido o no acceder a cierto recurso.

2.

Pregunta 2

¿Qué proporciona OAuth?

1 / 1 punto

Confidencialidad

Integridad

Delegación de acceso

Comunicaciones seguras

Correcto

¡Bravo! OAuth es un protocolo de autorización abierto que permite delegar el acceso a

la cuenta a terceros, sin revelar las credenciales de la cuenta directamente.

3.

Pregunta 3

¿Cómo se relaciona la inspección con la auditoría?

1 / 1 punto

No se relacionan.
Son exactamente lo mismo.

Auditoría es revisar los registros, mientras que inspección es registrar el acceso y el uso.

Auditoría es registrar el acceso y uso, mientras que inspección es revisar estos registros.

Correcto

¡Eso mismo! Auditoría implica el registro de recursos además del acceso a la red y el
uso de ella. Inspección implica revisar estos registros de uso buscando cualquier
anomalía.

Creo que lo que más disfruto es hacer felices a otras personas

que pueden tener algún tipo de problema,
su computadora tiene algún tipo de falla y tú la reparas.
Y luego hay una sonrisa gigante en su cara y están tan felices.
que pueden volver a su trabajo y a lo que están haciendo.
Y es realmente agradable
poder ayudar a alguien así y que estén tan agradecidos.
El soporte de TI me ayudó a mí
y ayudó a mi carrera como ingeniero de seguridad porque cuando eres ingeniero de
seguridad,
tienes que ser capaz de decirle a la gente: "No.
No deberías hacer esto.
No deberías hacer eso. No es seguro".
Pero como personal de soporte de TI, se supone que debes decir: "Sí.
Voy a reparar eso. Sí, voy a hacer esto.
Sí, lo haré".
De alguna manera me ayudó a cerrar la brecha, ya que digo: "No,
pero esta es una mejor manera de hacerlo", o: "Mira,
puedes hacerlo de esta manera y podrás obtener lo que quieres".
Cuando ejecuté por primera vez el código que crea toda nuestra política de firewalls,
le llevó aproximadamente 40 minutos pasar por todas las diferentes políticas.
Pensé en esto y dije:
"Es extremadamente largo.
Ejecutamos esto varias veces al día.
Todos en el equipo lo hacemos".
Entonces, lo estudié
y lo reduje a una ejecución de seis minutos de principio a fin.
Al final, hice cálculos
y se ahorró suficiente dinero como para contratar a otra persona al final.
Conozco a mucha gente en el campo que no tiene ningún título en absoluto.
Fueron a la secundaria y eso es todo.
Para tener éxito, necesitas poder resolver problemas.
Necesitas poder interactuar con la gente
y comunicarte. Esas son las dos cosas más importantes.
Si puedes descubrir cómo resolver el problema de alguien más
y puedes decirle cómo se debe resolver ese problema,
tienes al menos el 90% de lo que hay que hacer.

Seguridad AAA (no asistencia en carretera)

Calificación de la entrega más reciente: 90.9 %

1.

Pregunta 1

Authn es la abreviatura de ________.

1 / 1 punto

de autor

autorización

autoritario

autenticación

Correcto

¡Sí! La autenticación a veces se denomina "authn" en inglés para abreviar.

2.

Pregunta 2

Authz es la abreviatura de ________.

0 / 1 punto
de autor

autoritario

autorización

autenticación

Incorrecto

No exactamente. Consulta la lección "Ataques de red" para obtener una actualización.

3.

Pregunta 3

La autenticación se ocupa de determinar _______.

1 / 1 punto

la validez

el acceso

la elegibilidad

la identidad

Correcto

¡Bravo! La autenticación se refiere a la confirmación de las identidades de individuos.

4.
Pregunta 4

La autorización se refiere a determinar el (la) ______ a los recursos.

1 / 1 punto

validez

elegibilidad

acceso

identidad

Correcto

¡Correcto! La autorización se ocupa de determinar el acceso a los recursos.

5.

Pregunta 5

¿Cuáles de los siguientes son factores de autenticación de multifactor válidos? Marca

todos los que correspondan.

1 / 1 punto

Algo que tú sabes

Correcto

¡Buen trabajo! Los tres factores de autenticación que se pueden combinar para la
autenticación multifactor son: (1) algo que sabes, como una contraseña; (2) algo que
tienes, como un token físico; y (3) algo que eres, lo cual sería un factor biométrico.

Algo que tú hiciste

Algo que tú tienes

Correcto

¡Buen trabajo! Los tres factores de autenticación que se pueden combinar para la
autenticación multifactor son: (1) algo que sabes, como una contraseña; (2) algo que
tienes, como un token físico; y (3) algo que eres, lo cual sería un factor biométrico.

Algo que tú eres

Correcto

¡Buen trabajo! Los tres factores de autenticación que se pueden combinar para la
autenticación multifactor son: (1) algo que sabes, como una contraseña; (2) algo que
tienes, como un token físico; y (3) algo que eres, lo cual sería un factor biométrico.

6.

Pregunta 6

Los dos tipos de tokens de contraseña por única vez son ______ y ______. Marca todos
los que correspondan.

1 / 1 punto

basado en la identidad

basado en contraseña

basado en contador

Correcto

¡Así es! Un token generador de OTP puede basarse en el contador, en donde se

incrementa un contador en el token y el servidor después de la autenticación exitosa.

basado en el tiempo

Correcto
¡Así es! Un token generador de OTP puede estar basado en el tiempo, para permanecer
sincronizado con el servidor que usa el tiempo.

7.

Pregunta 7

Claves de seguridad son más ideales que los generadores de OTP porque son resistentes
a los ataques de _______.

1 / 1 punto

suplantación de identidad (phishing)

fuerza bruta

DDoS

contraseña

Correcto

¡Sí! Si bien se puede suplantar la identidad del código OTP, las llaves de seguridad
dependen de un sistema de desafío-respuesta que evita los ataques de phishing.

8.

Pregunta 8

Las llaves de seguridad utilizan un sistema seguro de autenticación de desafío-respuesta,

el cual se basa en ________.

1 / 1 punto

esteganografia

criptografía de clave pública

secretos compartidos

encriptación simétrica

Correcto

¡Impresionante! Las llaves de seguridad utilizan criptografía de clave pública para

realizar un proceso de desafío-respuesta seguro para la autenticación.

9.

Pregunta 9

Además de que el servidor autentica al cliente, la autenticación por certificado también

proporciona ______.

1 / 1 punto

autorización

integridad

protección contra malware

autenticación de servidor

Correcto

¡Exactamente! El cliente valida el certificado del servidor, proporcionando así

autenticación de servidor y autenticación de cliente.

10.

Pregunta 10

Kerberos usa _____ como tokens de autenticación.

1 / 1 punto

claves criptográficas

certificados

Tickets

contraseñas

Correcto

¡Buen trabajo! Kerberos emite tickets, los que representan tokens de autenticación y
autorización.