Az 500 - Español PDF

Examen Ref AZ-500 Tecnologías de
seguridad de Microsoft Azure
Yuri Diógenes
Orin Thomas
Contenido de un vistazo
Introducción
Capítulo 1 Gestionar la identidad y el acceso
Capítulo 2 Implementar la protección de la plataforma
Capítulo 3 Gestionar operaciones de seguridad
Capítulo 4 Datos y aplicaciones seguros
Índice
Contenido
Introducción
Organización de este libro
Preparándose para el examen
Certificaciones de Microsoft
Acceso rápido a referencias en línea
Erratas, actualizaciones y asistencia para libros
Mantente en contacto
Capítulo 1 Gestionar la identidad y el acceso

Habilidad 1.1: Administrar identidades de Azure Active Directory
Configurar la seguridad para los principales de servicio
Administrar grupos de directorios de Azure AD
Administrar usuarios de Azure AD
Configurar la escritura diferida de contraseñas
Configure los métodos de autenticación, incluidos el hash de
contraseña y la autenticación PassThrough (PTA), OATH y
autenticación sin contraseña
Transferir suscripciones de Azure entre inquilinos de Azure AD
Habilidad 1.2: configurar el acceso seguro mediante Azure AD
Supervisar el acceso privilegiado para Azure AD Privileged Identity
Management (PIM)
Configurar revisiones de acceso
Activar y configurar PIM
Implementar políticas de acceso condicional, incluida la autenticación
multifactor
Administrar usuarios de MFA
Configurar la protección de identidad de Azure AD
Habilidad 1.3: Administrar el acceso a las aplicaciones
Crear registros de aplicaciones
Configurar los alcances de los permisos de registro de aplicaciones
Administrar el consentimiento del permiso de registro de la aplicación
Administrar el acceso de API a suscripciones y recursos de Azure
Habilidad 1.4: Gestionar el control de acceso
Configurar permisos de suscripción y recursos
Configurar los permisos del grupo de recursos
Identificar el rol apropiado
Aplicar el principio de privilegio mínimo
Configurar roles RBAC personalizados
Interpretar permisos
Verificar acceso
Respuestas del experimento mental
Resumen del capítulo
Capítulo 2 Implementar la protección de la plataforma

Habilidad 2.1: Implementar seguridad de red avanzada
Descripción general de los componentes de la red de Azure
Asegure la conectividad de las redes virtuales
Configurar grupos de seguridad de red y grupos de seguridad de
aplicaciones
Crear y configurar Azure Firewall
Configurar el servicio Azure Front Door como puerta de enlace de
aplicaciones
Configurar el firewall de aplicaciones web (WAF) en Azure Application
Gateway
Configurar Azure Bastion
Configurar el firewall de recursos
Implementar punto final de servicio
Implementar DDoS
Habilidad 2.2: Configurar seguridad avanzada para computación
Configurar la seguridad del endpoint dentro de la VM
Configurar actualizaciones del sistema para máquinas virtuales en
Azure
Configurar la autenticación para contenedores
Configurar la seguridad para diferentes tipos de contenedores
Implementar la gestión de vulnerabilidades
Configurar el aislamiento para AKS
Configurar la seguridad para el registro de contenedores
Implementar el cifrado de disco de Azure
Configurar la seguridad para Azure App Service
Capítulo 3 Gestionar operaciones de seguridad

Habilidad 3.1: Configurar servicios de seguridad
Configurar Azure Monitor
Crea y personaliza alertas
Configurar el registro de diagnóstico y la retención de registros
Supervisión de registros de seguridad mediante Azure Monitor
Habilidad 3.2: Supervisar la seguridad mediante Azure Security Center
Evaluar los análisis de vulnerabilidades desde Azure Security Center
Configurar el acceso Just-In-Time VM mediante Azure Security Center
Configurar la administración de políticas centralizada mediante Azure
Security Center
Configure las políticas de cumplimiento y evalúe el cumplimiento
mediante el uso de Azure Security Center
Habilidad 3.3: Supervisar la seguridad mediante Azure Sentinel
Introducción a la arquitectura de Azure Sentinel
Configurar fuentes de datos en Azure Sentinel
Configurar una guía para un evento de seguridad con Azure Sentinel
Evaluar los resultados de Azure Sentinel
Habilidad 3.4: Configurar políticas de seguridad
Configure las opciones de seguridad mediante Azure Policy
Configure las opciones de seguridad mediante Azure Blueprint
Capítulo 4 Datos y aplicaciones seguros
Habilidad 4.1: Configurar la seguridad para el almacenamiento
Configurar el control de acceso para las cuentas de almacenamiento
Configurar la administración de claves para cuentas de
almacenamiento
Crear y administrar firmas de acceso compartido (SAS)
Crear una política de acceso almacenada para un blob o contenedores
de blobs
Configurar la autenticación de Azure AD para Azure Storage
Configurar la autenticación de Azure AD Domain Services para Azure
Files
Configurar el cifrado del servicio de almacenamiento
Protección contra amenazas avanzada para Azure Storage
Habilidad 4.2: Configurar la seguridad para bases de datos
Habilitar la autenticación de la base de datos
Habilitar la auditoría de la base de datos
Configurar la protección contra amenazas avanzada de Azure SQL
Database
Implementar el cifrado de la base de datos
Implementar Azure SQL Database Always Encrypted
Habilidad 4.3: Configurar y administrar Key Vault
Administrar el acceso a Key Vault
Cortafuegos y redes virtuales de Key Vault
Gestionar permisos para secretos, certificados y claves.
Configurar el uso de RBAC en Azure Key Vault
Administrar certificados
Gestionar secretos
Configurar la rotación de claves
Copia de seguridad y restauración de elementos de Key Vault
Índice
Sobre los autores
Yuri Diógenes, MsCtiene una Maestría en Ciencias en Inteligencia
de Ciberseguridad e Investigación Forense (UTICA College) y es
Gerente Principal de Programas para el Equipo del Centro de
Seguridad de Microsoft CxE Azure. Principalmente, Yuri ayuda a los
clientes a incorporar e implementar Azure Security Center y trabaja con
el equipo de ingeniería de ASC para la mejora continua del
producto. Yuri ha estado trabajando para Microsoft desde 2006 en
diferentes puestos, incluidos cinco años como ingeniero de
escalamiento de soporte senior para CSS Forefront Edge Team, y de
2011 a 2017 como miembro del equipo de desarrollo de contenido,
donde también ayudó a crear Azure Security Center. experiencia de
contenido después de su lanzamiento en 2016. Yuri ha publicado un
total de 23 libros, principalmente sobre seguridad de la información y
tecnologías de Microsoft. Yuri también tiene un MBA y muchas
certificaciones de la industria de TI / seguridad, como CISSP, E | CND,
E | CEH, E | CSA, E | CHFI, CompTIA Security +, CySA +, Cloud
Essentials Certified, Mobility +, Network +, CASP, CyberSec First
Responder, MCSE y MCTS. Puedes seguir a Yuri en Twitter
en@yuridiogenes .
Orin Thomas es un defensor principal de operaciones en la nube en

Microsoft y ha escrito más de tres docenas de libros para Microsoft
Press sobre temas que incluyen Windows Server, Windows Client,
Azure, Microsoft 365, Office 365, System Center, Exchange Server,
Seguridad y SQL Server. Ha sido autor de cursos de Arquitectura Azure
en Pluralsight, ha sido autor de varios cursos de Microsoft Official
Curriculum y EdX sobre una variedad de temas para profesionales de
TI, y está completando un Doctorado en Tecnología de la Información
sobre seguridad y cumplimiento de la computación en la nube en la
Universidad Charles Sturt. Puedes seguirlo en twitter
en @orinthomas .
Introducción
El examen AZ-500 trata temas avanzados que requieren que los
candidatos tengan un excelente conocimiento práctico de las
tecnologías de seguridad de Azure. Algunas partes del examen cubren
temas que incluso los administradores de seguridad de Azure
experimentados pueden encontrar raramente a menos que trabajen con
todos los aspectos de Azure de forma regular. Para tener éxito en la
realización de este examen, los candidatos no solo deben comprender
cómo administrar la identidad y el acceso a Azure, sino también cómo
implementar la protección de la plataforma Azure, administrar las
operaciones de seguridad de Azure y proteger los datos y las
aplicaciones de Azure. Los candidatos también deben poder
mantenerse actualizados con los nuevos desarrollos en las tecnologías
de seguridad de Azure, incluidas las características ampliadas y los
cambios en la interfaz.
Los candidatos para este examen deben tener experiencia en la materia
con la implementación de controles de seguridad y protección contra
amenazas; gestionar la identidad y el acceso; y la protección de datos,
aplicaciones y redes en entornos híbridos y de nube como parte de una
infraestructura de un extremo a otro.
Las responsabilidades de un ingeniero de seguridad de Azure incluyen
mantener la postura de seguridad, identificar y corregir
vulnerabilidades mediante el uso de una variedad de herramientas de
seguridad, implementar protección contra amenazas y responder a
escaladas de incidentes de seguridad. Los ingenieros de seguridad de
Azure a menudo forman parte de un equipo más grande dedicado a la
administración basada en la nube y la seguridad de entornos híbridos
como parte de una infraestructura de un extremo a otro.
Un candidato para este examen debe estar familiarizado con las
secuencias de comandos y la automatización y debe tener un
conocimiento profundo de las redes y la virtualización. Un candidato
también debe estar muy familiarizado con las capacidades de la nube,
los productos y servicios de Azure y otros productos y servicios de
Microsoft. Para aprobar, los candidatos requieren una comprensión
teórica completa de las tecnologías involucradas, así como una
experiencia práctica significativa en la implementación de las mismas.
Esta edición de este libro cubre Azure y los objetivos del examen AZ-
500 a fines de 2020. A medida que la funcionalidad de seguridad de
Azure evoluciona, también lo hacen los objetivos del examen AZ-500,
por lo que debe verificar cuidadosamente para determinar si se han
producido cambios desde esta edición de el libro fue escrito y debes
estudiarlo en consecuencia.
Este libro cubre todas las áreas temáticas principales que se encuentran
en el examen, pero no cubre todas las preguntas del examen. Solo el
equipo de examen de Microsoft tiene acceso a las preguntas del
examen, y Microsoft agrega periódicamente nuevas preguntas al
examen, lo que hace imposible cubrir preguntas específicas. Debe
considerar este libro como un complemento de su experiencia relevante
en el mundo real y otros materiales de estudio. Si encuentra un tema en
este libro con el que no se siente completamente cómodo, use la opción
"¿Necesita más revisión?" enlaces que encontrará en el texto para
encontrar más información y tomarse el tiempo para investigar y
estudiar el tema. Hay gran información disponible
en docs.microsoft.com y en blogs y foros.
ORGANIZACIÓN DE ESTE LIBRO

Este libro está organizado por la lista de "Habilidades medidas" publicada
para el examen. La lista "Habilidades medidas" está disponible para cada
examen en el sitio web de Microsoft Learn: http://aka.ms/examlist . Cada
capítulo de este libro corresponde a un área temática principal de la lista,
y las tareas técnicas de cada área temática determinan la organización de
un capítulo. Si un examen cubre seis áreas temáticas principales, por
ejemplo, el libro contendrá seis capítulos.
PREPARÁNDOSE PARA EL EXAMEN

Los exámenes de certificación de Microsoft son una excelente manera de
crear su currículum y dejar que el mundo conozca su nivel de
experiencia. Los exámenes de certificación validan su experiencia en el
trabajo y su conocimiento del producto. Aunque no hay sustituto para la
experiencia en el trabajo, la preparación a través del estudio y la práctica
pueden ayudarlo a prepararse para el examen. Este libro no está diseñado
para enseñarle nuevas habilidades.
Le recomendamos que amplíe su plan de preparación para el examen
utilizando una combinación de cursos y materiales de estudio
disponibles. Por ejemplo, puede usar la Referencia de examen y otra guía
de estudio para su preparación "en casa" y tomar un curso del plan de
estudios oficial de Microsoft para la experiencia en el aula. Elija la
combinación que crea que funciona mejor para usted. Obtenga más
información sobre la capacitación presencial disponible y encuentre
cursos en línea gratuitos y eventos en vivo
en http://microsoft.com/learn . Las pruebas de práctica oficiales de
Microsoft están disponibles para muchos exámenes
en http://aka.ms/practicetests .
Tenga en cuenta que esta referencia de examen se basa en información
disponible públicamente sobre el examen y la experiencia del autor. Para
salvaguardar la integridad del examen, los autores no tienen acceso al
examen en vivo.
CERTIFICACIONES DE MICROSOFT
Las certificaciones de Microsoft lo distinguen al demostrar su dominio de
un amplio conjunto de habilidades y experiencia con los productos y
tecnologías actuales de Microsoft. Los exámenes y las certificaciones
correspondientes se desarrollan para validar su dominio de las
competencias críticas a medida que diseña y desarrolla, o implementa y
brinda soporte, soluciones con productos y tecnologías de Microsoft tanto
en las instalaciones como en la nube. La certificación aporta una variedad
de beneficios para el individuo y para los empleadores y las
organizaciones.
Más información Todas las certificaciones de Microsoft
Para obtener información sobre las certificaciones de Microsoft, incluida una lista
completa de las certificaciones disponibles, visite http://www.microsoft.com/learn .
ACCESO RÁPIDO A REFERENCIAS EN LÍNEA

A lo largo de este libro hay direcciones de páginas web que el autor le ha
recomendado que visite para obtener más información. Algunos de estos
enlaces pueden ser muy largos y laboriosos de escribir, por lo que los
hemos reducido para que sea más fácil visitarlos. También los hemos
compilado en una sola lista a la que los lectores de la edición impresa
pueden consultar mientras leen.
Descargue la lista en MicrosoftPressStore.com/ExamRefAZ500/downloads
Las URL están organizadas por capítulo y encabezado. Cada vez que
encuentre una URL en el libro, busque el hipervínculo en la lista para ir
directamente a la página web.
ERRATAS, ACTUALIZACIONES Y ASISTENCIA

PARA LIBROS
Hemos hecho todo lo posible para garantizar la precisión de este libro y
su contenido complementario. Puede acceder a las actualizaciones de este
libro, en forma de lista de erratas enviadas y sus correcciones
relacionadas, en
MicrosoftPressStore.com/ExamRefAZ500/errata
Si descubre un error que aún no está en la lista, envíenoslo en la misma
página.
Para obtener ayuda e información adicional sobre libros, visite
http://www.MicrosoftPressStore.com/Support
Tenga en cuenta que el soporte de productos para software y hardware
de Microsoft no se ofrece a través de las direcciones anteriores. Para
obtener ayuda con el software o hardware de Microsoft, vaya a
http://support.microsoft.com
MANTENTE EN CONTACTO
¡Sigamos con la conversación! Estamos en
Twitter: http://twitter.com/MicrosoftPress .
Capítulo 1
Gestionar la identidad y el acceso

Un paso importante a la hora de proteger las cargas de trabajo es
determinar qué tráfico permitirá y qué tráfico bloqueará. En el pasado,
podía usar la ubicación de la red y el tipo de tráfico para tomar esta
determinación. Por ejemplo, puede permitir el tráfico que proviene de
una dirección IP en particular y en un puerto en particular y denegar
ese tráfico si no cumple con esas condiciones específicas. Con el
tiempo, los atacantes inteligentes han aprendido a falsificar la
información de la dirección IP, lo que les permite sortear estas barreras
tradicionales. Hoy, escuchará a los profesionales de la seguridad
pronunciar el aforismo "la identidad es el nuevo plano de control". Lo
que la frase significa es que cuando la ubicación de la red o las
propiedades del tráfico no son un gran indicador de si un host o tráfico
es confiable, la identidad que se usa para interactuar con el recurso que
está tratando de proteger podría ser una mejor guía; esto es
especialmente cierto si esas identidades se refuerzan con tecnologías
como la autenticación multifactor. En este capítulo, aprenderá a
administrar identidades en la nube, asegurar el acceso a recursos y
aplicaciones en la nube y administrar el control de acceso a las
herramientas administrativas de la nube.
Habilidades en este capítulo:

• Administrar las identidades de Azure Active Directory
• Configurar el acceso seguro mediante Azure AD
• Administrar el acceso a la aplicación
• Gestionar el control de acceso
HABILIDAD 1.1: ADMINISTRAR
IDENTIDADES DE AZURE ACTIVE
DIRECTORY
Este objetivo se ocupa de las identidades dentro de Azure Active
Directory. En Azure Active Directory, las identidades se representan como
usuarios, entidades de servicio, identidades administradas o
grupos. Azure Active Directory le permite usar una variedad de métodos
de autenticación que incluyen contraseñas de un solo uso y autenticación
multifactor para proteger estas identidades. Esta sección cubre los
siguientes temas:
• Configurar la seguridad para los principales de servicio
• Administrar grupos de directorios de Azure AD
• Administrar usuarios de Azure AD
• Configurar la escritura diferida de contraseñas
• Configure los métodos de autenticación, incluidos el hash de
contraseña y la autenticación PassThrough (PTA), OATH y
• Transferir suscripciones de Azure entre inquilinos de Azure
AD
Configurar la seguridad para los principales de

servicio
La seguridad de una entidad de servicio se configura cuando desea
controlar el acceso que tiene una aplicación a los recursos de
Azure. Cuando registre una aplicación de Azure Active Directory, se
crearán los siguientes objetos en su arrendamiento de Azure Active
Directory:
• Un objeto de aplicación Los objetos de aplicación se
almacenan en la instancia de Azure AD y definen la aplicación. El
esquema de las propiedades de un objeto de aplicación lo define el
tipo de recurso de entidad de aplicación de Microsoft Graph. Los
objetos de aplicación son una representación global de una
aplicación en todos los arrendamientos de Azure AD. El objeto de
aplicación funciona como una plantilla a partir de la cual se
determinan las propiedades comunes y predeterminadas cuando
Azure AD crea el objeto principal de servicio correspondiente. Los
objetos de aplicación tienen una relación de uno a uno con la
aplicación de software y una relación de uno a muchos con los
objetos principales de servicio correspondientes.
• Un objeto de entidad de servicio Una entidad de
seguridad de usuario en Azure AD es un objeto que representa a
un usuario. Una entidad de servicio es un objeto de Azure AD que
representa una aplicación. El ServicePrincipalobjeto le permite
especificar la política de acceso y los permisos para la aplicación y
el usuario de esa aplicación dentro del inquilino de Azure AD de su
organización. Se requiere una entidad de servicio para cada
arrendamiento donde se utiliza la aplicación. Una aplicación de un
solo inquilino solo tendrá un principal de servicio, y una aplicación
de varios inquilinos tendrá un principal de servicio para cada
inquilino donde un usuario de ese inquilino haya dado su
consentimiento para el uso de la aplicación. La entidad principal de
servicio de Microsoft Graph define el esquema utilizado para
unServicePrincipalpropiedades del objeto. La entidad de servicio es
la representación de la aplicación en un arrendamiento de Azure
AD específico.
El registro de una aplicación con Azure AD le permite aprovechar las
características de autorización e inicio de sesión seguro de la plataforma
de identidad de Microsoft para usar con esa aplicación. El registro de una
aplicación con Azure AD requiere que proporcione información, incluida
la dirección URL a la que se puede acceder a la aplicación, la dirección
URL para reenviar las respuestas después de que se produzca la
autenticación y la URI que identifica su aplicación. Aprenderá más sobre
cómo registrar aplicaciones con Azure AD más adelante en este capítulo.
Más información Aplicación y objetos principales de servicio
Puede obtener más información sobre los objetos de la entidad de servicio y la
aplicación en https://docs.microsoft.com/en-us/azure/active-directory/develop/app-
objects-and-service-principals .
Las entidades de servicio son análogas a una cuenta de servicio de Active

Directory local en el sentido de que ambas permiten que una aplicación
tenga una identidad y un contexto de seguridad. Las entidades de servicio
en Azure AD pueden incluir lo siguiente:
• Una referencia a un objeto de aplicación a través de la
propiedad ID de la aplicación.
• Propiedades de asignación de roles de aplicaciones de grupos
y usuarios locales
• Permisos de la aplicación de administrador y usuario local
• Datos de políticas locales, incluida información sobre políticas
de acceso condicional
• Datos sobre la configuración alternativa de la aplicación local,
incluida la
• Reglas de transformación de notificaciones
• Asignaciones de atributos (aprovisionamiento de
usuarios)
• Roles de aplicaciones específicos del directorio (cuando
la aplicación admite roles personalizados)
• Nombre o logotipo específico del directorio
Crear una entidad de servicio

Como ya ha aprendido, Azure AD creará una entidad de servicio cuando
registre una aplicación con una instancia de Azure AD. Esta es la forma en
que se crearán la mayoría de las entidades de servicio de Azure AD. Es
posible crear una entidad de servicio con el New-
AzADServicePrincipalcmdlet desde una sesión de Azure PowerShell. La
forma más sencilla de ejecutar Azure PowerShell es mediante una sesión
de Cloud Shell. Por ejemplo, para crear una nueva entidad de servicio
denominada ExampleServiceprincipal, ejecute el siguiente comando desde
una sesión de Azure PowerShell.
Haga clic aquí para ver la imagen del código
$ servicePrincipal = New-AzADServicePrincipal -DisplayName
"ExampleServiceprincipal"
Los directores de servicio pueden utilizar dos tipos diferentes de

autenticación: autenticación basada en contraseña y autenticación basada
en certificado. Si no especifica un tipo de autenticación de inicio de sesión
al crear una entidad de servicio, se utilizará la autenticación basada en
contraseña y se asignará una contraseña aleatoria a la cuenta de entidad
de servicio.
Para ver una lista de entidades de servicio asociadas con una instancia de
Azure AD, ejecute el siguiente comando desde una sesión de Azure
PowerShell:
Get-AzAdServicePrincipal | tabla de formato
Más información Crear director de servicio

Consulte https://docs.microsoft.com/en-us/powershell/azure/create-azure-service-
principal-azureps para obtener más información sobre la creación de directores de
servicio.
Asignar permisos a los principales de servicio a través

de roles
Para proporcionar acceso dentro de una suscripción a una aplicación,
asigna un conjunto de permisos a la entidad de servicio asociada con la
aplicación. La forma más sencilla de lograr este objetivo es asignar un rol
particular a la aplicación. Por ejemplo, si desea otorgar acceso de lectura a
una aplicación a los recursos dentro de un grupo de recursos en
particular, puede asignar la función Lector a la entidad de servicio
asociada con la aplicación.
Para asignar un rol a una aplicación que ya está registrada con una
instancia de Azure AD, realice los siguientes pasos:
1. En Azure Portal, seleccione la suscripción a la que está asociada la
aplicación y luego, en la página Suscripciones , seleccione
el nodo Control de acceso (IAM) , como se muestra en la Figura 1-
1.
Figura 1-1 Control de acceso (IAM) para una suscripción
2. En el control de acceso (IAM) página, seleccione Agregar una
asignación de funciones , seleccione la función que desea asignar
a la aplicación, y elija Azure AD usuario, grupo o servicio
principal del asignar acceso a menú desplegable, como se
muestra en la Figura 1-2 , y luego en el cuadro de
texto Seleccionar , especifique el nombre de la aplicación.
Figura 1-2 Asignar un rol a una aplicación
3. Haga clic en Guardar para asignar el rol a la entidad de servicio.
Más información Azure Roles
Puede obtener más información sobre los roles que puede asignar a los directores de
servicio en
https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles .
Así como puede asignar permisos a través de un rol a través del nodo de
Control de acceso (IAM) en el nivel de suscripción, puede usar el nodo de
Control de acceso (IAM) en el grupo de recursos o el nivel de recursos
para asignar un rol a una entidad de servicio. Al asignar permisos a una
entidad de servicio, debe asignar esos permisos de la manera más
restrictiva posible. Esto significa que solo debe asignar roles en el nivel de
alcance apropiado y solo asignar el rol que necesita la aplicación. Si la
aplicación solo requiere acceso de lector a un grupo de recursos, no
asigne el rol Colaborador en el nivel de suscripción a la entidad de
servicio de la aplicación.
Puede usar el New-AzRoleAssignmentcmdlet de PowerShell para asignar un
rol a una entidad de servicio. Por ejemplo, para crear una nueva entidad
de servicio y asignar permisos de lector a nivel de suscripción a la entidad
de servicio, promulgue los siguientes comandos de PowerShell:
$ servicePrincipal = New-AzADServicePrincipal -DisplayName
"ExampleServiceprincipal"
New-AzRoleAssignment -RoleDefinitionName "Reader" -

ApplicationId $ servicePrincipal.
ID de aplicación
Trabajar con entidades de servicio en entornos de línea de comandos

requiere que utilice ID de aplicación en lugar del nombre para mostrar de
la entidad de servicio. Esta es la razón por la que ApplicationIdse
especifica en el segundo comando del ejemplo anterior, que asigna el rol a
la entidad de servicio creada en el primer comando.
Puede determinar qué roles se han asignado a una entidad de servicio en
la suscripción, el grupo de recursos o los niveles de recursos realizando
los siguientes pasos:
1. En Azure Portal, seleccione la suscripción, el grupo de recursos o el
recurso al que está asociada la aplicación y, a continuación, en
la página Suscripciones , seleccione el nodo Control de acceso
(IAM) .
2. Seleccione la sección Asignaciones de roles . Esta página enumera
todos los roles asignados en este ámbito. En la columna Tipo , los
principales de servicio se enumeran con el tipo de aplicación ,
como se muestra en la Figura 1-3 .
Figura 1-3 Comprobación de las asignaciones de roles para los

principales de servicio
Administrar grupos de directorios de Azure AD

Los grupos le permiten agrupar usuarios y luego asignarles privilegios y
acceso a cargas de trabajo o servicios. En lugar de asignar directamente
privilegios y acceso a cargas de trabajo o servicios a los usuarios, puede
asignar estos derechos a un grupo y luego asignarlos indirectamente a los
usuarios agregando las cuentas de usuario al grupo apropiado. El uso de
grupos le permite asignar acceso y derechos agregando y quitando
usuarios de un grupo. Si bien es posible asignar acceso y derechos por
usuario, esto es administrativamente engorroso y dificulta determinar
qué usuarios tienen un derecho específico. La determinación de los
derechos puede ser mucho más fácil si los derechos solo se delegan a
grupos. Si solo asigna derechos a un grupo, si necesita determinar los
derechos, solo tiene que verificar la membresía del grupo.
Puede usar la consola administrativa de Azure AD en Azure Portal para
administrar grupos. Puede acceder al centro de administración de Azure
Active Directory en https://aad.portal.azure.com o mediante la hoja Azure
AD de Azure Portal. Azure AD admite dos tipos de grupos: grupos de
seguridad y grupos de Office 365. La Figura 1-4 muestra cómo seleccionar
el tipo de grupo al crear el grupo. Los grupos de Office 365 se usan para la
colaboración entre usuarios donde las organizaciones usan servicios
como Microsoft 365 u Office 365. Los usuarios en grupos pueden ser
internos o externos a la organización.
Figura 1-4 Crear grupo de Azure AD

La membresía de grupo para los grupos de seguridad debe estar asignada
y no es dinámica. Cuando se asigna la membresía de un grupo, los
administradores u otros usuarios que tienen los derechos adecuados
agregan y eliminan miembros manualmente.
Los tipos de grupo de Office 365 se pueden configurar como asignados o
dinámicos. Cuando se selecciona la opción dinámica, la pertenencia al
grupo se determina en función de los resultados de una consulta con los
atributos del usuario o del dispositivo. Por ejemplo, con los grupos de
Office 365, puede hacer que la pertenencia al grupo esté determinada por
atributos de usuario como la ubicación o el administrador. La Figura 1-
5 muestra un grupo de Office 365 con membresía dinámica, donde los
usuarios que tienen el atributo de departamento establecido
en Marketingse les asignará automáticamente la membresía del grupo.
Figura 1-5 Membresía de grupo dinámico de Office 365

Puede usar los siguientes comandos de PowerShell del módulo Azure AD
PowerShell para administrar los grupos de Azure AD:
• Get-AzureADGroup Proporciona información sobre los
grupos de Azure AD.
• New-AzureADGroup Crea un nuevo grupo de Azure AD.
• Set-AzureADGroup Configura las propiedades de un grupo
de Azure AD.
• Remove-AzureADGroup Quita un grupo de Azure AD.
• Add-AzureADGroupMember Agrega un usuario a un grupo
de Azure AD.
• Remove-AzureADGroupMember Quita un usuario de un
grupo de Azure AD.
• Add-AzureADGroupOwner Agrega un usuario como
propietario de un grupo de Azure AD. Otorga al usuario privilegios
de administración de grupo limitados.
• Remove-AzureADGroupOwner Quita un usuario como
propietario de un grupo de Azure AD.
Más información Azure AD Groups
Puede obtener más información sobre los grupos de Azure AD
en https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-
groups-view-azure-portal .
Creando grupos
Para crear un grupo de Azure AD, realice los siguientes pasos:
1. En Azure Portal, seleccione la hoja de menú de Azure Active
Directory .
2. En Administrar en la hoja de menú de Azure Active Directory ,
seleccione Grupos , como se muestra en la Figura 1-6 .
Figura 1-6 hoja de menú de Azure Active Directory

3. En la barra de control de la página Grupos , haga clic en Nuevo
grupo .
4. En la página Nuevo grupo que se muestra en la Figura 1-7 ,
proporcione la siguiente información y seleccione Crear :
1. Tipo de grupo Elija entre Seguridad y Office 365 .
2. Nombre del grupo Proporcione un nombre para el grupo. A
menudo es una buena idea idear un sistema para nombrar grupos, en
lugar de nombrar al grupo en función de lo que se le ocurra al completar
el formulario. Utilice este sistema para todos los grupos de la
suscripción. Una estrategia consiste en nombrar los grupos de una
manera que indique cómo recopilan las cuentas, como Research Userslas
cuentas de usuario relacionadas con la investigación. Los nombres de
grupo deben ser únicos dentro de una instancia de Azure Active
Directory.
3. Descripción del grupo Proporcione una descripción significativa
para el grupo. Esta descripción debe ser lo suficientemente significativa
como para que, si ganaras la lotería y te retiraste a Tahití, la persona que
te reemplazó podría comprender el propósito del grupo.
4. Tipo de membresía Si elige un grupo de seguridad , los miembros
del grupo deben agregarse manualmente. Si elige el tipo de grupo
de Office 365 , tendrá las siguientes opciones:
1. Propietarios Los usuarios designados como
propietarios del grupo pueden modificar la membresía
del grupo.
2. Miembros Le permite especificar la pertenencia a
un grupo. Puede incluir usuarios, grupos, directores de
servicio e identidades administradas.
Figura 1-7 Página de nuevo grupo
Puede crear grupos de Azure a partir de una sesión de Cloud Shell con
el az ad group createcomando. Por ejemplo, para crear un grupo
llamado Usuarios de contabilidad , use el siguiente comando:
Crear grupo de anuncios Az --display-name "Accounting Users"
--mail-nickname "Accounting.users"
Más información Creación de grupos

Puede obtener más información sobre el tema en https://docs.microsoft.com/en-
us/azure/active-directory/fundamentals/active-directory-manage-groups .
Agregar y eliminar miembros del grupo

Puede agregar miembros a un grupo de Azure AD desde una sesión de
Cloud Shell mediante el az ad group member addcomando. El desafío al usar
este comando es que debe especificar el miembro usando el ID de objeto
del miembro, en lugar del nombre del miembro. Por ejemplo, para
agregar el usuario con el ID de objeto ac5ebbfb-22c7-4381-b91d-
12aeb3093413al grupo Accounting Users, use el siguiente comando desde una
sesión de Azure PowerShell:
az ad group member add --group "Accounting Users" --member-id
ac5ebbfb-22c7-4381-b91d-
12aeb3093413
Puede determinar el ID de objeto de un usuario utilizando el az ad user

showcomando y especificando el nombre principal de usuario del usuario
con el IDparámetro. Por ejemplo, para determinar el ID de objeto del
usuario delta.user@tailwindtraders.net, ejecute el siguiente comando en
Cloud Shell:
az ad user show --id delta.user@tailwindtraders.net
Grupos anidados
Azure AD le permite agregar un grupo de seguridad como miembro de
otro grupo de seguridad, que se conoce como grupo anidado. Cuando
haga esto, el grupo de miembros heredará los atributos y propiedades del
grupo principal. Los grupos de anidación le permiten simplificar aún más
la gestión de un gran número de usuarios. Por ejemplo, puede tener
grupos para los gerentes en Melbourne, Sydney y Adelaide. Puede agregar
estos tres grupos a un grupo de administradores australianos y luego
asignar derechos y permisos de grupo de nivel superior a
administradores australianos, en lugar de asignar esos derechos a cada
grupo de administradores a nivel de ciudad. Esto también le brinda
flexibilidad en caso de que agregue grupos de administradores a nivel de
ciudad adicionales, como Brisbane y Perth, en algún momento en el
futuro, ya que simplemente agregaría estos grupos al grupo de
administradores australianos para asignar los mismos permisos.
En el momento de redactar este documento, Azure AD no admite los
siguientes escenarios de anidamiento:
• Agregar un grupo de Azure AD a un grupo sincronizado desde
Active Directory local
• Agregar grupos de seguridad de Azure AD a grupos de Office
365
• Agregar Office 365 a grupos que no sean otros grupos de
Office 365
• Asignar aplicaciones a grupos anidados
• Asignar licencias a grupos anidados
• Grupos de distribución de anidación
Para anidar grupos mediante Azure Portal, realice los siguientes pasos:
1. En la página Grupos: Todos los grupos de la hoja de Azure Active
Directory de Azure Portal, haga clic en el grupo que desea
anidar. Esto abrirá las propiedades del grupo, como se muestra en
la Figura 1-8 . En este ejemplo, el Melbournegrupo se agregará
al Australiagrupo.
Figura 1-8 Lista de grupos de Azure AD

2. Haga clic en el elemento Membresías de grupo en la sección
Administrar de las propiedades del grupo, como se muestra en
la Figura 1-9 .
Figura 1-9 Membresías de grupo enumeradas en el menú Grupos
3. En la página Membresías de grupo , haga clic en Agregar
membresías .
4. En la página Seleccionar grupos , seleccione el grupo en el que
desea anidar el grupo. En este caso, seleccionaremos
el Australiagrupo, como se muestra en la Figura 1-10 . Haga clic
en Seleccionar para anidar el grupo. Un grupo se puede anidar
dentro de varios grupos.
Figura 1-10 Selección de un grupo para anidar

Para eliminar un grupo de otro grupo, abra la página de membresía del
grupo del grupo principal y luego elimine el grupo anidado seleccionando
ese grupo y haciendo clic en Eliminar membresías .
Más información Grupos de anidación
Puede obtener más información sobre este tema en https://docs.microsoft.com/en-
us/azure/active-directory/fundamentals/active-directory-groups-membership-azure-
portal .
Administrar usuarios de Azure AD

Puede usar el Centro de administración de Azure AD en Azure Portal,
Azure PowerShell o el Centro de administración de Microsoft 365 para
administrar las cuentas de usuario de Azure AD. El centro de
administración de Azure AD le ofrece un mayor conjunto de opciones
para administrar las propiedades de las cuentas de usuario que el centro
de administración de Microsoft 365 porque puede editar las propiedades
de usuario extendidas, como se muestra en la Figura 1-11 .
Figura 1-11 Página de propiedades del usuario

Para crear un nuevo usuario de Azure AD, realice los siguientes pasos:
1. En la consola de Azure AD, seleccione Usuarios – Todos los
usuarios y luego haga clic en Nuevo usuario .
2. En la hoja Nuevo usuario que se muestra en la Figura 1-12 ,
proporcione la siguiente información:
1. Nombre El nombre real del usuario.
2. Nombre de usuario El nombre de inicio de sesión del
usuario en formato UPN.
3. Perfil El nombre, apellido, cargo y departamento del
usuario.
4. Propiedades Esto especifica la fuente de autoridad
para el usuario. De forma predeterminada, si crea el usuario
mediante el centro de administración de Azure AD o el centro
de administración de Microsoft 365, la fuente de autoridad
será Azure Active Directory.
5. Grupos Esto define a qué grupos debe pertenecer el
usuario.
6. Función de directorio Elija si la cuenta tiene una
función de usuario, administrador global o administrador
limitado.
7. Contraseña Esta como contraseña generada
automáticamente. Con la opción Mostrar contraseña , puede
transmitir la contraseña al usuario a través de un canal
seguro.
Figura 1-12 Página de propiedades de nuevo usuario
También puede usar el centro de administración de Azure AD para
realizar las siguientes tareas de administración de usuarios:
• Actualizar la información del perfil
• Asignar roles de directorio
• Administrar la membresía del grupo
• Administrar licencias
• Administrar dispositivos
• Administrar el acceso a los recursos de Azure
• Administrar métodos de autenticación
Cuando elimina un usuario de Azure AD, la cuenta permanece en la
Papelera de reciclaje de Azure Active Directory durante 30 días. Esto
significa que puede recuperar la cuenta en línea si fuera necesario. Si
elimina un usuario de su entorno de Active Directory local pero ha
habilitado la Papelera de reciclaje de Active Directory local, la
recuperación del usuario de la Papelera de reciclaje de Active Directory
local recuperará la cuenta de usuario en Microsoft 365. Si no lo hace ' Si
tiene habilitada la Papelera de reciclaje de Active Directory, deberá crear
otra cuenta con un nuevo GUID.
Más información Creación de usuarios de Azure AD
Puede obtener más información sobre los cmdlets de Azure AD PowerShell para
administrar usuarios en https://docs.microsoft.com/en-us/powershell/azure/active-
directory/new-user-sample .
Configurar la escritura diferida de contraseñas

La escritura diferida de la contraseña se produce cuando un usuario usa
la funcionalidad de contraseña de autoservicio (SSPR) para actualizar su
contraseña en Azure y esa contraseña actualizada se escribe en una
instancia local de Servicios de dominio de Active Directory. Azure AD
también es compatible con SSPR en cuentas nativas de Azure AD donde
no es necesaria la escritura diferida en una instancia local. Para
implementar SSPR para organizaciones con servicios de dominio de
Active Directory locales, primero debe instalar Azure AD Connect para
sincronizar las identidades locales con Azure.
Más información Reescritura de contraseña
Puede obtener más información sobre la escritura diferida de contraseñas
en https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-
enable-sspr-writeback .
Instalar y configurar Azure AD Connect

Azure AD Connect le permite conectar sus cuentas de Active Directory
locales con una instancia de Azure AD. Esto es útil no solo para las
aplicaciones que se ejecutan en Azure, sino que le permite implementar el
inicio de sesión único si su organización usa Microsoft 365 u Office 365. El
inicio de sesión único le permite usar una identidad para acceder a los
recursos locales y en la nube. . En muchos escenarios, el usuario ni
siquiera tendrá que volver a autenticarse.
Azure AD Connect es un software que se instala en un equipo que
administra el proceso de sincronización de objetos entre el Active
Directory local y la instancia de Azure Active Directory. Puede instalar
Azure AD Connect en equipos que ejecutan Windows Server 2012 o
sistemas operativos posteriores:
Azure AD Connect tiene los siguientes requisitos:
• Debe instalarse en una instancia de Windows Server que
tenga instalada la versión GUI del sistema operativo. No puede
instalar Azure AD connect en un equipo que ejecute el sistema
operativo Server Core.
• Puede implementar Azure AD Connect en un equipo que sea
un controlador de dominio o un servidor miembro. Si usa las
opciones personalizadas, se puede usar un servidor independiente.
• El servidor que aloja Azure AD Connect requiere .NET
Framework 4.5.1 o posterior.
• El servidor que aloja Azure AD Connect requiere Microsoft
PowerShell 3.0 o posterior.
• El servidor que aloja Azure AD Connect no debe tener
habilitada la Transcripción de PowerShell a través de la Directiva
de grupo.
• Si está implementando Azure AD Connect con los servicios de
federación de Active Directory, debe usar Windows Server 2012 R2
o posterior para el proxy de aplicación web, y la administración
remota de Windows debe estar habilitada en los servidores que
hospedarán roles de AD FS.
• Si los administradores globales tendrán habilitada la
autenticación multifactor (MFA), entonces la
URL https://secure.aadcdn.microsoftonline-p.com debe configurarse
como un sitio confiable.
Requisitos de conectividad
El equipo con Azure AD Connect instalado debe ser miembro de un
dominio en el bosque que desea sincronizar y debe tener conectividad a
un controlador de dominio grabable en cada dominio del bosque que
desea sincronizar en los siguientes puertos:
• Puerto DNS TCP / UDP 53
• Puerto 88 de Kerberos TCP / UDP
• Puerto RPC TCP 135
• Puerto LDAP TCP / UDP 389
• Puerto 443 de TLS / SSL TCP
• Puerto TCP 445 de SMB
El equipo con Azure AD Connect instalado debe poder establecer
comunicación con los servidores de Microsoft Azure en Internet a través
del puerto TCP 443. El equipo con Azure AD Connect instalado puede
estar ubicado en una red interna siempre que pueda iniciar la
comunicación en el puerto TCP 443. El equipo que aloja Azure AD
Connect no necesita una dirección IP enrutable públicamente. El equipo
que aloja Azure AD Connect siempre inicia la comunicación de
sincronización con Microsoft Azure. Microsoft Azure Active Directory no
inicia la comunicación de sincronización con el equipo que aloja Azure AD
Connect en la red local.
Dado que la instancia de Azure AD Connect requiere acceso a Internet, no
debe instalar Azure AD Connect en un controlador de dominio. Si va a
replicar más de 50.000 objetos, Microsoft recomienda que implemente
SQL Server en una computadora que esté separada de la computadora
que albergará Azure AD Connect. Si planea hospedar la instancia de SQL
Server en un equipo independiente, asegúrese de que sea posible la
comunicación entre el equipo que hospeda Azure AD Connect y el equipo
que hospeda la instancia de SQL en el puerto TCP 1433.
Si va a utilizar una instancia de SQL Server separada, asegúrese de que la
cuenta utilizada para instalar y configurar Azure AD Connect tenga
derechos de administrador de sistemas en la instancia de SQL y que la
cuenta de servicio utilizada para Azure AD Connect tenga permisos
públicos en Azure AD Connect. base de datos.
Requisitos de SQL Server

Cuando implementa Azure AD Connect, tiene la opción de que Azure AD
Connect instale una instancia de SQL Server Express, o puede elegir que
Azure AD Connect aproveche una instancia completa de SQL Server. SQL
Server Express está limitado a un tamaño máximo de base de datos de 10
GB. En términos de Azure AD Connect, esto significa que Azure AD
Connect solo puede administrar 100.000 objetos. Es probable que esto
sea adecuado para todos los entornos, excepto para los más grandes.
Para los entornos que requieren que Azure AD Connect administre más
de 100.000 objetos, necesitará que Azure AD Connect aproveche una
instancia completa de SQL Server. Azure AD Connect puede usar todas las
versiones de Microsoft SQL Server, desde Microsoft SQL Server 2012 con
la mayorcent service pack a SQL Server 2019. Es importante tener en
cuenta que SQL Azure no es compatible como base de datos para Azure
AD Connect. Si está implementando una instancia completa de SQL Server
para admitir Azure AD Connect, asegúrese de que se cumplan los
siguientes requisitos previos:
• Utilice una intercalación de SQL que no distinga entre
mayúsculas y minúsculas Las intercalaciones que no distinguen
entre mayúsculas y minúsculas tienen el _CI_identificador incluido
en sus nombres. Las intercalaciones que _CS_distinguen
entre mayúsculas y minúsculas (aquellas que usan la designación)
no se admiten para su uso con Azure AD Connect.
• Solo puede usar un motor de sincronización por instancia
de SQL. Si tiene un motor de sincronización de Azure AD Connect
adicional o si usa Microsoft Identity Manager en su entorno, cada
motor de sincronización requiere su propia instancia de SQL
independiente.
Requisitos para cuentas de implementación

Utiliza dos cuentas al configurar Azure AD Connect. Una cuenta debe
tener permisos específicos de Azure AD; la otra cuenta debe tener
permisos de Active Directory locales específicos. Las cuentas que usa para
instalar y configurar Azure AD Connect tienen los siguientes requisitos:
• La cuenta utilizada para configurar Azure AD Connect debe
tener privilegios de administrador global en el arrendamiento de
Azure AD. Debe crear una cuenta separada para esta tarea y
configurar la cuenta con una contraseña compleja que no
caduca. Esta cuenta se usa para el proceso de sincronización entre
AD local y Azure AD.
• La cuenta que se usa para instalar y configurar Azure AD
Connect debe tener permisos de administrador empresarial dentro
del bosque de Active Directory local si va a usar la configuración de
instalación Express. Esta cuenta solo es necesaria durante la
instalación y configuración. Una vez que Azure AD Connect está
instalado y configurado, esta cuenta ya no necesita permisos de
administrador empresarial. La mejor práctica es crear una cuenta
separada para la instalación y configuración de Azure AD Connect y
agregar temporalmente esta cuenta al grupo de administradores de
empresa durante el proceso de instalación y configuración. Una vez
que Azure AD Connect está instalado y configurado, esta cuenta se
puede quitar del grupo de administradores de empresa.
• La cuenta utilizada para instalar y configurar Azure AD
Connect debe ser miembro del grupo de administradores locales en
el equipo en el que está instalado Azure AD Connect.
Instalación de Azure AD Connect

La instalación de Azure AD Connect con la configuración Express es
adecuada si su organización tiene un solo bosque de Active Directory y
desea usar la sincronización de contraseñas para la autenticación. La
configuración de Azure AD Connect Express es adecuada para la mayoría
de las organizaciones. Puede descargar los archivos de instalación de
Azure AD Connect desde el sitio web del centro de descargas de Microsoft.
Para instalar Azure AD Connect con la configuración Express, realice los
siguientes pasos:
1. Haga doble clic en el AzureADConnect.msiarchivo que ha descargado
del centro de descargas de Microsoft. Se le solicitará una
advertencia de seguridad. Después de hacer clic Ejecutar ,Azure AD
Connect se instalará en su equipo. Cuando se complete la
instalación, se le presentará una pantalla de presentación que
detalla los términos de la licencia y muestra un aviso de
privacidad. Deberá aceptar estos términos antes de hacer clic
en Continuar .
2. Si su organización tiene un dominio interno no enrutable, será
necesario que utilice una configuración personalizada. La mejor
práctica es usar la sincronización de dominios cuando su instancia
de Active Directory local y su instancia de Azure Active Directory
usan el mismo nombre de dominio enrutable. Haga clic
en Continuar .
3. En la página Instalar componentes necesarios , que se muestra en
la Figura 1-13 , elija entre las siguientes opciones:
Figura 1-13 Página de instalación de componentes necesarios

1. Especificar una ubicación de instalación
personalizada Elija esta opción si desea instalar Azure AD
Connect en una ubicación separada, como en otro volumen.
2. Especificar un servidor SQL existente Elija esta
opción si desea especificar una instancia de servidor SQL
alternativa. De forma predeterminada, Azure AD Connect
instalará una instancia de SQL Server Express.
3. Usar una cuenta de servicio existente Puede
configurar Azure AD Connect para usar una cuenta de
servicio existente. De forma predeterminada, Azure AD
Connect creará una cuenta de servicio. Puede configurar
Azure AD Connect para usar una cuenta de servicio
administrado por grupo.Deberá usar una cuenta de servicio
existente si está usando Azure AD Connect con una instancia
remota de SQL Server o si la comunicación con Azure se
producirá a través de un servidor proxy que requiere
autenticación.
4. Especificar grupos de sincronización
personalizados Cuando implemente Azure AD Connect,
creará cuatro grupos locales en el servidor que hospeda la
instancia de Azure AD Connect. Estos grupos son el grupo de
administradores, el grupo de operadores, el grupo de
restablecimiento de contraseña y el grupo de exploración. Si
desea utilizar su propio conjunto de grupos, puede
especificarlos aquí. Estos grupos deben ser locales para el
servidor host y no miembros del dominio.
4. Una vez que haya especificado qué opciones personalizadas
necesita, y no es necesario que elija ninguna, haga clic en Instalar .
5. En la página Inicio de sesión de usuario que se muestra en
la Figura 1-14 , especifique qué tipo de inicio de sesión desea
permitir. Puede elegir entre las siguientes opciones, cuyos detalles
se trataron anteriormente en este capítulo:
0. Sincronización de contraseña
1. Autenticación de paso a través
2. Federación con AD FS
3. Federación con PingFederate
4. No configurar
5. Habilitar el inicio de sesión único
Figura 1-14 Página de opciones de inicio de sesión de usuario
La mayoría de las organizaciones elegirán la sincronización de
contraseñas porque es la opción más sencilla.
6. En la página Conectarse a Azure AD , proporcione las credenciales
de una cuenta con privilegios de administrador global en Azure
AD. Microsoft recomienda que use una cuenta en
el onmicrosoft.comdominio predeterminado asociado con la instancia
de Azure AD a la que se conectará. Si elige la opción Federación
con AD FS , asegúrese de no iniciar sesión con una cuenta en un
dominio que habilitará para la federación. La figura 1-15 muestra
un inicio de sesión con un escenario de sincronización de
contraseña .
Figura 1-15 Página Conectarse a Azure AD
7. Una vez que Azure AD Connect se haya conectado a Azure AD,
podrá especificar el tipo de directorio para sincronizar, así como el
bosque. Haga clic en Agregar directorio para agregar un bosque
específico. Cuando agrega un bosque haciendo clic en Agregar
directorio , deberá especificar las credenciales de una cuenta que
realizará la sincronización periódica. A menos que esté seguro de
haber aplicado los privilegios mínimos necesarios a una cuenta,
debe proporcionar las credenciales de administrador empresarial y
permitir que Azure AD Connect cree la cuenta, como se muestra en
la Figura 1-16 . Esto garantizará que a la cuenta solo se le asignen
los privilegios necesarios para realizar tareas de sincronización.
Figura 1-16 Página de cuenta de bosque de AD
8. Una vez que se hayan verificado las credenciales, como se muestra
en la Figura 1-17 , haga clic en Siguiente .
Figura 1-17 Página Conecte sus directorios
9. En la página Configuración de inicio de sesión de Azure AD , que
se muestra en la Figura 1-18 , revise el sufijo UPN y luego
inspeccione el atributo local para usarlo como el nombre de usuario
de Azure AD. Deberá asegurarse de que las cuentas usen un nombre
de usuario de Azure AD enrutable.
Figura 1-18 Página de configuración de inicio de sesión de Azure
AD
10. En la página Filtrado de dominios y unidades organizativas,
seleccione si desea sincronizar todos los objetos o solo los objetos
de dominios y unidades organizativas específicos.
11. En la página Identificar usuarios de forma exclusiva que
se muestra en la Figura 1-19 , especifique cómo se identificarán a
los usuarios. De forma predeterminada, los usuarios solo deben
tener una representación en todos los directorios. Si los usuarios
existen en varios directorios, puede tener coincidencias
identificadas por un atributo específico del directorio activo, siendo
el atributo de correo el valor predeterminado .
Figura 1-19 Página de identificación única de sus usuarios
12. En la página Filtrar usuarios y dispositivos , especifique si
desea sincronizar todos los usuarios y dispositivos o solo los
miembros de un grupo específico. La figura 1-20 muestra a los
miembros del grupo de usuarios piloto de Microsoft 365 que se
configuran para que sus cuentas se sincronicen con Azure.
Figura 1-20 Página Filtrar usuarios y dispositivos
13. En la página Funciones opcionales que se muestra en
la Figura 1-21 , seleccione las funciones opcionales que desee
configurar. Estas características incluyen lo siguiente:
Figura 1-21 Página de características opcionales
• Implementación híbrida de Exchange Esta opción es
adecuada para organizaciones que tienen una implementación de
Office 365 y donde hay buzones de correo alojados tanto en las
instalaciones como en la nube.
• Carpetas públicas de correo de Exchange Esta función
permite a las organizaciones sincronizar objetos de carpetas
públicas habilitadas para correo desde un entorno de Active
Directory local con Microsoft 365.
• Aplicación y filtrado de atributos de Azure AD
Al seleccionar esta opción, puede ser más selectivo sobre qué
atributos se sincronizan entre el entorno local y Azure AD.
• Sincronización de contraseña Sincroniza un hash de la
contraseña local de Azure AD del usuario. Cuando el usuario se
autentica en Azure AD, la contraseña enviada se codifica mediante
el mismo proceso y, si los hashes coinciden, se autentica al
usuario. Cada vez que un usuario actualiza su contraseña local, el
hash de contraseña actualizado se sincroniza con Azure AD.
• Reescritura de contraseñas La reescritura de contraseñas
permite a los usuarios cambiar sus contraseñas en la nube y que la
contraseña modificada se vuelva a escribir en la instancia de Active
Directory local.
• Reescritura de grupos Los cambios realizados en grupos en
Azure AD se escriben de nuevo en la instancia de AD local.
• Escritura diferida de dispositivos La información sobre los
dispositivos registrados por el usuario en Azure AD se vuelve a
escribir en la instancia de AD local.
• Sincronización de atributos de extensión de directorio Le
permite extender el esquema de Azure AD en función de las
extensiones realizadas en la instancia de Active Directory local de
su organización.
En la página Listo para configurar , puede elegir iniciar la sincronización
o habilitar el modo de ensayo. Cuando configure el modo de ensayo,
Azure AD Connect preparará el proceso de sincronización, pero no
sincronizará ningún dato con Azure AD.
Usar sufijos UPN y dominios no enrutables

Antes de realizar la sincronización entre un entorno de Active Directory
local y una instancia de Azure Active Directory, debe asegurarse de que
todos los objetos de cuenta de usuario en el entorno de Active Directory
local estén configurados con un valor para el sufijo UPN que pueda
funcionar tanto para el entorno local y cualquier aplicación con la que
desee utilizarlo en la nube. Esto no es un problema cuando el sufijo de
dominio de Active Directory interno de una organización es un dominio
enrutable públicamente. Por ejemplo, un nombre de dominio,
como contoso.como
adatum.com, que se puede resolver mediante servidores DNS públicos, será
suficiente. Las cosas se vuelven más complicadas cuando el sufijo de
dominio de Active Directory interno de la organización no se puede
enrutar públicamente.
Si un dominio no es enrutable, el dominio de instancia de Azure AD
predeterminado, como adatum2020.onmicrosoft.com, debe usarse para el
sufijo UPN. Esto requiere modificar el sufijo UPN de las cuentas
almacenadas en la instancia de Active Directory local. No se admite la
modificación de UPN después de que se haya producido la sincronización
inicial. Por lo tanto, debe asegurarse de que los UPN de Active Directory
locales estén configurados correctamente antes de realizar la
sincronización inicial con Azure AD Connect. Realice los siguientes pasos
para agregar un sufijo UPN al Active Directory local si el dominio de
Active Directory usa un espacio de nombres no enrutable:
1. Abra la consola Dominios y confianza de Active Directory y
seleccione Dominios y confianzas de Active Directory .
2. En el menú Acción , haga clic en Propiedades .
3. En la pestaña Sufijos UPN , ingrese el sufijo UPN que se usará con
Azure Active Directory. La figura 1-22 muestra el sufijo UPN
de epistemicus.com.
Figura 1-22 Configuración del sufijo UPN para un dominio

enrutable
4. Una vez que se ha agregado el sufijo UPN en el cuadro de diálogo
Dominios y confianzas de Active Directory , puede asignar el
sufijo UPN a las cuentas de usuario. Puede hacer esto manualmente,
como se muestra en la Figura 1-23 , usando
la pestaña Cuenta del cuadro de diálogo Propiedades del usuario .
Figura 1-23 Configurar UPN

5. También puede utilizar scripts de Microsoft PowerShell para
restablecer los UPN de varias cuentas de usuario. Por ejemplo, la
siguiente secuencia de comandos restablece los sufijos UPN de
todas las cuentas de usuario del epistemicus.internaldominio
a epistemicus.onmicrosoft.com.
Get-ADUser -Filter {UserPrincipalName -like
"*@epistemicus.internal"} -SearchBase
"DC = epistémico, DC = interno" |

ForEach-Object {
$ UPN =
$ _. UserPrincipalName.Replace ("epistemicus.internal",
"epistemicus.onmicrosoft.com")
Set-ADUser $ _ -UserPrincipalName $ UPN
Opciones de inicio de sesión

Azure AD Connect admite una variedad de opciones de inicio de
sesión. Usted configura cuál desea usar al configurar Azure AD Connect. El
método predeterminado, Sincronización de contraseñas, es apropiado
para la mayoría de las organizaciones que usarán Azure AD Connect para
sincronizar identidades en la nube.
Sincronización de contraseña
Los valores hash de las contraseñas de los usuarios de Active Directory
locales se sincronizan con Azure AD y las contraseñas cambiadas se
sincronizan inmediatamente con Azure AD. Las contraseñas reales nunca
se envían a Azure AD y no se almacenan en Azure AD. Esto permite un
inicio de sesión único sin problemas para los usuarios de equipos que
están unidos a un dominio de Active Directory que se sincroniza con
Azure AD. Además, la sincronización de contraseñas le permite habilitar
la escritura diferida de contraseñas para la funcionalidad de autoservicio
de restablecimiento de contraseñas a través de Azure AD.
Autenticación de paso
Al autenticarse en Azure AD, la contraseña del usuario se valida con un
controlador de dominio de Active Directory local. Las contraseñas y los
hash de contraseñas no están presentes en Azure AD. La autenticación
PassThrough permite que se apliquen las políticas de contraseñas
locales. La autenticación PassThrough requiere que Azure AD Connect
tenga un agente en un equipo unido al dominio que hospeda la instancia
de Active Directory que contiene las cuentas de usuario relevantes. La
autenticación PassThrough también permite un inicio de sesión único sin
inconvenientes para los usuarios de máquinas unidas a un dominio.
Con la autenticación PassThrough, la contraseña del usuario se valida con
el controlador de Active Directory local. No es necesario que la
contraseña esté presente en Azure AD de ninguna forma. Esto permite
que las políticas locales, como las restricciones de horas de inicio de
sesión, se evalúen durante la autenticación en los servicios en la nube.
La autenticación PassThrough usa un agente simple en una máquina
unida a un dominio con Windows Server 2012 R2, Windows Server 2016
o Windows Server 2019 en el entorno local. Este agente escucha las
solicitudes de validación de contraseña. No requiere que ningún puerto
de entrada esté abierto a Internet.
Además, también puede habilitar el inicio de sesión único para los
usuarios en máquinas unidas a un dominio que se encuentran en la red
corporativa. Con el inicio de sesión único, los usuarios habilitados solo
necesitan ingresar un nombre de usuario para ayudarlos a acceder de
manera segura a los recursos de la nube.
Federación de Active Directory

Esto permite a los usuarios autenticarse en los recursos de Azure AD
mediante credenciales locales. Cuando elige la opción Federación con AD
FS, los Servicios de federación de Active Directory se instalan y
configuran; Además, se instala un servidor proxy de aplicación web para
facilitar la comunicación entre la implementación de AD FS local y
Microsoft Azure Active Directory. Esta es la configuración de
sincronización de identidad más complicada y solo es probable que se
implemente en entornos con configuraciones de identidad complicadas.
Más información Opciones de inicio de sesión de Azure AD Connect
Puede obtener más información sobre las opciones de inicio de sesión consultando el
siguiente artículo: https://docs.microsoft.com/en-us/azure/active-
directory/connect/active-directory-aadconnect-user-signin .
Implementar y administrar el restablecimiento de

contraseña de autoservicio de Azure AD
Algo que es difícil de implementar en un entorno local pero que es
relativamente sencillo de implementar en un entorno que usa Azure AD
como fuente de autoridad de identidad es el autoservicio de
restablecimiento de contraseñas. Un restablecimiento de contraseña de
autoservicio permite a los usuarios restablecer sus propias contraseñas
cuando las olvidan, en lugar de tener que ponerse en contacto con la mesa
de servicio y hacer que un miembro del personal de TI realice la tarea por
ellos. Para habilitar el autoservicio de restablecimiento de contraseña,
realice los siguientes pasos:
1. Abra el portal de Azure Active Directory
en https://aad.portal.azure.com con una cuenta que tenga permisos
de administrador de inquilinos.
2. En el centro de administración de Azure Active Directory, haga clic
en el nodo Usuarios , que abrirá la hoja Usuarios , como se
muestra en la Figura 1-24 .
Figura 1-24 Centro de administración de Azure Active Directory

3. En la hoja Usuarios del centro de administración de Azure Active
Directory, haga clic en Restablecer contraseña .
4. En la página Restablecimiento de contraseña - Propiedades ,
haga clic en Todo , como se muestra en la Figura 1-25 , para
habilitar el restablecimiento de contraseña de autoservicio para
todos los usuarios de Microsoft 365.
Figura 1-25 Habilitar el restablecimiento de contraseña de autoservicio
Una vez habilitado, los usuarios recibirán información adicional la
próxima vez que inicien sesión. Esta información se utilizará para
verificar sus identidades si utilizan la herramienta de autoservicio para
restablecer la contraseña. Los usuarios pueden restablecer sus
contraseñas navegando al sitio web
https://passwordreset.microsoftonline.com que se muestra en la Figura 1-
26 y completando el formulario.
Figura 1-26 Restablecer contraseña

Más información Autoservicio Restablecimiento de contraseña
Puede obtener más información sobre cómo configurar la contraseña de autoservicio
en https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-
howitworks .
Configure los métodos de autenticación,
incluidos el hash de contraseña y la
autenticación PassThrough (PTA), OATH y
Otro aspecto importante en el diseño de la autenticación es decidir qué
métodos de autenticación serán compatibles con las cuentas en la
instancia de Azure AD de su organización. Por ejemplo, debe decidir si
desea admitir el restablecimiento de contraseña de autoservicio o la
autenticación multifactor de Azure, como se muestra en la figura 1-27 .
Figura 1-27 Múltiples métodos para verificar la identidad durante la
autenticación
Puede usar los métodos de autenticación que se enumeran en la Tabla 1-
1 con cuentas hospedadas en Azure Active Directory.
Tabla 1-1 Métodos de autenticación y uso
Método de autentificación Donde se puede utilizar
Contraseña Autenticación multifactor y restablecimiento de con

autoservicio
Preguntas de seguridad Solo restablecimiento de contraseña de autoservicio
Dirección de correo electrónico Solo restablecimiento de contraseña de autoservicio
Aplicación Microsoft Autenticación multifactor y restablecimiento de con

Authenticator autoservicio
Tokens de hardware OATH Autenticación multifactor y restablecimiento de con

autoservicio
SMS Autenticación multifactor y restablecimiento de con

autoservicio
Llamada de voz Autenticación multifactor y restablecimiento de con

autoservicio
Contraseñas de la aplicación Autenticación multifactor en algunos casos

Estos métodos de autenticación tienen las siguientes propiedades:
• Contraseña La contraseña asignada a una cuenta de Azure
AD es un método de autenticación. Si bien puede realizar una
autenticación sin contraseña, no puede deshabilitar la contraseña
como método de autenticación.
• Preguntas de seguridad Solo están disponibles para el
restablecimiento de contraseña de autoservicio de Azure AD y solo
se pueden usar con cuentas a las que no se les han asignado roles
administrativos. Las preguntas se almacenan en el objeto de
usuario dentro de Azure AD y un administrador no puede leerlas ni
modificarlas. Deben usarse junto con otro método. Azure AD
incluye las siguientes preguntas predefinidas y es posible crear
preguntas personalizadas:
• ¿En qué ciudad conoció a su primer cónyuge / pareja?
• ¿En que ciudad se reunieron tus padres?
• ¿En qué ciudad vive su hermano más cercano?
• ¿En qué ciudad nació tu padre?
• ¿En qué ciudad fue tu primer trabajo?
• ¿En qué ciudad nació tu madre?
• ¿En qué ciudad estabas el año nuevo del 2000?
• ¿Cuál es el apellido de tu maestro favorito en la escuela
secundaria?
• ¿Cuál es el nombre de la universidad a la que solicitó
pero no asistió?
• ¿Cómo se llama el lugar en el que celebró su primera
recepción nupcial?
• ¿Cuál es el segundo nombre de tu padre?
• ¿Cuál es tu comida favorita?
• ¿Cuál es el nombre y apellido de su abuela materna?
• ¿Cuál es el segundo nombre de tu madre?
• ¿Cuál es el mes y año del cumpleaños de su hermano
mayor? (por ejemplo, noviembre de 1985)
• ¿Cuál es el segundo nombre de su hermano mayor?
• ¿Cuál es el nombre y apellido de su abuelo paterno?
• ¿Cuál es el segundo nombre de su hermano menor?
• ¿A qué escuela asistió en sexto grado?
• ¿Cuál fue el nombre y apellido de tu mejor amigo de la
infancia?
• ¿Cuál fue el nombre y apellido de su primera pareja?
• ¿Cuál era el apellido de su maestro de escuela primaria
favorito?
• ¿Cuál fue la marca y el modelo de su primer automóvil o
motocicleta?
• ¿Cómo se llamaba la primera escuela a la que asistió?
• ¿Cómo se llamaba el hospital en el que nació?
• ¿Cómo se llamaba la calle de la primera casa de su
infancia?
• ¿Cómo se llamaba el héroe de su infancia?
• ¿Cómo se llamaba su peluche favorito?
• ¿Cuál era el nombre de tu primera mascota?
• ¿Cuál era su apodo de la infancia?
• ¿Cuál fue tu deporte favorito en la escuela secundaria?
• ¿Cuál fue su primer trabajo?
• ¿Cuáles fueron los últimos cuatro dígitos del número de
teléfono de su niñez?
• Cuando eras joven, ¿qué querías ser de mayor?
• ¿Quién es la persona más famosa que has conocido?
• Dirección de correo electrónico Esto solo se usa para
restablecimientos de contraseñas de autoservicio de Azure AD y
debe ser independiente de la dirección de correo electrónico de
Microsoft 365 Exchange Online del usuario.
• La aplicación Microsoft Authenticator está disponible para
Android e iOS. O implica que se notifique al usuario a través de la
aplicación móvil y se le pida que seleccione el mismo número en la
aplicación móvil que se muestra en el mensaje de inicio de sesión, o
que el usuario ingrese un conjunto de números que cambian
periódicamente que se muestran en la aplicación móvil.
• Tokens de hardware OATH Azure AD admite el uso
de tokens OATH-TOTP SHA-1 de 30 y 60 segundos. Las claves
secretas pueden tener un máximo de 128 caracteres. Una vez que
se adquiere un token, se debe cargar en formato separado por
comas, incluido UPN, número de serie, clave secreta, intervalo de
tiempo, fabricante y modelo. Tenga en cuenta que OATH es
diferente de OAuth. OATH es una arquitectura de referencia para la
autenticación; OAuth es un estándar relacionado con la
autorización.
• Teléfono móvil Puede usarse para enviar un código a través
de un mensaje de texto que debe ingresarse en un cuadro de
diálogo para completar la autenticación o cuando se realiza una
llamada telefónica al usuario que luego debe proporcionar un PIN
de autenticación personal. Los números de teléfono deben incluir el
código del país.
• Contraseñas de aplicaciones Varias aplicaciones que no son
de navegador no admiten la autenticación multifactor. Una
contraseña de aplicación permite que estos usuarios continúen
autenticándose utilizando estas aplicaciones cuando no se admite
la autenticación multifactor. Se puede generar una contraseña de
aplicación para cada aplicación, lo que permite revocar cada
contraseña de aplicación individualmente.
Más información Métodos de autenticación
Puede obtener más información sobre los métodos de autenticación
en https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-
authentication-methods .
Autenticación basada en certificados

La autenticación basada en certificados le permite eliminar la necesidad
de una combinación de nombre de usuario y contraseña. La autenticación
basada en certificados es compatible con dispositivos Windows, Android
e iOS y tiene los siguientes requisitos:
• Solo es compatible con entornos federados para aplicaciones
de navegador o donde los clientes nativos usan autenticación
moderna a través de la biblioteca de autenticación de Active
Directory (ADAL). Exchange Active Sync (EAS) para Exchange
Online (EXO) está exento del requisito de federación y se puede
usar con cuentas tanto federadas como administradas.
• La entidad emisora de certificados (CA) raíz de la
organización y las CA intermedias deben integrarse con Azure AD.
• Cada CA organizacional debe publicar una Lista de revocación
de certificados (CRL) en una ubicación que sea accesible a Internet.
• El dispositivo Windows, Android o iOS debe tener acceso a
una CA organizacional que esté configurada para emitir certificados
de cliente.
• El dispositivo Windows, Android o iOS debe tener instalado
un certificado válido.
• Los clientes de Exchange ActiveSync requieren que el
certificado de cliente incluya la dirección de correo electrónico
enrutable del usuario en el campo Nombre alternativo del sujeto.
Para agregar una CA organizacional en la que Azure Active Directory
confíe, debe asegurarse de que la CA esté configurada con una ubicación
de publicación CRL que sea accesible en Internet y luego exportar el
certificado de CA. Una vez que haya exportado el certificado de CA, que
incluirá la ubicación accesible a Internet donde se publica la CRL, use
el New-AzureADTrustedCertificateAuthoritycmdlet de PowerShell para
agregar el certificado de CA de la organización a Azure Active
Directory. Puede ver una lista de CA de confianza para la instancia de
Azure AD de su organización mediante el Get-
AzureADTrustedCertificateAuthoritycmdlet.
Más información Autenticación de Azure AD basada en certificados
Puede obtener más información sobre la autenticación de Azure AD basada en
certificados en https://docs.microsoft.com/en-us/azure/active-
directory/authentication/active-directory-certificate-based-authentication-get-started .
Autenticación sin contraseña

La autenticación sin contraseña le permite reemplazar la autenticación
usando una contraseña con autenticación que requiere "algo que usted
tiene" y "algo que sabe". Un ejemplo de esto podría ser un biométrico
como su rostro o huella dactilar combinada con un código generado por
un dispositivo autenticador.
Microsoft ofrece actualmente tres opciones de autenticación sin
contraseña. Estos son
• Windows Hello para empresas Este método utiliza
tecnologías de autenticación biométrica incluidas con las
computadoras con Windows, como cámaras compatibles con
Windows Hello para reconocimiento facial o lectores de huellas
digitales compatibles con Windows Hello. Más apropiado para
usuarios que son las únicas personas que interactúan con una
computadora Windows específica de forma regular.
• Iniciar sesión con llave de seguridad Permite el acceso a
través de llaves de seguridad FIDO2. Este método es apropiado
para los usuarios que inician sesión en máquinas compartidas,
como las de un centro de llamadas. Debido a que requiere la clave
de seguridad física FIDO2, este también es un método excelente
para proteger las identidades privilegiadas porque esta clave, a su
vez, puede guardarse en una caja fuerte para la que otra persona
tiene el código de acceso.
• Inicio de sesión telefónico a través de la aplicación
Microsoft Authenticator La aplicación Microsoft Authenticator se
ejecuta en teléfonos iOS y Android y admite la verificación de
identidad mediante autenticación biométrica o basada en PIN. Al
usar este método, se le pedirá al usuario en la pantalla que
seleccione un número específico que se muestra entre una lista de
opciones en la aplicación Microsoft Authenticator, así como que
realice la verificación de identidad a través de datos biométricos o
un PIN.
La implementación de la autenticación sin contraseña requiere las
siguientes funciones administrativas:
• Rol de administrador global que permite la implementación
de la experiencia de registro combinada en el directorio.
• Administrador de autenticación Función que puede
implementar y administrar métodos de autenticación para cuentas
de usuarios individuales.
• Usuario Aunque no es un rol administrativo, esta cuenta es
necesaria para poder configurar una aplicación de autenticación en
un dispositivo o inscribir un dispositivo de seguridad para sus
cuentas específicas una vez que la autenticación sin contraseña está
habilitada para sus cuentas.
Para habilitar la autenticación de inicio de sesión telefónico sin
contraseña, realice los siguientes pasos:
1. En el portal de administración de Azure Active Directory, haga clic
en Seguridad .
2. En la página Seguridad que se muestra en la Figura 1-28 , haga clic
en Métodos de autenticación .
Figura 1-28 Sección de métodos de autenticación de la página
Seguridad
3. En la página Métodos de autenticación que se muestra en
la Figura 1-29 , seleccione el método de autenticación que desea
habilitar, cambie el control deslizante a Activado y luego elija si
desea habilitar el método de autenticación para algunos o todos los
usuarios de Azure AD eligiendo Todos los usuarios. o seleccione
Usuarios .
Figura 1-29 Habilite el método de autenticación sin contraseña
Más información Autenticación de Azure AD sin contraseña
Puede obtener más información sobre la autenticación sin contraseña
en https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-
authentication-passwordless .
Transferir suscripciones de Azure entre inquilinos

de Azure AD
Cada suscripción de Azure está asociada y puede confiar solo en un
arrendamiento de Azure AD específico. Se pueden asociar varias
suscripciones a un arrendamiento específico. Esto permite que diferentes
partes de una organización usen un solo conjunto de cuentas de usuario
en múltiples suscripciones. Por ejemplo, su organización puede tener una
suscripción de producción para los recursos de producción, una
suscripción de desarrollo para los recursos del entorno de desarrollo y
suscripciones individuales para los desarrolladores individuales. No se
puede asociar una única suscripción a varios arrendamientos de Azure
AD. Sin embargo, es posible transferir la tenencia de Azure AD con la que
está asociada una suscripción.
Las razones por las que podría necesitar transferir suscripciones de Azure
incluyen
• Su organización adquiere otra organización. Desea mover sus
suscripciones de Azure existentes a un arrendamiento central. Por
ejemplo, Contoso adquiere Fabrikam, que tiene 3 suscripciones de
Azure existentes, mientras que Contoso tiene 10. Contoso quiere
mover las 3 suscripciones de Fabrikam Azure existentes en el
arrendamiento de Contoso Azure AD.
• Su organización va a escindir una subsidiaria y desea mover
una o más suscripciones a un nuevo directorio.
• Una suscripción ha caducado y ha perdido el acceso a los
recursos asociados con esa suscripción. Puede asociar otra
suscripción con la tenencia de Azure AD de esa suscripción original
y transferir los recursos existentes a la nueva suscripción.
Cuando cambia la asociación de Azure AD de una suscripción, todos los
usuarios a los que se les hayan asignado roles a través del control de
acceso basado en roles, sobre el que obtendrá más información más
adelante en este capítulo, también perderán el acceso. Además, la
transferencia de una suscripción a un arrendamiento de Azure AD
diferente elimina las asignaciones de políticas.
Antes de transferir una suscripción a un nuevo arrendamiento de Azure
AD, debe tener una cuenta que tenga la asignación de rol de propietario
para la suscripción. Esta cuenta debe existir tanto en el directorio actual
como en el nuevo. Puede agregar una cuenta de un arrendamiento de
Azure AD a otro con usuarios de colaboración B2B.
Más información AÑADIR usuarios de colaboración B2B
Puede obtener más información sobre los usuarios de colaboración B2B
en https://docs.microsoft.com/en-us/azure/active-directory/b2b/add-users-administrator .
Para transferir una suscripción existente de un inquilino de Azure AD a

otro, realice los siguientes pasos:
1. En la página Suscripciones de Azure Portal, seleccione Cambiar
directorio . Esto solo será posible si la cuenta utilizada para
realizar esta operación tiene los permisos necesarios para realizar
esta acción.
2. En el cuadro de diálogo Cambiar el directorio que se muestra en
la Figura 1-30 , seleccione la tenencia de Azure AD con la que desea
asociar la suscripción y seleccione Cambiar , que cambiará la
tenencia.
Figura 1-30 Cuadro de diálogo Cambiar el directorio

Más información Asociar una suscripción con un inquilino diferente
Puede obtener más información sobre cómo asociar una suscripción con un inquilino
diferente en https://docs.microsoft.com/en-us/azure/active-
directory/fundamentals/active-directory-how-subscriptions-associated-directory .
Sugerencia para el examen
Recuerde que puede asignar derechos a una aplicación asociando la
entidad de servicio de la aplicación con roles específicos de Azure
AD.
HABILIDAD 1.2: CONFIGURAR EL ACCESO

SEGURO MEDIANTE AZURE AD
Azure AD Privileged Identity Management (PIM) le permite asignar roles
de Azure AD y Azure Role Based Access Control (RBAC) a los usuarios de
forma temporal en lugar de permanente. Los roles se pueden otorgar a
pedido o sujetos a condiciones tales como que el solicitante realice la
autenticación multifactor (MFA) o que su solicitud sea revisada y
aprobada por otro usuario. Las solicitudes de activación de roles se
registran, lo que brinda a las organizaciones la capacidad de auditar el uso
de privilegios administrativos en la suscripción de Azure. Este objetivo
trata de monitorear el acceso privilegiado, configurar revisiones de
acceso y el proceso de activación de PIM.
Supervisar el acceso privilegiado para Azure AD

Privileged Identity Management (PIM)
Privileged Identity Management (PIM) le permite implementar la
activación de roles administrativos basada en el tiempo y en la
aprobación. Por ejemplo, puede configurar PIM para que un miembro del
personal de soporte de la mesa de ayuda solo tenga derecho a cambiar la
contraseña de un usuario durante un máximo de 60 minutos una vez que
la solicitud de ese derecho haya sido aprobada por un usuario autorizado
específico. PIM difiere de los modelos administrativos anteriores en los
que la mesa de ayuda siempre puede cambiar las contraseñas de los
usuarios de Azure AD. PIM le permite hacer lo siguiente:
• Configure el acceso privilegiado justo a tiempo a Azure AD y
los recursos de Azure. El acceso justo a tiempo es un acceso
limitado a una cantidad de tiempo, en lugar de proporcionar acceso
permanente a esos recursos.
• Asigne acceso de duración determinada a los recursos
mediante fechas de inicio y finalización.
• Requiere la aprobación de otro usuario al activar roles
privilegiados.
• Requiere que se produzca la autenticación multifactor antes
de la activación del rol.
• Exija a los usuarios que proporcionen una justificación escrita
registrada de por qué necesitan realizar la activación. Esto permite
a los auditores en una etapa posterior correlacionar la actividad
administrativa que ocurre con la razón declarada para
proporcionar acceso privilegiado.
• Proporcione notificaciones, como alertas por correo
electrónico enviadas a una lista de distribución, cuando se activan
los roles privilegiados.
• Realice revisiones de acceso para determinar la frecuencia
con la que se utilizan los privilegios y si los usuarios específicos aún
requieren roles.
• Exporte un historial de auditoría que pueda ser examinado
por auditores internos o externos.
Para ver toda la actividad asociada con los roles de Azure AD, debe ver el
historial de auditoría de recursos. Para ver el historial de auditoría de
recursos, realice los siguientes pasos:
1. En la hoja del centro de administración de Azure AD de Azure
Portal, seleccione Identity Governance en el área Administrar ,
Figura 1-31 Gobierno de identidad
2. En la hoja Identity Governance , seleccione Azure AD
Roles en Privileged Identity Management .
3. Haga clic en Auditoría de recursos y luego use los filtros para ver
la información apropiada, como se muestra en la Figura 1-32 .
Figura 1-32 Auditoría de recursos
Más información Ver historial de auditoría
Puede obtener más información sobre cómo revisar los registros de auditoría de PIM
en https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-
management/pim-how-to-use-audit-log .
Configurar revisiones de acceso

Se han producido muchos incidentes de seguridad porque un atacante ha
obtenido acceso a través de una cuenta olvidada con privilegios
administrativos. Las revisiones de acceso le permiten determinar si las
asignaciones de funciones de PIM existentes siguen siendo relevantes y
qué asignaciones de funciones se pueden eliminar porque ya no se
utilizan activamente.
Hay dos tipos de revisión de acceso: revisiones de acceso de roles de PIM
de recursos de Azure y revisiones de acceso de roles de PIM de Azure
AD. Para realizar una revisión de acceso de un rol de PIM de recursos de
Azure, realice los siguientes pasos:
1. En la hoja del centro de administración de Azure AD de Azure
Portal, seleccione Identity Governance en el área Administrar y
luego seleccione Privileged Identity Management .
2. En la hoja Privileged Identity Management , haga clic
en Recursos de Azure , como se muestra en la Figura 1-33 .
Figura 1-33 Recursos de Azure

3. Las revisiones de acceso existentes se mostrarán en el informe que
se muestra en la Figura 1-34 .
Figura 1-34 Informe de revisión de acceso a recursos de Azure

4. Haga clic en Nuevo para crear una nueva revisión de acceso. Provee
la siguiente informacion:
1. Nombre de revisión de acceso Un nombre para la
revisión de acceso.
2. Fecha de inicio Fecha en la que está programado el
inicio de la revisión.
3. Frecuencia Con qué frecuencia debe realizarse la
revisión. Puede elegir una frecuencia de una vez, semanal,
mensual, trimestral, anual o semestral.
4. Duración Especifique el número de días durante los
que se realizará la revisión de acceso. Una duración más larga
le dará una mejor idea de la frecuencia con la que se utilizan
los roles privilegiados.
5. Finalizar Especifique cómo finalizar las revisiones de
acceso recurrentes. Puede especificar una fecha de
finalización o configurar la revisión para que finalice después
de un número específico de ciclos.
6. Usuarios Especifique los roles de los que está
revisando la membresía.
7. Revisores Especifique qué personas revisarán a todos
los usuarios.
8. Al finalizar Como se muestra en la Figura 1-35 ,
configure cómo desea que se implementen los resultados de
la revisión de acceso. Si desea eliminar automáticamente el
acceso de los usuarios, establezca Aplicar resultados
automáticamente a los recursos en Habilitar . Si desea
aplicar los resultados manualmente una vez finalizada la
revisión, configúrelo en Desactivar .
Figura 1-35 Configuración al finalizar
• Si el revisor no responde En este menú desplegable, tiene
las siguientes opciones:
• Sin cambios Esto asegurará que no se realicen cambios
en la configuración PIM actual.
• Eliminar acceso Esto eliminará el acceso de los
usuarios donde el acceso ya no sea necesario.
• Aprobar acceso Aprobar el acceso de los usuarios.
• Tomar recomendaciones Utilice las del sistema
cuando se trata de eliminar o aprobar el acceso continuo.
Los pasos para configurar una revisión de acceso de un rol PIM de Azure
AD son similares a los que realiza al configurar una revisión para los
recursos de Azure, excepto que selecciona Roles de Azure AD en lugar
de Recursos de Azure en el menú Administrar de la hoja Privileged
Identity Management de el centro de administración de Azure AD.
Más información Revisar el acceso a los roles de Azure AD
us/azure/active-directory/privileged-identity-management/pim-how-to-perform-security-
review .
Activar y configurar PIM

Azure AD Privileged Identity Management (PIM) le permite hacer que la
asignación de roles sea temporal y supeditada a la aprobación, en lugar de
hacer que la asignación de roles sea permanente, como es el caso cuando
agrega manualmente un miembro al rol. PIM requiere Azure AD P2, que
debe estar habilitado antes de poder configurarlo. Para configurar un rol
administrativo de Azure AD para su uso con PIM, realice los siguientes
pasos:
1. En el centro de administración de Azure AD, seleccione Roles y
administradores .
2. Seleccione la función a la que desea agregar un usuario. Esto abrirá
la página de propiedades del rol.
3. En la página Propiedades del rol , haga clic en Administrar en
PIM . El rol se abrirá y todos los miembros asignados
permanentemente al rol aparecerán en la lista con el estado
de Permanente , como se muestra en la Figura 1-36 .
Figura 1-36 Miembros del rol de administradores de contraseñas

4. Seleccione el usuario que desea convertir
de permanente a elegible . Un usuario elegible puede solicitar
acceso al rol, pero ese usuario no tendrá sus derechos y privilegios
asociados hasta que se le otorgue ese acceso. En la página de
propiedades del usuario, haga clic en Hacer elegible .
Puede editar las condiciones bajo las cuales se puede otorgar un usuario
elegible realizando los siguientes pasos:
1. En la hoja Privileged Identity Management , haga clic en Azure
AD Roles .
2. En Administrar , como se muestra en la Figura 1-37 , haga clic
en Configuración .
Figura 1-37 Administrar PIM
3. Haga clic en Roles y luego seleccione el rol que desea configurar. La
Figura 1-38 muestra la configuración de PIM para el rol de
administrador de seguridad, donde la activación del rol puede
ocurrir durante una hora como máximo, pero donde no se requiere
MFA y una aprobación.
Figura 1-38 Administrar la configuración de PIM para un rol
Los usuarios pueden activar roles para los que son elegibles desde el
área Privileged Identity Management de la consola administrativa de
Azure AD. Los administradores con los permisos adecuados también
pueden usar el área Privileged Identity Management de la consola
administrativa de Azure AD para aprobar solicitudes que requieren
aprobación y revisar activaciones de roles.
Más información Gestión de identidad privilegiada
us/azure/active-directory/privileged-identity-management/pim-configure .
PIM requiere que configure los usuarios de Azure AD con las licencias
adecuadas. PIM requiere que se asigne una de las siguientes categorías de
licencia a los usuarios que realizarán tareas relacionadas con PIM:
• Azure AD Premium P2
• Enterprise Mobility + Security (EMS) E5
• Microsoft 365 M5
Las tareas relacionadas con PIM que requieren una licencia son las
siguientes:
• Cualquier usuario que sea elegible para un rol de Azure AD
administrado mediante PIM
• Cualquier usuario que pueda aprobar o rechazar solicitudes
de activación de PIM
• Usuarios asignados a roles de recursos de Azure con
asignaciones justo a tiempo o basadas en el tiempo
• Cualquier usuario que pueda realizar una revisión de acceso
• Cualquier usuario asignado a una revisión de acceso
Más información Requisitos de la licencia PIM
Puede obtener más información sobre los requisitos de licencia de PIM
en https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-
management/subscription-requirements .
No puede usar PIM para administrar las siguientes funciones clásicas de

administrador de suscripción:
• Administrador de cuenta
• Administrador de servicios
• Co-administrador
A la primera persona que active PIM se le asignarán los roles de
administrador de seguridad y administrador privilegiado para el
arrendamiento.
Más información Activación de la gestión de identidades privilegiadas
us/azure/active-directory/privileged-identity-management/pim-security-wizard .
Implementar políticas de acceso condicional,

incluida la autenticación multifactor
Las políticas de acceso condicional le permiten exigir que se tomen pasos
adicionales cuando ocurren ciertas circunstancias. Por ejemplo, puede
configurar una política de acceso condicional para requerir que se
produzca MFA si un usuario intenta acceder a un recurso específico en
Azure o si un usuario accede a Azure desde una ubicación inusual. Las
políticas de acceso condicional también se pueden usar para bloquear
completamente el acceso a los recursos de Azure cuando se cumplen
ciertas condiciones, como cuando alguien intenta acceder a una aplicación
desde una región en la que se han bloqueado los rangos de direcciones IP.
Políticas de acceso condicional

Las políticas de acceso condicional solo se aplicarán después de que se
haya completado la autenticación de primer factor. Las directivas de
acceso condicional requieren una suscripción a Azure AD P2 o
equivalente. Las políticas de acceso condicional más utilizadas incluyen
• Requerir MFA para todos los usuarios con roles
administrativos
• Requerir MFA antes de realizar tareas de administración de
Azure
• Bloquear inicios de sesión para protocolos de autenticación
heredados
• Requerir una ubicación de confianza al registrarse en Azure
MFA
• Bloquear el acceso desde ubicaciones específicas
• Requerir dispositivos administrados por la organización para
ciertas aplicaciones
Las políticas de acceso condicional se pueden aplicar según las
circunstancias del usuario que incluyen, entre otras, las siguientes:
• Ubicación de la dirección IP Un administrador puede
designar ciertos rangos de direcciones IP como confiables, como las
direcciones IP públicas asociadas con los dispositivos de puerta de
enlace de Internet de la organización. Los administradores también
pueden especificar rangos de direcciones IP regionales como
bloqueados de acceso, como los que pertenecen a personas que
intentan acceder a recursos desde Tasmania.
• Dispositivo Si el usuario está intentando acceder a los
recursos de Azure AD desde un dispositivo de confianza o desde un
nuevo dispositivo que no es de confianza.
• Aplicación Si el usuario está intentando acceder a una
aplicación de Azure AD específica.
• Membresía de grupo Si el usuario es miembro de un grupo
específico.
Además de la opción simple de bloquear el acceso, las políticas de acceso
condicional se pueden configurar para
• Requerir autenticación multifactor
• Requerir que un dispositivo se marque como compatible
• Requerir que el dispositivo esté unido a Hybrid Azure AD
• Requerir una aplicación cliente aprobada
• Requerir una política de protección de aplicaciones
Para crear una política de acceso condicional, realice los siguientes pasos:
1. En el área de Azure Active Directory de Azure Portal,
seleccione Seguridad y luego seleccione Acceso condicional ,
Figura 1-39 Página de seguridad con Acceso condicional resaltado
2. Sobre el acceso condicional | En la página Políticas que
se muestra en la Figura 1-40 , seleccione Nueva política .
Figura 1-40 Políticas de acceso condicional
3. En la página Nueva política de acceso condicional que
se muestra en la Figura 1-41 , proporcione la siguiente información:
1. Nombre Un nombre para la política de acceso
condicional.
2. Usuarios y grupos Usuarios y grupos a los que se
aplica la política.
3. Aplicaciones o acciones en la nube A qué aplicaciones
o acciones del usuario en la nube se aplica la política. Las
políticas pueden aplicarse a algunas o todas las aplicaciones
en la nube. También puede especificar acciones de usuario
específicas que activarán la directiva de acceso condicional,
como intentar acceder a un recurso de Azure específico,
como una máquina virtual.
4. Condiciones Las condiciones asociadas con la
póliza. Estos incluyen riesgo de usuario, riesgo de inicio de
sesión, plataformas de dispositivo, ubicaciones, aplicaciones
de cliente y estado del dispositivo.
5. Controles de acceso Seleccione qué controles
adicionales se requieren para otorgar acceso. Esto le brinda
la opción de requerir MFA, un dispositivo compatible, un
dispositivo híbrido unido a Azure AD, una aplicación cliente
aprobada, una política de protección de la aplicación o que el
usuario realice un cambio de contraseña.
6. Sesión Le permite especificar el comportamiento de
aplicaciones específicas en la nube. Las opciones
incluyen Control de aplicaciones de acceso
condicional , Frecuencia de inicio de sesión y Sesión de
navegador persistente .
7. Habilitar política Se puede configurar en Solo
informe , que debe usar para determinar cómo funcionará la
política antes de hacerla cumplir, habilitar la política o
deshabilitarla.
Figura 1-41 Nueva política de acceso condicional
4. Haga clic en Crear para crear la política.
Más información Políticas de acceso condicional
Puede obtener más información sobre las políticas de acceso condicional
en https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview .
Implementación de MFA
Al implementar MFA, debe tomar decisiones sobre qué capacidades de
MFA estarán disponibles para los usuarios asociados con la tenencia de
Azure AD de su organización. MFA requiere que se utilice más de un
método de autenticación al iniciar sesión en un recurso. Por lo general,
esto implica que el usuario proporcione sus credenciales de nombre de
usuario y contraseña, y luego proporcione uno de los siguientes:
• Un código generado por una aplicación de
autenticación. Puede ser la aplicación de autenticación de
Microsoft o una aplicación de autenticación de terceros, como la
aplicación de autenticación de Google.
• Una respuesta proporcionada a la aplicación de
autenticación de Microsoft Cuando se usa este método, Azure AD
proporciona un código en pantalla al usuario que se autentica y que
también debe seleccionarse en una aplicación que está registrada
con Azure AD.
• Una llamada telefónica a un número registrado con Azure
AD El usuario debe proporcionar un pin preconfigurado que el
servicio automatizado que realiza la llamada telefónica le indicará
que ingrese. Microsoft proporciona un saludo predeterminado
durante las llamadas telefónicas de autenticación, por lo que no
tiene que grabar uno para su propia organización.
• Un mensaje SMS enviado a un número de teléfono móvil
registrado en Azure AD El usuario proporciona el código enviado
en el mensaje como segundo factor durante la autenticación.
Al diseñar su solución, deberá tener una forma de garantizar que los
usuarios tengan acceso a la tecnología MFA adecuada. Esto puede
requerir que se le ocurra un método para asegurarse de que todos los
usuarios de su organización ya tengan la aplicación Microsoft
Authenticator instalada en sus dispositivos móviles antes de habilitar
MFA en sus cuentas.
Más información Plan para la autenticación multifactor
Puede obtener más información sobre el diseño de una solución de autenticación
multifactor para implementaciones de Office 365 en https://docs.microsoft.com/en-
us/office365/admin/security-and-compliance/multi-factor-authentication-plan .
MFA no está habilitado de forma predeterminada en los inquilinos de

Azure AD. Antes de que pueda configurar cuentas para usar MFA, deberá
habilitar MFA en el arrendamiento. Para habilitar MFA en un
arrendamiento de Azure AD y configurar MFA para usuarios específicos,
1. En el centro de administración de Azure Active Directory, navegue
hasta Usuarios y luego haga clic en Todos los usuarios .
2. Haga clic en Más y luego en Autenticación multifactor , como se
Figura 1-42 Configurar Azure MFA

3. Después de seleccionar esta opción, MFA se habilitará para el
arrendamiento y se le proporcionará una lista de usuarios similar a
la que se muestra en la Figura 1-43 .
Figura 1-43 Configurar usuarios para Azure MFA
4. Seleccione los usuarios que desea configurar para MFA, como se
muestra en la Figura 1-44 , y luego haga clic en Habilitar .
Figura 1-44 Habilitar Azure MFA

5. En el cuadro de diálogo Acerca de la activación de la
autenticación multifactor que se muestra en la Figura 1-45 , haga
clic en Activar autenticación multifactor .
Figura 1-45 Habilitación de la autorización multifactor
6. La próxima vez que los usuarios inicien sesión, se les pedirá que se
inscriban en la autenticación multifactor y se les presentará un
cuadro de diálogo similar al que se muestra en la Figura 1-46 ,
pidiéndoles que proporcionen información adicional.
Figura 1-46 Se requiere más información

7. Y luego elija entre proporcionar un número de teléfono móvil o un
número de teléfono de la oficina o configurar una aplicación móvil,
Figura 1-47 Preferencias de contacto

8. Cuando especifica una de estas opciones, se le presenta un código
QR. Dentro de la aplicación, puede agregar una nueva cuenta
escaneando el código QR. Una vez que haya configurado la
aplicación, se le pedirá que confirme que la configuración se
completó correctamente al aprobar un inicio de sesión a través de
la aplicación, como se muestra en la Figura 1-48 .
Figura 1-48 Verifique la aplicación
9. Una vez hecho esto, se le pedirá que proporcione información de
seguridad adicional en forma de número de teléfono, como se
Figura 1-49 Proporcione información de seguridad adicional

Puede configurar los siguientes ajustes del servicio de autenticación
multifactor, como se muestra en la Figura 1-50 .
• Contraseñas de aplicaciones Permitir o impedir que los
usuarios utilicen contraseñas de aplicaciones para aplicaciones que
no son de navegador y que no admiten la autenticación multifactor.
• Direcciones IP de confianza Configure una lista de
direcciones IP de confianza donde se omitirá MFA cuando se
configure la federación entre el entorno local y la tenencia de
Microsoft 365 Azure AD.
• Opciones de verificación Especifique qué opciones de
verificación están disponibles para los usuarios, incluidas llamadas
telefónicas, mensajes de texto, verificación basada en aplicaciones o
token de hardware.
• Recuerde la autenticación multifactor Decida si permitirá
que los usuarios recuerden la autenticación MFA durante un
período de tiempo específico en un dispositivo, de modo que no sea
necesario realizar MFA cada vez que el usuario inicie sesión. El
valor predeterminado es 14 días.
Figura 1-50 Configuración del servicio MFA
Más información Configurar la autenticación multifactor
Puede obtener más información sobre la autenticación multifactor
en https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-
howitworks .
Administrar usuarios de MFA

Una vez que MFA está configurado para los usuarios, puede haber ciertas
ocasiones en las que desee obligar a los usuarios a proporcionar métodos
de contacto actualizados, es posible que desee revocar todas las
contraseñas de aplicaciones o tal vez desee restaurar MFA en todos los
dispositivos recordados. Puede hacer esto realizando los siguientes pasos:
1. Con una cuenta a la que se le ha asignado el rol de administrador
global, abra el centro de administración de Azure AD y seleccione
el nodo Todos los usuarios , como se muestra en la Figura 1-
51 . Seleccione el usuario para administrar MFA.
Figura 1-51 Seleccione el usuario para administrar MFA

2. En la página de propiedades del usuario, seleccione Métodos de
autenticación .
3. En la página Métodos de autenticación que se muestra en
la Figura 1-52 , seleccione qué acción realizar.
Figura 1-52 Métodos de autenticación
Si desea realizar un restablecimiento masivo para varios usuarios, siga los
siguientes pasos:
1. En la página Todos los usuarios que se muestra en la Figura 1-53 ,
haga clic en Autenticación multifactor.
Figura 1-53 Lista de usuarios

2. En la página Usuarios de autenticación multifactor que se muestra
en la Figura 1-54 , seleccione los usuarios para los que desea
restablecer la configuración de MFA y haga clic en Administrar
configuración de usuario .
Figura 1-54 Seleccionar usuarios para restablecer MFA

3. En la página Administrar configuración de usuario que
se muestra en la Figura 1-55 , seleccione las tareas que desea
realizar, como solicitar a los usuarios que proporcionen métodos de
contacto nuevamente, eliminar todas las contraseñas de
aplicaciones existentes y restaurar MFA en dispositivos
recordados. Después de hacer la selección, haga clic en Guardar .
Figura 1-55 Gestión de la configuración de usuario

Más información Configuración de la autenticación multifactor
Puede obtener más información sobre cómo configurar la autenticación multifactor
en https://docs.microsoft.com/en-us/office365/admin/security-and-compliance/setup-
multi-factor-authentication .
Bloqueo de cuenta
La configuración de bloqueo de cuenta para MFA, que se muestra en
la Figura 1-56 , le permite configurar las condiciones bajo las cuales se
producirá el bloqueo de MFA. En esta página, puede configurar la
cantidad de denegaciones de MFA que activarán el proceso de bloqueo de
la cuenta, cuánto tiempo antes de que se restablezca el contador de
bloqueo de la cuenta y la cantidad de minutos hasta que se desbloquee la
cuenta. Por ejemplo, si el contador de bloqueo de la cuenta se restablece
después de 10 minutos y el número de denegaciones de MFA para activar
el bloqueo de la cuenta se establece en 5, entonces 5 denegaciones en 10
minutos activarán un bloqueo, pero 5 denegaciones en un transcurso de
30 minutos lo harán. no porque el contador de bloqueo de la cuenta se
reiniciaría durante ese período.
Figura 1-56 Configuración de bloqueo de cuenta
Bloquear / desbloquear usuarios

La configuración de usuario bloqueado que se muestra en la Figura 1-57
le permite bloquear usuarios específicos de un servidor MFA local para
que no puedan recibir una solicitud MFA. Todas las solicitudes enviadas a
un usuario de la lista de usuarios bloqueados se rechazarán
automáticamente. Los usuarios de esta lista permanecen bloqueados
durante 90 días, después de lo cual se eliminan de la lista de usuarios
bloqueados. Para desbloquear a un usuario bloqueado, haga clic
en Desbloquear .
Figura 1-57 Página Bloquear / Desbloquear usuarios
Configuración de alerta de fraude

La configuración de alerta de fraude, que se muestra en la Figura 1-58 , le
permite configurar si los usuarios pueden denunciar solicitudes de
verificación fraudulentas. Una solicitud de verificación fraudulenta puede
ocurrir cuando un atacante tiene acceso a la contraseña de un usuario
pero no tiene acceso a un método MFA alternativo. Un usuario se da
cuenta de esto al recibir un mensaje de MFA, ya sea a través de su
aplicación, un SMS o una llamada telefónica cuando no ha intentado
autenticarse en una carga de trabajo de Microsoft 365. Cuando un usuario
denuncia un fraude, puede elegir una opción para que su cuenta se
bloquee automáticamente durante 90 días, lo que indica que es probable
que la contraseña se vea comprometida.
Figura 1-58 Página de alerta de fraude
Tokens OATH
La página de tokens OATH que se muestra en la Figura 1-59 le permite
cargar un archivo CSV con formato especial que contiene los detalles y
claves de los tokens OATH que desea usar para la autenticación
multifactor. El archivo CSV con formato especial debe incluir una fila de
encabezado formateada como se muestra aquí con el UPN (nombre
principal del usuario), número de serie, clave secreta, intervalo de tiempo,
fabricante y modelo. Cada archivo está asociado a un usuario específico. Si
un usuario tiene varios tokens OATH, estos deben incluirse en el archivo
asociado con su cuenta.
Figura 1-59 Página de tokens OATH

Configuración de llamadas telefónicas
La configuración de llamadas telefónicas le permite configurar el número
de identificación de la persona que llama que se muestra cuando se
contacta al usuario para la autenticación MFA. Este número debe ser un
número de Estados Unidos. También puede usar la página de
configuración de llamadas telefónicas que se muestra en la Figura 1-
60 para configurar mensajes de voz personalizados. Los mensajes de voz
deben estar en formato .wavo .mp3, no deben tener más de 5 MB y deben
durar menos de 20 segundos.
Figura 1-60 Página de configuración de llamadas telefónicas

Más información Gestión de la configuración de MFA
Puede obtener más información sobre cómo administrar la configuración de MFA
en https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-
mfasettings .
Informar sobre la utilización de MFA

Azure MFA proporciona una serie de informes que puede usar para
comprender cómo se usa MFA en su organización, incluido
• Historial de usuarios bloqueados Proporciona un historial
de solicitudes para bloquear o desbloquear usuarios.
• Alertas de uso y fraude Proporciona información sobre un
historial de alertas de fraude enviadas por los usuarios. También
proporciona información sobre el uso general de MFA
• Uso de componentes locales Proporciona información sobre
la utilización de MFA a través de la extensión del servidor de
directivas de red, los servicios de federación de Active Directory y
el servidor MFA local.
• Historial de usuarios omitidos Proporciona información
sobre las solicitudes para omitir MFA por parte de un usuario
específico
• Estado del servidor Proporciona datos de estado de los
servidores MFA asociados con la tenencia de Azure AD de su
organización.
Más información Informes de autenticación multifactor de Azure
Puede obtener más información sobre los informes de autenticación multifactor de
Azure en https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-
mfa-reporting .

Recuerde los pasos que puede seguir para bloquear
automáticamente a los usuarios que responden incorrectamente a
las solicitudes de MFA.
Configurar la protección de identidad de Azure

AD
Azure AD Identity Protection le permite automatizar la detección y
corrección de riesgos basados en la identidad, incluidos los siguientes:
• Viajes atípicos Cuando el inicio de sesión de la cuenta de un
usuario indica que ha realizado cambios de ubicación
inusuales. Esto podría incluir que un usuario inicie sesión desde
Sydney y luego desde Los Ángeles en un período de dos horas,
cuando el vuelo entre las dos ciudades toma aproximadamente
siete veces esa cantidad de tiempo.
• Dirección IP anónima Cuando un usuario inicia sesión desde
una dirección IP anónima. Si bien un usuario puede estar usando
una VPN anónima para acceder a los recursos de la organización,
los atacantes también usan herramientas como los nodos TOR
cuando lanzan intentos de compromiso.
• Propiedades de inicio de sesión desconocidas Cuando
las propiedades de inicio de sesión de un usuario difieren
sustancialmente de las que se han observado en el pasado.
• Dirección IP vinculada con malware Cuando se sabe que la
dirección IP desde la que el usuario inicia sesión es parte de una
botnet de malware o ha mostrado otra actividad de red maliciosa
en el pasado.
• Credenciales filtradas Que las credenciales del usuario se
han descubierto en una filtración de datos, como las registradas
en haveIbeenpwned.com .
• Inteligencia de tratamiento de Azure AD Que el
comportamiento de inicio de sesión se correlaciona con un patrón
de ataque conocido identificado por las fuentes de inteligencia de
amenazas internas o externas de Microsoft.
La habilitación de la protección de identidad de Azure AD requiere una
licencia de Azure AD P2.
Azure AD Identity Protection le permite configurar dos tipos de política
de riesgo: una política de riesgo de inicio de sesión y una política de
riesgo de usuario:
• Riesgo de inicio de sesión Estas políticas analizan las señales
de cada inicio de sesión y determinan la probabilidad de que el
inicio de sesión no lo haya realizado la persona asociada a la cuenta
de usuario. Si se determina que un inicio de sesión es arriesgado,
los administradores pueden especificar si bloquear el acceso o
permitir el acceso, pero requieren autenticación multifactor.
• Riesgo del usuario Estas políticas se basan en la
identificación de desviaciones del comportamiento normal del
usuario. Por ejemplo, el usuario inicia sesión desde una ubicación
inusual en un momento que difiere sustancialmente de cuando
normalmente inicia sesión. Las políticas de riesgo del usuario
permiten a los administradores bloquear el acceso, permitir el
acceso o permitir el acceso, pero requieren un cambio de
contraseña cuando se activa la política.
Para habilitar las políticas de riesgo de inicio de sesión y riesgo de
usuario, realice los siguientes pasos:
1. En el centro de administración de Azure Active Directory,
seleccione Seguridad en el área Administrar y luego
seleccione Protección de identidad .
2. En la sección Proteger de la hoja Protección de identidad , que se
muestra en la Figura 1-61 , seleccione Política de riesgo del
usuario .
Figura 1-61 Hoja de protección de identidad

3. Haga clic en Política de riesgo del usuario . En la hoja Política de
riesgos del usuario , que se muestra en la Figura 1-62 , configure
las siguientes opciones.
Figura 1-62 Política de corrección de riesgos del usuario
4. Haga clic en Política de riesgo de inicio de sesión . En
la hoja Política de corrección de riesgos de inicio de sesión , que
se muestra en la Figura 1-63 , configure las siguientes opciones y
haga clic en Guardar :
1. Asignaciones: Usuarios Determinan a qué usuarios se aplica la
política de corrección de riesgos del usuario.
2. Asignaciones: Condiciones Le permite determinar en qué nivel de
riesgo se aplica la política. Puede elegir entre Bajo y superior , Medio y
superior o Alto .
3. Controles: Acceso Para una política de riesgo de usuario, puede
elegir entre Bloquear , Permitir y Permitir y requerir autenticación
multifactor .
4. Hacer cumplir la política La política se puede
activar en o apagado .
Figura 1-63 Política de corrección de riesgos de inicio de sesión
Más información Azure AD Identity Protection
Puede obtener más información sobre la protección de identidad de Azure AD
en https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-
identity-protection .
Recuerde los requisitos para habilitar MFA en un arrendamiento de
Azure AD.
HABILIDAD 1.3: ADMINISTRAR EL ACCESO

A LAS APLICACIONES
Este objetivo trata de los pasos que se pueden seguir para configurar y
administrar el acceso a las aplicaciones. Esto incluye comprender el
registro de la aplicación con un arrendamiento de Azure AD, administrar
el acceso a las propias aplicaciones, configurar los ámbitos de los
permisos de la aplicación, el consentimiento del permiso de la aplicación
y el acceso de la API a las suscripciones y recursos de Azure.
Esta sección cubre los siguientes temas:
• Crear registros de aplicaciones
• Configurar los alcances de los permisos de registro de
aplicaciones
• Administrar el consentimiento del permiso de registro de la
aplicación
• Administrar el acceso de API a suscripciones y recursos de
Azure
Crear registros de aplicaciones

Como aprendió anteriormente en este capítulo, registrar una aplicación
con Azure Active Directory le permite usar la funcionalidad de Azure
Active Directory, como la identidad del usuario y los permisos, con la
aplicación. Para registrar una aplicación con Azure Active Directory
mediante Azure Portal, realice los siguientes pasos:
1. En Azure Portal, abra la hoja Azure Active Directory .
2. En la sección Administrar que se muestra en la Figura 1-64 , haga
clic en Registros de aplicaciones .
Figura 1-64 Sección de registros de aplicaciones de la hoja de
Azure Active Directory
3. En la hoja Registros de aplicaciones de la sección Azure Active
Directory de Azure Portal, haga clic en Nuevo registro . La Figura
1-65 muestra el elemento Nuevo registro.
Figura 1-65 Hoja de registros de aplicaciones con la opción Nuevo

registro
4. En la página Registrar una aplicación , que se muestra en la Figura
1-66 , elija qué usuarios pueden usar esta aplicación o acceder a
esta API. Puede elegir entre las siguientes opciones:
1. Cuentas en este directorio organizativo solo Apropiado para
escenarios de un solo inquilino donde las únicas personas que usarán la
aplicación tienen cuentas que residen dentro de la instancia de Azure
AD. Puede cambiar a la opción de inquilino múltiple y volver a la opción
de inquilino único después de completar el registro mediante
la página Autenticación en Azure Portal.
2. Cuentas en cualquier directorio de la organización Elija esta
opción cuando desee que la aplicación esté disponible para los usuarios
de su propia tenencia y de otras instancias de Azure AD. Esto también se
conoce como la opción multiusuario. Puede cambiar entre esta opción y la
opción de inquilino único mediante la página Autenticación en Azure
Portal.
3. Cuentas en cualquier directorio organizativo y cuentas
personales de Microsoft Esta opción permite no solo a los usuarios que
tienen cuentas en los arrendamientos de Azure AD, sino también a las
cuentas personales de Microsoft, como las cuentas
de Hotmail.com y outlook.com . Actualmente, no puede cambiar de este
modo a multiusuario o inquilino único en Azure Portal, pero puede
realizar este cambio si usa el editor de manifiesto de la aplicación.
Figura 1-66 Tipos de cuenta admitidos para el registro de

aplicaciones
5. La sección Redirect URI (Optional) , que se muestra en la Figura 1-
67 , le permite especificar el tipo de aplicación que se está
registrando, con las opciones Web oCliente público (móvil y
escritorio) . Si está registrando una aplicación web, debe
especificar la URL base de la aplicación (por
ejemplo, https://newapp.tailwindtraders.net:31544 ). Si elige la
opción Cliente público, en su lugar debe proporcionar el
Identificador uniforme de recursos (URI) que Azure AD usará para
devolver respuestas de token específicas de la aplicación que está
registrando.
Figura 1-67 URI de redireccionamiento
6. Después de proporcionar esta información, haga clic
en Registrarse .
Una vez que se completa el proceso de registro de la aplicación, se le
asignará una aplicación única o ID de cliente y se incluirá en
la página Registros de la aplicación en el portal de Azure, como se
Figura 1-68 Registros de aplicaciones

Más información Registro de una aplicación
Puede obtener más información sobre cómo registrar una solicitud
en https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-
app .
Administrar el acceso a las aplicaciones

La forma de asignar el acceso a las aplicaciones depende de la edición de
Azure AD para la que su organización tenga licencia. Si su organización
solo tiene una edición gratuita de Azure AD, solo podrá asignar acceso a
las aplicaciones por usuario. Si su organización licencia una edición paga
de Azure AD, podrá realizar una asignación basada en grupo. Cuando
realiza una asignación basada en grupo, si un usuario puede acceder a una
aplicación dependerá de si el usuario es miembro del grupo en el
momento en que intenta acceder a la aplicación.
Se puede usar cualquier forma de grupo de Azure AD para asignar acceso
a las aplicaciones, incluidos los grupos dinámicos basados en atributos,
los grupos de Active Directory locales o los grupos administrados de
autoservicio. Actualmente, no se admite la pertenencia a grupos anidados
cuando se trata de asignar acceso a aplicaciones a través de Azure AD.
Más información Administrar el acceso a las aplicaciones
Puede obtener más información sobre cómo administrar el acceso a las aplicaciones
en https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/what-is-access-
management .
Asignar a los usuarios acceso a una aplicación

Para asignar acceso a una aplicación a un usuario o grupo, realice los
siguientes pasos:
1. En el centro de administración de Azure AD, seleccione Azure
Active Directory y, en la sección Administrar , haga clic
en Aplicaciones empresariales , como se muestra en la Figura 1-
69 .
Figura 1-69 Sección de administración de Azure AD
2. En la hoja Aplicaciones empresariales , asegúrese
de seleccionar Todas las aplicaciones , como se muestra en
la Figura 1-70 , y luego seleccione la aplicación a la que desea
habilitar el acceso de los usuarios.
Figura 1-70 Todas las aplicaciones
3. Una vez que se abre la aplicación, haga clic en Usuarios y
grupos en el panel de navegación de la aplicación, que se muestra
en la Figura 1-71 .
Figura 1-71 Descripción general de la aplicación

4. En la página Usuarios y grupos de la aplicación , que se muestra en
la Figura 1-72 , haga clic en Agregar usuario . Tenga en cuenta que
usa el botón Agregar usuario para agregar también una asignación
de grupo si Azure AD tiene la licencia del nivel adecuado.
Figura 1-72 Usuarios y grupos

5. En la página Agregar asignación que se muestra en la Figura 1-
73 , busque el usuario o grupo al que desea otorgar acceso a la
aplicación.
Figura 1-73 Agregar asignación para usuarios y grupos
6. Seleccione un usuario o grupo y luego haga clic en Seleccionar ,
Figura 1-74 Selección de la asignación de grupo

7. Una vez que se selecciona el usuario o grupo, haga clic
en Asignar . Verifique que se haya realizado la asignación
revisando la lista recién actualizada de usuarios y grupos, como se
Figura 1-75 Usuarios y grupos
Más información Asignar acceso a usuarios y grupos
us/azure/active-directory/manage-apps/methods-for-assigning-users-and-groups .
Configurar los alcances de los permisos de

registro de aplicaciones
La configuración de los alcances de los permisos de registro de
aplicaciones controla a qué información tiene acceso una aplicación. La
forma en que la plataforma de identidad de Microsoft implementa OpenID
Connect utiliza varios ámbitos que corresponden a Microsoft Graph. Al
configurar el registro de la aplicación, puede utilizar los siguientes
ámbitos de permisos para determinar a qué información puede acceder la
aplicación:
• OpenID Utilice este ámbito si una aplicación realiza un inicio
de sesión mediante OpenID Connect. Este permiso otorga a una
aplicación un identificador único para el usuario en forma de
subclama y también le da acceso a la aplicación al UserInfopunto
final. Este alcance se usa cuando se interactúa con la plataforma de
identidad de Microsoft para adquirir tokens de identificación, que
luego la aplicación puede usar para la autenticación.
• Correo electrónico El alcance del correo electrónico le da a la
aplicación acceso a la dirección de correo electrónico de un usuario
en forma de una dirección de correo electrónico asociada con una
cuenta de usuario.
• Perfil El alcance del perfil se puede utilizar para proporcionar
a la aplicación información sobre el usuario. Esto puede incluir el
nombre de pila de un usuario, el apellido, el nombre de usuario
preferido y la identificación del objeto.
• Offline_accessEl alcance offline_access proporcionará una
aplicación de acceso a los recursos en nombre del usuario durante
un período prolongado. Si un usuario da su consentimiento para
el offline_accessalcance, la aplicación puede recibir un token de
actualización de larga duración, que se puede actualizar a medida
que caducan los tokens más antiguos.
Más información Permisos y consentimiento
Puede obtener más información sobre los permisos y el consentimiento en un extremo
de la plataforma de identidad de Microsoft en https://docs.microsoft.com/en-
us/azure/active-directory/develop/v2-permissions-and-consent .
Administrar el consentimiento del permiso de

registro de la aplicación
El consentimiento del permiso de registro de la aplicación permite a los
usuarios y administradores controlar cómo y qué datos pueden acceder
las aplicaciones. La plataforma de identidad de Microsoft admite los
siguientes tipos de permisos:
• Permisos delegados Estos permisos son utilizados por
aplicaciones que son aprovechadas por un usuario que inició
sesión. El usuario o un administrador da su consentimiento a los
permisos requeridos por la aplicación. Luego, la aplicación usa un
permiso delegado para funcionar como el usuario que inició sesión
cuando intenta acceder al recurso de destino.
• Permisos de la aplicación Estos permisos los utilizan las
aplicaciones que se ejecutan sin un usuario que haya iniciado
sesión. Estas pueden ser aplicaciones en segundo plano de larga
ejecución. Los permisos de la aplicación solo pueden ser
autorizados por un administrador.
Los permisos efectivos son el conjunto de permisos con menos privilegios
que se calcula al comparar los permisos que se concedieron directamente
a la aplicación y los permisos del usuario que inició sesión. Para
configurar una lista de permisos solicitados estáticamente para una
aplicación, realice los siguientes pasos:
1. En la hoja Registros de aplicaciones de la consola de Azure Active
Directory, seleccione la aplicación registrada o la que desea
configurar los permisos estáticos.
2. En Administrar , haga clic en Permisos de API , como se muestra
en la Figura 1-76 .
Figura 1-76 Permisos de API en el menú Administrar de una

aplicación registrada
3. En la hoja Permisos de API que se muestra en la Figura 1-77 ,
configure qué permisos le gustaría que tuviera la aplicación. Puede
usar esta página para agregar permisos o otorgar el consentimiento
de administrador. El consentimiento del administrador le permite
otorgar permisos de aplicación a un inquilino de Azure AD
específico.
Figura 1-77 Administrar permisos de API

Más información Permiso y consentimiento de registro de la aplicación
Puede obtener más información sobre el permiso y el consentimiento de registro de la
aplicación en: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-
permissions-and-consent .
Administrar el acceso de API a suscripciones y

recursos de Azure
Las políticas de administración de API le permiten controlar el
comportamiento de una API. Una política de administración de API es una
colección de declaraciones que se aplican secuencialmente a las
solicitudes o respuestas de la API. Por ejemplo, estas políticas incluyen la
conversión de formato de XML a JSON o la limitación de la tasa de
llamadas. La limitación de la tasa de llamadas puede ser una forma útil de
garantizar que una API hospedada en Azure no se inunde de solicitudes,
lo que puede generar cargos de suscripción inusualmente altos. Las
políticas de administración de API son documentos XML que se dividen en
secciones de entrada, salida, back-end y en caso de error.
Las políticas de administración de API se evalúan según el alcance en el
que se aplican. Los alcances de las políticas se evalúan en el siguiente
orden:
1. Alcance global
2. Definición del producto
3. Alcance de la API
4. Alcance de la operación
Puede ver todas las políticas que se aplican en el alcance actual haciendo
clic en Volver a calcular la política efectiva para el alcance
seleccionado en el editor de políticas de administración de API.
Para establecer o editar una política de administración de la API de Azure,
1. En Azure Portal, seleccione la instancia de APIM. En la pestaña API ,
seleccione la API importada.
2. En la pestaña Diseño, seleccione la operación a la que desea aplicar
la política. También tiene la opción de aplicar la política a todas las
operaciones.
3. Haga clic en el icono </> (editor de código) en
las secciones Procesamiento entrante o Procesamiento
saliente .
4. Ingrese el código de póliza deseado en la sección apropiada del
código.
Más información Políticas de restricción de acceso a la administración de API
Puede obtener más información sobre las políticas de restricción de acceso a la
administración de API en https://docs.microsoft.com/en-us/azure/api-management/api-
management-policies .
HABILIDAD 1.4: GESTIONAR EL CONTROL

DE ACCESO
El control de acceso es otro término para asignar permisos a los
recursos. En esta sección, aprenderá a proteger los recursos dentro de
una suscripción de Azure mediante la asignación de permisos, que se
realiza más fácilmente mediante la asignación de usuarios a roles. Para
dominar este objetivo, deberá comprender los permisos de suscripción y
recursos, los permisos de grupos de recursos, los roles RBAC
personalizados, el principio de privilegio mínimo, cómo interpretar los
permisos y cómo verificar el acceso.
Esta sección cubre los siguientes temas:
• Configurar permisos de suscripción y recursos
• Configurar los permisos del grupo de recursos
• Configurar roles RBAC personalizados
• Aplicar el principio de privilegio mínimo
• Interpretar permisos
• Verificar acceso
Configurar permisos de suscripción y recursos

El control de acceso basado en roles de Azure (RBAC) le permite
configurar la administración de acceso detallada a los recursos de
Azure. Con RBAC, puede controlar lo que puede hacer una entidad de
seguridad y dónde puede hacerlo. Lo hace con una combinación de
principales de seguridad, roles y ámbitos.
Como recordará anteriormente en este capítulo, las entidades de
seguridad son objetos de Azure que representan individuos, colecciones
de individuos, aplicaciones o servicios. Los principios de seguridad
incluyen
• Personas individuales Se representan como usuarios de
Azure AD u objetos de usuario que son referencias dentro de Azure
AD de otros inquilinos.
• Colecciones de individuos Se representan como grupos de
Azure AD.
• Aplicaciones y servicios Se representan como entidades de
servicio o identidades administradas.
Un rol de RBAC es una colección de permisos. Los permisos se pueden
considerar como un conjunto de operaciones, como leer, escribir y
eliminar, que se pueden realizar en el objeto de Azure al que se asigna el
rol.
El alcance es el límite al que se aplican los permisos definidos en el
rol. Puede configurar el ámbito para que se produzca una asignación de
roles en el nivel de grupo de administración, suscripción, grupo de
recursos o recurso individual de Azure. Las asignaciones de ámbito
funcionan en una relación padre-hijo, lo que significa que la asignación de
permisos que se produce en el nivel de ámbito principal se hereda en el
nivel de ámbito secundario. Por ejemplo, si configura el alcance de una
asignación de funciones para que esté en el nivel del grupo de recursos,
todos los recursos dentro de ese grupo tendrán esa asignación de
funciones.
La asignación de permisos a las suscripciones y recursos de Azure
requiere la combinación de entidades de seguridad que representan a
quién desea asignar el permiso, la definición de rol que define los
permisos y el ámbito que define dónde se asignan los permisos.
Más información Comprensión de Rbac
Puede obtener más información sobre cómo comprender RBAC
en https://docs.microsoft.com/en-us/azure/role-based-access-control/overview .
Gestionar roles de administrador

Azure Active Directory incluye muchos roles que proporcionan una
variedad de permisos para diferentes aspectos de las cargas de trabajo de
Azure AD y Microsoft 365. Estos roles y los permisos que otorgan se
enumeran en la Tabla 1-2 :
Tabla 1-2 Roles de Azure AD
Papel Descripción
Administrador de Puede administrar aplicaciones empresariales, registro

aplicaciones y configuraciones de proxy de aplicaciones.
Desarrollador de aplicaciones Puede crear registros de aplicaciones.
Administrador de Puede ver la configuración actual del método de auten

autenticación establecer o restablecer credenciales sin contraseña. P
en el próximo inicio de sesión.
Administrador de facturación Puede comprar y administrar suscripciones. Puede adm

de soporte y monitorear el estado del servicio.
Administrador de Puede administrar todos los aspectos de las aplicacion

aplicaciones en la nube empresariales, pero no puede administrar el proxy de
Papel Descripción
Administrador de Puede habilitar, deshabilitar y quitar dispositivos en A

dispositivos en la nube ver las claves de cifrado de la unidad BitLocker de Win
de Azure Portal.
Administrador de Administre funciones en el centro de cumplimiento de

cumplimiento centro de administración de Microsoft 365, Azure y el C
cumplimiento y seguridad de Microsoft 365.
Administrador de acceso Derechos administrativos sobre la configuración de ac

condicional de Azure AD.
Aprobador de acceso a la caja Gestiona las solicitudes de la caja de seguridad del clie
de seguridad del cliente puede habilitar y deshabilitar la función Caja de seguri
Administradores del Los usuarios a los que se les asigne esta función se con
dispositivo administradores locales en todos los equipos que ejecu
que están unidos a Azure AD.
Lectores de directorio Función de las aplicaciones que no admiten el marco d

consentimiento. No debe asignarse a usuarios.
Cuentas de sincronización de Asignado al servicio Azure AD Connect y no se usa par

directorios usuario.
Escritores de directorio Una función heredada asignada a aplicaciones que no a

de consentimiento. Solo debe asignarse a aplicaciones,
usuario.
Administrador de Dynamics Acceso administrativo a Dynamics 365 Online.

365 / Administrador de CRM
Administrador de Exchange Acceso administrativo a Exchange Online.

Papel Descripción
Administrador global / Acceso administrativo a todas las funciones de Azure A

Administrador de la empresa acceso administrativo a los servicios que usan las ident
AD, incluido el centro de seguridad de Microsoft 365, e
cumplimiento de Microsoft 365, Exchange Online, Shar
Skype for Business Online. La cuenta utilizada para reg
arrendamiento se convierte en el administrador global
administradores globales pueden restablecer las contr
cualquier usuario, incluidos otros administradores glob
Invitadora invitada Puede administrar las invitaciones de usuarios invitad

B2B.
Administrador de protección Puede administrar todos los aspectos de Azure Inform

de la información incluida la configuración de etiquetas, la administració
protección y la activación de la protección.
Administrador de Intune Tiene todos los derechos administrativos sobre Micros
Administrador de licencia Puede administrar asignaciones de licencias en usuario

pueden comprar ni administrar suscripciones.
Lector del centro de mensajes Puede monitorear notificaciones y avisos de Microsoft

mensajes de Microsoft 365.
Administrador de Puede realizar las siguientes tareas para todos los usua
contraseñas / Administrador aquellos que tienen roles administrativos:
del servicio de asistencia • Cambiar contraseñas
técnica
• Invalidar tokens de actualización
• Gestionar solicitudes de servicio
• Supervisar el estado del servicio
Administrador de Power BI Tiene permisos de administrador sobre Power BI.

Papel Descripción
Administrador de funciones Puede administrar todos los aspectos de Azure AD Priv

privilegiadas Management. Puede administrar asignaciones de roles
Lector de informes Puede ver los datos de los informes en el panel de info
365.
Administrador de seguridad Tiene acceso de nivel de administrador para administr

de seguridad en el centro de seguridad de Microsoft 36
Identity Protection, Azure Information Protection y el C
cumplimiento y seguridad de Microsoft 365.
Lector de seguridad Tiene acceso de solo lectura a las funciones de segurid

con la seguridad de Microsoft 365.
Administrador de soporte de Puede abrir y ver solicitudes de soporte con Microsoft

servicio relacionados con Microsoft 365.
Administrador de SharePoint Tiene permisos de administrador global para cargas de

SharePoint Online.
Administrador de Skype Tiene permisos de administrador global para cargas de

Empresarial / Lync Empresarial.
Administrador de equipos Puede administrar todos los elementos de Microsoft T
Administrador de Puede administrar cargas de trabajo de Teams relacion

comunicaciones de Teams telefonía, incluida la asignación de números de teléfono
voz y reuniones.
Ingeniero de soporte de Puede solucionar problemas de comunicación en Team

comunicaciones de Teams Empresarial. Puede ver los detalles de los registros de
los participantes en una conversación.
Papel Descripción
Especialista en soporte de Puede solucionar problemas de comunicación en Team

comunicaciones de Teams Empresarial. Solo puede ver los detalles del usuario en
usuario específico.
Administrador de cuentas de Puede crear y administrar cuentas de usuario. Puede c

usuario administrar grupos. Puede administrar las vistas de los
tickets de soporte y puede monitorear el estado del ser
Más información Funciones de administrador de Azure AD
Puede obtener más información sobre los roles de administrador de Azure AD
en https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-
assign-admin-roles .
Configurar RBAC en Azure AD

Azure RBAC (control de acceso basado en roles) le permite configurar un
control de acceso detallado a los recursos de Azure, como máquinas
virtuales y cuentas de almacenamiento. Cuando configura RBAC, asigna
un rol y un alcance, siendo el alcance el recurso que desea
administrar. Azure RBAC incluye más de 70 roles. Proporcionar los
detalles de los 70 está más allá del alcance de este texto, pero hay 4 roles
fundamentales que las personas responsables de administrar Microsoft
365 deben conocer. Estos roles se pueden asignar a suscripciones, grupos
de recursos o recursos específicos de Azure:
• Propietario Los usuarios que tienen este rol tienen acceso
completo a todos los recursos dentro del alcance de la asignación y
pueden delegar el acceso a otros.
• Los usuarios colaboradores que tienen este rol pueden crear
y administrar recursos dentro del alcance de la asignación, pero no
pueden otorgar acceso a otros.
• Los usuarios lectores que tienen este rol pueden ver los
recursos dentro del alcance de la asignación, pero no pueden
realizar otras tareas y no pueden otorgar acceso a otros.
• Administrador de acceso de usuario Los usuarios que
tienen este rol pueden administrar el acceso de los usuarios a los
recursos de Azure dentro del alcance de la asignación.
Más información Azure RBAC
Puede obtener más información sobre Azure RBAC en docs.microsoft.com/en-
us/azure/role-based-access-control/rbac-and-directory-admin-roles .
Derechos de administrador delegado

Para ver a qué usuarios se les asigna un rol específico, realice los
siguientes pasos:
1. En el centro de administración de Azure AD, seleccione Funciones
y administradores , como se muestra en la figura 1-78 .
Figura 1-78 Funciones y administradores

2. Para ver la información de membresía de un rol, haga clic en el rol
que desee. La figura 1-79 muestra los miembros del rol de
administradores de contraseñas.
Figura 1-79 Miembros del rol de administradores de contraseñas

Puede usar los siguientes cmdlets de Azure PowerShell para ver roles y
pertenencia a roles:
• Get-AzureADDirectoryRole Ver una lista de roles de Azure
AD Directory
• Get-AzureADDirectoryRoleMember Ver la membresía
asignada a los usuarios en un rol de Azure AD Directory
Más información Delegación de derechos de administrador
Puede obtener más información sobre la delegación de derechos de administrador
en https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/roles-
concept-delegation .
Administrar las asignaciones de roles mediante Azure

AD
Para asignar un usuario a un rol específico dentro de Azure AD, realice los
siguientes pasos:
1. En el centro de administración de Azure AD, seleccione Roles y
administradores .
2. Seleccione la función a la que desea agregar un usuario. Esto abrirá
la página de propiedades del rol.
3. En la página Propiedades del rol , haga clic en Agregar
miembro . La Figura 1-80 muestra cómo agregar al usuario Adele
Vance al rol de Administrador de seguridad.
Figura 1-80 Miembros del rol de administradores de seguridad

Puede usar los siguientes cmdlets de Azure PowerShell para administrar
las pertenencias a roles:
• Add-AzureADDirectoryRoleMember Agrega un usuario a
un rol de Azure AD Directory
• Remove-AzureADDirectoryRoleMember Quita un usuario
de un rol de Azure AD Directory
Más información Ver y asignar roles de administrador de Azure AD
Puede obtener más información sobre cómo ver y asignar roles de administrador
en https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-
manage-roles-portal .
Configurar los permisos del grupo de recursos

Cualquier permiso asignado a nivel de grupo de recursos se aplicará a
todos los recursos almacenados dentro de ese grupo de recursos. Por
ejemplo, si asigna la función de administrador de la máquina virtual en el
nivel del grupo de recursos a un grupo de usuarios, esos usuarios tendrán
esa función para todas las máquinas virtuales almacenadas dentro del
grupo de recursos. Para asignar permisos a nivel de grupo de recursos,
asigne un rol específico a un usuario, grupo, entidad de servicio o
identidad administrada. Para asignar un rol a nivel de grupo de recursos,
1. En la hoja Grupos de recursos de Azure Portal, seleccione el grupo
de recursos para el que desea configurar el permiso, como se
Figura 1-81 Asignación de roles a nivel de grupo de recursos

2. En la hoja Grupos de recursos , haga clic en Control de acceso
(IAM) .
3. En la página Control de acceso (IAM) , elija Agregar > Asignación
de funciones .
4. En la página Agregar asignación de rol , que se muestra en
la Figura 1-82 , seleccione el rol que desea asignar, especifique a
qué usuario, grupo, entidad de servicio o identidad administrada
por el sistema desea que se aplique el rol y luego especifique el
identidad de ese principal de seguridad.
Figura 1-82 Agregar asignación de funciones

Más información Permisos de grupos de recursos
Puede obtener más información sobre los permisos de los grupos de recursos
en https://docs.microsoft.com/en-
us/rest/api/authorization/permissions/listforresourcegroup .
Identificar el rol apropiado

Hay una gran cantidad de roles preexistentes disponibles dentro de
Azure, y es probable que un rol existente satisfaga sus necesidades, por lo
que probablemente no necesitará configurar un rol
personalizado. Primero, debe especificar exactamente qué acciones debe
y no debe poder realizar un principio de seguridad. Una vez que haya
generado esta lista, debe revisar los roles existentes y determinar si uno
de los roles existentes satisface sus necesidades o si necesita crear un rol
personalizado.
Más información Roles por categoría
Puede obtener más información sobre los roles de Azure RBAC por categoría
en https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles .
Aplicar el principio de privilegio mínimo

Al configurar Azure RBAC, asegúrese de seguir el principio de privilegio
mínimo. Esto significa que solo debe otorgar el acceso necesario para
realizar tareas específicas. Hacerlo reduce la posibilidad de que se
realicen acciones accidentales o no autorizadas. Por ejemplo, si un grupo
solo requiere la capacidad de ver la configuración de un recurso de Azure,
solo necesita asignar un rol que tenga el permiso de lectura a ese
recurso. Si un grupo solo requiere acceso de Azure Portal a una máquina
virtual en un grupo de recursos (aunque el grupo de recursos hospeda
varias máquinas virtuales), establezca el alcance de la asignación de roles
a la máquina virtual en lugar del grupo de recursos al asignar el rol a ese
grupo.
Más información Prácticas recomendadas de Azure Access Control
Puede obtener más información sobre las mejores prácticas de Azure RBAC, incluido
el privilegio mínimo, en https://docs.microsoft.com/en-
us/azure/security/fundamentals/identity-management-best-practices .
Configurar roles RBAC personalizados

Si uno de los muchos roles RBAC existentes no cumple con los requisitos
de su organización, puede crear un rol RBAC personalizado. Por ejemplo,
hay tres roles de RBAC relacionados con las máquinas virtuales: Inicio de
sesión de administrador de máquina virtual, Colaborador de máquina
virtual e Inicio de sesión de usuarios de máquina virtual. Si desea permitir
que un usuario reinicie una VM pero no inicie sesión en la VM o elimine la
VM, puede crear una función RBAC personalizada que permita ese
permiso específico. Al igual que con los roles de Azure RBAC existentes,
puede asignar roles personalizados a usuarios, grupos, entidades de
servicio e identidades administradas en los niveles de grupo de
administración, suscripción, grupo de recursos y recursos individuales.
Puede crear un rol personalizado a través de Azure Portal, Azure
PowerShell, la CLI de Azure o la API REST de Azure, o puede crear una
plantilla ARM. En general, la creación de un rol personalizado implica
seguir estos pasos básicos:
1. Determine qué método utilizará para crear el rol
personalizado. Determine qué permisos requiere el rol. Puede saber
qué operaciones están disponibles para definir supermiso al ver las
operaciones del proveedor de recursos de Azure Resource
Manager. Para las operaciones de gestión, estos
serán Actionso NotActions. Para las operaciones de datos, estos
serán DataActionso NotDataActions.
2. Crea el rol. Puede hacer esto clonando un rol existente y luego
haciendo modificaciones o creando un nuevo rol desde cero. El
método más sencillo de hacerlo es a través del portal de Azure.
3. Pruebe el rol personalizado. Asegúrate de probar la función a fondo
para determinar que solo permite lo que quieres que permita y no
tiene algunos permisos inesperados, como permitir que Wally, el
operador de VM, escriba algo en Cloud Shell que bloquee a todos los
demás usuarios en el Arrendamiento de Azure AD.
Al crear un rol RBAC personalizado, recuerde agregar solo la menor
cantidad de privilegios necesarios al rol. Cuando cree una función
personalizada, aparecerá en Azure Portal con un icono de recurso
naranja, en lugar de azul. Los roles RBAC personalizados están
disponibles entre suscripciones que están asociadas con el mismo
arrendamiento de Azure AD. Cada inquilino de Azure AD admite hasta
5000 roles personalizados.
Para clonar y luego modificar un rol en Azure Portal, realice los siguientes
pasos:
1. En Azure Portal, abra la hoja Control de acceso (IAM) en el nivel
de suscripción o en el nivel del grupo de recursos donde desea que
se pueda asignar el rol personalizado.
2. Seleccione la pestaña Roles para ver la lista de todos los roles
personalizados e integrados disponibles.
3. Seleccione el rol que desea clonar y luego modifíquelo. La Figura 1-
83 muestra la función Colaborador de la máquina virtual que se
selecciona para la clonación.
Figura 1-83 Seleccione un rol para clonar
4. En la pestaña Conceptos básicos de la página Crear un rol
personalizado que se muestra en la Figura 1-84 , proporcione
un Nombre de rol personalizado .
Figura 1-84 Asistente para crear un rol personalizado con la

pestaña Básicos seleccionada
5. En la pestaña Permisos que se muestra en la Figura 1-85 , puede
eliminar los permisos existentes o agregar nuevos permisos.
Figura 1-85 Asistente para crear un rol personalizado con la
pestaña Permisos seleccionada
6. En la pestaña Ámbitos asignables , puede especificar dónde se
puede asignar el rol. Puede seleccionar las suscripciones asociadas
con el arrendamiento de Azure AD, así como los grupos de recursos
incluidos en esas suscripciones.
7. En la pestaña JSON , puede ver la función personalizada formateada
en JSON. Esta pestaña le brinda la oportunidad de editar el rol en
JSON. Si desea agregar un permiso comodín, hágalo en esta pestaña
porque esto no es posible en otros puntos durante la creación de un
rol personalizado.
8. Una vez que haya revisado el código JSON, haga clic en Revisar y
crear para crear la función personalizada.
Más información Funciones personalizadas de Azure
Puede obtener más información sobre los roles personalizados de Azure
en https://docs.microsoft.com/en-us/azure/role-based-access-control/custom-roles .
Interpretar permisos
La clave para comprender lo que se puede hacer con los permisos es que
existen permisos relacionados con las operaciones de administración y
permisos relacionados con las operaciones de datos. Para las operaciones
del plano de administración, los permisos determinan las acciones que se
pueden tomar contra los objetos en el plano de administración de Azure,
que incluye el portal de Azure, la CLI de Azure, Azure PowerShell y la API
de REST de Azure. Estos se definen como Actionsy NotActions. En el nivel
de operaciones de datos, hay acciones que se pueden tomar contra los
datos, como los datos almacenados en una cuenta de
almacenamiento. Estos se definen como DataActionsy NotDataActions. Para
enumerar los permisos dentro de un rol, use el Get-
AzRoleDefinitioncmdlet de PowerShell. Por ejemplo, para ver los permisos
asociados con la función Colaborador, ejecute el siguiente comando:
Get-AzRoleDefinition "Colaborador" | Acciones FL, NotActions
Los permisos son acumulativos. Si se concede a un

usuario Actionso DataActionsen varios roles y ámbitos, se aplicarán todos
los permisos. Cuando varias funciones se aplican a una entidad de
seguridad, ninguna NotActionso NotDataActionsque se aplican anulará
cualquier Actionso DataActionslo que corresponda.
Más información Gestión y operaciones de datos
Puede obtener más información sobre la administración y las operaciones de datos
en https://docs.microsoft.com/en-us/azure/role-based-access-control/role-
definitions#management-and-data-operations .
Verificar acceso
Para ver el acceso que tiene un usuario a un recurso específico, realice los
siguientes pasos:
1. En Azure Portal, seleccione el recurso específico para el que desea
verificar el acceso.
2. Seleccione Control de acceso (IAM) para abrir la hoja de Control
de acceso (IAM).
3. Haga clic en la pestaña Verificar acceso .
4. En la sección Verificar acceso , use el menú
desplegable Buscar para seleccionar la opción principal de servicio,
grupo o usuario de Azure AD y escriba el nombre del usuario cuyo
acceso desea verificar, como se muestra en la Figura 1-
86 . Seleccione el usuario.
Figura 1-86 La pestaña Verificar acceso
5. En la pestaña Asignaciones que se muestra en la Figura 1-87 ,
revise las asignaciones de roles del usuario y rechace las
asignaciones al recurso.
Figura 1-87 La pestaña Asignaciones de roles

Más información Ver el acceso del usuario a los recursos
Puede obtener más información sobre el acceso de los usuarios de View a los recursos
en https://docs.microsoft.com/en-us/azure/role-based-access-control/check-access .

Recuerde aplicar siempre el principio de privilegio mínimo al
intentar determinar qué rol asignar a un usuario que necesita
acceso a un recurso.
Experimento mental
En este experimento mental, demuestre sus habilidades y conocimiento
de los temas cubiertos en este capítulo. Puede encontrar respuestas a este
experimento mental en la siguiente sección.
Identidad y acceso en Tailwind Traders

Usted es uno de los administradores de Azure de Tailwind Traders, una
tienda general en línea que se especializa en una variedad de productos
que se utilizan en el hogar. Como parte de sus funciones para Tailwind
Traders, ha registrado una nueva aplicación con su instancia de Azure
AD. Aunque la aplicación esté registrada, desea limitar las acciones que la
aplicación puede realizar en los recursos de la suscripción de Tailwind
Traders Azure mediante la aplicación de un rol RBAC
personalizado. Tailwind Traders ha estado utilizando PIM durante algún
tiempo como un método para mejorar la seguridad de los recursos dentro
de las suscripciones propiedad de la organización. Debido a que el acceso
se configuró hace algún tiempo, sabe que varios usuarios que se
configuraron como elegibles para roles de PIM han cambiado de roles de
trabajo. Para mejorar la seguridad, desea eliminar la elegibilidad de PIM
si ya no es necesaria. Otro objetivo de Tailwind Traders es permitir que
algunos usuarios de la nueva aplicación accedan a la aplicación desde
fuera del lugar de trabajo. Sin embargo, desde una perspectiva de
seguridad, cualquier persona que acceda a la aplicación desde fuera de la
red interna de Tailwind Traders debe tomar medidas adicionales para
verificar su identidad. Con esta información en mente, responda las
siguientes preguntas:
1. 1. ¿Cómo puede asignar el rol RBAC personalizado a la nueva
aplicación?
2. 2. ¿Cómo puede determinar qué personal eliminar de la elegibilidad
para los roles de PIM?
3. 3. ¿Cómo puede asegurarse de que todos los usuarios realicen MFA
si acceden a la nueva aplicación desde una ubicación fuera de la
oficina de Tailwind Traders?
RESPUESTAS DEL EXPERIMENTO MENTAL

Esta sección contiene la solución al experimento mental. Cada respuesta
explica por qué la opción de respuesta es correcta.
1. 1. Puede asignar roles a la nueva aplicación asignando roles a la
entidad de servicio creada cuando se registró la aplicación. Al
asignar la función RBAC personalizada a la entidad de servicio,
asigna esa función a la aplicación.
2. 2. Debe configurar una revisión de acceso para determinar qué
usuarios que se han configurado como elegibles para los roles de
PIM en realidad no están usando esos roles.
3. 3. Puede configurar una política de acceso condicional para obligar
a los usuarios a realizar MFA cuando se encuentran en una
ubicación que no es de confianza, como cualquier ubicación de red
fuera de las redes de confianza identificadas como pertenecientes a
Tailwind Traders.
RESUMEN DEL CAPÍTULO

• Las entidades de seguridad se crean automáticamente cuando
registra una aplicación con Azure AD.
• Puede asignar roles RBAC a los principales de seguridad como
una forma de asignar permisos a las aplicaciones.
• Los grupos de Azure AD le permiten recopilar entidades de
seguridad de Azure, incluidos usuarios, entidades de servicio y
otros grupos.
• Los usuarios de Azure AD representan a personas dentro de
Azure AD. Pueden ser cuentas solo en la nube o pueden replicarse
desde un entorno de Servicios de dominio de Active Directory local.
• La escritura diferida de contraseñas permite que las
contraseñas cambiadas dentro de Azure AD se vuelvan a escribir en
un entorno de Servicios de dominio de Active Directory.
• Privileged Identity Management permite la administración
justo a tiempo y el acceso justo a tiempo a los recursos de Azure.
• Las políticas de acceso condicional le permiten implementar
requisitos de autenticación más estrictos si se cumplen ciertas
condiciones.
• Los alcances de los permisos de registro de aplicaciones le
permiten controlar a qué recursos y datos puede acceder una
aplicación.
• Los roles RBAC personalizados se pueden configurar si un rol
RBAC existente no tiene los permisos adecuados para las
necesidades de su organización.
Capitulo 2
Implementar la protección de la
plataforma
Uno de los principales aspectos de la computación en la nube es el modelo
de responsabilidad compartida, donde el proveedor de soluciones en la
nube (CSP) y el cliente comparten diferentes niveles de
responsabilidades, según la categoría del servicio en la nube. Cuando se
trata de seguridad de plataforma, infraestructura como servicio (IaaS), los
clientes tendrán una larga lista de responsabilidades. Sin embargo, en un
escenario de plataforma como servicio (PaaS) todavía existen algunas
responsabilidades de seguridad de la plataforma, no son tan extensas
como cuando se utilizan cargas de trabajo de IaaS.
Azure tiene capacidades y servicios de seguridad de plataforma nativa
que deben aprovecharse para proporcionar el nivel necesario de
seguridad para sus cargas de trabajo IaaS y PaaS mientras se mantiene
una capa de administración segura.

• Habilidad 2.1: Implementar seguridad de red avanzada
• Habilidad 2.2: Configurar seguridad avanzada para
computación
HABILIDAD 2.1: IMPLEMENTAR

SEGURIDAD DE RED AVANZADA
Para implementar una infraestructura de red de Azure, debe comprender
las diferentes opciones de conectividad disponibles en Azure. Estas
opciones le permitirán implementar una variedad de escenarios con
diferentes requisitos. Esta sección del capítulo cubre las habilidades
necesarias para implementar seguridad de red avanzada.
Descripción general de los componentes de la
red de Azure
La red de Azure proporciona capacidades integradas para habilitar la
conectividad entre los recursos de Azure, la conectividad de las redes
locales a los recursos de Azure y la conectividad de una sucursal a otra en
Azure.
Si bien esas habilidades no se mencionan directamente en el esquema del
examen AZ-500, es importante que comprenda estos conceptos. Si ya se
siente cómodo con su nivel de habilidad, puede pasar a "Asegurar la
conectividad de las redes virtuales", más adelante en este capítulo.
Para comprender mejor los diferentes componentes de una red de Azure,
revisemos el diagrama de arquitectura de Contoso que se muestra en
la Figura 2-1 .
Figura 2-1 Diagrama de red de Contoso

En la Figura 2-1 , puede ver la infraestructura de Azure (en la parte
superior), con tres redes virtuales. Contoso necesita segmentar su red
Azure en diferentes redes virtuales (VNets) para proporcionar un mejor
aislamiento y seguridad. Tener redes virtuales en su infraestructura de
Azure permite a Contoso conectar máquinas virtuales (VM) de Azure para
comunicarse de forma segura entre sí, con Internet y con las redes locales
de Contoso.
Si piensa en la red física tradicional local donde opera en su propio centro
de datos, eso es básicamente lo que es VNet, pero con los beneficios
adicionales de la infraestructura de Azure, que incluye escalabilidad,
disponibilidad y aislamiento. Cuando crea una red virtual, debe
especificar una dirección IP privada personalizada que usarán los
recursos que pertenecen a esta red virtual. Por ejemplo, si implementa
una máquina virtual en una red virtual con un espacio de direcciones de
10.0.0.0/24, a la máquina virtual se le asignará una IP privada, como
10.0.0.10/24.
Importantes redes virtuales múltiples y emparejamiento de redes virtuales
Una red virtual de Azure tiene como ámbito una única región o ubicación. Si necesita
conectar varias redes virtuales de diferentes regiones, puede utilizar el
emparejamiento de redes virtuales.
Observe en la Figura 2-1 que hay subredes en cada VNet en la red de

Contoso. Contoso necesita segmentar la red virtual en una o más subredes
y asignar una parte del espacio de direcciones de la red virtual a cada
subred. Con esta configuración, Contoso puede implementar recursos de
Azure en una subred específica, tal como solía hacerlo en su red
local. Desde una perspectiva organizativa y de estructura, las subredes
han permitido a Contoso segmentar su espacio de direcciones de VNet en
segmentos más pequeños que son apropiados para su red interna. Al usar
subredes, Contoso también pudo mejorar la eficiencia de la asignación de
direcciones.
Otro trío importante de componentes se muestra en la Figura 2-1 :
subredes A1, B1 y C1. Cada una de estas subredes tiene un grupo de
seguridad de red (NSG) vinculado a ella, que proporciona una capa
adicional de seguridad basada en reglas que permiten o niegan el tráfico
de red entrante o saliente.
Las reglas de seguridad de NSG se evalúan por su prioridad y cada una se
identifica con un número entre 100 y 4096, donde los números más bajos
se procesan primero. Las reglas de seguridad utilizan información de 5
tuplas (dirección de origen, puerto de origen, dirección de destino, puerto
de destino y protocolo) para permitir o denegar el tráfico. Cuando se
evalúa el tráfico, se crea un registro de flujo para las conexiones
existentes y la comunicación se permite o deniega según el estado de
conexión del registro de flujo. Puede comparar este tipo de configuración
con la antigua segmentación de VLAN que a menudo se implementaba con
redes locales.
Las interrupciones de tráfico importantes no pueden interrumpirse
Es posible que las conexiones existentes no se interrumpan cuando elimine una regla
de seguridad que habilitó el flujo. Se produce una interrupción del tráfico cuando se
detienen las conexiones y no fluye tráfico en ninguna dirección durante al menos unos
minutos.
Contoso tiene su sede en Dallas y una sucursal en Sydney. Contoso debe

proporcionar conectividad RDP / SSH segura y sin problemas a sus
máquinas virtuales directamente desde Azure Portal a través de
TLS. Contoso no desea usar máquinas virtuales Jumpbox y, en su lugar,
desea permitir el acceso remoto a las subredes de back-end a través del
navegador. Por este motivo, Contoso implementó Azure Bastion, como
puede ver en la red virtual C, subred C1 en la Figura 2-1 .
Azure Bastion es un servicio PaaS administrado por plataforma que se
puede aprovisionar en una red virtual.
Para la conectividad de Contoso con la sucursal de Sydney, utiliza una
puerta de enlace VPN en Azure. Una puerta de enlace de red virtual en
Azure se compone de dos o más máquinas virtuales que se implementan
en una subred específica denominada subred de puerta de enlace. Las
máquinas virtuales que forman parte de la puerta de enlace de la red
virtual contienen tablas de enrutamiento y ejecutan servicios de puerta
de enlace específicos. Estas máquinas virtuales se crean automáticamente
cuando crea la puerta de enlace de red virtual y no tiene acceso directo a
esas máquinas virtuales para realizar configuraciones personalizadas en
el sistema operativo.
Al planificar sus redes virtuales, tenga en cuenta que cada red virtual solo
puede tener una puerta de enlace de red virtual de cada tipo, y el tipo de
puerta de enlace solo puede ser VPN o ExpressRoute. Utilice VPN cuando
necesite enviar tráfico cifrado a través de la Internet pública a sus
recursos locales.
Sugerencia de examen Configuración de la dirección
IP
Al realizar el examen, preste especial atención a los escenarios que
incluyen direcciones IP para diferentes subredes y posibles
problemas de conectividad debido a una configuración de IP
incorrecta.
Por ejemplo, digamos que Contoso necesita una latencia más rápida, más
confiable, segura y consistente para conectar su red Azure a su sede en
Dallas. Contoso decide usar ExpressRoute, como se muestra en la Figura
2-1 . ExpressRoute permite que Contoso extienda sus redes locales a la
nube de Microsoft (Azure u Office 365) a través de una conexión privada
porque ExpressRoute no pasa por la Internet pública.
En la Figura 2-1 , observe que el circuito ExpressRoute consta de dos
conexiones, las cuales son enrutadores de borde empresarial de Microsoft
(MSEE) en una ubicación de ExpressRoute del proveedor de conectividad
o del borde de su red. Si bien puede optar por no implementar
dispositivos redundantes o circuitos Ethernet en su extremo, los
proveedores de conectividad utilizan dispositivos redundantes para
garantizar que sus conexiones se transfieran a Microsoft de manera
redundante. Esta redundancia de conectividad de capa 3 es un requisito
para que Microsoft SLA sea válido.
La segmentación de la red es importante en muchos escenarios y es
necesario comprender los requisitos de diseño para sugerir las opciones
de implementación. Supongamos que desea asegurarse de que los hosts
de Internet no se puedan comunicar con los hosts de una subred de back-
end, pero que puedan comunicarse con los hosts de la subred de front-
end. En este caso, debe crear dos redes virtuales: una para sus recursos
de front-end y otra para sus recursos de back-end.
Al configurar su red virtual, también tenga en cuenta que los recursos que
implemente dentro de la red virtual heredarán la capacidad de
comunicarse entre sí. También puede permitir que las redes virtuales se
conecten entre sí, o puede permitir que los recursos de cualquiera de las
redes virtuales se comuniquen entre sí mediante el emparejamiento de
redes virtuales. Al conectar redes virtuales, puede optar por acceder a
otras redes virtuales que se encuentran en la misma o en diferentes
regiones de Azure. Siga los pasos a continuación para configurar su red
virtual mediante Azure Portal:
1. Vaya al portal de Azure en https://portal.azure.com .
2. En la barra de búsqueda, escriba redes virtuales y en Servicios ,
haga clic en Redes virtuales . El Virtual Redes aparece la página,
Figura 2-2 Página de redes virtuales de Azure

3. Haga clic en el botón Agregar y aparecerá la página Crear red
virtual , como se muestra en la Figura 2-3 .
Figura 2-3 La página Crear red virtual le permite personalizar la

implementación de su red virtual
4. En la pestaña Conceptos básicos , seleccione la suscripción para la
red virtual y el grupo de recursos .
5. En el campo Nombre , escriba un nombre completo para la red
virtual y, en el campo Región , seleccione la región de Azure en la
que residirá la red virtual. Finalmente, haga clic en
la pestaña Direcciones IP .
6. En la página Direcciones IP , en el campo IPv4 , escriba el espacio
de direcciones en formato de enrutamiento entre dominios sin
clases (CIRD); por ejemplo, podría ingresar 10.3.0.0/16 .
7. Haga clic en el botón Agregar subred . Los Agregar
subred aparece la cuchilla, como se muestra en la Figura 2-4 .
Figura 2-4 Agregar hoja de subred

8. En el campo Nombre de subred , escriba un nombre para esta
subred.
9. En el rango de direcciones de subred , escriba el rango de IP para
esta subred en formato CIDR, como 10.3.0.0/16 . Tenga en cuenta
que la subred IPv4 admitida más pequeña es / 29 y la más grande
es / 8.
10. Haga clic en el botón Agregar ; la subred que acaba de crear
aparece en la sección Nombre de subred .
11. Deje las selecciones predeterminadas por ahora y haga clic en
el botón Revisar + Crear . Aparece el resultado de la validación,
que es similar al que se muestra en la Figura 2-5 .
Figura 2-5 Resumen de las selecciones con los resultados de la
validación
12. Haga clic en el botón Crear .
13. El general página aparece con el estatus final de
implementación. En esta página, haga clic en el botón Ir a recurso y
revise estas opciones en el panel de navegación
izquierdo: Descripción general , Espacio de
direcciones y Subredes .
Tenga en cuenta que los parámetros que configuró durante la creación de
su red virtual se distribuirán entre las diferentes opciones en la página de
la red virtual. Como vio en los pasos anteriores, crear una red virtual con
Azure Portal es un proceso sencillo, aunque en algunas circunstancias, es
posible que deba automatizar el proceso de creación y puede usar
PowerShell para hacerlo.
Cuando crea su red virtual, puede utilizar cualquier rango de IP que forme
parte de RFC 1918, que incluye
• (multidifusión)
224.0.0.0/4
• 255.255.255.255/32 (transmisión)
• 127.0.0.0/8 (bucle invertido)
• 169.254.0.0/16 (enlace-local)
• 168.63.129.16/32 (DNS interno)
También considere los siguientes puntos:
• Azure se reserva x.x.x.0como dirección de red y x.x.x.1como
puerta de enlace predeterminada.
• x.x.x.2y x.x.x.3se asignan a las direcciones IP de Azure DNS
al espacio de la red virtual.
• x.x.x.255 está reservado para una dirección de difusión de
red.
Para automatizar eso, puede usar PowerShell en su estación de trabajo
cliente (usando Connect-AzAccountpara conectarse a su suscripción de
Azure) o usando Cloud Shell directamente
desde https://shell.azure.com . Para crear una red virtual con PowerShell,
debe usar New-AzVirtualNetwork cmdlet, como se muestra aquí:
$ AZ500Subnet = New-AzVirtualNetworkSubnetConfig -Name
AZ500Subnet -AddressPrefix
"10.3.0.0/24"
New-AzVirtualNetwork -Name AZ500VirtualNetwork -

ResourceGroupName ContosoCST -Location
centralus -AddressPrefix "10.3.0.0/16" -Subnet $ AZ500Subnet
En este ejemplo, tiene la variable $AZ500Subnet , que configura una nueva

subred para esta red virtual utilizando New-AzVirtualNetworkSubnetConfig
cmdlet. A continuación, New-AzVirtualNetwork cmdletse usa para crear la
nueva red virtual y llama a la $AZ500Subnetvariable al final de la línea de
comandos para crear la subred.
Después de crear su red virtual, puede comenzar a conectar recursos a
ella. En un escenario de IaaS, es muy común conectar sus máquinas
virtuales (VM) a la red virtual. Suponiendo que tiene privilegios de
colaborador de máquina virtual en la suscripción, puede implementar
rápidamente una nueva máquina virtual, el New-AzVMcmdlet de PowerShell,
como se muestra aquí:
New-AzVm `
-ResourceGroupName "ContosoCST" `
-Ubicación "Este de EE. UU."
-VirtualNetworkName "AZ500VirtualNetwork" `
-SubnetName "AZ500Subnet" `
-Nombre "AZ500VM" `
Enrutamiento
En un entorno de red física, por lo general, debe comenzar a configurar
rutas tan pronto como expanda su red para tener múltiples subredes. En
Azure, la tabla de enrutamiento se crea automáticamente para cada
subred dentro de una red virtual de Azure. Las rutas predeterminadas
creadas por Azure y asignadas a cada subred en una red virtual no se
pueden quitar. La ruta predeterminada que se crea contiene un prefijo de
dirección y el siguiente salto (donde debe ir el paquete). Cuando el tráfico
sale delsubred, va a una dirección IP dentro del prefijo de dirección de
una ruta; la ruta que contiene el prefijo es la ruta que usa Azure.
Cuando crea una red virtual, Azure crea una ruta con un prefijo de
dirección que corresponde a cada rango de direcciones que definió dentro
del espacio de direcciones de su red virtual. Si la red virtual tiene
definidos varios rangos de direcciones, Azure crea una ruta individual
para cada rango de direcciones. No necesita preocuparse por crear rutas
entre subredes dentro de la misma red virtual porque Azure enruta
automáticamente el tráfico entre subredes mediante las rutas creadas
para cada rango de direcciones. Además, a diferencia de la topología de la
red física y el mecanismo de enrutamiento, no es necesario definir
puertas de enlace para que Azure enrute el tráfico entre subredes. En una
tabla de enrutamiento de Azure, esta ruta aparece como:
• Fuente predeterminada
• Prefijo de dirección Único para la red virtual
• Tipo de siguiente salto Red virtual
Si el destino del tráfico es Internet, Azure aprovecha el 0.0.0.0/0prefijo de
dirección de ruta predeterminado del sistema , que enruta el tráfico para
cualquier dirección no especificada por un rango de direcciones dentro de
una red virtual a Internet. La única excepción a esta regla es si la dirección
de destino es para uno de los servicios de Azure. En este caso, en lugar de
enrutar el tráfico a Internet, Azure enruta el tráfico directamente al
servicio a través de la red troncal de Azure. Los otros escenarios en los
que Azure agregará rutas son los siguientes:
• Cuando crea un emparejamiento de redes virtuales En este
caso, se agrega una ruta para cada rango de direcciones dentro del
espacio de direcciones de cada emparejamiento de redes virtuales
que creó.
• Cuando agrega una puerta de enlace de red virtual En este
caso, se agregan una o más rutas con una puerta de enlace de red
virtual listada como el siguiente tipo de salto.
• Cuando se agrega un
VirtualNetworkServiceEndpoint Cuando habilita un punto de
conexión de servicio para publicar un servicio de Azure en Internet,
Azure agrega las direcciones IP públicas de los servicios a la tabla
de enrutamiento.
También puede ver Noneen la columna Tipo de salto siguiente , en la
tabla de enrutamiento. El tráfico enrutado a este salto se descarta
automáticamente. Azure crea automáticamente las rutas
predeterminadas para 10.0.0.0/8, 192.168.0.0/16(RFC 1918),
y 100.64.0.0/10(RFC 6598).

El examen puede incluir escenarios que involucren problemas
relacionados con el enrutamiento. Asegúrese de prestar mucha
atención a los detalles sobre la configuración de enrutamiento y si
falta alguna configuración de enrutamiento.
En este punto, puede preguntar: "Si todas estas rutas se crean
automáticamente, ¿en qué escenario debería crear una ruta
personalizada?" Debe hacer esto solo cuando necesite modificar el
comportamiento de enrutamiento predeterminado. Por ejemplo, si agrega
un Firewall de Azure o cualquier otro dispositivo virtual, puede cambiar
la ruta predeterminada ( 0.0.0.0/0) para que apunte a este dispositivo
virtual. Esto permitirá que el dispositivo inspeccione el tráfico y
determine si reenviar o eliminar el tráfico. Otro ejemplo es cuando desea
asegurarse de que el tráfico de los hosts no vaya a Internet; puede
controlar las reglas de enrutamiento para lograrlo.
Para crear una ruta personalizada que sea eficaz para sus necesidades,
debe crear una tabla de enrutamiento personalizada, crear una ruta
personalizada y asociar la tabla de enrutamiento a una subred, como se
muestra en la secuencia de PowerShell que sigue.
1. Cree la tabla de enrutamiento usando New-AzRouteTable cmdlet, como
se muestra aquí:
$ routeTableAZ500 = New-AzRouteTable `
-Nombre 'AZ500RouteTable' ''
-ResourceGroupName ContosoCST `
-ubicación EastUS
2. Cree la ruta personalizada utilizando varios cmdlets. Primero,
recupera la información de la tabla de rutas usando Get-
AzRouteTabley luego crea la ruta usando Add-AzRouteConfig. Por
último, usa Set-AzRouteTablepara escribir la configuración de
enrutamiento en la tabla de enrutamiento:
Get-AzRouteTable `
-ResourceGroupName "ContosoCST" `
-Nombre "AZ500RouteTable" `
| Add-AzRouteConfig `
-Nombre "ToAZ500Subnet" `
-AddressPrefix 10.0.1.0/24 `
-NextHopType "MyVirtualAppliance" `
-NextHopIpAddress 10.0.2.4 `
| Set-AzRouteTable
3. Ahora que tiene la tabla de enrutamiento y la ruta personalizada,

puede asociar la tabla de enrutamiento con la subred. Observe aquí
que primero escribe la configuración de la subred en la red virtual
con la extensión Set-AzVirtualNetwork cmd. Después de eso, usa Set-
AzVirtualNetworkSubnetConfigpara asociar la tabla de rutas a la
subred:
$ virtualNetwork | Set-AzVirtualNetwork
Set-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $ virtualNetwork `
-Nombre 'CustomAZ500Subnet' ''
-AddressPrefix 10.0.0.0/24 `
-RouteTable $ routeTableAZ500 | '

Set-AzVirtualNetwork
Peering de red virtual

Cuando tiene varias redes virtuales en su infraestructura de Azure, puede
conectar esas redes virtuales mediante emparejamiento de redes
virtuales. Puede usar el emparejamiento de redes virtuales para conectar
redes virtuales dentro de la misma región de Azure o entre regiones de
Azure; hacerlo se denomina emparejamiento global de redes virtuales.
Cuando las redes virtuales están en la misma región, la latencia de red
entre las máquinas virtuales que se comunican a través del
emparejamiento de redes virtuales es la misma que la latencia dentro de
una sola red virtual. También es importante mencionar que el tráfico
entre máquinas virtuales en redes virtuales emparejadas no se realiza a
través de una puerta de enlace ni a través de la Internet pública; en
cambio, ese tráfico se enruta directamente a través de la infraestructura
troncal de Microsoft. Para crear un emparejamiento de redes virtuales
mediante Azure Portal, siga estos pasos:
2. En la barra de búsqueda, escriba redes virtuales y, en Servicios ,
haga clic en Redes virtuales .
3. Haga clic en la red virtual que desea emparejar y, en el panel de
navegación izquierdo, haga clic en Peerings (consulte la Figura 2-
6 ).
Figura 2-6 Configuración de emparejamiento de redes virtuales
4. Haga clic en el botón Agregar y aparecerá la página Agregar
emparejamiento , como se muestra en la Figura 2-7 .
Figura 2-7 Agregar un nuevo emparejamiento
5. En el campo Nombre , escriba un nombre para este
emparejamiento.
6. En el campo Suscripción , seleccione la suscripción que tiene la red
virtual a la que desea conectarse.
7. En el campo Red virtual , haga clic en el menú desplegable y
seleccione la red virtual que desea emparejar.
8. En el campo Nombre del emparejamiento desde red virtual
remota , escriba el nombre con el que desea que aparezca esta
conexión de emparejamiento en la otra red virtual .
9. Las siguientes dos opciones: Permitir el acceso a la red virtual
desde [nombre de la red virtual] a la red virtual
remota y Permitir el acceso a la red virtual desde la red virtual
remota a [nombre de la red virtual] se utilizan para controlar la
comunicación entre esas redes virtuales. Si desea una conectividad
total desde ambas direcciones, asegúrese de dejar
la opción Habilitada seleccionada (selección predeterminada) para
ambas. Habilitar la comunicación entre redes virtuales permite que
los recursos conectados a cualquiera de las redes virtuales se
comuniquen entre sí con el mismo ancho de banda y latencia como
si estuvieran conectados a la misma red virtual.
10. Las siguientes dos opciones, Permitir tráfico reenviado
desde la red virtual remota a [nombre de la red
virtual] y Permitir el tráfico reenviado desde [nombre de la red
virtual] a la red virtual remota, están relacionadas con permitir el
tráfico reenviado. Debe seleccionar Habilitarpara ambas
configuraciones solo cuando necesite permitir que un dispositivo
virtual de red reenvíe el tráfico que no se originó en la red virtual a
través de un emparejamiento. Por ejemplo, considere tres redes
virtuales llamadas VNetTX, VNetWA y MainHub. Existe un
emparejamiento entre cada red virtual de radio (VNetTX y
VNetWA) y la red virtual del concentrador, pero no existen
emparejamientos entre las redes virtuales de radio. Se implementa
un dispositivo virtual de red en Hub VNet y las rutas definidas por
el usuario se pueden aplicar a cada VNet radial para enrutar el
tráfico entre las subredes a través del dispositivo virtual de red. Si
esta opción está desactivada, no habrá flujo de tráfico entre los dos
radios a través del concentrador.
11. Haga clic en Aceptar para finalizar la configuración.
Para configurar un emparejamiento de redes virtuales mediante
PowerShell, solo necesita usar el Add-AzVirtualNetworkPeeringcmdlet, como
se muestra aquí:
Add-AzVirtualNetworkPeering -Name 'NameOfTheVNetPeering' -
VirtualNetwork SourceVNet
-RemoteVirtualNetworkId RemoteVNet
Una red virtual emparejada puede tener su propia puerta de enlace y la

red virtual puede usar su puerta de enlace para conectarse a una red
local. Un uso común del emparejamiento de redes virtuales es cuando se
crea una red radial de concentrador. En este tipo de topología, el
concentrador es una red virtual que actúa como un concentrador central
para la conectividad a su red local. Los radios son redes virtuales que se
interconectan con el concentrador, lo que les permite estar aisladas, lo
que aumenta sus límites de seguridad. En la Figura 2-8 se muestra un
ejemplo de esta topología .
Figura 2-8 Topología de red de radios de concentrador mediante
emparejamiento de redes virtuales
Una red híbrida usa el modelo de arquitectura de radio concentrador para
enrutar el tráfico entre redes virtuales de Azure y redes locales. Cuando
hay una conexión de sitio a sitio entre la red virtual de Azure y el centro
de datos local, debe definir una subred de puerta de enlace en la red
virtual de Azure. Todo el tráfico del centro de datos local fluirá luego a
través de la subred de la puerta de enlace.
Traducción de Direcciones de Red

Azure tiene una capacidad de NAT de red virtual (traducción de
direcciones de red) que permite la conectividad a Internet solo saliente
para redes virtuales. Este es un escenario común cuando desea que la
conectividad saliente use una dirección IP pública estática específica
(NAT estática) o desea usar un grupo de direcciones IP públicas (NAT
dinámica).
Tenga en cuenta que la conectividad saliente es posible sin el uso de un
equilibrador de carga de Azure o una dirección IP pública directamente
adjunta a la máquina virtual. La Figura 2-9 muestra un ejemplo de la
topología con una puerta de enlace NAT.
Figura 2-9 Topología de puerta de enlace NAT
Puede implementar NAT mediante el uso de un prefijo de IP pública
directamente, o puede distribuir las direcciones IP públicas del prefijo
entre varios recursos de puerta de enlace NAT. NAT también cambia la
ruta de la red porque tiene prioridad sobre otros escenarios salientes y
reemplazará el destino de Internet predeterminado de una subred. Desde
el punto de vista de la disponibilidad (que es fundamental para la
seguridad), NAT siempre tiene varios dominios de fallas, lo que significa
que puede soportar múltiples fallas sin interrupción del servicio.
Facturación importante de Nat Gateway
Una puerta de enlace NAT se factura con dos contadores separados: horas de recursos
y datos procesados. Consulte la página de precios de Azure NAT para conocer los
precios más recientes.
Para crear una puerta de enlace NAT para su subred, primero debe crear
una dirección IP pública y un prefijo de IP pública. Siga los pasos a
continuación para realizar estas tareas:
2. En el panel principal, haga clic en el botón Crear un recurso .
3. En la página Nueva , escriba IP pública y haga clic en
la opción Dirección IP pública que aparece en la lista.
4. En la página Dirección IP pública , haga clic en
el botón Crear ; la Crear dirección IP pública aparece la página,
como se muestra en la figura 2-10 .
Figura 2-10 Creación de una dirección IP pública para ser utilizada
por NAT Gateway
5. Escriba el nombre de esta dirección IP pública y seleccione la
suscripción, el grupo de recursos y la ubicación de Azure. Para este
ejemplo, puede dejar todas las demás opciones con sus selecciones
predeterminadas. Una vez que termine, haga clic en el botón Crear .
6. Ahora debe repetir los pasos 1 y 2. En el tercer paso, escriba el
prefijo de IP pública y haga clic en la opción Prefijo de IP
pública que aparece en el menú desplegable.
7. En la página Crear un prefijo de IP pública , configure las
siguientes opciones relevantes:
1. Seleccione la suscripción adecuada .
2. Seleccione el grupo de recursos apropiado .
3. Escriba el nombre del prefijo .
4. Seleccione la región de Azure adecuada .
5. En el menú desplegable Tamaño de prefijo , seleccione el tamaño
adecuado para su implementación.
8. Una vez que termine de configurar estas opciones, haga clic en el
botón Revisar + Crear y haga clic en Crear para finalizar.
9. Ahora que ha cumplido los dos requisitos, puede crear la puerta de
enlace NAT.
11. En el panel principal, haga clic en el botón Crear un recurso .
12. En la página Nueva, escriba NAT Gateway y haga clic en
la opción NAT Gateway en la lista.
13. En la página Puerta de enlace NAT , haga clic
en Crear . El Crear Network Address Translation (NAT) de
puerta de enlace aparece la página, como se muestra en la figura
2-11 .
Figura 2-11 Creación de una puerta de enlace NAT en Azure
14. En la pestaña Básicos , asegúrese de configurar las siguientes
opciones:
0. Seleccione la suscripción y el grupo de
recursos adecuados .
1. Escriba el nombre de la puerta de enlace NAT .
2. Seleccione la región de Azure y la zona de
disponibilidad adecuadas .
15. Vaya a la siguiente pestaña, IP saliente , y seleccione la
Dirección IP pública y el Nombre de prefijo que creó anteriormente.
16. A continuación, en la pestaña Subred , configurará qué
subredes de una red virtual deben usar esta puerta de enlace NAT.
17. La pestaña Etiquetas es opcional y debe usarla solo cuando
necesite organizar lógicamente sus recursos en una taxonomía
particular para identificarlos fácilmente más adelante.
18. Puede revisar un resumen de las selecciones en
la pestaña Revisar + Crear . Una vez que termine de revisarlo, haga
clic en el botón Crear .
También puede usar el New-AzNatGatewaycmdlet para crear una puerta de
enlace NAT con PowerShell, como se muestra:
New-AzNatGateway -ResourceGroupName "AZ500RG" -Name "nat_gt"
-IdleTimeoutInMinutes 4
-Sku "Estándar" -Ubicación "eastus2" -PublicIpAddress

PublicIPAddressName
Asegure la conectividad de las redes virtuales

Con las organizaciones que migran a la nube, las redes privadas virtuales
(VPN) se utilizan constantemente para establecer un vínculo de
comunicación seguro entre la infraestructura de red local y la nube. Si
bien este es un escenario común, hay muchos otros escenarios en los que
se puede utilizar una VPN. Puede usar Azure VPN para conectar dos
regiones de Azure diferentes o suscripciones diferentes.
Azure ofrece de forma nativa un servicio llamado puerta de enlace VPN,
que es un tipo específico de puerta de enlace de red virtual que se usa
para enviar tráfico cifrado entre una red virtual de Azure y recursos
locales. También puede usar una puerta de enlace VPN para enviar tráfico
cifrado entre redes virtuales de Azure. Cuando planifique la
implementación de su puerta de enlace VPN, tenga en cuenta que cada
red virtual solo puede tener una puerta de enlace VPN y puede crear
varias conexiones a la misma puerta de enlace VPN. Dependiendo del
escenario, puede seleccionar entre diferentes tipos de conectividad
VPN. Las opciones disponibles son
• VPN de sitio a sitio (S2S) Este tipo de VPN se usa en
escenarios en los que necesita conectar recursos locales a Azure. El
túnel de conexión cifrado utiliza IPsec / IKE (IKEv1 o IKEv2).
• VPN de punto a sitio (P2S) Este tipo de VPN se usa en
escenarios en los que necesita conectarse a su red virtual de Azure
desde una ubicación remota. Por ejemplo, usaría P2S cuando
trabaja de forma remota (hotel, casa, conferencia, etc.) y necesita
acceder a recursos en su red virtual. Esta VPN utiliza SSTP
(Protocolo de túnel de sockets seguros) o IKE v2 y no requiere un
dispositivo VPN.
• VNet-a-VNet Como su nombre indica, esta VPN se utiliza en
situaciones en las que hay que cifrar la conectividad entre
VNets. Este tipo de conexión utiliza IPsec (IKE v1 e IKE v2).
• VPN de varios sitios Este tipo de VPN se utiliza en escenarios
en los que necesita expandir su configuración de sitio a sitio para
permitir que varios sitios locales accedan a una red virtual.
ExpressRoute es otra opción que permite la conectividad desde sus
recursos locales a Azure. Esta opción usa una conexión privada a Azure
desde su WAN, en lugar de una conexión VPN a través de Internet.
Autenticación VPN
La conexión VPN de Azure se autentica cuando se crea el túnel. Azure
genera una clave precompartida (PSK), que se usa para la
autenticación. Esta clave precompartida es un carácter de cadena ASCII de
no más de 128 caracteres. Esta autenticación ocurre para VPN basada en
políticas (enrutamiento estático) o VPN (enrutamiento dinámico) basada
en enrutamiento. Puede ver y actualizar la clave previamente compartida
para una conexión con estos cmdlets de PowerShell:
• Get-AzVirtualNetworkGatewayConnectionSharedKey Este
comando se usa para mostrar la clave previamente compartida.
• Set-AzVirtualNetworkGatewayConnectionSharedKey Este
comando se usa para cambiar la clave previamente compartida a
otro valor.
Para escenarios de VPN de punto a sitio (P2S), puede usar la
autenticación de certificado de Azure nativa o la autenticación de Azure
AD. Para la autenticación de certificado nativo de Azure, se presenta un
certificado de cliente en el dispositivo, que se usa para autenticar a los
usuarios que se conectan. El certificado puede ser uno emitido por una
autoridad certificadora (CA) empresarial o puede ser un certificado raíz
autofirmado. Para Azure AD nativo, puede usar las credenciales nativas
de Azure AD. Tenga en cuenta que Azure AD nativo solo es compatible con
el protocolo OpenVPN y Windows 10. (Windows 10 requiere el uso del
cliente VPN de Azure).
Si su escenario requiere la aplicación de un segundo factor de
autenticación antes de que se otorgue el acceso al recurso, puede usar
Azure Multi-Factor Authentication (MFA) con acceso condicional. Incluso
si no desea implementar MFA en toda su empresa, puede establecer el
MFA para que se emplee solo para usuarios de VPN que utilicen la
capacidad de acceso condicional.
Más información sobre la configuración de MFA para el acceso VPN
Puede ver los pasos para configurar MFA para el acceso VPN
en http://aka.ms/az500mfa .
Otra opción disponible para P2S es la autenticación mediante RADIUS

(que también admite IKEv2 y SSTP VPN). Tenga en cuenta que RADIUS
solo es compatible con los SKU VpnGw1, VpnGw2 y VpnGw3. Para
obtener más información sobre los SKU de VPN más recientes,
visite http://aka.ms/az500vpnsku . La Figura 2-12 muestra un ejemplo de
las opciones que aparecen cuando está configurando una VPN P2S y
necesita seleccionar el tipo de autenticación.
Figura 2-12 Opciones de autenticación para VPN
Las opciones que aparecen justo debajo de la sección Tipo de
autenticación variarán según el Tipo de autenticación que seleccione. En
la Figura 2-12 , se elige el certificado de Azure y la página muestra
opciones para ingresar el nombre y los datos de certificación
pública para los certificados raíz y el nombre y la huella digital para
los certificados revocados . Si selecciona la autenticación RADIUS ,
deberá especificar la dirección IP del servidor y el secreto del
servidor . Por último, si selecciona Azure Active Directoryopción,
deberá especificar la URL del inquilino ; la audiencia (que identifica el
recurso receptor al que está destinado el token); y el Emisor (que
identifica el Security Token Service (STS) que emitió el token). Por último,
elija el inquilino de Azure AD.
Su escenario particular dictará qué opción utilizar. Por ejemplo, el
departamento de TI de Contoso necesita implementar una solución VPN
que pueda integrarse con una infraestructura de autenticación de
certificados que ya tiene a través de RADIUS. En este caso, debe utilizar la
autenticación de certificado RADIUS. Cuando se usa la autenticación del
certificado RADIUS, la solicitud de autenticación se reenvía a un servidor
RADIUS, que maneja la validación del certificado. Si el escenario requiere
que la puerta de enlace de VPN de Azure realice la autenticación del
certificado, la opción correcta sería usar la autenticación del certificado
nativo de Azure.
Cifrado ExpressRoute
Si su escenario de conectividad requiere un mayor nivel de confiabilidad,
velocidades más rápidas, latencias consistentes y mayor seguridad que las
conexiones típicas a través de Internet, debe usar ExpressRoute, que
proporciona conectividad de capa 3 entre su red local y Microsoft Cloud.
ExpressRoute admite dos tecnologías de cifrado diferentes para
garantizar la confidencialidad y la integridad de los datos que se
transmiten desde las instalaciones a la red de Microsoft. Las opciones son
• Cifrado punto a punto por MACsec
• Cifrado de extremo a extremo por IPSec
MACsec cifra los datos en el nivel de control de acceso a medios (MAC) o
en la capa de red 2. Cuando habilita MACsec, todo el tráfico de control de
red se cifra, lo que incluye el tráfico de datos del protocolo de puerta de
enlace fronteriza (BGP) y su tráfico de datos (del cliente) . Esto significa
que no puede cifrar solo algunos de sus circuitos ExpressRoute.
Si necesita cifrar los enlaces físicos entre sus dispositivos de red y los
dispositivos de red de Microsoft cuando se conecta a Microsoft a través de
ExpressRoute Direct, se prefiere MACsec. MACsec también le permite
traer su propia clave MACsec para el cifrado y almacenarla en Azure Key
Vault. Si esta es la opción de diseño, recuerde que deberá decidir cuándo
girar la llave.
Sugerencia Expressroute Direct
Aunque MACsec solo está disponible en ExpressRoute Direct, viene deshabilitado de
forma predeterminada en los puertos ExpressRoute Direct.
Tenga en cuenta que cuando actualice la clave MACsec, los recursos

locales perderán temporalmente la conectividad con Microsoft a través de
ExpressRoute. Esto sucede porque la configuración de MACsec solo
admite el modo de clave precompartida, por lo que debe actualizar la
clave en ambos lados. En otras palabras, si hay una discrepancia, no se
producirá el flujo de tráfico. Planifique la ventana de mantenimiento
correcta para reducir el impacto en los entornos de producción.
La otra opción es utilizar el cifrado de extremo a extremo con IPSec, que
cifra los datos en el nivel de protocolo de Internet (IP) o en la capa de red
3. Un escenario muy común es utilizar IPSec para cifrar la conexión de
extremo a extremo. entre los recursos locales y su red virtual de Azure. En
un escenario en el que necesite cifrar la capa 2 y la capa 3, puede habilitar
MACsec e IPSec.
Más información Crear Ipsec sobre Expressroute
Puede aprender a crear IPsec sobre ExpressRoute para Virtual WAN
en http://aka.ms/az500vpnexpressroute .
Punto a sitio
Para implementar una VPN de punto a sitio (P2S) en Azure, primero debe
decidir qué método de autenticación usará en función de las opciones que
se presentaron anteriormente en esta sección. El método de autenticación
dictará cómo se configurará la VPN P2S. Al configurar la VPN P2S, verá las
opciones disponibles en Tipo de túnel , como se muestra en la Figura 2-
13 .
Figura 2-13 Diferentes opciones para el túnel VPN
• Otra variable importante a seleccionar es el protocolo que se
utilizará. Utilice la Tabla 2-1 para seleccionar el protocolo más
apropiado según las ventajas y limitaciones:
Tabla 2-1 Ventajas y limitaciones
Protocolo Ventajas Limitaciones
Protocolo Esta es una solución basada en TLS VPN No se admite el SKU básic
OpenVPN que puede atravesar la mayoría de los
firewalls del mercado. No disponible para el mod
implementación clásico.
Se puede utilizar para conectarse desde
una variedad de sistemas operativos,
incluidos dispositivos Android, iOS
(versiones 11.0 y superiores), Windows,
Linux y Mac (versiones OSX 10.13 y
superiores).
Protocolo Ventajas Limitaciones
Protocolo de Puede atravesar la mayoría de los Solo compatible con dispo

túnel de cortafuegos porque usa el puerto TCP
socket seguro 443. Admite hasta 128 conexio
(SSTP) independientemente del S
de enlace.
IKEv2 Solución VPN IPsec basada en No se admite el SKU básic

estándares.
No disponible para el mod
Se puede utilizar para conectarse a implementación clásico.
dispositivos Mac (versiones OSX 10.11 y
superiores). Utiliza puertos UDP no es
debe asegurarse de que es
estén bloqueados en el fir
usuario. Los puertos en us
4500.

Para el examen AZ-500, asegúrese de leer detenidamente los
escenarios porque habrá indicaciones de lo que la empresa quiere
lograr, y esas indicaciones se utilizarán para decidir qué protocolo
implementar o qué protocolo no es una opción para el escenario
especificado. .
Sitio a Sitio
En la mayoría de los escenarios se usa una VPN de sitio a sitio (S2S) para
permitir la comunicación desde una ubicación (local) a otra (Azure) a
través de Internet. Para configurar un S2S, es necesario que se cumplan
los siguientes requisitos previos antes de comenzar:
• Un dispositivo VPN local que es compatible con la
configuración basada en políticas o la configuración basada en
rutas de Azure VPN. Consulte la lista completa
en https://aka.ms/az500s2sdevices .
• Dirección IPv4 pública externa.
• Rango de direcciones IP de su red local que se utilizará para
permitir que Azure se enrute a su ubicación local.
Más información Más información Creación de una VPN S2S
Una vez que tenga esos requisitos, puede crear su VPN S2S. Para obtener más
información sobre los pasos, consulte https://aka.ms/az500s2svpn . Si su conexión VPN
es a través de IPsec (IKE v1 e IKE v2), debe tener un dispositivo VPN o un RRAS.
Configurar grupos de seguridad de red y grupos

de seguridad de aplicaciones
Los grupos de seguridad de red (NSG) en Azure le permiten filtrar el
tráfico de red mediante la creación de reglas que permiten o deniegan el
tráfico de red entrante o el tráfico de red saliente de diferentes tipos de
recursos. Por ejemplo, puede configurar un NSG para bloquear el tráfico
entrante de Internet a una subred específica que solo permite el tráfico de
un dispositivo virtual de red (NVA).
Los grupos de seguridad de red se pueden habilitar en la subred o en la
interfaz de red en la VM, como se muestra en la Figura 2-14 .
Figura 2-14 Diferentes implementaciones de NSG
En el diagrama que se muestra en la Figura 2-14 , tiene dos usos
diferentes de NSG. En el primer caso, el NSG se asigna a la subred A. Esta
puede ser una buena forma de proteger toda la subred con un solo
conjunto de reglas del NSG. Sin embargo, habrá escenarios en los que es
posible que deba controlar el NSG en el nivel de la interfaz de red, que es
el caso del segundo escenario (subred B), donde VM 5 y VM 6 tienen un
NSG asignado a la interfaz de red.
Cuando el tráfico entrante llega a través de la red virtual, Azure procesa
primero las reglas del grupo de seguridad de red que están asociadas con
la subred, si las hay, y luego procesa las reglas del grupo de seguridad de
red que están asociadas con la interfaz de red. Cuando el tráfico sale de la
red virtual (tráfico saliente), Azure procesa primero las reglas del grupo
de seguridad de red que están asociadas con la interfaz de red, seguidas
de las reglas del grupo de seguridad de red que están asociadas a la
subred.
Cuando crea un NSG, debe configurar un conjunto de reglas para
fortalecer el tráfico. Estas reglas utilizan los siguientes parámetros:
• Nombre El nombre de la regla.
• Prioridad El orden en el que se procesará la regla. Los
números más bajos tienen alta prioridad, lo que significa que una
prioridad de regla 100 se evaluará antes que la prioridad de regla
300. Una vez que el tráfico coincide con la regla, dejará de avanzar
para evaluar otras reglas. Al configurar la prioridad, puede asignar
un número entre 100 y 4096.
• Origen Defina la IP de origen, el bloque CIDR, la etiqueta de
servicio o el grupo de seguridad de la aplicación.
• Destino Defina la IP de destino, el bloque CIDR, la etiqueta de
servicio o el grupo de seguridad de la aplicación.
• Protocolo Defina el protocolo TCP / IP que se utilizará, que se
puede configurar en TCP , UDP , ICMP o Cualquiera .
• Rango de puertos Defina el rango de puertos o un solo
puerto.
• Acción Esto determina la acción que se tomará una vez que se
procese esta regla. Esto se puede establecer
en Permitir o Denegar .
Antes de crear un nuevo NSG y agregar nuevas reglas, es importante
saber que Azure crea automáticamente reglas predeterminadas en las
implementaciones del NSG. A continuación se muestra una lista de las
reglas de entrada que se crean:
• AllowVNetInBound
• Prioridad 6500
• Fuente VirtualNetwork
• Puertos de origen 0-65535
• Red virtual de destino
• Puertos de destino 0-65535
• Protocolo Alguna
• Acceso Permitir
• AllowAzureLoadBalancerInBound
• Prioridad 6501
• Fuente AzureLoadBalancer
• Destino 0.0.0.0/0
• Acceso Permitir
• DenyAllInbound
• Prioridad 6501
• Fuente AzureLoadBalancer
• Destino 0.0.0.0/0
• Acceso denegado
A continuación, se muestra una lista de las reglas de salida que se crean:
• AllowVnetOutBound
• Prioridad 6501
• Fuente VirtualNetwork
• Red virtual de destino
• Acceso Permitir
• AllowInternetOutBound
• Prioridad 6501
• Fuente 0.0.0.0/0
• Internet de destino
• Acceso Permitir
• DenyAllOutBound
• Prioridad 6501
• Fuente 0.0.0.0/0
• Destino 0.0.0.0/0
• Acceso denegado
No se pueden eliminar las reglas predeterminadas importantes
Tenga en cuenta que estas reglas predeterminadas no se pueden eliminar, aunque, si
es necesario, puede anularlas creando reglas con prioridades más altas.
Siga los pasos a continuación para crear y configurar un NSG, que en este
ejemplo, se asociará con una subred:
1. Navegue hasta Azure Portal abriendo https://portal.azure.com .
2. En la barra de búsqueda, escriba seguridad de red y, en Servicios ,
haga clic en Grupos de seguridad de red ; la seguridad de la red
Grupos aparece la página.
3. Haga clic en el botón Agregar ; la Creación de seguridad de red
Grupo aparece la página, como se muestra en la figura 2-15 .
Figura 2-15 Parámetros iniciales del grupo de seguridad de la red

4. En el campo Suscripción , seleccione la suscripción donde residirá
este NSG.
5. En el campo Grupo de recursos , seleccione el grupo de recursos
en el que residirá este grupo de seguridad de red.
6. En el campo Nombre , escriba el nombre de este NSG.
7. En el campo Región , seleccione la región de Azure en la que
residirá este grupo de seguridad de red.
8. Haga clic en el botón Revisar + Crear , revise las opciones y haga
clic en el botón Crear .
9. Una vez que se complete la implementación, haga clic en el botón Ir
a recurso . Aparece la página NSG.
En este punto, ha creado correctamente su NSG y puede ver que las reglas
predeterminadas ya forman parte de él. El siguiente paso es crear las
reglas personalizadas, que pueden ser entrantes o salientes. (Este
ejemplo usa reglas de entrada). Se podría realizar la misma operación con
el New-AzNetworkSecurityGroupcmdlet de PowerShell, como se muestra en el
siguiente ejemplo:
New-AzNetworkSecurityGroup -Nombre "AZ500NSG" -
ResourceGroupName "AZ500RG" -Ubicación
"westus"
Siga estos pasos para crear una regla de entrada que permita el tráfico
FTP desde cualquier origen a un servidor específico mediante Azure
Portal:
1. En la página NSG, en Configuración en el panel de navegación
izquierdo, haga clic en Reglas de seguridad de entrada .
2. Haga clic en el botón Agregar ; el Agregar regla de seguridad
entrante cuchilla aparece, como se muestra en la Figura 2-16 .
Figura 2-16 Creación de una regla de seguridad entrante para su
NSG
3. En esta hoja, comienza especificando la fuente, que puede ser una
dirección IP, una etiqueta de servicio o un ASG. Si deja la opción
predeterminada ( Cualquiera ), está permitiendo cualquier
fuente. Para este ejemplo, deje esto establecido en Cualquiera .
4. En el campo Rangos de puertos de origen , puede reforzar el
puerto de origen. Puede especificar un solo puerto o un
intervalo. Por ejemplo, puede permitir el tráfico desde los puertos
50 a 100. Además, puede usar una coma para agregar otra
condición al rango, como 50-100, 135, que especifica los puertos 50 a
100 y 135. Deje la selección predeterminada ( * ), que permite
cualquier Puerto de origen.
5. En el campo Destino , las opciones son casi las mismas que en
el campo Origen . La única diferencia es que puede seleccionar la
red virtual como destino. Para este ejemplo, cambie esta opción
a Direcciones IP e ingrese la dirección IP interna de la VM que creó
al principio de este capítulo.
6. En el campo Rangos de puertos de destino , especifique el puerto
de destino que se permitirá. El puerto predeterminado es
8080; para este ejemplo, cámbielo a 21.
7. En el campo Protocolo , puede seleccionar qué protocolo va a
permitir; en este caso, cámbielo a TCP .
8. Deje el campo Acción establecido en Permitir , que es la selección
predeterminada.
9. También puede cambiar la Prioridad de esta regla. Recuerde que la
prioridad más baja se evalúa primero. Para este ejemplo, cámbielo
a 101 .
10. En el campo Nombre , cámbielo a AZ500NSGRule_FTP y
haga clic en el botón Agregar .
Se creará el NSG y se agregará una nueva regla a las reglas de entrada. En
este punto, sus reglas de entrada deberían parecerse a las reglas que se
muestran en la Figura 2-17 .
Figura 2-17 Lista de reglas de entrada
Si bien estos son los pasos para crear la regla de entrada, este NSG no
sirve de nada si no está asociado con una subred o una interfaz de red
virtual. Para este ejemplo, asociará este NSG a una subred. La intención es
bloquear todo el tráfico a esta subred y solo permitir el tráfico FTP a este
servidor específico. Utilice los siguientes pasos para crear esta asociación:
1. En el panel de navegación izquierdo de la página Reglas de
seguridad de entrada de NSG en Configuración , haga clic
en Subredes .
2. Haga clic en el botón Asociar y, en el menú desplegable Red
virtual , seleccione la red virtual donde reside la subred.
3. Después de esta selección, verá que aparece el menú
desplegable Subred ; seleccione la subred y haga clic en
el botón Aceptar .
También puede usar PowerShell para crear un NSG y luego asociar el NSG
a una subred. Para crear un NSG con PowerShell, use el New-
AzNetworkSecurityRuleConfigcmdlet, como se muestra en el siguiente
ejemplo:
$ MyRule1 = New-AzNetworkSecurityRuleConfig -Name ftp-rule -
Description "Allow FTP"
-Acceso Permitir -Protocolo Tcp -Dirección entrante -

Prioridad 100 -SourceAddressPrefix *
-SourcePortRange * -DestinationAddressPrefix * -
DestinationPortRange 21
Grupo de seguridad de la aplicación

Si necesita definir para definir políticas de seguridad de red granulares
basadas en cargas de trabajo que están centralizadas en patrones de
aplicación en lugar de direcciones IP explícitas, debe usar el grupo de
seguridad de aplicaciones (ASG). Un ASG le permite agrupar máquinas
virtuales y aplicaciones seguras porfiltrar el tráfico de los segmentos
confiables de su red, lo que agrega un nivel adicional de
microsegmentación.
Puede implementar varias aplicaciones dentro de la misma subred y
aislar el tráfico según los ASG. Otra ventaja es que puede reducir la
cantidad de NSG en su suscripción. Por ejemplo, en algunos escenarios,
puede utilizar un único NSG para varias subredes de su red virtual y
realizar la microsegmentación en el nivel de la aplicación mediante
ASG. La Figura 2-18 muestra un ejemplo de cómo se puede utilizar ASG
junto con NSG.
Figura 2-18 ASG utilizado como destino en la tabla de enrutamiento de

NSG
En el ejemplo que se muestra en la Figura 2-18 , se han creado dos ASG
para definir el patrón de aplicación para una aplicación web y otro ASG
para definir el patrón de aplicación para una base de datos SQL. Dos VM
forman parte de cada grupo y el ASG se usa en la tabla de enrutamiento
del NSG ubicado en la subred A. En la tabla de enrutamiento del NSG,
puede especificar un ASG como origen y destino, pero no puede
especificar varios ASG en el origen o destino.
Cuando implementa VM, puede convertirlas en miembros de los ASG
correspondientes. En caso de que su VM tenga múltiples cargas de trabajo
(Web App y SQL, por ejemplo), puede asignar múltiples ASG a cada
aplicación. Esto le permitirá tener diferentes tipos de acceso a la misma
VM según la carga de trabajo. Este enfoque también ayuda a implementar
un modelo de confianza cero al limitar el acceso a los flujos de
aplicaciones que están explícitamente permitidos. Siga estos pasos para
crear un ASG:
2. En la barra de búsqueda, escriba seguridad de la aplicación y
en Servicios , haga clic en Grupos de seguridad de la aplicación .
3. En el panel de Grupos de seguridad de aplicaciones , haga clic en
el botón Agregar , que hace que aparezca la página Crear un grupo
de seguridad de aplicaciones , como se muestra en la Figura 2-19 .
Figura 2-19 Crear un grupo de seguridad de aplicaciones

4. En el menú desplegable Suscripción , seleccione la suscripción
adecuada para este ASG.
5. En el menú desplegable Grupo de recursos , seleccione el grupo de
recursos en el que residirá este ASG.
6. En el campo Nombre , escriba un nombre para este ASG.
7. En el menú desplegable Región , seleccione la región adecuada para
este ASG y haga clic en el botón Revisar + Crear .
8. En la página del botón Revisar + Crear , haga clic en
el botón Crear .
Ahora que se creó el ASG, debe asociar este ASG a la interfaz de red de la
VM que tiene la carga de trabajo que desea controlar. Siga estos pasos
para realizar esta asociación:
2. En la barra de búsqueda, escriba virtual y en Servicios , haga clic
en Máquinas virtuales .
3. Haga clic en la máquina virtual que desea realizar esta asociación.
4. En la página de la máquina virtual, en la sección Configuración ,
haga clic en la opción Redes .
5. Haga clic en la pestaña Application Security Group y aparecerá la
página que se muestra en la Figura 2-20 .
Figura 2-20 Asociación del ASG a la tarjeta de interfaz de red

virtual
6. Haga clic en el Grupos de seguridad configurar la aplicación
de botón y los Configurar los grupos de seguridad de
aplicaciones aparece la hoja, como se muestra en la figura 2-21 .
Figura 2-21 Selección del ASG
7. Seleccione el ASG apropiado y haga clic en el botón Guardar .
También puede usar el New-AzApplicationSecurityGroupcmdlet para crear
un nuevo ASG, como se muestra en el siguiente ejemplo:
New-AzApplicationSecurityGroup -ResourceGroupName "MyRG" -
Name "MyASG" -Location "West
NOSOTROS"
Ahora, cuando cree su nueva regla NSG para el tráfico entrante o saliente,
puede seleccionar el ASG como origen o destino.
Crear y configurar Azure Firewall

Si bien NSG proporciona un flujo de paquetes con estado y reglas de
seguridad personalizadas, necesitará una solución más sólida cuando
necesite proteger una red virtual completa. Si su empresa necesita un
firewall de red centralizado y con estado completo como servicio (FWaaS)
que proporcione protección a nivel de aplicación y de red en diferentes
suscripciones y redes virtuales, debe elegir Azure Firewall.
Además, Azure Firewall se puede usar en escenarios en los que necesita
abarcar varias zonas de disponibilidad para aumentar la
disponibilidad. Aunque no hay ningún costo adicional para un firewall de
Azure implementado en una zona de disponibilidad, existen costos
adicionales para las transferencias de datos entrantes y salientes
asociadas con las zonas de disponibilidad. La figura 2-22 muestra un
Firewall de Azure en su propia red virtual y subred, lo que permite cierto
tráfico y bloquea otro tráfico en función de una serie de evaluaciones.
Figura 2-22 Topología de Azure Firewall

Como se muestra en la Figura 2-22 , Azure Firewall realizará una serie de
evaluaciones antes de permitir o bloquear el tráfico. Al igual que con un
grupo de seguridad de red, las reglas de Azure Firewall se procesan según
el tipo de regla en orden de prioridad (números más bajos a números más
altos). El nombre de una colección de reglas puede contener solo letras,
números, guiones bajos, puntos o guiones. Puede configurar reglas de
NAT, reglas de red y reglas de aplicaciones en Azure Firewall. Tenga en
cuenta que Azure Firewall usa una dirección IP pública estática para sus
recursos de red virtual y la necesita antes de implementar su
firewall. Azure Firewall también admite rutas de aprendizaje a través del
Protocolo de puerta de enlace fronteriza (BGP).
Para evaluar el tráfico saliente, Azure Firewall consultará la red y las
reglas de la aplicación. Al igual que con un NSG, cuando se encuentra una
coincidencia en una regla de red, no se procesan otras reglas. Si no hay
ninguna coincidencia, Azure Firewall usará la colección de reglas de
infraestructura. Azure Firewall crea esta colección automáticamente e
incluye nombres de dominio completos (FQDN) específicos de la
plataforma. Si todavía no hay ninguna coincidencia, Azure Firewall
deniega el tráfico saliente.
Para la evaluación del tráfico entrante, Azure Firewall usa reglas basadas
en la traducción de direcciones de red de destino (DNAT). Estas reglas
también se evalúan en prioridad y antes que las reglas de red. Si se
encuentra una coincidencia, se agrega una regla de red correspondiente
implícita para permitir el tráfico traducido. Aunque este es el
comportamiento predeterminado, puede anularlo agregando
explícitamente una colección de reglas de red con reglas de denegación
que coincidan con el tráfico traducido (si es necesario).
Importante Web Application Firewall (WAF)
Las reglas de la aplicación no se aplican a las conexiones entrantes. Microsoft
recomienda utilizar Web Application Firewall (WAF) si desea filtrar el tráfico HTTP
/ S entrante.
En la Figura 2-22 , también vio que Azure Firewall aprovecha Microsoft

Threat Intelligence durante la evaluación del tráfico. Microsoft Threat
Intelligence funciona con Intelligent Security Graph y muchos otros
servicios de Azure, incluido Azure Security Center, lo utilizan.
Ahora que conoce los componentes clave de Azure Firewall, utilice los
siguientes pasos para implementarlo y configurarlo:
2. En el panel principal, haga clic en Crear un recurso .
3. Escriba firewall y haga clic en Firewall en el menú desplegable.
4. En la página Cortafuegos , haga clic en el botón Crear y aparecerá
la hoja Crear un cortafuegos , como se muestra en la Figura 2-23 .
Figura 2-23 Creación de un nuevo firewall de Azure
5. Si tiene varias suscripciones, asegúrese de hacer clic en el menú
desplegable Suscripción y seleccione la que desea usar para
implementar Azure Firewall.
recursos en el que desea implementar su Firewall de Azure.
7. En la sección Detalles de la instancia , en el campo Nombre ,
escriba el nombre de esta instancia de Azure Firewall. Hay un límite
de 50 caracteres para el nombre.
8. En el menú desplegable Región , seleccione la región donde residirá
Azure Firewall.
9. En el menú desplegable Zona de disponibilidad , seleccione la
zona de disponibilidad en la que residirá el firewall.
10. Para la opción Elegir red virtual , seleccione Usar
existente y seleccione una red virtual existente.
11. En el menú desplegable Red virtual , seleccione la red
virtual en la que desea implementar Azure Firewall.
12. En el campo Dirección IP pública del cortafuegos ,
seleccione una dirección IP pública no utilizada existente o haga clic
en Agregar nueva para crear una nueva en caso de que todas sus
direcciones IP públicas ya estén asignadas.
13. Puede habilitar o deshabilitar Force Tunneling . La opción
predeterminada es Desactivada . Al habilitar esta opción, está
indicando a Azure Firewall que enrute todo el tráfico vinculado a
Internet a un siguiente salto designado en lugar de ir directamente
a Internet. Tenga en cuenta que si configura Azure Firewall para
admitir la tunelización forzada, no puede deshacer esta
configuración. Deje la selección predeterminada y haga clic en el
botón Revisar + Crear .
14. La creación de Azure Firewall llevará varios minutos. Una vez
completada la implementación, puede hacer clic en el botón Ir a
recurso .
También puede implementar un nuevo Azure Firewall mediante el New-
AzFirewallcmdlet, como se muestra en el siguiente ejemplo:

New-AzFirewall -Nombre "azFw" -ResourceGroupName MyRG -
Location centralus -VirtualNetwork
MyVNet -PublicIpAddress MyPubIP

Crear una regla de aplicación
Ahora que se creó el Firewall de Azure, puede comenzar a crear
reglas. Para empezar, creará una regla de aplicación para permitir el
acceso saliente a www.bing.com . Siga estos pasos para crear una regla:
1. En la página que ha abierto para el firewall que creó, haga clic
en Reglas , como se muestra en la Figura 2-24 .
Figura 2-24 Opciones de firewall

2. Haga clic en la pestaña Colección de reglas de aplicación y luego
haga clic en la opción + Agregar colección de reglas de
aplicación . La Agregar colección regla de la aplicación aparece
la página, como se muestra en la figura 2-25 .
Figura 2-25 Creación de una nueva colección de reglas de
aplicación
3. En el campo Nombre , escriba un nombre para la regla; para este
ejemplo, escriba Bing .
4. En el campo Prioridad , escriba la prioridad de esta regla; para este
ejemplo, escriba 100 .
5. En el menú desplegable Acción , deje la opción predeterminada
( Permitir ).
6. No es necesario realizar cambios en el campo Etiquetas FQDN .
7. En el campo FQDN de destino , escriba AllowBing y deje el Tipo
de fuente configurado en Dirección IP .
8. Escriba * en el campo Fuente .
9. En el campo Protocolo: Puerto , escriba http, https .
10. En el campo FQDN de destino , escriba www.bing.com .
11. Haga clic en el botón Agregar .
En caso de que desee realizar la misma configuración con PowerShell,
puede usar el New-AzFirewallApplicationRulecmdlet, como se muestra aquí:
$ MyAppRule = New-AzFirewallApplicationRule -Name AllowBing -
SourceAddress * `
-Protocolo http, https -TargetFqdn www.bing.com
$ AppCollectionRule = New-AzFirewallApplicationRuleCollection
-Name App-Coll01 `
-Prioridad 100 -ActionType Allow -Rule $ MyAppRule
$ Azfw.ApplicationRuleCollections = $ AppRuleCollection
Set-AzFirewall -AzureFirewall $ Azfw
Sugerencia Firewall de aplicaciones web de Azure (WAF)

Si su organización necesita protección HTTP / S entrante, se recomienda que use un
firewall de aplicaciones web como Azure Web Application Firewall (WAF) en lugar
de crear una regla de aplicación para el puerto 443.
Crear una regla de red

Crear una regla de red es muy similar a crear una regla de aplicación. Para
este ejemplo, creará una regla de red saliente que permita el acceso a un
servidor DNS externo. Siga estos pasos para crear su regla de red:
1. En la página de reglas de Firewalls , haga clic en
el pestaña Colección de reglas de red .
2. Haga clic en la opción Agregar colección de reglas de
red ; el Agregar red regla de recopilación de lámina aparece,
Figura 2-26 Creación de una nueva colección de reglas de red

3. En el campo Nombre , escriba DNS .
4. En el campo Prioridad , escriba 200 .
5. En el campo Acción , deje la selección predeterminada ( Permitir ).
6. En la sección Direcciones IP , escriba DNSOutbound en
el Nombre campo .
7. Seleccione UDP en el protocolo campo .
8. Deje la selección de Dirección IP en el campo Tipo de fuente .
9. En el campo Fuente , escriba el rango de su subred,
como 10.30.0.0/24 .
10. Deje la selección de Dirección IP en el campo Tipo de
destino .
11. En el campo Dirección de destino , escriba la dirección IP del
DNS externo.
12. En el puerto de destino , escriba 53 .
En caso de que desee realizar la misma configuración con PowerShell,
puede usar el
New-AzFirewallNetworkRulecmdlet, como se muestra aquí:

New-AzFirewallNetworkRule -Name "DNSOutbound" -Protocol UDP -
SourceAddress
"10.30.0.0/24" -DestinationAddress IP_of_the_DNSSErver -

DestinationPort 53
Registros de firewall
Cuando los administradores del sistema necesitan auditar los cambios de
configuración en Azure Firewall, deben usar los registros de actividad de
Azure. Por ejemplo, la creación de esas dos reglas (aplicación y red)
aparecerá en el Registro de actividad, que se verá similar a la Figura 2-27 .
Figura 2-27 Registros de actividad que muestran los cambios en Azure
Firewall
Si bien estas acciones se registran automáticamente en el registro de
actividad de Azure, el registro de diagnóstico para las reglas de la
aplicación y la red no está habilitado de forma predeterminada. También
puede habilitar las métricas de Firewall. Estas métricas se recopilan cada
minuto y pueden ser útiles para alertar porque se pueden muestrear con
frecuencia. Cuando habilita la recopilación de métricas, las siguientes
métricas estarán disponibles para Azure Firewall:
• Recuento de aciertos de las reglas de la aplicación
• Recuento de aciertos de las reglas de red
• Datos procesados
• Estado de salud del cortafuegos
• Utilización del puerto SNAT
Estas métricas y el registro de diagnóstico para la aplicación y la regla de
red se pueden habilitar en el panel de Azure Firewall. Utilice los
siguientes pasos para habilitar estos registros:
1. En la página Cortafuegos , en el panel de navegación izquierdo, en
la sección Supervisión , haga clic en Configuración de
diagnóstico . La configuración de diagnóstico aparece la página,
Figura 2-28 Página de configuración de diagnóstico
2. Haga clic en la opción Agregar configuración de diagnóstico , que
hace que aparezca la hoja Configuración de diagnóstico , como se
Figura 2-29 Página de configuración de diagnóstico

3. En el campo Nombre de la configuración de diagnóstico , escriba
un nombre para esta configuración.
4. En la sección Registro ,
habilite AzureFirewallApplicationRule y AzureFirewallNetwork
Rule .
5. En la sección Métrica , habilite AllMetrics .
6. En la sección Detalles del destino , puede elegir dónde desea
enviar los registros: Log Analytics, Cuenta de almacenamiento o
Centro de eventos. Si necesita conservar los registros durante más
tiempo para revisarlos según sea necesario, la cuenta de
almacenamiento es la mejor opción. Si necesita enviar los
registros a una herramienta de gestión de eventos e información de
seguridad (SIEM), Event Hub es la mejor opción. Si necesita más
supervisión en tiempo real, Log Analytics es la mejor opción. Tenga
en cuenta que puede seleccionar múltiples opciones, lo que le
permite abordar múltiples necesidades.
7. Para este ejemplo, seleccione Enviar a Log Analytics y seleccione
el espacio de trabajo en el que residirán los registros.
8. Haga clic en Guardar y, una vez guardado, cierre la hoja.
9. Observe que el nombre de su configuración de registro ahora
aparece en la página Configuración de diagnóstico .
10. Puede usar el Set-AzDiagnosticSettingcmdlet para habilitar el
registro de diagnóstico, como se muestra en el siguiente ejemplo:
Set-AzDiagnosticSetting -ResourceId / subscriptions /
<subscriptionId> /
resourceGroups / <nombre del grupo de recursos>

/providers/Microsoft.Network/
azureFirewalls / <nombre del cortafuegos> `
-StorageAccountId / subscriptions / <subscriptionId> /

resourceGroups / <grupo de recursos
name> /providers/Microsoft.Storage/storageAccounts/ <nombre de la

cuenta de almacenamiento> `
-Habilitado $ verdadero
11. Ahora que el registro de diagnóstico está configurado, haga

clic en Registros en el panel de navegación izquierdo en
la sección Supervisión . El área de trabajo de Log
Analytics aparece con el esquema de Azure Firewall, como se
Figura 2-30 Esquema para el Firewall de Azure en Log Analytics

12. Para realizar consultas en el espacio de trabajo de Log
Analytics, utilice Kusto Query Language (KQL). Puede utilizar la
consulta de muestra para recuperar los registros relacionados con
las reglas de la red:
AzureDiagnostics
| donde Category == "AzureFirewallNetworkRule"
Configurar el servicio Azure Front Door como

puerta de enlace de aplicaciones
Considere una implementación de Azure en diferentes regiones que debe
proporcionar una experiencia de alto rendimiento para las aplicaciones y
es resistente a fallas. Para este tipo de escenario, Azure Front Door es la
mejor solución.
Azure Front Door funciona en la capa 7 (HTTP / HTTPS) y usa el
protocolo anycast con TCP dividido, además de la red global de Microsoft
para mejorar la conectividad global. Mediante el uso del protocolo
anycast basado en TCP dividido, Front Door asegura que sus usuarios se
conecten rápidamente al POP (punto de presencia) de Front Door más
cercano.
Puede configurar Front Door para enrutar las solicitudes de sus clientes al
back-end de aplicaciones más rápido y disponible, que es cualquier
servicio con conexión a Internet alojado dentro o fuera de Azure. Algunas
otras capacidades incluidas en Front Door se enumeran aquí:
• Sonda de salud inteligente Front Door monitorea sus back-
end para verificar la disponibilidad y latencia. De acuerdo con sus
resultados, se realizará una conmutación por error instantánea
cuando un back-end se caiga.
• Enrutamiento basado en URL Le permite enrutar el tráfico
al back-end según la ruta de la URL de la solicitud. Por ejemplo, el
tráfico a www.fabrikam.com/hr/*se enruta a un grupo específico,
mientras que www.fabrikam.com/soc/*a otro.
• Alojamiento de múltiples sitios Le permite configurar una
topología más eficiente para sus implementaciones agregando
diferentes sitios web a una sola puerta principal y redireccionando
a diferentes grupos.
• Afinidad de sesión Utiliza la afinidad de sesión basada en
cookies para mantener la sesión en el mismo back-end.
• Terminación TLS Soporte para terminación TLS en el borde.
• Administración personalizada de dominios y
certificados Puede dejar que Front Door administre su certificado,
o puede cargar su propio certificado TLS / SSL.
• Seguridad de la capa de aplicación Le permite crear sus
propias reglas de firewall de aplicaciones web (WAF)
personalizadas para el control de acceso, y viene con Azure DDoS
Basic habilitado. Front Door también es un proxy inverso de capa 7,
lo que significa que solo permite que el tráfico web pase a través de
los backends y bloquee otros tipos de tráfico de forma
predeterminada.
• Redirección de URL Le permite configurar diferentes tipos
de redirección, que incluyen redirección de HTTP a HTTPS,
redirección a diferentes nombres de host, redirección a diferentes
rutas o redirecciones a una nueva cadena de consulta en la URL.
• Reescritura de URL Le permite configurar una ruta de
reenvío personalizada para construir una solicitud para reenviar el
tráfico al back-end.
Pasarela de aplicación de sugerencias
Si su escenario requiere un equilibrador de carga de capa 7 (HTTP / HTTPS) solo
para una región, puede usar Azure Application Gateway. Si necesita un servicio
global que funcione en varias regiones, debe usar Azure Front Door.
El diagrama que se muestra en la Figura 2-31 refleja algunas de las

características que se mencionaron anteriormente y le brinda una mejor
vista de topología del caso de uso principal de Azure Front Door.
Figura 2-31 Un caso de sse para Azure Front Door

Siga los pasos a continuación para configurar su Azure Front Door:
2. En la barra de búsqueda, escriba frente y en Servicios , haga clic
en Puertas frontales .
3. En la página Front Doors , haga clic en el botón Agregar ; el crear
un frente de la puerta aparece la página, como se muestra en la
figura 2-32 .
Figura 2-32 Página de creación de Azure Front Door
4. En el menú desplegable Suscripción , seleccione la suscripción que
desea utilizar para crear la puerta principal.
recursos que desee para esta puerta principal.
6. Haga clic en el botón Siguiente:
Configuración> ; la configuración aparece pestaña, como se
muestra en la figura 2-33 .
Figura 2-33 Configuración inicial de la puerta delantera
7. Haga clic en el signo más ( + ) en el primer cuadro, Frontends /
Domains ; el Agregar Front End Host aparece la hoja, como se
Figura 2-34 Agregar un host de frontend
8. En el campo Nombre de host , escriba un nombre exclusivo para
esta interfaz.
9. Front Door reenvía las solicitudes que se originan en el mismo
cliente a diferentes backends en función de la configuración de
equilibrio de carga, lo que significa que Front Door no usa la
afinidad de sesión de forma predeterminada. Sin embargo, algunas
aplicaciones con estado generalmente prefieren que las solicitudes
posteriores del mismo usuario lleguen al mismo back-end que
procesó la solicitud inicial. En este caso, debe habilitar la afinidad
de sesión. Para este ejemplo, deje la selección predeterminada
en Afinidad de sesión ( habilitada ).
10. Si desea utilizar Web Application Firewall (WAF) para
proteger su aplicación web, puede aprovechar la administración
centralizada proporcionada por Front Door. Para este ejemplo, deje
la configuración predeterminada Deshabilitada para el Firewall
de aplicaciones web y haga clic en el botón Agregar .
11. Haga clic en el signo más ( + ) en el segundo cuadrado, Back
End Pools ; el Agregar Back End piscina cuchilla aparece, como se
Figura 2-35 Agregar un grupo de back-end
12. En el campo Nombre , escriba un nombre único para el grupo
de back-end.
13. En la sección Back Ends , haga clic en Add A Back
End ; el Agregar Un Back End cuchilla aparece, como se muestra
en la figura 2-36 .
Figura 2-36 Configurando un nuevo backend
14. En el menú desplegable Tipo de host de back-end , puede
elegir el tipo de recurso que desea agregar. Seleccione App
Service en el menú desplegable.
15. Una vez que realice esta selección, los parámetros restantes
deben completarse automáticamente con las opciones
predeterminadas. Revise los valores y haga clic en
el botón Agregar .
16. Ahora que ha vuelto a la hoja Agregar grupo back-end ,
revise las opciones en la sección Sondas de estado y observe que la
configuración predeterminada para Método de
sonda es HEAD. El HEADmétodo es idéntico a GET; la diferencia es que
el servidor no debe devolver un cuerpo de mensaje en la
respuesta. Esta es también la configuración recomendada para
reducir la carga y el costo de la espalda.
17. La configuración de equilibrio de carga para el grupo de
back-end define cómo se evalúan las sondas de estado. Esta
configuración se usa para determinar si el back-end está en buen
estado o no. El tamaño de la muestra se utiliza para determinar
cuántas sondas de estado de muestra son necesarias para
considerar el estado del back-end (evaluación de
estado). Las Muestras Exitosas Requeridas es el umbral de
cuántas muestras deben tener éxito para ser consideradas
exitosas. La opción Sensibilidad de latencia (en milisegundos) se
utiliza cuando desea enviar solicitudes a los backends dentro del
rango de sensibilidad de medición de latencia establecido.
18. Deje las selecciones predeterminadas y haga clic en
el botón Agregar .
19. Haga clic en el signo más ( + ) en el tercer cuadrado; Reglas
de enrutamiento ; el Agregar regla aparece la hoja, como se
Figura 2-37 Agregar una nueva regla
20. En el campo Nombre , escriba un nombre exclusivo para esta
regla de enrutamiento.
21. En la sección Patrones para combinar , puede agregar un
patrón específico que desee utilizar. Cuando Front Door evalúa la
solicitud, busca cualquier ruta con una coincidencia exacta en el
host. Si ningún host de front-end exacto coincide, rechaza la
solicitud y envía un error 400 Bad Request. Después de determinar
el host de front-end específico, Front Door filtrará las reglas de
enrutamiento según la ruta solicitada. Para este ejemplo, deje las
selecciones predeterminadas.
22. En la sección Detalles de la ruta , puede configurar el
comportamiento de la ruta. En la opción Tipo de ruta , puede
seleccionar si desea reenviar al grupo de back-end o redirigir a otro
lugar. Para este ejemplo, deje esto configurado en Reenviar , que es
el predeterminado. Habilite la opción Reescritura de URL si desea
crear una ruta de reenvío
personalizada. La opción Almacenamiento en caché está
deshabilitada de forma predeterminada, lo que significa que las
solicitudes que coincidan con esta regla de enrutamiento no
intentarán utilizar contenido almacenado en caché. En otras
palabras, las solicitudes siempre se recuperarán del back-end. Deje
todas las selecciones predeterminadas en esta sección y haga clic en
el botón Agregar .
23. Haga clic en el botón Revisar + Crear , revise el resumen de
su configuración y haga clic en el botón Crear para finalizar.
24. Espere hasta que finalice la implementación. Una vez que
haya terminado, haga clic en el botón Ir a recurso para ver el panel
de la puerta principal.
La configuración tardará unos minutos en implementarse globalmente en
todas partes después de que termine de crear su Front Door.
Ruta importante de la puerta principal
Las rutas para su puerta principal no están ordenadas. Se selecciona una ruta
específica en función de la mejor coincidencia.
Firewall de aplicaciones web
El firewall de aplicaciones web (WAF) se puede utilizar en Front
Door. Azure también le permite implementar WAF de otras formas, por lo
que es importante comprender los requisitos de diseño antes de decidir
qué implementación de WAF debe usar.
Revise el diagrama de flujo disponible
en http://aka.ms/wafdecisionflow para comprender mejor las
características de WAF, que incluyen Azure Load Balancer, Application
Gateway y Azure Front Door. Si su escenario tiene la siguiente
característica, WAF con Front Door es una buena opción:
• Tu aplicación usa HTTP / HTTPS.
• Tu aplicación está orientada a Internet.
• Su aplicación se distribuye globalmente en diferentes
regiones.
• Su aplicación está alojada en PaaS (como un servicio de
aplicaciones de Azure).
Considere implementar WAF en Front Door cuando necesite una solución
global y centralizada. Cuando se usa WAF con Front Door, las aplicaciones
web serán inspeccionadas para cada solicitud entrante entregada por
Front Door en el borde de la red.
Importante integración WAF con Front Door
Si su implementación requiere la descarga de TLS y la inspección de paquetes, WAF
se integra de forma nativa con Front Door, lo que le permite inspeccionar una
solicitud después de que se descifra.
Configurar el firewall de aplicaciones web (WAF)

en Azure Application Gateway
En un escenario en el que necesita proteger sus aplicaciones web de
amenazas comunes como inyección SQL, secuencias de comandos entre
sitios y otras vulnerabilidades basadas en la web, el uso de Azure Web
Application Firewall (WAF) en Azure Application Gateway es la forma
más adecuada de abordarlos. necesidades. WAF en Application Gateway
se basa en el conjunto de reglas centrales 3.1, 3.0 o 2.2.9 de Open Web
Application Security Project (OWASP). Estas reglas se utilizarán para
proteger sus aplicaciones web contra las 10 principales vulnerabilidades
de OWASP, que puede encontrar en https://owasp.org/www-project-top-
ten .
Puede utilizar WAF en Application Gateway para proteger varias
aplicaciones web. Una sola instancia de Application Gateway puede
albergar hasta 40 sitios web, y esos sitios web estarán protegidos por un
WAF. Aunque tenga varios sitios web detrás del WAF, aún puede
crearpolíticas para abordar las necesidades de esos sitios. El diagrama
que se muestra en la Figura 2-38 tiene más detalles sobre los diferentes
componentes de esta solución.
Figura 2-38 Diferentes componentes de integración para WAF en

Application Gateway
En el ejemplo que se muestra en la Figura 2-38 , se ha configurado una
política WAF para el sitio de back-end. Esta política es donde usted define
todas las reglas, reglas personalizadas, exclusiones y otras
personalizaciones, como un límite de carga de archivos.
WAF en Application Gateway admite la terminación de Transport Layer
Security (TLS), la afinidad de sesión basada en cookies, la distribución de
carga por turnos y el enrutamiento basado en contenido. El diagrama que
se muestra en la Figura 2-38 también destaca la integración con Azure
Monitor, que recibirá todos los registros relacionados con posibles
ataques contra sus aplicaciones web. Las alertas de WAV v1 también se
transmitirán a Azure Security Center y aparecerán en el panel de alertas
de seguridad.
Según los requisitos del escenario, puede configurar WAF en Application
Gateway para que funcione en dos modos diferentes:
• Modo de detección Este modo no interferirá con el tráfico
cuando se produzca una actividad sospechosa. En lugar de
bloquear la actividad sospechosa, este modo solo detecta y registra
todas las alertas de amenazas. Para que este modo funcione
correctamente, el registro de diagnóstico y el registro WAF deben
estar habilitados.
• Modo de prevención Como su nombre lo indica, este modo
bloquea el tráfico que coincide con las reglas. Bloqueado solicitado
genera un mensaje 403 Acceso no autorizado. En ese momento, la
conexión se cierra y se crea un registro en los registros WAF.
Al revisar el registro WAF de una solicitud que fue bloqueada, verá un
mensaje que contiene algunos campos que son similares a este ejemplo:
Regla obligatoria. No se puede inhabilitar. Se superó la
puntuación de anomalía de entrada (puntuación de entrada
total:
5 - SQLI = 0, XSS = 0, RFI = 0, LFI = 0, RCE = 0, PHPI = 0,

HTTP = 0, SESS = 0): Falta el encabezado del agente de
usuario;
Puntajes individuales de nivel de paranoia: 3, 2, 0, 0
El anomaly scoreproviene de las reglas de OWASP 3.x, que tienen una

gravedad específica: crítico, error, advertencia o aviso. El mensaje
anterior indica que la puntuación de entrada total es 5, lo que se traduce
en una gravedad igual a Crítica. Es importante enfatizar que el tráfico no
se bloqueará hasta que alcance el umbral, que es 5. Esto significa que si el
tráfico coincide con la regla de bloqueo pero tiene una puntuación de
anomalía de 3, no se bloqueará, aunque aparecerá el mensaje de que Verá
en el registro WAF que dice que está bloqueado. Los niveles de gravedad
son 5 (Crítico), 4 (Error), 3 (Advertencia) y 2 (Aviso).
Pasarela de aplicación de sugerencias
Para crear una puerta de enlace de aplicaciones con un firewall de aplicaciones web
mediante Azure Portal, siga los pasos de este artículo: https://aka.ms/az500wafag .
Configurar Azure Bastion

La implementación de Azure Bastion se realiza por red virtual, lo que
significa que aprovisiona el servicio Azure Bastion en la red virtual y, en
ese momento, el acceso RDP / SSH estará disponible para todas las
máquinas virtuales que pertenecen a la misma red virtual. La arquitectura
general es similar a la de la Figura 2-39 .
Figura 2-39 Arquitectura principal para la implementación de Azure

Bastion
Inicio de sesión importante
Una sesión debe iniciarse solo desde Azure Portal. Si intenta acceder a la URL desde
otra sesión o pestaña del navegador, es posible que reciba el error "Su sesión ha
expirado".
Al analizar la definición del escenario, identificará pistas que lo llevarán a

usar Azure Bastion. Por ejemplo, en un escenario en el que los
administradores de Contoso no quieren usar una IP pública en las VM,
pero necesitan proporcionar acceso RDP externo a esas VM. Ese es un
escenario típico en el que Azure Bastion será la mejor opción de
diseño. Otra ventaja de no exponer la dirección IP pública (solo v4) es que
su VM no recibirá ataques de escaneo de puertos.
Aunque Azure Bastion recibirá solicitudes externas, no necesita
preocuparse por fortalecer el servicio, ya que Azure Bastion es un servicio
PaaS completamente administrado, y la plataforma Azure mantiene Azure
Bastion fortalecido y actualizado para usted. Este enfoque también ayuda
a prevenir ataques de día cero. Azure Bastion permite hasta 25 sesiones
RDP simultáneas y 50 conexiones SHC simultáneas. Aunque este es el
límite oficial, las sesiones de alto uso pueden afectar la forma en que
Azure Bastion responderá a otras conexiones, lo que significa que puede
permitir menos del máximo si el uso es alto.
Para establecer una conexión a Azure Bastion, necesita el rol de lector en
la máquina virtual, el rol de lector en la NIC con IP privada de la máquina
virtual y el rol de lector en el recurso de Azure Bastion. Para crear un host
de Azure Bastion mediante el portal, siga estos pasos:
2. En la barra de búsqueda, escriba bastión y, en Servicios , haga clic
en Bastiones .
3. En la página Bastiones , haga clic en el botón Agregar ; la Crear un
bastión aparece la página, como se muestra en la figura 2-40 .
Figura 2-40 Crear un bastión
4. Seleccione la suscripción y el grupo de recursos que desea alojar su
Azure Bastion.
5. En la sección Detalles de la instancia , escriba el nombre de este
bastión y seleccione la región donde residirá.
6. En la sección Configurar redes virtuales , seleccione la red virtual
en la que se creará el Bastión, o si no tiene una disponible, puede
hacer clic en el botón Crear nueva y seguir los pasos para crear un
Bastión.
7. Seleccione la dirección IP pública que utilizará el Bastión. Puede
crear uno (opción predeterminada) o utilizar uno existente que esté
disponible.
8. Tenga en cuenta que la opción SKU de dirección IP pública se
rellena previamente y no le permite cambiarla. Esto se debe a que
Azure Bastion solo admite SKU de IP pública estándar.
9. La opción Asignación se rellena previamente con Estático . Si
selecciona Usar dirección IP existente , esta opción no estará
disponible porque se usará la configuración establecida durante la
creación de la IP pública.
10. Haga clic en el botón Revisar + Crear .
En este punto, se creará el Bastión, que suele tardar cinco minutos en
completarse. Una vez creado el Bastión, podrá conectarse a una máquina
virtual utilizando este Bastión. La opción aparecerá cuando haga
clic en Conectar en la hoja VM, como se muestra en la Figura 2-41 .
Figura 2-41 Acceso a una máquina virtual mediante Azure Bastion
Configurar el firewall de recursos

Además de Azure Firewall, también puede aprovechar las capacidades
nativas relacionadas con el firewall para diferentes servicios. Azure
Storage y SQL Database son ejemplos de servicios de Azure que tienen
esta funcionalidad.
Cuando aprovecha esta funcionalidad incorporada para fortalecer sus
recursos, está agregando una capa adicional de seguridad a su carga de
trabajo y siguiendo la estrategia de defensa en profundidad, como se
Figura 2-42 Múltiples capas de protección para acceder al recurso
Firewall de almacenamiento de Azure

Cuando habilita esta característica en Azure Storage, puede controlar
mejor el nivel de acceso a sus cuentas de almacenamiento según el tipo y
subconjunto de redes utilizadas. Cuando se configuran las reglas de red,
solo las aplicaciones que solicitan datos a través del conjunto de redes
especificado pueden acceder a una cuenta de almacenamiento.
Puede crear controles granulares para limitar el acceso a su cuenta de
almacenamiento a solicitudes provenientes de direcciones IP específicas,
rangos de IP o de una lista de subredes en una red virtual de Azure. Las
reglas de firewall creadas en Azure Storage se aplican a todos los
protocolos de red que se pueden usar para acceder a su cuenta de
almacenamiento, incluidos REST y SMB.
Debido a que la configuración predeterminada de las cuentas de
almacenamiento permite conexiones de clientes en cualquier otra red
(incluida Internet), se recomienda que configure esta función para limitar
el acceso a las redes seleccionadas. Siga estos pasos para configurar el
firewall de Azure Storage:
2. En la barra de búsqueda, escriba almacenamiento y, en Servicios ,
haga clic en Cuentas de almacenamiento .
3. Haga clic en la cuenta de almacenamiento para la que desea
modificar la configuración del firewall.
4. En la página de la cuenta de almacenamiento, en
la sección Configuración en el panel de navegación izquierdo, haga
clic en la opción Cortafuegos y redes virtuales ; aparece la página
que se muestra en la Figura 2-43 .
Figura 2-43 Configuración de red virtual y firewall de Azure

Storage
5. En Permitir acceso desde , haga clic en Redes seleccionadas ; las
opciones que se muestran en la Figura 2-44 estarán disponibles.
Figura 2-44 Configuración del firewall de Azure Storage

6. En la sección Redes virtuales , puede agregar una nueva red
virtual o asignar esta cuenta de almacenamiento a una red
virtual específica.
7. En la sección Firewall , puede reforzar el rango de direcciones que
pueden tener acceso a esta cuenta de almacenamiento. Para eso,
debe escribir las direcciones IP o el rango usando el formato
CIDR. Tenga en cuenta que los servicios implementados en la
misma región que la cuenta de almacenamiento usan direcciones IP
privadas de Azure para la comunicación. Por lo tanto, no puede
restringir el acceso a servicios de Azure específicos en función de su
rango de direcciones IP salientes públicas.
8. En la sección Excepciones , puede habilitar o deshabilitar las
siguientes opciones:
1. Permitir que los servicios de Microsoft de confianza accedan a
esta cuenta de almacenamiento Habilitar esta opción otorgará acceso a
su cuenta de almacenamiento desde Azure Backup, Azure Event Grid,
Azure Site Recovery, Azure DevTest Labs, Azure Event Hubs, Azure
Networking, Azure Monitor y Azure SQL Data Warehouse .
2. Permitir acceso de lectura al registro de almacenamiento
desde cualquier red Habilite este punto si desea permitir este nivel de
acceso.
3. Permitir acceso de lectura a métricas de almacenamiento
desde cualquier red Habilite esta opción si necesita que las métricas de
almacenamiento sean accesibles desde todas las redes.
9. Una vez que termine de configurar, haga clic en el botón Guardar .
Si desea denegar rápidamente el acceso de red a la cuenta de
almacenamiento, puede usar el Update-
AzStorageAccountNetworkRuleSetcmdlet, como se muestra aquí:

Update-AzStorageAccountNetworkRuleSet -ResourceGroupName
"MyRG" -Name "mystorage"
-DefaultAction Deny
Firewall de base de datos SQL de Azure

Al configurar su base de datos de Azure SQL, puede restringir el acceso a
una red específica mediante las reglas de firewall de nivel de servidor o
las reglas de firewall de nivel de base de datos. Estas reglas pueden
habilitar o deshabilitar el acceso de los clientes a todas las bases de datos
dentro del mismo servidor de SQL Database. Estas reglas se almacenan en
la base de datos maestra.
Si se puede acceder a su base de datos desde Internet y una computadora
intenta conectarse a ella, el cortafuegos primero verifica la dirección IP de
origen de la solicitud con las reglas del cortafuegos IP a nivel de la base de
datos para la base de datos que solicita la conexión. Si la dirección no está
dentro de un rango en las reglas de firewall de IP a nivel de base de datos,
el firewall verifica las reglas de firewall de IP a nivel de servidor.
Las reglas de firewall de nivel de servidor se pueden configurar a través
del portal de Azure, mientras que el firewall de nivel de base de datos
debe configurarse en la propia base de datos mediante
el sp_set_database_firewall_rulecomando SQL. Para configurar el firewall a
nivel de servidor, siga estos pasos:
2. En la barra de búsqueda, escriba base de datos y, en Servicios ,
haga clic en Bases de datos SQL .
3. Haga clic en la base de datos para la que desea modificar la
configuración del firewall a nivel del servidor.
4. En la página Descripción general, haga clic en el botón Establecer
regla del servidor , como se muestra en la Figura 2-45 .
Figura 2-45 Selección de la opción para configurar el firewall a

nivel de servidor
5. Aparece la página de configuración del Firewall, como se muestra
en la Figura 2-46 .
Figura 2-46 Opciones de configuración de firewall a nivel de
servidor
6. En la opción Denegar acceso a la red pública , seleccione Sí si
desea prohibir el acceso desde Internet o No si desea permitir el
acceso de Internet a esta base de datos.
7. La opción Política de conexión le permite configurar cómo los
clientes pueden conectarse a Azure SQL. Las opciones disponibles
son
1. Predeterminado La política predeterminada es básicamente una
redirección para todas las conexiones de cliente que se originan dentro de
Azure y un proxy para todas las conexiones de cliente que se originan
fuera.
2. Política Al seleccionar esta opción, todas las conexiones se
transfieren a través de las puertas de enlace de Azure SQL Database (que
varía según la región de Azure). Esta configuración aumentará la latencia
y reducirá el rendimiento.
3. Redirigir Al seleccionar esta opción, todos los clientes establecerán
conexiones directamente con el nodo que aloja la base de datos, lo que
reduce la latencia y mejora el rendimiento.
8. En Permitir que los servicios y recursos de Azure accedan a este
servidor , tiene la opción de habilitar o deshabilitar este tipo de
acceso.
9. Los siguientes son tres campos, Nombre de la regla , IP de
inicio e IP final , que le permiten crear filtros para las conexiones
de los clientes.
10. La última opción que puede configurar es la configuración
de Redes virtuales , que le permite crear o agregar una red virtual
existente.
11. Una vez que termine de configurar, haga clic en
el botón Guardar .
Cortafuegos de Azure Key Vault

Al igual que los recursos anteriores, Azure Key Vault también le permite
crear restricciones de acceso a la red mediante el uso del firewall de Key
Vault, que se aplica al plano de datos de Key Vault. Esto significa que las
operaciones como la creación de una nueva bóveda o la eliminación o
modificación de la configuración no se verán afectadas por las reglas del
firewall. A continuación, se muestran dos escenarios de casos de uso para
Azure Key Vault Firewall:
• Contoso necesita implementar Azure Key Vault para
almacenar claves de cifrado para sus aplicaciones. Contoso quiere
bloquear el acceso a sus claves para las solicitudes provenientes de
Internet.
• Fabrikam implementó Azure Key Vault, y ahora necesita
bloquear el acceso a sus claves y habilitar el acceso solo a las
aplicaciones de Fabrikam y una breve lista de hosts específicos.
Para configurar Azure Key Vault Firewall, primero debe habilitar el
registro de Key Vault mediante la siguiente secuencia de comandos de
PowerShell:
$ storagea = New-AzStorageAccount -ResourceGroupName
ContosoResourceGroup -Name
fabrikamkeyvaultlogs -Type Standard_LRS -Location 'East US'
$ kvault = Get-AzKeyVault -VaultName 'ContosoKeyVault'
Set-AzDiagnosticSetting -ResourceId $ kvault.ResourceId -

StorageAccountId $ storagea.Id
-Habilitado $ true -Category AuditEvent
En esta secuencia, creará una nueva cuenta de almacenamiento para

almacenar los registros, obtener la información de Key Vault y,
finalmente, configurar la configuración de diagnóstico para su Key Vault.
Después de terminar esta parte, puede ir al portal de Azure, abrir su Key
Vault y, en el panel de navegación izquierdo, en
la sección Configuración , haga clic en Redes > Punto final privado y
redes seleccionadas. , como se muestra en la Figura 2-47 .
Figura 2-47 Configuración de Azure Key Vault Firewall
En esta página, puede hacer clic en Agregar redes virtuales
existentes o Agregar nuevas redes virtuales opciones para comenzar a
crear su lista de redes virtuales permitidas para acceder a su Key
Vault. Tenga en cuenta que una vez que configure esas reglas, los usuarios
solo pueden realizar operaciones en el plano de datos de Key Vault
cuando sus solicitudes se originan en esta lista de redes virtuales
permitidas. Lo mismo se aplica cuando los usuarios intentan realizar
operaciones en el plano de datos desde el portal, como enumerar las
claves.
ImportanteReglas la red IP
Si está creando reglas de red IP, solo puede usar direcciones IP públicas. Los rangos
de direcciones IP reservados no están permitidos en las reglas de IP. Las redes
privadas incluyen direcciones definidas con RFC 1918.
En la Figura 2-47 , observe la opción Permitir que los servicios de

confianza de Microsoft omitan este cortafuegos , que está establecida
en Sí de forma predeterminada. Esto permitirá que los siguientes
servicios tengan acceso a su Key Vault independientemente de la
configuración del firewall: servicio de implementación de Azure Virtual
Machines, servicio de implementación de plantillas de Azure Resource
Manager, SKU de Azure Application Gateway v2, servicio de cifrado de
volumen de Azure Disk Encryption, Azure Backup, Exchange Online ,
SharePoint Online, Azure Information Protection, Azure App Service,
Azure SQL Database, Azure Storage Service, Azure Data Lake Store, Azure
Databricks, Azure API Management, Azure Data Factory, Azure Event
Hubs, Azure Service Bus, Azure Import / Export, y Registro de
contenedores de Azure.
Cortafuegos de Azure App Service

Es posible que también desee reforzar el acceso a la red para sus
aplicaciones que se implementan a través de Azure App Service. Aunque
la terminología utilizada en esta sección se refiere a " Azure App Service
Firewall ", lo que realmente está implementando es una lista de control de
acceso a nivel de red. La capacidad de restricciones de acceso en Azure
App Service se implementa en los roles de front-end de App Service. Estos
roles de front-end son anteriores a los hosts de trabajo donde se ejecuta
su código.
Un escenario de examen común para la implementación de esta capacidad
es cuando necesita restringir el acceso a su aplicación desde ciertas redes
virtuales o Internet. En el examen AZ-500, asegúrese de leer
detenidamente el escenario porque, en este caso, está agregando
restricciones para acceder a la aplicación en sí, no al host.
Para configurar restricciones de acceso en sus servicios de aplicaciones
de Azure, abra el portal de Azure, abra el panel de servicios de
aplicaciones , haga clic en su servicio de aplicaciones o función de Azure
y, en la sección Configuración , haga clic
en Redes . La opción Restricciones de acceso se muestra a la derecha
(consulte la Figura 2-48 ).
Figura 2-48 Restricción de acceso a Azure App Services
Para iniciar la configuración, haga clic en Configurar restricciones de
acceso en la sección Restricción de acceso . Verá la página
de Restricción de acceso , como se muestra en la Figura 2-49 . La tabla
inicial está en blanco (sin reglas) y puede hacer clic en Agregar
regla para comenzar a configurar sus restricciones.
Figura 2-49 Adición de restricciones de acceso

Se recomienda que programe una ventana de mantenimiento para
configurar estas restricciones porque cualquier operación (agregar, editar
o eliminar) en esas reglas reiniciará su aplicación para que los cambios
surtan efecto.
Implementar punto final de servicio

También puede tener una red virtual que solo tenga servicios PaaS y
permitir que estos servicios sean accesibles fuera de la red virtual en la
que residen. Por ejemplo, el administrador de la base de datos debe
acceder a Azure SQL Database desde Internet. En este escenario, el
administrador de la base de datos debe crear un punto final de servicio
para permitir un acceso seguro a la base de datos.
En el momento en que se escribió este capítulo, los siguientes servicios de
Azure admitían la configuración del punto de conexión del servicio:
• Almacenamiento de Azure
• Base de datos SQL de Azure
• Almacenamiento de datos SQL de Azure
• Base de datos de Azure para el servidor PostgreSQL
• Base de datos de Azure para servidor MySQL
• Base de datos de Azure para MariaDB
• Azure Cosmos DB
• Azure Key Vault
• Bus de servicio de Azure
• Centros de eventos de Azure
• Azure Data Lake Store Gen 1
• Servicio de aplicaciones de Azure
• Registro de contenedores de Azure
Actualizaciones importantes de la red
Para obtener la lista más actualizada de puntos finales de servicio admitidos,
consulte https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-
endpoints-overview .
Desde una perspectiva de seguridad, los puntos finales de servicio

brindan la capacidad de proteger los recursos del servicio de Azure en su
red virtual al extender la identidad de la red virtual al servicio. Después
de habilitar los puntos de conexión de servicio en su red virtual, puede
agregar una regla de red virtual para proteger los recursos del servicio de
Azure en su red virtual. Al agregar esta regla, está mejorando la seguridad
al eliminar por completo el acceso público a Internet a los recursos y
permitir el tráfico solo desde su red virtual.
Otra ventaja de utilizar un punto final de servicio es la optimización del
tráfico. El punto de conexión del servicio siempre lleva el tráfico del
servicio directamente desde su VNet al servicio en la red troncal de
Microsoft Azure, lo que significa que el tráfico se mantiene dentro de la
red troncal de Azure. Al tener este control, puede continuar auditando y
monitoreando el tráfico de Internet saliente desde su VNet sin afectar el
tráfico del servicio.
Modelo de implementación importante
Esta característica solo está disponible para redes virtuales implementadas a través
del modelo de implementación de Azure Resource Manager.
El punto de conexión del servicio VNet le permite fortalecer el acceso al
servicio de Azure solo para el acceso permitido a la VNet y la subred. Esto
agrega un nivel adicional de seguridad a la red y aísla el tráfico del
servicio de Azure. Todo el tráfico que utiliza los puntos finales del servicio
VNet fluye a través de la red troncal de Microsoft, lo que proporciona otra
capa de aislamiento de la Internet pública. También puede eliminar por
completo el acceso público a Internet a los recursos del servicio de Azure
y permitir el tráfico solo desde sus redes virtuales a través de una
combinación de firewall de IP y lista de control de acceso en la red virtual,
que protege los recursos del servicio de Azure del acceso no autorizado.
Para configurar el punto final del servicio de red virtual, deberá realizar
estas dos acciones principales:
• Habilitar el punto final de servicio en la subred
• Agregar un punto final de servicio a su red virtual
Si está configurando Azure Storage, también debe configurar una
directiva de punto de conexión de servicio.
Nota Política de servicio de Vnet
Para obtener más información sobre las políticas de punto de conexión del servicio
Azure VNet para Azure Storage, consulte https://docs.microsoft.com/en-
us/azure/virtual-network/virtual-network-service-endpoint-policies-overview .
La habilitación de un punto final de servicio en la subred se puede

realizar durante la creación de la subred o después de que se crea la
subred. En las propiedades de la subred, puede seleccionar el punto final
del servicio en el menú desplegable Servicios , como se muestra en
la Figura 2-50 .
Figura 2-50 Configuración de los puntos finales de servicio en la subred

Para configurar el punto final del servicio de red virtual en su red virtual,
siga los siguientes pasos:
2. En la barra de búsqueda, escriba redes virtuales ; en Servicios ,
haga clic en Redes virtuales .
3. Haga clic en la red virtual para la que desea configurar el punto final
de servicio.
4. En el panel izquierdo, haga clic en Service Endpoint , como se
Figura 2-51 Configuración de un punto final de servicio de VNet

6. En la página Agregar puntos de conexión de servicio , haga clic
en el menú desplegable y seleccione el servicio de Azure que desea
agregar.
Implementar DDoS
De forma predeterminada, la protección básica de denegación de servicio
distribuida (DDoS) de Azure ya está habilitada en su suscripción. Esto
significa que el monitoreo del tráfico y la mitigación en tiempo real de los
ataques comunes a nivel de red están completamente cubiertos y brindan
el mismo nivel de defensa que los utilizados por los servicios en línea de
Microsoft.
Si bien la protección básica proporciona mitigaciones automáticas de
ataques contra DDoS, hay algunas capacidades que solo proporciona el
nivel DDoS Standard. Los requisitos de la organización lo llevarán a
determinar qué nivel utilizará. En un escenario en el que Contoso necesita
implementar protección DDoS en el nivel de la aplicación, necesita tener
métricas de ataque en tiempo real y registros de recursos disponibles
para su equipo. Contoso también necesita crear informes de mitigación
posteriores al ataque para presentarlos a la administración
superior. Estos requisitos solo pueden ser cumplidos por el nivel DDoS
Standard. La Tabla 2-2 proporciona un resumen de las capacidades
disponibles para cada nivel:
Tabla 2-2 Azure DDoS básico frente a estándar
Capacidad DDoS básico Estándar D
Monitoreo activo del X X

tráfico y detección siempre
activa
Mitigación automática de X X
ataques
Garantía de disponibilidad Por región de Azure. Por aplicaci
Políticas de mitigación Ajustado por volumen de región de Azure. Ajustado pa

tráfico de la
Métricas y alertas No disponible. X
Registros de flujo de No disponible. X

mitigación
Personalización de la No disponible. X
política de mitigación
Apoyo Sí, pero es un enfoque de mejor Sí, y propor

esfuerzo. En otras palabras, no hay expertos en
garantía de que el soporte aborde el ataque activ
problema.
Capacidad DDoS básico Estándar D
SLA Región de Azure. Garantía de

protección d
Precios Libre. Uso mensua

Tip Attacks cubiertos por Azure Ddos
Para obtener más información sobre los diferentes tipos de ataques cubiertos por
Azure DDoS, visite http://aka.ms/az500DDoS .
Para configurar Azure DDoS, su cuenta debe ser miembro del rol
Colaborador de red, o puede crear un rol personalizado que tenga
privilegios de lectura, escritura y eliminación
en Microsoft.Network/ddosProtectionPlansy privilegio de acción
en Microsoft.Network/ddosProtectionPlans/join. Su rol personalizado
también debe tener privilegios de lectura, escritura y eliminación
en Microsoft.Network/virtualNetworks. Después de otorgar acceso al
usuario, siga los siguientes pasos para crear un plan de protección DDoS:
2. En la barra de búsqueda, escriba DDoS y en Servicios , haga clic
en Planes de protección contra DDoS .
3. En la página Planes de protección DDoS , haga clic en
el botón Agregar ; el crear un Plan de Protección DDoS aparece
la página, como se muestra en la figura 2-52 .
Figura 2-52 Crear un plan de protección DDoS
4. En el campo Nombre , escriba el nombre de esta protección DDoS.
5. En el campo Suscripción , seleccione la suscripción adecuada.
6. En el campo Grupo de recursos , haga clic en el menú desplegable
y seleccione el grupo de recursos que desee.
7. En el campo Ubicación , seleccione la región para el DDoS.
8. Antes de hacer clic en el botón Crear , lea la nota que se encuentra
debajo de este botón. Esta nota enfatiza que al hacer clic en Crear ,
conoce el precio de la protección DDoS. Debido a que no hay un
período de prueba para esta función, se le cobrará durante el
primer mes de uso de esta función.
9. Después de hacer clic en Crear , vaya a la barra de búsqueda,
escriba red y haga clic en Redes virtuales .
10. Haga clic en la red virtual para la que desea habilitar el
estándar DDoS.
11. En el panel de navegación izquierdo, haga clic en
la opción Protección DDoS .
12. Haga clic en la opción Estándar , como se muestra en
la Figura 2-53 .
Figura 2-53 Habilitación del estándar DDoS en la red virtual

13. Haga clic en el menú desplegable Plan de protección DDoS y
seleccione el plan de protección DDoS que creó en el paso 9.
14. Haga clic en el botón Guardar .
En este punto, puede configurar Azure Monitor para enviar alertas
aprovechando las métricas de protección DDoS. Para hacerlo, abra Azure
Monitor, haga clic en Métricas , seleccione el alcance de la dirección IP
pública ubicada en la red virtual donde está habilitado el estándar DDoS,
haga clic en el menú desplegable Métrica y seleccione Bajo ataque DDoS
o no , como se muestra en la Figura 2 -54 .
Figura 2-54 Supervisión de la actividad DDoS
Para acceder a un informe de mitigación de ataques DoS, primero debe
configurar los ajustes de diagnóstico. Este informe utiliza los datos del
protocolo Netflow para proporcionar información detallada sobre el
ataque DDoS a su recurso. Para configurar esta opción, haga
clic en Configuración de diagnóstico en la sección Configuración en la
hoja Azure Monitor, como se muestra en la Figura 2-55 .
Figura 2-55 Configuración del registro de diagnóstico

Como se puede ver en la parte inferior de la hoja, esta página le permite
configurar el registro de
diagnóstico DDoSProtectionNotifications, DDoSMitigationFlowLogsy DDoSMitig
ationReports.
Al igual que con cualquier otra configuración de diagnóstico,
puede almacenar estos datos en una cuenta de almacenamiento, Event
Hub o en un espacio de trabajo de Log Analytics.

Para el examen AZ-500, asegúrese siempre de revisar los detalles
del caso de uso para asegurarse de que está seleccionando la opción
más adecuada de acuerdo con la descripción del escenario.
Además de estas opciones, es importante mencionar que Azure Security
Center también mostrará alertas de seguridad generadas por DDoS
Protection. Hay dos alertas principales que podrían ser activadas por este
servicio y aparecer en Security Center:
• Ataque DDoS detectado para IP pública
• Ataque DDoS mitigado para IP pública
HABILIDAD 2.2: CONFIGURAR SEGURIDAD

AVANZADA PARA COMPUTACIÓN
Esta sección del capítulo cubre las habilidades necesarias para configurar
la seguridad avanzada para la computación, de acuerdo con el esquema
del Examen AZ-500.
Configurar la seguridad del endpoint dentro de la

VM
La seguridad de los endpoints es una parte imperativa de su estrategia de
seguridad y, en estos días, no puede tener protección de endpoints sin
una solución antimalware instalada en su computadora.
Considere un escenario en el que aprovisiona una nueva máquina virtual
que no tiene configurada una protección de punto final. ¿No sería ideal
tener una solución que le avise del hecho de que falta una protección de
punto final en esa máquina virtual? Esto es exactamente lo que sucede
cuando tiene Azure Security Center (niveles gratuitos o estándar)
habilitado en su suscripción.
Siga estos pasos para acceder a Security Center y revisar las
recomendaciones de protección de endpoints:
2. En la barra de búsqueda, escriba seguridad y en Servicios , haga
clic en Centro de seguridad .
3. En el panel principal de Security Center, en la sección Higiene de
seguridad de recursos , haga clic en Computación y
aplicaciones .
4. En la lista resultante, haga clic en la opción Instalar Endpoint
Protection Solution en máquinas virtuales ; la protección de
punto final no está instalado en Azure VM aparece la página,
Figura 2-56 Lista de máquinas virtuales que no tienen instalada

una solución de protección de endpoints
5. Seleccione la máquina virtual en la que desea instalar la protección
de punto final y haga clic en el botón Instalar en 1 máquina
virtual . La Selección de Endpoint Protection aparece la página,
Figura 2-57 Selección de la solución de protección de endpoints

disponible para instalar
6. Security Center sugiere automáticamente que instale Microsoft
Antimalware para Azure, que es una protección gratuita en tiempo
real que ayuda a identificar y eliminar virus, spyware y otro
software malintencionado. Haga clic en la opción Microsoft
Antimalware ; el Microsoft Antimalware aparece la página, como
se muestra en la figura 2-58 .
Figura 2-58 Instalación de Microsoft Antimalware

7. Haga clic en el botón Crear ; la Instalación de Microsoft
Antimalware aparece la hoja, como se muestra en la figura 2-59 .
Figura 2-59 Opciones de instalación
8. Si necesita crear una lista de exclusión de protección de endpoints,
aquí es donde lo haría. Por ejemplo, supongamos que sabe que
desea evitar problemas causados por análisis antimalware de los
archivos utilizados por su aplicación. Puede agregar las rutas
utilizadas por esta aplicación en la lista de exclusión. Esta hoja
contiene las siguientes opciones:
1. Archivos y ubicaciones excluidos Aquí, puede especificar
cualquier ruta o ubicación para excluir del análisis. Para agregar varias
rutas o ubicaciones, sepárelas con punto y coma. Esta es una
configuración opcional.
2. Archivos y extensiones excluidos Este cuadro le permite
especificar nombres de archivo o extensiones para excluir del
análisis. Nuevamente, para agregar varios nombres o extensiones,
sepárelos con un punto y coma. Tenga en cuenta que debe evitar el uso de
caracteres comodín.
3. Procesos excluidos Utilice este cuadro para especificar cualquier
proceso que deba excluirse del análisis. Nuevamente, use punto y coma
para separar varios procesos.
4. Protección en tiempo real De forma predeterminada, esta casilla
de verificación está habilitada. A menos que tenga una buena razón
comercial para hacer lo contrario, debe dejarlo así.
5. Ejecutar un análisis programado Al seleccionar esta casilla de
verificación, podrá ejecutar un análisis programado.
6. Tipo de análisis Si seleccionó la casilla de verificación Ejecutar
un análisis programado , puede utilizar este menú desplegable para
especificar el tipo de análisis. (Se ejecuta un análisis rápido de forma
predeterminada).
7. Día del análisis Si seleccionó la casilla de verificación Ejecutar
especificar el día en que se ejecutará el análisis.
8. Tiempo de análisis Si seleccionó la casilla de verificación Ejecutar
especificar a qué hora se ejecutará el análisis. El tiempo se indica en
incrementos de 60 minutos (60 = 1 AM, 120 = 2 AM, etc.).
9. Después de personalizar las opciones según sus necesidades, haga
clic en el botón Aceptar .
10. Después de este paso, comenzará el proceso de
instalación. Puede cerrar el panel de Security Center en este punto.
A menudo, querrá ver un reflejo inmediato de los cambios que realizó en
el tablero. Sin embargo, tenga en cuenta que el panel de Security Center
tiene diferentes tiempos de actualización, que varían según los
objetos. Por ejemplo, los datos de las configuraciones de seguridad del
sistema operativo se actualizan en 48 horas y los datos de Endpoint
Protection se actualizan en 8 horas. Esto significa que incluso la
instalación del punto final se realiza correctamente en los próximos cinco
minutos después de que comenzó, el panel solo reflejará esa instalación
en el próximo ciclo de actualización.
Dicho esto, es importante mencionar que, si el antimalware que se instaló
en la máquina identifica un código malicioso en ejecución,
inmediatamente disparará una alerta. Esta alerta aparecerá en el panel de
alertas de seguridad de Security Center, como se muestra en la Figura 2-
60 .
Figura 2-60 La alerta que aparece en Security Center cuando Microsoft

Antimalware realiza una acción
Cuando abra esta alerta, verá más detalles sobre la operación, que incluye
el recurso atacado, la suscripción, el estado de la amenaza y la ruta del
archivo, como se muestra en la Figura 2-61 .
Figura 2-61 Detalles sobre una alerta que se activa en Azure Security
Center cuando se detecta malware
Tener una protección de punto final instalada es solo el primer paso para
mejorar la protección general de su máquina virtual. Hay muchos otros
aspectos de la seguridad de las máquinas virtuales que deben tenerse en
cuenta, y el refuerzo es uno de ellos. (Consulte la siguiente sección). Más
allá del endurecimiento, ¿qué más se puede implementar para proteger
una máquina virtual? Empecemos por el control de acceso. En un
escenario en el que una organización tiene varias suscripciones, es
posible que necesite una forma de administrar el acceso de manera
eficiente. Establecer una buena política de control de acceso es una forma
de hacerlo.
En Azure, puede usar las políticas de Azure para crear convenciones para
los recursos y crear políticas personalizadas para controlar el
acceso. Puede aplicar estas políticas a los grupos de recursos y las
máquinas virtuales que pertenecen a esos grupos de recursos heredarán
esas políticas. Puede implementar esas políticas en el nivel del grupo de
administración si tiene varias suscripciones que deberían recibir la
misma política.
Al configurar el control de acceso, asegúrese siempre de utilizar el
enfoque de privilegios mínimos. Puede aprovechar los roles integrados de
Azure para permitir que los usuarios accedan y configuren máquinas
virtuales. En lugar de otorgar un mayor nivel de acceso, puede asignar un
usuario a la función Colaborador de la máquina virtual, y ese usuario
heredará los derechos para administrar las VM, aunque el usuario no
podrá administrar la red virtual o la cuenta de almacenamiento a la que él
o ella está conectado. Lo mismo se aplica a los usuarios que necesitan
acceso a Azure Security Center para visualizar las recomendaciones para
sus VM; deben tener la función de lector de seguridad, que les permitirá
ver recomendaciones pero no les permitirá realizar cambios en la
configuración.
Si bien el nivel gratuito de Security Center proporciona buenos
conocimientos sobre la situación de seguridad actual de sus cargas de
trabajo, también debe considerar la detección de amenazas para las
máquinas virtuales que viene con el nivel estándar de Security Center. El
nivel estándar de Security Center tiene un análisis de comportamiento de
máquina virtual (VMBA) que utiliza análisis de comportamiento para
identificar los recursos comprometidos en función de un análisis de los
registros de eventos de la máquina virtual (VM), como el procesamiento
de eventos de creación y los eventos de inicio de sesión. Si su escenario
requiere la detección de ataques contra sus máquinas virtuales, el nivel
estándar de Security Center debe estar habilitado.
Las detecciones de amenazas de máquinas virtuales en el nivel Security
Center Standard son aplicables para los sistemas operativos Windows y
Linux. La Figura 2-62 muestra un ejemplo de detección de amenazas
basada en VMBA en Security Center. Esta alerta aparece en el panel
de alertas de seguridad en Security Center.
Figura 2-62 Ejemplo de detección de amenazas de VM en Security Center

La detección de amenazas es un control de seguridad importante, aunque
hay otros controles de seguridad que también deben estar en su lugar y
que se clasifican como medidas proactivas o controles de seguridad
proactivos.
El cifrado de disco también debe aplicarse a sus máquinas
virtuales. Considere un escenario en el que la organización necesita
asegurarse de que el cifrado esté en su lugar sin importar dónde se
encuentren los datos (en reposo o en tránsito) y usted necesita identificar
rápidamente si los datos están cifrados. Incluso el nivel gratuito de
Security Center puede brindarle este nivel de visibilidad.
Security Center activará una recomendación cuando identifique máquinas
virtuales que no tienen habilitado el cifrado de disco. Otro aspecto de la
seguridad de las máquinas virtuales es la identificación del abuso de
recursos. Cuando los procesos de VM consumen más recursos de los que
deberían, esto también podría ser un indicio de una actividad
sospechosa. Sin lugar a dudas, los problemas de rendimiento pueden
ocurrir por una variedad de problemas, incluida una aplicación que no
está bien escrita. Los problemas de rendimiento también pueden ocurrir
porque la máquina virtual se está quedando sin recursos porque la carga
válida es alta. (En este caso, debe actualizar la máquina virtual con más
recursos). Cualquiera que sea la causa, la conclusión es que el
rendimiento de una máquina virtual puede provocar la interrupción del
servicio, lo que viola directamente el principio de seguridad de
disponibilidad.
Puede usar Azure Monitor para obtener visibilidad del estado de su
máquina virtual. Al aprovechar las características de Azure Monitor, como
los archivos de registro de diagnóstico de recursos, puede identificar
problemas potenciales que podrían comprometer el rendimiento y la
disponibilidad. Azure Monitor y el registro de diagnóstico se tratan con
más detalle en el Capítulo 3 , " Administrar operaciones de seguridad ".
Configurar actualizaciones del sistema para

máquinas virtuales en Azure
Mantener el sistema actualizado es otra medida imperativa para
cualquier organización que desee implementar la seguridad del host. La
buena noticia es que en Azure tiene dos servicios principales que se
pueden utilizar para asegurarse de que sus máquinas virtuales estén
completamente actualizadas.
Considere un escenario en el que necesita administrar las actualizaciones
del sistema operativo para sus máquinas virtuales de Windows y Linux,
no solo en Azure, sino también en las instalaciones y en cualquier otro
entorno de nube. Puede usar la solución Update Management en Azure
Automation para administrar sus máquinas virtuales. Los siguientes son
los componentes utilizados por Update Management:
• Agente de Log Analytics para Windows o Linux Este es el
mismo agente que usa Security Center, lo que significa que debería
tenerlo ya instalado si usa Security Center.
• Configuración de estado deseado (DSC)
de PowerShell para Linux La plataforma de administración en
PowerShell que se ejecuta en Linux.
• Trabajador de Runbook híbrido de Automation Cada
máquina Windows administrada por la solución se enumera en los
grupos de trabajadores híbridos.
• Microsoft Update o Windows Server Update Services
(WSUS) para máquinas con Windows La plataforma de
administración de actualizaciones administrada por Microsoft
(Microsoft Update) o administrada por sus organizaciones (WSUS).
La recopilación de la administración de actualizaciones se realiza
mediante un análisis que se realiza dos veces al día para cada servidor
Windows administrado (los clientes no son compatibles) y cada hora para
las máquinas Linux. Las siguientes versiones de los sistemas operativos
son compatibles con esta solución:
• Windows Server 2019 (centro de datos / centro de datos
básico / estándar)
• Windows Server 2016 (centro de datos / centro de datos
básico / estándar)
• Windows Server 2012 R2 (centro de datos / estándar)
• Windows Server 2012
• Windows Server 2008 R2 RTM y SP1 Standard (solo
evaluación, no se admiten parches)
• CentOS 6 (x86 / x64) y 7 (x64)
• Red Hat Enterprise 6 (x86 / x64) y 7 (x64)
• SUSE Linux Enterprise Server 11 (x86 / x64) y 12 (x64)
• Ubuntu 14.04 LTS, 16.04 LTS y 18.04 (x86 / x64)
Puede habilitar la solución Update Management directamente desde las
propiedades de la VM, lo cual es un buen enfoque si solo necesita habilitar
esta solución para una VM. Si necesita implementar en todas las máquinas
virtuales, puede seleccionar todas las máquinas virtuales a la vez desde
el panel de máquinas virtuales e implementarlas en todas las máquinas
virtuales desde allí. Las máquinas virtuales se pueden distribuir en hasta
tres grupos de recursos cuando se habilita esta solución para varias
máquinas virtuales. Siga estos pasos para habilitar esta función para
varias máquinas virtuales:
2. En la barra de búsqueda, escriba máquina virtual y, en Servicios ,
haga clic en Máquinas virtuales .
3. Haga clic en la casilla de verificación junto al campo Nombre para
seleccionar todas las máquinas virtuales.
4. Haga clic en el botón Servicios y haga clic en Gestión de
actualizaciones ; la Habilitación de administración de
actualizaciones Aparece la página, como se muestra en la figura 2-
63 .
Figura 2-63 Habilitación de la gestión de actualizaciones para

máquinas virtuales
5. Observe que la configuración predeterminada tiene seleccionada la
opción AUTO . Esta opción configurará automáticamente el espacio
de trabajo de Log Analytics y la cuenta de automatización en
función de la suscripción y la ubicación de sus máquinas
virtuales. Si ya tiene VM implementadas con Log Analytics y el
agente ya está configurado para informar a un área de trabajo
específica, la configuración automática no funcionará; debe
seleccionar PERSONALIZADO y desde allí seleccionar el espacio de
trabajo donde reside la máquina virtual, así como la cuenta de
automatización de Azure que utilizará la Administración
actualizada.
6. Para este ejemplo, deje la selección predeterminada y haga clic en
el botón Habilitar .
La implementación de esta solución puede llevar algún tiempo
dependiendo de la cantidad de VM que seleccione; espere hasta que esté
completamente terminado antes de continuar.
Gestionar actualizaciones
Ahora que la solución Update Management está implementada en sus VM,
puede acceder a su panel para visualizar la lista de actualizaciones
faltantes y programar implementaciones de actualizaciones. Para acceder
al panel de Gestión de actualizaciones, siga los siguientes pasos:
2. En la barra de búsqueda, escriba automatizar y en Servicios , haga
clic en Cuentas automatizadas .
3. Haga clic en la cuenta de automatización que utiliza su solución de
gestión de actualizaciones.
4. En el panel izquierdo, haga clic en Administración de
actualizaciones y, si se completa el análisis, aparecerá la lista de
actualizaciones, como se muestra en la Figura 2-64 .
Figura 2-64 Panel de administración de actualizaciones

5. Haga clic en la pestaña Actualizaciones faltantes para visualizar
las actualizaciones que faltan actualmente en las máquinas
(consulte la Figura 2-65 ).
Figura 2-65 Panel de administración de actualizaciones
En el ejemplo dado en los pasos anteriores, vio un entorno que ya estaba
en producción, con máquinas que ya informaban a Update Management y
un programa de implementación ya creado. En una nueva
implementación, verá que hay un botón Programar implementación de
actualizaciones en el panel principal de Administración de
actualizaciones , como se muestra en la Figura 2-66 .
Figura 2-66 Opción para programar la implementación de las

actualizaciones
Configurar la autenticación para contenedores

Hay varias formas de configurar la autenticación para proteger los
clústeres de Kubernetes. Puede aprovechar Azure RBAC para administrar
el acceso según los usuarios o grupos y los recursos a los que necesitan
acceder, o también puede integrarse con Azure Active Directory (AD). Si
decide utilizar RBAC, primero debe asignar permisos a los usuarios con
Kubernetes RBAC. Si necesita el mismo permiso aplicado a los recursos en
todo el clúster, debe usar un ClusterRole.
Para mejorar la seguridad de los clústeres de AKS, debe aprovechar la
integración con Azure AD, que le permite integrar identidades locales en
los clústeres de AKS para proporcionar una única fuente de seguridad y
administración de cuentas. La autenticación de Azure AD se proporciona
a los clústeres de AKS que tienen OpenID Connect, que es una capa de
identidad construida sobre el protocolo OAuth 2.0.
No debe pensar que uno es mejor que el otro; en realidad, usará RBAC y
Azure AD para asegurarse de tener un método de autenticación más
sólido. El diagrama que se muestra en la Figura 2-67 muestra un ejemplo
de cómo ambos funcionan juntos.
Figura 2-67 Proceso de autenticación

El paso 1 del proceso de autenticación que se muestra en la Figura 2-67 es
el cliente que se autentica en Azure AD, que emite un token de acceso
(paso 2). El usuario inicia una tarea (como crear un pod) que aprovecha
este token (paso 3). AKS valida este token con Azure AD (paso 4) y,
durante esta validación, recupera la pertenencia al grupo del usuario. Se
aplican políticas de clúster y AKS RBAC (paso 5). Por último, en el paso 6,
AKS responde a la solicitud del usuario, permitiendo o denegando la
solicitud en función del proceso de validación, que incluye la validación
de Azure AD, la pertenencia al grupo (RBAC) y las políticas.
Cuando crea su clúster AKS, puede definir si el clúster utilizará RBAC en la
pestaña Autenticación, como se muestra en la Figura 2-68 .
Figura 2-68 Opciones de autenticación durante la creación del clúster de
AKS
Si hace clic en Configurar entidad de servicio , tiene la opción de crear
una nueva (lo que Azure hará por usted) o usar una existente. Si elige usar
uno existente, necesita el ID de cliente principal del servicio, que es su
AppID y el secreto del cliente principal del servicio, que es el valor de la
contraseña. Cada entidad de servicio está asociada a una aplicación de
Azure AD. La entidad de servicio de un clúster de AKS se puede asociar
con cualquier nombre de aplicación de Azure AD válido. Si necesita crear
manualmente una entidad de servicio, puede usar el siguiente comando
de la CLI de Azure:
az ad sp create-for-rbac --skip-assign --name myAKSClusterSP
Como práctica recomendada de seguridad, asegúrese de crear roles y

enlaces que asignen la menor cantidad de privilegios necesarios. Cuando
sea posible, integre con Azure AD para que cualquier cambio en el estado
del usuario o la pertenencia a un grupo se actualice automáticamente y el
acceso a los recursos del clúster esté actualizado.
Configurar la seguridad para diferentes tipos de
contenedores
Hay muchas capacidades integradas en AKS que ayudan a garantizar que
su clúster de AKS sea seguro. Esas capacidades integradas se basan en
características nativas de Kubernetes, como políticas de red y secretos,
con la adición de componentes de Azure, como NSG y actualizaciones de
clústeres orquestadas.
La combinación de estos componentes se utiliza para que su clúster de
AKS ejecute las últimas actualizaciones de seguridad del sistema
operativo y las versiones de Kubernetes, proteja el tráfico de pod y brinde
acceso a credenciales confidenciales. La figura 2-69 muestra un diagrama
con los componentes de seguridad centrales de AKS.
Figura 2-69 Componentes de seguridad principales de AKS

Cuando implementa AKS en Azure, los componentes maestros de
Kubernetes forman parte del servicio administrado proporcionado por
Microsoft. Cada clúster de AKS tiene un maestro de Kubernetes
dedicado. Este maestro se utiliza para proporcionar servidor API,
programador, etc. Puede controlar el acceso al servidor de API mediante
los controles RBAC de Kubernetes y Azure AD.
Si bien Microsoft administra y mantiene el maestro de Kubernetes, los
nodos de AKS son máquinas virtuales que usted administra y
mantiene. Estos nodos pueden usar el sistema operativo Linux
(distribución optimizada de Ubuntu) o Windows Server 2019. La
plataforma Azure aplica automáticamente parches de seguridad del
sistema operativo a los nodos de Linux todas las noches, pero en los
nodos de Windows, Windows Update no se ejecuta ni aplica
automáticamente las últimas actualizaciones. Esto significa que si tiene
nodos de Windows, debe mantener el cronograma en torno al ciclo de
vida de la actualización y hacer cumplir esas actualizaciones.
Desde la perspectiva de la red, estos nodos se implementan en una subred
de red virtual privada sin direcciones IP públicas asignadas. SSH está
habilitado de forma predeterminada y solo debe usarse para solucionar
problemas porque solo está disponible usando la dirección IP interna. En
la Figura 2-69 , también tiene un NSG, que también se puede usar para
mejorar la protección de la red.
Los nodos de AKS usan Azure Managed Disks y los datos se cifran
automáticamente en reposo dentro de la plataforma Azure. Para cumplir
con el principio de seguridad de disponibilidad, estos discos también se
replican de forma segura dentro del centro de datos de Azure.
Planificación importante AKS
Cuando planifique la alta disponibilidad de AKS, también tenga en cuenta el proceso
de actualización de un clúster de AKS. Lea este artículo para obtener más
información sobre el proceso de actualización: https://docs.microsoft.com/en-
us/azure/aks/upgrade-cluster .
El diagrama que se muestra en la Figura 2-69 muestra el elemento secreto

de Kubernetes, que se utiliza para inyectar datos confidenciales en pods,
como credenciales o claves. El uso de secretos reduce la información
confidencial que se define en el manifiesto YAML del pod o del
servicio. Puede leer más sobre secretos en Kubernetes
en https://kubernetes.io/docs/concepts/configuration/secret .
Centro de seguridad para AKS

Además de las capacidades nativas en Kubernetes y Azure que se
describieron anteriormente, puede mejorar la postura de seguridad de su
implementación de AKS aprovechando las recomendaciones de Azure
Security Center. En Security Center, verá recomendaciones como la que se
Figura 2-70 Recomendaciones de Security Center para AKS

Security Center monitorea constantemente las configuraciones de AKS y
Docker y luego genera recomendaciones de seguridad que reflejan los
estándares de la industria. Además de eso, si actualiza Security Center a
Standard Tier y habilita la detección de amenazas AKS, Security Center
analizará continuamente los eventos de seguridad sin procesar, como los
datos de red y la creación de procesos y el registro de auditoría de
Kubernetes.
Según esta información, Security Center puede alertarlo sobre amenazas
y actividad maliciosa detectadas en el nivel del host y del clúster de
AKS. La Figura 2-71 muestra un ejemplo de una alerta que le notifica
acerca de una configuración que puede llevar a los atacantes a utilizar un
espacio de nombres para ocultar componentes maliciosos.
Figura 2-71 Alerta del centro de seguridad para AKS
Implementar la gestión de vulnerabilidades

Al administrar ACR, es una buena práctica implementar una solución de
evaluación de vulnerabilidades que escanee todas las imágenes
enviadas. Puede aprovechar el nivel Security Center Standard con el
paquete ACR habilitado para tener la funcionalidad de evaluación de
vulnerabilidades.
Cuando esta capacidad está habilitada, Security Center escanea la imagen
que se envió mediante un escáner Qualys, que está completamente
integrado con el nivel estándar de Security Center, y no hay ningún costo
adicional para el motor Qualys. La Figura 2-72 muestra un diagrama de
cómo se realiza la administración de vulnerabilidades para ACR usando
Security Center.
Figura 2-72 Proceso de análisis de vulnerabilidades en Security Center
Si se encuentra un problema durante este proceso de análisis, Security
Center genera una recomendación procesable con orientación para
solucionar el problema. La Figura 2-73 muestra un ejemplo del tipo de
recomendaciones de Security Center que puede ver.
Figura 2-73 Una recomendación de ACR Security Center
Configurar el aislamiento para AKS

El aislamiento de contenedores se aplica a escenarios en los que necesita
aislar cargas de trabajo o equipos. AKS proporciona capacidades para
clústeres de múltiples inquilinos y aislamiento de recursos. De forma
nativa, Kubernetes ya crea un límite de aislamiento lógico mediante el uso
de un espacio de nombres, que es el grupo lógico de recursos (como los
pods).
Además, las siguientes características de Kubernetes deben usarse en
escenarios que requieren aislamiento y tenencia múltiple:
• Programación El programador de AKS le permite controlar
la distribución de los recursos informáticos y limitar el impacto de
los eventos de mantenimiento. Este componente incluye el uso de
funciones como cuotas de recursos y presupuestos de interrupción
de pods.
• Redes Las redes AKS le permiten aprovechar la capacidad de
la política de red para permitir o denegar el flujo de tráfico a los
pods.
• Autenticación y autorización Como se mencionó
anteriormente en el capítulo, el uso de la integración de RBAC y
Azure AD es imperativo para mejorar la seguridad de su
autenticación y autorización.
• Otras características Estas características incluyen políticas
de seguridad de pod, contextos de seguridad de pod, escaneo de
imágenes y tiempos de ejecución en busca de vulnerabilidades.
Privilegio mínimo importante
Una consideración de diseño importante a la hora de planificar su AKS es
proporcionar la menor cantidad de privilegios que tengan como ámbito los recursos
que necesita cada equipo.
Hay dos tipos principales de aislamiento para los clústeres de AKS: lógico
y físico. Debe utilizar el aislamiento lógico para separar equipos y
proyectos. Con el aislamiento lógico, un solo clúster de AKS se puede usar
para múltiples cargas de trabajo, equipos o entornos.
También se recomienda minimizar la cantidad de clústeres de AKS físicos
que implementa para aislar equipos o aplicaciones. La figura 2-
74 muestra un ejemplo de este aislamiento lógico.
Figura 2-74 Aislamiento lógico de AKS
El aislamiento lógico puede ayudar a minimizar los costos al habilitar el
ajuste de escala automático y ejecutar solo la cantidad de nodos
necesarios a la vez.
El aislamiento físico generalmente se selecciona cuando tiene un entorno
hostil de múltiples inquilinos en el que desea evitar por completo que un
inquilino afecte la seguridad y el servicio de otro. El aislamiento físico
significa que debe separar físicamente los clústeres de AKS. En este
modelo de aislamiento, a los equipos o cargas de trabajo se les asignan
sus propios clústeres de AKS. Si bien este enfoque generalmente parece
más fácil de aislar, agrega gastos administrativos y financieros
adicionales.
Configurar la seguridad para el registro de

contenedores
Azure Container Registry (ACR) es un registro privado de imágenes de
Docker y Open Container Initiative (OCI), basado en Docker Registry 2.0
de código abierto. Los desarrolladores pueden extraer (descargar)
imágenes de un registro de contenedor de Azure y también pueden enviar
(cargar) a un registro de contenedor como parte de un flujo de trabajo de
desarrollo de contenedor. Los niveles de precios de ACR son
• Básico Más adecuado para desarrolladores que están
aprendiendo sobre ACR
• Estándar Mayor rendimiento de almacenamiento e imagen y
más adecuado para un entorno de producción
• Premium Más adecuado para escenarios de gran volumen y
alto rendimiento de imágenes

En el examen, es posible que deba seleccionar el mejor nivel de
precios (también conocido como SKU) de acuerdo con el escenario
dado.
Puede usar una entidad de servicio de Azure AD para proporcionar acceso
de inserción y extracción de la ventana acoplable de imagen de
contenedor a su registro de contenedor. Las entidades de seguridad de
Azure AD brindan acceso a los recursos de Azure dentro de su
suscripción. Piense en una entidad de servicio como una identidad de
usuario para un servicio.
ACR también admite roles de Azure integrados para proporcionar
diferentes niveles de permisos a un registro de contenedor de Azure. Por
ejemplo, puede usar asignaciones de roles para otorgar acceso AKS acceso
a ACR. Los roles ACR incorporados son
• Propietario Puede acceder al Administrador de recursos,
crear y eliminar registros, enviar y extraer imágenes, eliminar
datos de imágenes y cambiar políticas
• Colaborador Puede realizar las mismas operaciones que el
propietario
• El lector puede acceder al Administrador de recursos y
extraer imágenes
• ArcPush puede empujar y tirar de imágenes
• ArcPull puede extraer una imagen
• ArcDelete Puede eliminar datos de imágenes
• ArcImageSigner Puede firmar imágenes
Para extraer o enviar imágenes a un registro de contenedor de Azure, un
cliente debe interactuar a través de HTTPS con dos puntos de conexión
diferentes: el punto de conexión de la API de REST del registro y el punto
de conexión de almacenamiento. Por defecto,un ACR acepta conexiones a
través de Internet desde hosts en cualquier red. Si usa ACR Premium,
puede aprovechar las reglas de acceso a la red de Azure VNet para
controlar el acceso a su ACR.
Implementar el cifrado de disco de Azure

El cifrado de datos en reposo es una parte extremadamente importante
de su estrategia general de seguridad de VM. Security Center incluso
activará una recomendación de seguridad cuando a una máquina virtual
le falte el cifrado de disco. Puede cifrar los discos de sus máquinas
virtuales de Windows y Linux mediante Azure Disk Encryption
(ADE). Para el sistema operativo Windows, necesita Windows 8 o
posterior (para el cliente) y Windows Server 2008 R2 o posterior (para
servidores).
ADE proporciona cifrado de disco de datos y sistema operativo. Para
Windows, utiliza el cifrado de dispositivo BitLocker; para Linux, utiliza el
sistema DM-Crypt. ADE no está disponible en los siguientes escenarios:
• VM básicas de la serie A
• VM con menos de 2 GB de memoria
• VM de generación 2 y VM de la serie Lsv2
• Volúmenes sin montar
ADE requiere que su máquina virtual de Windows tenga conectividad con
Azure AD para obtener un token para conectarse con Key Vault. En ese
momento, la máquina virtual necesita acceso al punto final de Key Vault
para escribir las claves de cifrado, y la máquina virtual también necesita
acceso a un punto final de almacenamiento de Azure. Este punto de
conexión de almacenamiento alojará el repositorio de extensiones de
Azure, así como la cuenta de almacenamiento de Azure que aloja los
archivos VHD.
Filtrado de URL importante
Si la VM está reforzada y existen restricciones de acceso a Internet, asegúrese de que
esta VM pueda al menos acceder al URI. Consulte http://aka.ms/az500kvfw .
La política de grupo es otra consideración importante al implementar

ADE. Si las máquinas virtuales para las que está implementando ADE
están unidas a un dominio, asegúrese de no impulsar ninguna política de
grupo que haga cumplir los protectores del Módulo de plataforma segura
(TPM). En este caso, deberá asegurarse de que la directiva Permitir
BitLocker sin un TPM compatible esté configurada. Además, la política
de BitLocker unido al dominio VM con la política de grupo personalizado
debe incluir la siguiente configuración: Configure User Storage Of
BitLocker Recovery Information / Allow 256-Bit Recovery Key.
Debido a que ADE usa Azure Key Vault para controlar y administrar
claves y secretos de cifrado de disco, debe asegurarse de que Azure Key
Vault tenga la configuración adecuada para esta implementación. Una
consideración importante al configurar Azure Key Vault para ADE es que
ambos (VM y Key Vault) deben formar parte de la misma
suscripción. Además, asegúrese de que los secretos de cifrado no crucen
las fronteras regionales; ADE requiere que Key Vault y las VM estén
ubicadas en la misma región. Al configurar Azure Key Vault,use Set-
AzKeyVaultAccessPolicycon -EnabledForDiskEncryptionpara permitir que la
plataforma Azure acceda a las claves de cifrado o secretos en su almacén
de claves, como se muestra aquí:
Set-AzKeyVaultAccessPolicy -VaultName "<su -nombre-keyvault>"
-ResourceGroupName
"MyResourceGroup" -EnabledForDiskEncryption
Si bien estas son las consideraciones principales para cifrar la máquina

virtual de Windows, las máquinas virtuales de Linux tienen algunos
requisitos adicionales. Cuando necesite cifrar tanto los datos como los
volúmenes del sistema operativo donde el /uso del sistema de
archivos raíz ( ) sea de 4 GB o menos, deberá tener al menos 8 GB de
memoria. Sin embargo, si necesita cifrar solo el volumen de datos, el
requisito se reduce a 2 GB de memoria. El requisito se duplica si los
sistemas Linux utilizan un /sistema de archivos root ( ) de más de 4 GB, lo
que significa que el requisito mínimo de memoria es root file system
usage * 2.
Más información sobre distribuciones de Linux compatibles
Para ver la lista de distribuciones de Linux admitidas para la implementación de
ADE, visite http://aka.ms/az500ADELinux .

Comprender esas consideraciones antes de implementar ADE es
muy importante, principalmente al leer un escenario en el examen
AZ-500. La descripción del escenario le dará los requisitos y las
restricciones, lo que significa que en algunos escenarios, no será
posible implementar ADE a menos que se ejecute alguna otra tarea
antes de la implementación de ADE.
Suponiendo que tiene los requisitos previos adecuados para implementar
ADE, puede usar el Set-AzVmDiskEncryptionExtensioncmdlet de PowerShell
para implementar el cifrado en una máquina virtual, como se muestra en
el siguiente ejemplo:
$ AKeyVault = Get-AzKeyVault -VaultName MyAKV -
ResourceGroupName MyRG
Set-AzVMDiskEncryptionExtension -ResourceGroupName MyRG -

VMName MyVM
-DiskEncryptionKeyVaultUrl $ AKeyVault.VaultUri -
DiskEncryptionKeyVaultId $ AKeyVault.
ResourceId
Espere unos minutos y la salida mostrará el

campo IsSuccessStatusCodecomo Truey el StatusCodecomo OK. También
puede verificar el estado del cifrado mediante el Get-
AzVmDiskEncryptionStatuscmdlet. Si se cifró correctamente, debería ver un
resultado similar a este:
OsVolumeEncrypted: cifrado
DataVolumesEncrypted: NoDiskFound
OsVolumeEncryptionSettings:
Microsoft.Azure.Management.Compute.Models.
DiskEncryptionSettings
ProgressMessage: el aprovisionamiento se realizó

correctamente
Más información Cifrado de disco

Para conocer más escenarios de cifrado de disco para Windows VM,
consulte http://aka.ms/az500ADEWin .
Configurar la seguridad para Azure App Service

Azure App Service es un servicio basado en HTTP para hospedar
aplicaciones web, API REST y backends móviles. Azure App Service
Environment (ASE) es una característica de Azure App Service que
proporciona un entorno aislado y dedicado para ejecutar de forma segura
aplicaciones de App Service en la nube. Puede crear varios ASE para
alojar varias aplicaciones que se ejecutan en Windows, Linux, Docker,
móviles y aplicaciones de funciones.
Nivel de precios importante
Todos los niveles de precios ejecutan sus aplicaciones en la infraestructura de red
compartida en Azure App Service, excepto el nivel de precios aislado, que le brinda
un aislamiento de red completo al ejecutar sus aplicaciones dentro de un entorno de
App Service dedicado.
Para configurar la seguridad para Azure App Service, debe comprender la

variedad de opciones disponibles. Azure App Service tiene controles de
seguridad integrados que se pueden aprovechar para mejorar la postura
de seguridad general de sus aplicaciones. Básicamente, algunos de estos
controles son componentes de Azure que se describieron a lo largo de
este capítulo. La Tabla 2-3 proporciona un resumen de los controles de
seguridad que se pueden usar con Azure App Service.
Tabla 2-3 Ventajas y limitaciones
Capa Control de seguridad Descripción
La red Punto final de servicio Puede usar restricciones de acceso para

de permitir / denegar ordenada por prio
controle el acceso a la red a su aplicación
práctica importante para limitar la expos
red entrante.
Soporte de inyección de Este control de seguridad se usa para AS

VNet implementación privada de App Service d
cliente e inyectada en la red virtual de es
Soporte de aislamiento Puede configurar la lista de control de ac

de red y cortafuegos (ACL) para bloquear el tráfico entrante p
Soporte de túnel forzado Aunque el tráfico de dependencia salient

pasar por el VIP que se aprovisiona con e
configurarlo para personalizar el enrutam
Capa Control de seguridad Descripción
Vigilancia Soporte de monitoreo de Puede revisar cuotas y métricas para una

Azure plan de App Service. También puede conf
métricas basadas en reglas de escala auto
Registro y auditoría del Debido a que todas las operaciones de ad

plano de control y realizadas en los objetos de App Service s
gestión través de Azure Resource Manager (ARM
registros históricos de estas operaciones
que no hay registros ni auditorías de plan
disponibles para App Service.
Identidad Autenticación Admite la integración con Azure AD y otr

de OAuth.
Autorización Controlado por Azure AD y RBAC.
Protección de Cifrado del lado del El contenido del archivo del sitio de App
Datos servidor en reposo: almacena en Azure Storage, que cifra aut
claves administradas por contenido en reposo, y los secretos propo
Microsoft cliente se cifran en reposo.
Cifrado del lado del Admite el almacenamiento del secreto de

servidor en reposo: en Key Vault, para que pueda recuperars
claves administradas por tiempo de ejecución.
el cliente (BYOK)
Cifrado en tránsito Admite el uso de HTTPS para el tráfico en
Llamadas a API También se admite a través de llamadas

encriptadas HTTPS.
Gestión de la Soporte de gestión de El estado de una configuración de App Se

configuración configuración exportar como una plantilla ARM.
Además de los controles de seguridad disponibles que se heredan de
Azure, también debe asegurarse de que siempre está desarrollando sus
aplicaciones con las últimas versiones de plataformas, lenguajes de
programación, protocolos y marcos compatibles. Es muy importante que
a lo largo del ciclo de vida del desarrollo, configure correctamente la
autenticación para estas aplicaciones. Asegúrese siempre de que se
requiera autenticación y de que el acceso anónimo esté deshabilitado, a
menos que la descripción del escenario indique claramente que debe
habilitarse. También puede mejorar la seguridad de su autenticación
solicitando a los clientes que utilicen un certificado para
autenticarse. Esta práctica mejora la seguridad al permitir conexiones
solo de clientes que pueden autenticarse con los certificados que usted
proporcione.
Como parte de su configuración segura de App Service, asegúrese de que
los datos en tránsito estén protegidos, lo que significa que siempre debe
redirigir el tráfico HTTP a HTTPS y hacer cumplir la última versión del
protocolo TLS. Las comunicaciones de Azure App Service y otros recursos
de Azure, como Azure Storage, también deben estar cifradas. Si la
descripción del escenario requiere que transfiera archivos desde su
aplicación de Azure a otra ubicación mediante FTP, asegúrese de utilizar
FTPS en su lugar.
Algunas de las recomendaciones de seguridad generales para Azure App
Service también aparecerán en Azure Security Center, como se muestra
en la Figura 2-75 .
Figura 2-75 Recomendaciones de Security Center para App Service
Security Center realizará esta evaluación de seguridad en sus
aplicaciones, que forma parte del nivel gratuito de Azure Security
Center. Sin embargo, si actualiza al nivel Estándar, también obtendrá
detección de amenazas para App Service. La detección de amenazas de
App Service de Security Center incluye modelos de análisis y aprendizaje
automático que cubren todas las interfaces que permiten a los clientes
interactuar con sus aplicaciones, ya sea a través de HTTP o mediante uno
de los métodos de administración.
Configurar certificados SSL / TLS

Para asegurarse de que siempre está protegiendo los datos en tránsito,
debe configurar su App Service para usar un certificado SSL / TLS. Para
crear un enlace TLS de su certificado a su aplicación o habilitar
certificados de cliente para su aplicación App Service, su plan de App
Service debe configurarse en los niveles Básico, Estándar, Premium o
Aislado.
App Service habilita diferentes escenarios para manejar certificados, lo
que incluye la capacidad de comprar un certificado; importar un
certificado existente desde App Service; cargue un certificado existente
que quizás ya tenga; para importar un certificado de Key Vault (de
cualquier suscripción en el mismo inquilino); o para crear un certificado
personalizado gratuito de App Service. (Esta última opción no es
compatible con dominios simples).
Con la excepción de comprar un certificado, que está disponible a través
del botón Comprar certificado , todas las demás opciones aparecen en
la pestaña Certificados de clave privada (.pfx) en
la opción Configuración de TLS / SSL en el panel de navegación de la
derecha de App Service. que seleccionaste. La Figura 2-76 muestra un
ejemplo de esta pestaña.
Figura 2-76 Opciones para configurar un certificado de clave privada

para App Service
A los efectos del examen AZ-500, la descripción del escenario es lo que le
lleva a elegir una opción sobre la otra. Por ejemplo, supongamos que un
administrador de Contoso necesita proteger los datos en tránsito para su
App Service, pero el administrador necesita ahorrar costos, aprovechar la
infraestructura de clave pública (PKI) existente en las instalaciones y
admitir dominios simples. En este caso, la opción más adecuada sería
cargar un certificado existente. Esto ahorrará costos porque aprovechará
la PKI existente (que ya cumplió con el segundo requisito) y es compatible
con dominios desnudos. Al cargar un certificado existente, asegúrese de
tener la contraseña para el archivo PFX protegido; la clave privada debe
tener al menos 2048 bits de longitud y debe contener todos los
certificados intermedios en la cadena de certificados.
Otro escenario importante es cuando necesita responder a las solicitudes
de un nombre de host específico a través de HTTPS. En este caso, debe
proteger un dominio personalizado en un enlace TLS. En este escenario,
usaría la opción Agregar enlace TLS / SSL , que está disponible en
la pestaña Enlaces , como se muestra en la Figura 2-77 .
Figura 2-77 Opciones para agregar un enlace TLS / SSL

El certificado que se utilizará para vincular TLS / SSL debe contener
un ExtendedKeyUsageidentificador de objeto de autenticación del servidor
(OID), que es 1.3.6.1.5.5.7.3.1, y debe estar firmado por una autoridad de
certificación confiable. Además, tenga en cuenta que en esta página,
también puede configurar su App Service para que solo responda a
HTTPS, y puede configurar la versión de TLS que se utilizará.
Certificados de propinas
Para conocer los pasos detallados para configurar los diferentes tipos de certificados,
consulte https://aka.ms/az500AppCertificates .
Configurar la autenticación
De forma predeterminada, la autenticación y la autorización están
desactivadas. Al habilitarlo, todas las solicitudes HTTP entrantes pasan a
través de él antes de ser manejadas por el código de su aplicación. El
módulo de autenticación y autorización se ejecuta por separado de su
código de aplicación y se configura mediante la configuración de la
aplicación.
Los módulos de autenticación y autorización son responsables de
manejar la autenticación de usuarios según el proveedor seleccionado, y
valida, almacena y actualiza tokens. También administran la sesión
autenticada e inyectan información de identidad en los encabezados de
las solicitudes. Para configurar la autenticación en la aplicación de
servicio, es necesario cambiar la autenticación de Servicio de
Aplicación de palanca a EN , y debajo de autenticación / autorización ,
aparecerán las opciones de autenticación, como se muestra en la figura 2-
78 .
Figura 2-78 Opciones de autenticación y autorización

Dado que App Service usa identidad federada, en la que un proveedor de
identidad de terceros administra las identidades de usuario y el flujo de
autenticación, el siguiente paso es configurar el tipo de proveedor de
autenticación que responderá a las solicitudes que no están
autenticadas. Haga clic en el menú desplegable Acción a tomar cuando
la solicitud no está autenticada y seleccione la opción adecuada. La
opción que seleccionó en el menú desplegable debe coincidir con el
proveedor que seleccione en la sección Proveedores de
autenticación . Una vez que seleccione el proveedor adecuado, su punto
final de inicio de sesión estará disponible para la autenticación de
usuarios y para la validación de los tokens de autenticación del proveedor
seleccionado.
Sugerencia Autenticación y autorización de extremo a extremo
Para obtener un ejemplo de cómo autenticar y autorizar a los usuarios de un extremo
a otro en Azure App Service, consulte http://aka.ms/az500AppServiceAuth .
Si selecciona la opción Permitir solicitudes anónimas (sin acción) en el

menú desplegable, esta opción aplazará la autorización del tráfico no
autenticado al código de su aplicación; en otras palabras, debe escribir el
código de autenticación en su aplicación. Si se trata de una solicitud
autenticada, App Service pasará la información de autenticación en los
encabezados HTTP. La tabla 2-4 muestra un resumen de cada proveedor
de identidad:
Tabla 2-4 Proveedores de identidad de App Service
Proveedor de Punto final de inicio de sesión Requisitos de configuración
identidad
Azure AD /.auth/login/aad Puede crear una nueva aplicación

usar una existente.
Le permite habilitar los permisos d
Services (CDS).
Cuenta de /.auth/login/microsoftaccount Requiere el ID de cliente y el secre

Microsoft
Puede seleccionar diferentes ámbi
responsables de habilitar diferente
Facebook /.auth/login/facebook Requiere el ID de la aplicación y el

aplicación.
Proveedor de Punto final de inicio de sesión Requisitos de configuración
identidad
Puede seleccionar diferentes ámbi

responsables de habilitar diferente
Google /.auth/login/google Requiere una identificación de clie

de cliente.
Gorjeo /.auth/login/twitter Requiere una clave de API y un sec

Servicio de datos comunes importante (CDS)
Common Data Service (CDS) le permite almacenar y administrar de forma segura los
datos que utilizan sus aplicaciones. Las entidades estándar y personalizadas dentro de
CDS brindan una opción de almacenamiento segura y basada en la nube para sus
datos. Para obtener más información sobre CDS,
consulte https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/data-
platform-intro .
Si el requisito del administrador de Contoso es almacenar y administrar

de forma segura los datos que usa la aplicación de la empresa, Azure AD
es el proveedor de identidad que cumple con este requisito porque Azure
AD le permite usar CDS.
Actualizaciones automáticas
Dado que App Service es una plataforma como servicio (PaaS), Azure
administra el sistema operativo (SO) y la pila de aplicaciones, lo que
significa que no debe preocuparse por la actualización de software. Azure
administra la revisión del sistema operativo en dos niveles: los servidores
físicos y las máquinas virtuales invitadas que ejecutan los recursos de
App Service. Ambos seguirán el ciclo regular de actualización de Microsoft
Patch Tuesday, que es una vez al mes, a menos que sea un parche de día
cero, que se manejará con mayor prioridad y probablemente fuera de
banda (fuera del ciclo regular de Patch Tuesday). Cuando se agrega una
nueva versión mayor o menor a App Service, se instala junto con las
versiones existentes.
App Service conserva su Acuerdo de nivel de servicio (SLA) incluso
durante las actualizaciones de parches, lo que significa que incluso si un
parche requiere que se reinicie una máquina virtual, no afectará la
producción de App Service porque siempre habrá búfer en capacidad.
El acceso a los parches en el registro
en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component
Based Servicing\Packagesestá bloqueado, aunque se puede consultar
información básica sobre el sistema operativo y las actualizaciones de
tiempo de ejecución utilizando Kudu Console
en https://github.com/projectkudu/kudu/wiki/Kudu-console . Por
ejemplo, si desea ver la versión de Windows, puede acceder a esta
URL: https: // <appname> .scm.azurewebsites.net / Env.cshtml .
Experimento mental
Seguridad avanzada para computación en Tailwind Traders

para el hogar. Tailwind Traders está implementando nuevas máquinas
virtuales en Azure para aumentar la capacidad informática porque la
compañía prevé un aumento en las compras en la tienda en línea durante
la próxima temporada navideña. Antes de lanzar esas VM para su uso,
deben asegurarse de que estas VM estén configuradas para usar las
mejores prácticas de seguridad, que incluyen configuraciones seguras,
instalación de protección de endpoints y garantizar que el sistema
operativo esté completamente actualizado.
Actualmente, Tailwind Traders no cuenta con ninguna gestión de la
postura de seguridad en la nube, pero la empresa está interesada en
probar el nivel gratuito de Azure Security Center. Para mejorar la
seguridad, también necesitan monitorear continuamente esos servidores
para identificar posibles ataques, y desean recibir una alerta en caso de
que haya actividades sospechosas o indicios de un ataque contra esos
servidores. Otro objetivo de Tailwind Traders es permitir que los
analistas del Security Operation Center (SOC) tengan acceso de solo
lectura al panel del Security Center para ver las alertas. Con esta
información en mente, responda las siguientes preguntas:
1. 1. ¿El nivel gratuito de Azure Security Center cumplirá esos
requisitos?
2. 2. ¿Qué función de Azure deben tener los analistas de SOC para
lograr sus objetivos?
3. 3. ¿En qué lugar del Centro de seguridad de Azure debe ir el
administrador para identificar si los servidores tienen instalada
una solución de protección de endpoints?

1. 1. El nivel gratuito de Azure Security Center solo logrará resultados
parciales de los requisitos deseados. Permitirá al administrador ver
recomendaciones de seguridad y mejorar la postura de seguridad
de las cargas de trabajo, pero para tener un monitoreo continuo de
la detección de amenazas, el administrador debe actualizar Security
Center al nivel Estándar.
2. 2. Debe asignar la función de lector de seguridad a los analistas de
SOC.
3. 3. Para identificar si los servidores tienen instalada una solución de
protección de endpoints, debe ir alpanel Recomendaciones en
Azure Security Center.

• Hay diferentes tipos de VPN de Azure que se seleccionarán de
acuerdo con los requisitos de la organización, incluidas VPN de
sitio a sitio, VPN de punto a sitio, VNet a VNet y VPN de varios
sitios.
• Considere usar ExpressRoute si su escenario de conectividad
requiere un mayor nivel de confiabilidad, velocidades más rápidas,
latencias consistentes y mayor seguridad que las conexiones típicas
de Internet.
• El grupo de seguridad de red (NSG) en Azure le permite filtrar
el tráfico de red mediante la creación de reglas.
• Considere el uso de Azure Firewall cuando su organización
requiera un firewall con estado completo, administración
centralizada y protección a nivel de red y aplicación.
• Considere usar Azure Front Door cuando los requisitos de su
organización incluyan la implementación de Azure en diferentes
regiones con una experiencia de alto rendimiento para las
aplicaciones y que sea resistente a fallas.
• Use Azure Bastion para habilitar el acceso seguro a través de
TLS a los usuarios de Internet que necesitan acceder a los recursos
que se encuentran en su red de Azure.
• Cuando necesite un filtrado a nivel de recursos para mejorar
la seguridad de sus cargas de trabajo, asegúrese de utilizar un
firewall a nivel de recursos.
• Habilite Azure DDoS Standard cuando necesite ajustar el
volumen de tráfico de la aplicación y desee garantizar un nivel de
SLA que proporcione garantía de aplicación y protección de costos.
• Para recibir alertas de amenazas en Azure Security Center,
debe actualizar al nivel Estándar.
• Puede usar Azure Security Center para supervisar la postura
de seguridad de Azure Kubernetes y Azure Container Registry.
• Azure Disk Encryption requiere que su máquina virtual de
Windows tenga conectividad con Azure AD para obtener un token
para conectarse con Key Vault.
• Para asegurarse de que siempre está protegiendo los datos en
tránsito, debe configurar su App Service para usar un certificado
SSL / TLS.
Capítulo 3
Gestionar operaciones de
seguridad
El objetivo principal de las operaciones de seguridad es mantener y
restaurar las garantías de seguridad de los sistemas cuando los
adversarios los atacan. El Instituto Nacional de Estándares y Tecnología
(NIST) describe las tareas de las operaciones de seguridad en su Marco de
Ciberseguridad, que son Detectar, Responder y Recuperar. Para poder
ejecutar esas funciones en un entorno de nube, no solo necesita el
enfoque correcto, sino que también debe comprender cómo funcionan las
herramientas nativas para proporcionarle los datos que necesita para
limitar el tiempo y el acceso que un atacante puede obtener a valiosos
sistemas y datos.
Azure tiene capacidades nativas que puede aprovechar para monitorear
continuamente las operaciones de seguridad de su entorno, de modo que
pueda identificar rápidamente las amenazas potenciales a sus cargas de
trabajo.

• Habilidad 3.1: supervisar la seguridad mediante Azure
Monitor
• Habilidad 3.2: Supervisar la seguridad mediante Azure
Security Center
• Habilidad 3.3: Supervisar la seguridad mediante Azure
Sentinel
• Habilidad 3.4: Configurar políticas de seguridad
HABILIDAD 3.1: CONFIGURAR SERVICIOS

DE SEGURIDAD
Las operaciones de seguridad comienzan asegurando que tenga
visibilidad y acceso a los registros subyacentes de los diferentes servicios
que desea monitorear. Azure Monitor puede recopilar y almacenar datos
de aplicaciones, sistemas operativos, recursos de Azure, suscripciones de
Azure, inquilinos de Azure y recursos personalizados de Azure. Esta
sección del capítulo cubre las habilidades necesarias para configurar los
servicios de seguridad, que se basan en Azure Monitor, de acuerdo con el
esquema del Examen AZ-500.
Configurar Azure Monitor

Una pregunta común cuando se trata del uso de Azure Monitor es:
"¿Cómo lo habilito?" Azure Monitor se habilita automáticamente cuando
crea una nueva suscripción de Azure. En ese momento, el registro de
actividad y las métricas de la plataforma se recopilan
automáticamente. La otra pregunta habitual es: "¿Azure Monitor también
puede supervisar los recursos locales?" Aunque Azure Monitor implica
(por el nombre) que los recursos están en Azure, también recopila datos
de máquinas virtuales y aplicaciones en otras nubes y locales para
monitorear.
Por este motivo, antes de realizar cualquier tipo de configuración en
Azure Monitor, es importante comprender algunos conceptos
fundamentales de esta plataforma. La sección que sigue cubre algunos
principios clave.
Revisión de los conceptos de Azure Monitor

El diagrama que se muestra en la Figura 3-1 le ayuda a comprender mejor
la amplitud de Azure Monitor y las diferentes áreas que toca.
Figura 3-1 Diagrama de arquitectura de la solución Azure Monitor
En el lado izquierdo del diagrama que se muestra en la Figura 3-1 , tiene
las diferentes capas que representan los componentes que generarán
registros, que pueden ser ingeridos por Azure Monitor. Desde la
perspectiva de la aplicación y el sistema operativo, la máquina se puede
ubicar físicamente en las instalaciones, en Azure o en otro proveedor de la
nube. Además de estas fuentes de datos, también puede ingerir datos de
diferentes recursos y suscripciones de Azure y del propio inquilino de
Azure. Estos datos se ingieren en el área de trabajo de Log Analytics, que
es parte de la solución Azure Monitor y una vez que los datos están allí,
puede consultarlos usando Kusto Query Language, que usa entidades de
esquema que están organizadas en una jerarquía similar a las bases de
datos, tablas de SQL. y columnas.
Las últimas tres capas que aparecen en el lado izquierdo del diagrama que
se muestra en la Figura 3-1 representan las tres capas principales en
Azure donde puede obtener información de registro. La definición de
cada capa se muestra aquí:
• Recursos de Azure Aquí podrá obtener registros de recursos,
que tienen operaciones que se ejecutaron en el nivel del plano de
datos de Azure. Un ejemplo de eso sería obtener un secreto de
Azure Key Vault. Estos registros también se denominan registros
de diagnóstico.
• Suscripción de Azure Aquí podrá obtener registros de
actividad, que tiene operaciones que se ejecutaron en el plano de
administración. Debe revisar estos registros cuando necesite
determinar la respuesta para el qué (qué operación se
realizó), quién (quién realizó esta operación) y cuándo (cuándo se
realizó esta operación). Por ejemplo, si una VMse eliminó, debe ir al
Registro de actividad de Azure para averiguar la respuesta
del qué , quién y cuándo con respecto a la operación de eliminación
de VM.
• Azure Tenant Aquí podrá obtener los registros de Azure
Active Directory. En esta capa, tiene el historial de la actividad de
inicio de sesión y la pista de auditoría de los cambios realizados en
Azure Active Directory.
Es muy importante comprender esas capas al estudiar para el examen AZ-
500 porque es posible que tenga situaciones en las que deberá
seleccionar la opción correcta con respecto a dónde buscar una
información específica. Por ejemplo, el administrador de Contoso desea
identificar al usuario que detuvo la máquina virtual hace dos
semanas; ¿Dónde debería buscar esta información? Si respondió Registro
de actividad de Azure, está en lo correcto. Como se mencionó
anteriormente, en el Registro de actividades encontrará las operaciones
del plano de gestión y la identificación del qué , quién y cuándo se realizó
una operación.
Las métricas son otro tipo de información que se puede ingerir. Las
métricas son valores numéricos que describen algún aspecto de un
sistema en un momento determinado. La telemetría, como eventos y
seguimientos, y los datos de rendimiento se almacenan como registros
para que se puedan combinar para el análisis. Este tipo de información se
puede utilizar en situaciones en las que es necesario recopilar contadores
de rendimiento relacionados con la seguridad de varias máquinas
virtuales y crear alertas basadas en determinados umbrales.
Dado que Azure Monitor comienza a recopilar datos de un recurso tras la
creación de ese recurso, es importante saber dónde buscar cuando
necesite información sobre esos recursos. Muchos recursos tendrán un
resumen de los datos de rendimiento que son relevantes para ese recurso
y, por lo general, se encuentra en la página Descripción general de ese
recurso. Por ejemplo, en la opción Descripción general de una cuenta de
almacenamiento de Azure, verá información sobre la latencia promedio,
los datos de salida y las solicitudes, como se muestra en la Figura 3-2 .
Figura 3-2 Resumen de información sobre el rendimiento de la cuenta de
almacenamiento
Si necesita consultar registros que tienen operaciones que se ejecutaron
en el plano de administración, debe usar el registro de actividad de
Azure. Para acceder al Registro de actividad, siga estos pasos:
2. En la barra de búsqueda, escriba actividad y en Servicios , haga
clic en Registro de actividad . El registro de actividad aparece la
página, como se muestra en la Figura 3-3 .
Figura 3-3 Página inicial del registro de actividad
3. Aquí, puede utilizar el filtro Intervalo de tiempo para ajustar la
línea de tiempo en la que desea realizar su consulta. Para este
ejemplo, este filtro se cambió durante la última hora y, después de
aplicar el cambio, aparece el resultado, como se muestra en
la Figura 3-4 .
Figura 3-4 Resultados del registro de actividad después del filtrado

4. El resultado muestra un resumen de la operación, incluido el estado
de la hora, la marca de tiempo y quién inició el evento. Si desea
información más detallada sobre la operación, puede expandir el
campo del nombre de la operación y hacer clic en él. Allí tendrás los
detalles de la operación en la pestaña JSON.
Como se mencionó en la sección anterior de este capítulo, el otro tipo de
datos que puede querer usar es métrico. Si está monitoreando una
máquina virtual y necesita más métricas además de las que aparecen en
la página Resumen , puede ir a la página Métricas y desde allí
personalizar las métricas que desea monitorear como se muestra en el
ejemplo de la Figura 3- 5 .
Figura 3-5 Visualización de métricas de VM

Otra característica importante de Azure Monitor es la capacidad de crear
alertas para diferentes tipos de eventos. Puede utilizar el siguiente tipo de
datos para generar alertas con los datos recopilados durante los últimos
30 días (de forma predeterminada):
• Valores métricos
• Consultas de búsqueda de registros
• Eventos de registro de actividad
• Estado de la plataforma Azure subyacente
• Pruebas de disponibilidad del sitio web
En la Figura 3-5 , puede ver una opción justo encima del gráfico Nueva
regla de alerta. Esta opción le permite ir desde este panel directamente
al panel de alertas y crear una regla de alerta utilizando la métrica que se
muestra actualmente en la pantalla, que, en este caso, es para monitorear
los bytes de lectura del disco del sistema operativo / seg, como se
muestra en la Figura 3. -6 .
Figura 3-6 Creación de una regla de alerta
La página Crear regla de alerta tiene algunos parámetros importantes
que se deben completar, pero cuando activa esta página desde
la página Métricas donde ya configuró las métricas que desea
monitorear, esta página rellena previamente el Alcance (que es el recurso
de destino que desea monitorear) y la Condición (que es la lógica de la
regla que se utilizará para activar la alerta). Si bien el alcance tiene el
recurso que desea monitorear, la condición puede necesitar algunos
ajustes según sus necesidades. Para personalizar la condición,
simplemente haga clic en el nombre de la condición y aparecerá la
hoja Configurar lógica de señal , como se muestra en la Figura 3-7 .
Figura 3-7 Personalización de la lógica de alerta
La primera parte de esta hoja tiene el nombre del contador de
rendimiento que está utilizando para esta regla y un gráfico de muestra
con datos de las últimas 6 horas. La segunda parte de esta hoja es donde
configura el umbral. En la sección Alert Logic , puede cambiar el
conmutador para que sea Estático (proporcione un valor específico como
umbral) o Dinámico (que usa el aprendizaje automático para aprender
continuamente sobre el patrón de comportamiento). En este caso, el
administrador de Contoso desea recibir una alerta si el contador
promedio de bytes de lectura / seg del disco del sistema operativo es
superior a 3 MB, lo que significa que estático es la mejor opción para
usar. En este caso, el operador permanece greater than, el Tipo de
agregación permaneceaverage, y solo necesita ingresar el valor (en este
caso, 3) en el campo Valor de umbral . La sección Vista previa de la
condición explica la lógica para que pueda confirmar que esto es lo que
desea hacer. La sección Evaluada basada en es donde puede configurar
la opción Granularidad de agregación (período) , que define el
intervalo en el que se agrupan los puntos de datos. También puede
configurar la Evaluación de frecuencia , que define la frecuencia con la
que se debe ejecutar esta regla de alerta. La evaluación de
frecuencia debe ser la misma que la granularidad de agregación o
superior. Una vez que termine, haga clic en el botón Listo .
A continuación, configure la sección Grupo de acción , que le permite
configurar el tipo de notificación que desea recibir. Para configurar esta
opción, haga clic en Seleccionar grupo de acciones y, en
la hoja Seleccionar un grupo de acciones para adjuntar a esta regla
de alerta , haga clic en la opción Crear grupo de acciones ; el Grupo de
Acción Agregar cuchilla aparece, como se muestra en la Figura 3-8 .
Figura 3-8 Configuración del grupo de acciones
En esta hoja, debe comenzar escribiendo un nombre para este grupo de
acciones; este puede ser un nombre largo que le ayude a identificar lo que
hace este grupo. En el campo Nombre corto , agregue un nombre corto,
que aparece en los correos electrónicos o mensajes que podría enviar esta
alerta. Seleccione la suscripción y el grupo de recursos donde reside este
grupo de acción; en Nombre de la acción , escriba un nombre para la
primera acción. Observe que hay muchos campos para acciones; eso se
debe a que puede tener acciones como enviar un correo electrónico,
enviar un mensaje SMS o ejecutar un runbook, entre otras. En su caso, el
administrador de Contoso desea enviar un correo electrónico a una lista
de distribución y enviar un mensaje SMS al teléfono de guardia. Para el
tipo de acción, seleccione Correo electrónico / Mensaje SMS / Push /
Voice , y elAparece la hoja Correo electrónico / Mensaje SMS / Push /
Voice . En esta hoja, escriba el correo electrónico y el número de SMS
después de eso, haga clic en Aceptar y luego en Aceptar nuevamente.
Para finalizar la creación de la alerta, solo necesita agregar un nombre de
regla de alerta y una breve descripción y luego elegir la gravedad de la
alerta en el menú desplegable. La severidad debe representar el nivel de
criticidad que desea asignar a esta regla. En este caso, el administrador de
Contoso entiende que cuando se alcanza este umbral, se debe generar una
alerta importante (no crítica), que, en este caso, podría estar
representada por Sev 2 , como se muestra en la Figura 3-9 .
Figura 3-9 Configuración de los detalles de la regla de alerta

Idealmente, debería habilitar esta regla al crearse, razón por la cual
la casilla de verificación Habilitar regla de alerta al crearse está
seleccionada de forma predeterminada. Para confirmar todos los cambios,
haga clic en el botón Crear regla de alerta .
Hora de activación importante
Normalmente, las nuevas reglas de métricas tardan hasta 10 minutos en activarse.
Una vez que termine de crear la regla, debería recibir un correo

electrónico informándole que fue agregado al grupo de acción. En
la Figura 3-10 se muestra una muestra de este correo electrónico .
Figura 3-10 Notificación por correo electrónico generada por Azure
Monitor
También debería recibir el mensaje SMS. Observe que el nombre corto
que utilizó aparece en el mensaje, como se muestra en la Figura 3-11 .
Figura 3-11 Notificación por SMS generada por Azure Monitor
Ahora que creó una alerta basada en una métrica que utilizó
anteriormente, la pregunta es: " ¿Qué pasa si necesito cambiar la regla de
alerta?" Si desea poder ver y cambiar las alertas, puede utilizar el panel
de alertas . Siga los pasos a continuación para acceder a este panel.
2. En la barra de búsqueda, escriba alerta y, en Servicios , haga clic
en Alertas .
3. Haga clic en el botón Administrar reglas de alerta y aparecerá la
página Reglas , como se muestra en la Figura 3-12 .
Figura 3-12 Resultados del registro de actividad después del
filtrado
4. La regla de alerta que creó aparece en la lista. Para editar la regla,
solo necesita hacer clic en ella. Si necesita crear una nueva regla de
alerta, haga clic en el botón Nueva regla de alerta . Ambos pasos lo
llevarán a la página Crear regla de alerta , que se mostró
anteriormente en la Figura 3-6 .
Se requieren roles importantes de RBAC
El consumo y la administración de instancias de alerta requieren que el usuario tenga
las funciones RBAC integradas de colaborador de monitoreo o lector de monitoreo.
Una vez que se activa una alerta, el estado de la alerta se establece

en Nuevo , lo que significa que se detectó la regla, pero no se ha
revisado. Tenga en cuenta que el estado de alerta es diferente e
independiente de la condición del monitor . Mientras que el estado de
alerta lo establece el usuario, el sistema establece automáticamente
la condición de monitorización . Cuando se activa una alerta,
la condición del monitor de la alerta se establece en Activado . Cuando
se borra la condición subyacente que provocó que se disparara la alerta
(por ejemplo, si su condición era enviar una alerta si la CPU alcanza el 80
por ciento de utilización, y luego la utilización de la CPU se redujo al 50
por ciento), la condición del monitor se establece en Resuelto. Puede ver
esta información en el correo electrónico, suponiendo que haya
configurado la regla para enviar un correo electrónico, como se muestra
en la Figura 3-13 .
Figura 3-13 Notificación por correo electrónico que indica que se
resolvió una alerta
Configurar el registro de diagnóstico y la

retención de registros
En Azure, cada recurso requiere su propia configuración de
diagnóstico. En esta configuración, usted define las categorías de registros
y datos métricos que deben enviarse a los destinos definidos en la
configuración. Además, debe definir el destino del registro, que incluye
enviarlo al área de trabajo de Log Analytics, Event Hubs y Azure Storage.
Es importante mencionar que cada recurso puede tener hasta cinco
configuraciones de diagnóstico. Esto significa que si el requisito del
escenario establece que debe enviar registros al área de trabajo de Log
Analytics y Azure Storage, necesitará dos configuraciones de
diagnóstico. Siga estos pasos para configurar los ajustes de diagnóstico:
2. En la barra de búsqueda, escriba monitor y en Servicios , haga clic
en Monitor . El monitor | Aparece la página de descripción
general .
3. En el panel de navegación izquierdo, en Configuración , haga clic
en Configuración de diagnóstico ; el Monitor | Aparece la página
de configuración de diagnóstico , como se muestra en la Figura 3-
14 .
Figura 3-14 Página de configuración de diagnóstico en Azure
Monitor
4. Como puede ver, todos los recursos que pueden tener
configuraciones de diagnóstico aparecen en esta lista. Para este
ejemplo, haga clic en el recurso Front Door que se creó en el
capítulo anterior.
5. Haga clic en la opción Agregar configuración de
diagnóstico ; la Configuración de diagnóstico aparece la página,
Figura 3-15 Configuración de diagnóstico para un recurso de
puerta delantera
6. En el campo Nombre de la configuración de diagnóstico , escriba
un nombre completo para esta configuración.
7. Para este recurso específico, tiene dos tipos de registros. El primero
es un registro de métricas, en el que solo puede seleccionar las que
necesita para su escenario; el segundo es el registro de destino, que
puede ser Log Analytics, una cuenta de almacenamiento o Event
Hub.
8. En este caso, el administrador de Contoso debe poder consultar
fácilmente los registros de acceso de Front Door y los registros
WAF mediante un lenguaje de consulta completo. Para cumplir con
este requisito, debe seleccionar Log Analytics , que utiliza Kusto
Query Language (KQL) para realizar consultas.
9. Cuando seleccione la opción Enviar a Log Analytics , verá la opción
para seleccionar la suscripción y el espacio de trabajo de Log
Analytics que desea utilizar (suponiendo que tenga una). Haga una
selección y haga clic en el botón Guardar .
10. Después de guardar, el botón Guardar ya no está disponible,
lo que indica que los cambios se han confirmado.
Si bien la configuración de muestra anterior describe los pasos para
configurar el espacio de trabajo de Log Analytics como el destino de la
configuración de diagnóstico, la configuración general puede variar según
el destino. Por ejemplo, si selecciona una cuenta de almacenamiento,
aparecerán las opciones que se muestran en la Figura 3-16 .
Figura 3-16 Configuración de diagnóstico de la cuenta de

almacenamiento
Tenga en cuenta que al configurar una cuenta de almacenamiento como
su destino, puede personalizar la política de retención para cada
registro. En un escenario donde el requisito es almacenar los registros de
acceso de Front Door durante 50 días y los registros WAF durante 40
días, el mejor destino para esta configuración es la cuenta de
almacenamiento porque permite este tipo de configuración granular.
Considere seleccionar Event Hub como destino cuando necesite
transmitir los datos a otra plataforma. Por ejemplo, puede hacer esto si
necesita enviar la puerta principal (podría sercualquier otro recurso de
Azure) acceda a los registros a una solución de administración de eventos
e información de seguridad (SIEM) de terceros, como Splunk. En este
caso, usar Event Hub es la mejor opción porque permite que los registros
se transmitan fácilmente a una solución SIEM.
Para el examen AZ-500, asegúrese de comprender las capacidades
de cada destino porque los requisitos de cada escenario conducirán
a diferentes opciones de almacenamiento.
Supervisión de registros de seguridad mediante

Azure Monitor
Dado que cada recurso de Azure puede tener diferentes conjuntos de
registros y configuraciones, debe asegurarse de recopilar todos los
registros que afecten a la supervisión de la seguridad. Para los servicios
de plataforma como servicio (PaaS) como Azure Key Vault, solo necesita
configurar los ajustes de diagnóstico en la ubicación de destino (área de
trabajo de Log Analytics, cuenta de almacenamiento o Event Hub) donde
se almacenará el registro. Para las VM de infraestructura como servicio
(IaaS), necesita más pasos porque desea asegurarse de que está
recopilando los registros de seguridad relevantes del propio sistema
operativo.
Los registros del plano de datos son los que le brindarán más información
sobre los eventos relacionados con la seguridad en las VM de
IaaS. Suponiendo que ya tiene un área de trabajo de Log Analytics que
almacenará estos datos, deberá realizar las siguientes acciones para
configurar Azure Monitor para ingerir registros de seguridad de las
máquinas virtuales. Primero, habilite Log Analytics VM Extension y
recopile eventos de seguridad del sistema operativo. Una vez que se
recopilan los datos, puede visualizarlos usando el espacio de trabajo de
Log Analytics y realizar consultas usando KQL. Suponiendo que ya ha
creado un espacio de trabajo de Log Analytics, siga estos pasos para
configurar esta recopilación de datos:
2. En la barra de búsqueda, escriba análisis de registros y,
en Servicios , haga clic en Espacios de trabajo de análisis de
registros .
3. En la página Espacios de trabajo de Log Analytics , haga clic en el
espacio de trabajo en el que desea almacenar los registros de
seguridad.
4. En el panel de navegación izquierdo de la página del espacio de
trabajo, en Fuentes de datos del espacio de trabajo , haga clic
en Máquinas virtuales .
5. Haga clic en la máquina virtual que desea conectar a este espacio de
trabajo. Observe que el estado de Conexión de Log
Analytics aparece como No conectado , como se muestra para el
AZ500VM3 en la Figura 3-17 .
Figura 3-17 Máquinas virtuales que están disponibles en el espacio

de trabajo
6. En la página de la VM, haga clic en el botón Conectar , como se
Figura 3-18 Conexión de una máquina virtual a un espacio de
trabajo
7. En este punto, el agente de Log Analytics se instalará y configurará
en esta máquina. Este proceso lleva unos minutos, durante los
cuales el estado se muestra como Connecting. Puede cerrar esta
página y el proceso continuará en segundo plano.
8. Una vez instalado el agente, el estado cambiará a This Workspace.
9. En el panel de navegación izquierdo de la página del espacio de
trabajo principal, en Configuración , haga clic en Configuración
avanzada .
10. En la página Configuración avanzada , haga clic
en Datos > Registros de eventos de Windows , como se muestra
en la Figura 3-19 .
Figura 3-19 Configuración de la fuente de datos para la ingestión

11. En el campo Recopilar eventos de los siguientes registros
de eventos , escriba Sistema y seleccione Sistema en el menú
desplegable. Haga clic en el signo más ( + ) para agregar este
registro. Deje las opciones predeterminadas seleccionadas. Si tiene
eventos de seguridad específicos que desea recopilar,
escriba seguridad y seleccione los eventos apropiados.
13. Haga clic en Aceptar en la ventana emergente y cierre esta
página.
Azure Monitor también tiene soluciones que pueden mejorar la
recopilación de datos para diferentes escenarios. Esto puede resultar de
gran ayuda para el control de la seguridad. También puede aprovechar
una plantilla de Azure Resource Manager (ARM) para implementar el
agente a escala; al hacerlo, necesitará dos parámetros: el ID del espacio de
trabajo y la clave del espacio de trabajo.
Solución de seguridad y auditoría

Las soluciones de supervisión aprovechan los servicios de Azure para
proporcionar información adicional sobre el funcionamiento de una
aplicación o servicio. Estas soluciones recopilan datos de registro y
brindan consultas y vistas para analizar los datos recopilados. Las
soluciones requieren un espacio de trabajo de Log Analytics para
almacenar los datos recopilados por la solución y albergar sus búsquedas
y vistas de registros.
Si agrega la solución Security And Audit a su espacio de trabajo,
automáticamente podrá recopilar eventos de seguridad de Windows que
estén configurados de acuerdo con las mejores prácticas de la política de
auditoría. Esto le permitirá buscar eventos específicos en su espacio de
trabajo. Siga estos pasos para agregar la solución de seguridad y
auditoría a su espacio de trabajo:
2. En la barra de búsqueda, escriba soluciones y, en Servicios , haga
clic en Soluciones .
3. En la página Soluciones , haga clic en el botón Agregar .
4. En el campo Buscar en el mercado , escriba seguridad y
auditoría y presione Entrar.
5. En los resultados de la búsqueda, haga clic en el mosaico Seguridad
y auditoría .
7. Seleccione el espacio de trabajo al que desea agregar esta solución y
haga clic en el botón Crear .
Una vez agregada la solución, puede abrir el espacio de trabajo de Log
Analytics seleccionando Soluciones en General en el panel de
navegación izquierdo. Vea la Figura 3-20 .
Figura 3-20 Espacio de trabajo de Log Analytics donde se muestra la

nueva solución
Búsqueda de eventos de seguridad en el espacio de

trabajo de Log Analytics
Ahora que los eventos de seguridad están almacenados en el espacio de
trabajo, puede comenzar a buscar eventos que puedan indicar una
actividad sospechosa. Para acceder a los registros en el espacio de
trabajo, vaya a la página principal del espacio de trabajo y, en el panel de
navegación izquierdo, haga clic en
la opción Registros en General ; la nueva consulta aparece la página,
Figura 3-21 Página de nueva consulta

Los escenarios que siguen proporcionan más ejemplos de cómo estas
consultas pueden ser útiles al investigar eventos de seguridad
relacionados con la autenticación:
• El administrador de seguridad de Contoso está investigando
un posible movimiento lateral en la red de Contoso, y el
administrador sabe que una de las formas de realizar este
movimiento lateral es haciendo enumeración de cuentas. Le
gustaría conocer todos los equipos que fueron objeto de esta
enumeración. La consulta utilizada para realizar esta tarea se
muestra aquí:
SecurityEvent | donde EventID == 4799
El EventID 4799se activa cada vez que se enumera una pertenencia a

un grupo local con seguridad habilitada. El resultado de la consulta
mostrará una lista de todas las computadoras que tienen este
evento.
• El administrador de seguridad de Fabrikam está investigando
el uso de un software no autorizado en su entorno. Quiere saber
cuándo se lanzó este software. No está seguro de cuál es la línea de
comando exacta para el software, pero sabe que comienza
con CM . La consulta utilizada para realizar esta tarea se muestra
aquí:
SecurityEvent | donde EventID == 4688 y CommandLine contienen "cm"
El EventID 4688 se activa cada vez que se crea un nuevo proceso, y

el CommandLineatributo evaluará el CommandLinecampo del evento para
verificar si contiene la cadena cm.
• El administrador de seguridad de Contoso recibió una
solicitud para informar todos los intentos de inicio de sesión
anónimos exitosos provenientes de la red. La consulta utilizada
para realizar esta tarea es
SecurityEvent | donde EventID == 4624 y Account contienen "inicio
de sesión anónimo" y
LogonType == 3
El EventID 4624se activa cada vez que se produce un inicio de sesión

exitoso; el Accountatributo solo filtrará para anonymousiniciar
sesión. Con el LogonTypeatributo establecido en 3, solo filtrará los
intentos de red.
HABILIDAD 3.2: SUPERVISAR LA

SEGURIDAD MEDIANTE AZURE SECURITY
CENTER
En organizaciones grandes donde es necesario tener un estándar
centralizado en múltiples suscripciones, es común usar Azure
Management Groups para agregar todas las suscripciones que comparten
un conjunto común de políticas. Security Center le permite tener una vista
centralizada de múltiples suscripciones para asegurarse de tener una
mejor visibilidad de su postura de seguridad en la nube. Esta sección del
capítulo cubre las habilidades necesarias para configurar las políticas de
seguridad en Security Center de acuerdo con el esquema del Examen AZ-
500.
Evaluar los análisis de vulnerabilidades desde
Azure Security Center
La evaluación de la vulnerabilidad es un componente clave de cualquier
estrategia de gestión de la postura de seguridad. El nivel estándar de
Security Center proporciona una capacidad de evaluación de
vulnerabilidades incorporada para sus máquinas virtuales de Azure
basada en una solución de gestión de vulnerabilidades líder del sector,
Qualys. Esta integración no tiene ningún costo adicional, siempre que
Security Center utilice el modelo de precios de niveles estándar. Si está
utilizando el nivel gratuito, seguirá recibiendo una recomendación para
instalar la evaluación de vulnerabilidades en su máquina, pero esta
recomendación (que no sugiere elevaluación de vulnerabilidades)
requiere que tenga la licencia para su solución de evaluación de
vulnerabilidades, que puede ser Qualys o Rapid7.
Suponiendo que tenga habilitado el nivel Estándar, Security Center
identificará las máquinas virtuales que no tienen una solución de
evaluación de vulnerabilidades instalada y activará una recomendación
de seguridad que sugiere que se instale la extensión Qualys
incorporada. Esta recomendación es similar al ejemplo que se muestra en
la Figura 3-22 .
Figura 3-22 Recomendación para instalar la extensión Qualys

incorporada
Para instalar esta solución de evaluación de vulnerabilidades, necesita
permisos de escritura en la máquina virtual en la que está
implementando la extensión. Suponiendo que tenga el nivel correcto de
privilegio, podrá seleccionar la máquina virtual de la lista que se muestra
en la pestaña Recursos en mal estado y hacer clic en
el botón Remediar . Esta recomendación tiene la capacidad Quick-Fix, lo
que significa que puede activar la instalación de la extensión
directamente desde este panel. Como cualquier extensión en Azure, la
extensión de Qualys se ejecuta en la parte superior del agente de la
máquina virtual de Azure, lo que significa que se ejecuta como host local
en los sistemas Windows y como raíz en los sistemas Linux.
Las máquinas virtuales que ya tienen el agente instalado se enumerarán
en la pestaña Recursos saludables . Cuando Security Center no puede
implementar la extensión del escáner de vulnerabilidades en las VM,
enumerará esas VM en la pestaña Recursos no aplicables . Las máquinas
virtuales pueden aparecer en esta pestaña si forman parte de una
suscripción que utiliza el nivel de precio gratuito o si a la imagen de
máquina virtual le falta la ImageReferenceclase (que se usa en imágenes
personalizadas y máquinas virtuales restauradas desde la copia de
seguridad). Otra razón para que una máquina virtual se incluya en esta
pestaña es si la máquina virtual no está ejecutando uno de los sistemas
operativos compatibles:
• Microsoft Windows (todas las versiones)
• Red Hat Enterprise Linux (versiones 5.4+, 6, 7.0 a 7.7, 8)
• Red Hat CentOS (versiones 5.4+, 6, 7.0 a 7.7)
• Red Hat Fedora (versiones 22 a 25)
• SUSE Linux Enterprise Server (versiones 11, 12, 15)
• SUSE OpenSUSE (versiones 12, 13)
• SUSE Leap (versión 42.1)
• Oracle Enterprise Linux (versiones 5.11, 6, 7.0 a 7.5)
• Debian (versiones 7.xa 9.x)
• Ubuntu (versiones 12.04 LTS, 14.04 LTS, 15.x, 16.04 LTS,
18.04 LTS)
Escáner de vulnerabilidad de ASC importante
La solución de escáner de vulnerabilidades incorporada de Security Center no se
integra con Qualys Console.
Si está implementando esta evaluación de vulnerabilidad incorporada en

un servidor que tiene acceso restringido a Internet, es importante saber
que durante el proceso de configuración, se realiza una verificación de
conectividad para garantizar que la VM pueda comunicarse con el servicio
en la nube de Qualys en las siguientes dos direcciones IP: 64.39.104.113 y
154.59.121.74.
Una vez que la extensión está instalada en la VM de destino, el agente
realizará la evaluación de vulnerabilidad de la VM a través de un proceso
de escaneo. El resultado del análisis aparecerá en otra recomendación de
seguridad, que se llama Remediar las vulnerabilidades encontradas
en sus máquinas virtuales (con tecnología Qualys) . En la Figura 3-23
se muestra un ejemplo de esta recomendación .
Figura 3-23 Lista de vulnerabilidades encontradas durante el análisis

En esta página, puede ver la lista de hallazgos en
la sección Verificaciones de seguridad . Si hace clic en un control de
seguridad específico, Security Center mostrará otra hoja con los detalles
de esa vulnerabilidad, que incluye el impacto ; Vulnerabilidades
comunes ; Exposición (CVE) (ubicada en la sección Información
general ); la Descripción del tipo de amenaza; los pasos
de remediación ; Referencias adicionales para este control de
seguridad; y la lista de recursos afectados . Vea la Figura 3-24 .
Figura 3-24 Hoja de detalles de vulnerabilidad
La implementación de estas soluciones recomendadas se realiza fuera de
banda; en otras palabras, los implementará fuera de Security Center. Por
ejemplo, si una verificación de seguridad requiere que instale una
actualización de seguridad en su computadora de destino, deberá
implementar esa actualización de seguridad con otro producto, como la
Administración de actualizaciones. Algunas otras soluciones se centrarán
más en las mejores prácticas de seguridad. Por ejemplo, la comprobación
de seguridad 105098 (Usuarios sin caducidad de contraseña) recomienda
que cree una política de contraseñas que tenga una fecha de
caducidad. Por lo general, esto se implementa mediante la directiva de
grupo en Active Directory.
Escaneo de vulnerabilidades para SQL
Otra categoría de análisis de vulnerabilidades que está disponible de
forma nativa en Security Center es la evaluación de vulnerabilidades para
servidores SQL. Esta capacidad es parte de la integración de Security
Center con la función SQL Advanced Data Security (ADS). Puede habilitar
esta función en la configuración de Nivel de precios de Security Center ,
que habilitará ADS para todas las bases de datos en la suscripción, o
puede habilitarla solo en las bases de datos que desea que tengan esta
capacidad.
Cuando habilita ADS, la protección contra amenazas está disponible para
SQL. La protección contra amenazas para Azure SQL Database detecta
actividades anómalas que indican intentos inusuales y potencialmente
dañinos de acceder o explotar bases de datos. Por ejemplo, una alerta que
puede generar esta función es la posible vulnerabilidad a la inyección
SQL. Esta alerta podría indicar una posible vulnerabilidad a los ataques de
inyección de SQL. Por lo general, hay dos posibles razones para una
declaración defectuosa: un defecto en el código de la aplicación podría
haber construido la declaración SQL defectuosa, o el código de la
aplicación / procedimientos almacenados no desinfectaron la entrada del
usuario.
Cuando Security Center identifica que hay bases de datos que no tienen
esta función habilitada, activará una recomendación de seguridad, como
Figura 3-25 Recomendación de seguridad para habilitar ADS

Una vez habilitada esta función, Security Center también indicará que
también debe habilitar la evaluación de vulnerabilidades para sus
servidores SQL (consulte la Figura 3-26 ).
Figura 3-26 Recomendación de seguridad para habilitar la evaluación de

vulnerabilidades en SQL

Para el examen AZ-500, asegúrese de recordar las opciones de
escaneo de vulnerabilidades y que la evaluación de vulnerabilidad
incorporada para VM en Security Center se puede implementar
usando la función Quick-Fix.
Configurar el acceso Just-In-Time VM mediante

Azure Security Center
Cuando el escenario requiera que reduzca la superficie de ataque de las
VM de IaaS, debe asegurarse de aprovechar una capacidad de nivel
estándar de Security Center denominada acceso a VM Just-In-Time
(JIT). La intención de esta capacidad es garantizar que los puertos de
administración no estén expuestos a Internet todo el tiempo. Debido a
que la mayoría de los ataques contra las VM de IaaS intentarán utilizar
técnicas como RDP o SSH de fuerza bruta, las VM que tengan esos puertos
de administración abiertos serán más susceptibles de verse
comprometidas.
Cuando habilita el acceso JIT VM, Security Center fortalece el tráfico
entrante a sus VM de Azure mediante la creación de una regla de grupo de
seguridad de red (NSG). Esta regla se basa en los puertos seleccionados
en la VM a los que se bloqueará el tráfico entrante. Security Center
configura los grupos de seguridad de red (NSG) y Azure Firewall para
permitir el tráfico entrante a los puertos seleccionados y los rangos o
direcciones IP de origen solicitados, durante el tiempo especificado. Una
vez transcurrido el tiempo, Security Center restaura los grupos de
seguridad de red a sus estados anteriores.
Conexiones importantes establecidas
Cuando expire el tiempo, las conexiones que ya estén establecidas no se
interrumpirán.
Para configurar o editar una política de acceso de máquina virtual JIT

para una máquina virtual, necesitará acceso de escritura para el alcance
de la suscripción o el grupo de recursos para los siguientes objetos:
• Microsoft.Security/locations/jitNetworkAccessPolicies/write
• Microsoft.Compute/virtualMachines/write
El usuario que solicita acceso a una máquina virtual configurada con JIT
necesitará acceso de lectura en el alcance de la suscripción o grupo de
recursos para los siguientes objetos:
• Microsoft.Security/locations/jitNetworkAccessPolicies/initiat
e/action
• Microsoft.Security/locations/jitNetworkAccessPolicies/*/read
• Microsoft.Compute/virtualMachines/read
• Microsoft.Network/networkInterfaces/*/read
Si desea permitir que un usuario tenga acceso de lectura a la política JIT,
puede asignarle el rol de lector de seguridad. Si necesita un nivel más
profundo de personalización, puede asignar acceso de lectura a los
siguientes objetos:
• Microsoft.Security/locations/jitNetworkAccessPolicies/read
• Microsoft.Security/locations/jitNetworkAccessPolicies/initiat
e/action
• Microsoft.Security/policies/read
• Microsoft.Compute / virtualMachines / read
• Microsoft.Network/*/read
Siga estos pasos para configurar el acceso a la máquina virtual JIT en
Security Center:
2. En la barra de búsqueda, escriba seguridad y, en Servicios , haga
3. En el panel de navegación izquierdo, en la sección Advanced Cloud
Defense , haga clic en Just In Time VM Access . El centro de
seguridad | Aparecerá la página Just In Time VM Access , como se
Figura 3-27 Página principal de JIT VM Access

4. En el ejemplo que se muestra en la Figura 3-27 , no hay VM
configuradas (en la pestaña Configurado ). Si hace clic en
la pestaña No configurada , debería ver todas las máquinas
virtuales que pueden admitir esta solución pero que aún no se han
configurado. En la pestaña No admitidas , verá todas las VM que no
pueden usar esta función, que incluyen VM a las que les falta un
NSG, VM clásicas o VM que están en una suscripción que usa el nivel
gratuito.
5. Haga clic en la pestaña No configurado , seleccione la máquina
virtual en la que desea habilitar JIT y haga clic en el botón Habilitar
JIT en 1 máquina virtual . La configuración de acceso JIT
VM aparece la página, como se muestra en la figura 3-28 .
Figura 3-28 Puertos disponibles para configurar JIT

6. Puede seleccionar uno de los puertos predeterminados según el
protocolo para el que desea permitir el acceso: 22 (SSH), 3389
(RDP) y 5985/5986 (WinRM). También puede hacer clic en
el botón Agregar si desea personalizar el puerto en el que desea
permitir el tráfico entrante. Para este ejemplo, haga clic
en 3389 y aparecerá la hoja Agregar configuración de puerto ,
Figura 3-29 Configuración del puerto
7. En esta hoja, puede personalizar el puerto , así como el tipo
de protocolo , los rangos de IP de origen permitidos a los que se
permite acceder (que podría ser la IP de solicitud o un bloquede
direcciones IP) y el intervalo de tiempo (tiempo máximo de
solicitud ) para el que esta regla permanecerá habilitada. Después
de terminar esas configuraciones, haga clic en el botón Aceptar .
8. Si no está utilizando los otros puertos, puede seleccionar cada uno
de los puertos no utilizados, hacer clic en los puntos suspensivos al
final de cada puerto y seleccionar Eliminar .
9. Haga clic en el botón Guardar para confirmar los cambios.
Si desea ver los cambios que el acceso JIT VM hizo a su VM, abra las
propiedades de la VM y haga clic en Redes . El ejemplo que se muestra en
la Figura 3-30 muestra una nueva regla (la primera regla en la lista) que
fue creada por JIT para denegar el acceso a esos puertos. Debido a que
esta regla es administrada por JIT, no le haga ningún cambio manual.
Figura 3-30 Reglas de puerto de entrada con la adición de la regla de

acceso JIT VM
Ahora que JIT está configurado, veamos cómo solicitar acceso a una
máquina virtual con JIT habilitado. Utilice los siguientes pasos para
realizar esta acción:
3. En el panel de navegación izquierdo, en la sección Advanced Cloud
Defense , haga clic en Just In Time VM Access .
4. En el Centro de seguridad | En la página Just In Time VM Access ,
en la pestaña Configurado , seleccione la VM para la que habilitó
JIT y haga clic en el botón Solicitar acceso , como se muestra en
la Figura 3-31 .
Figura 3-31 Solicitud de acceso a una máquina virtual mediante JIT

5. En la página Solicitar acceso , tiene la opción de seleccionar
el puerto al que desea acceder, la IP de origen permitida y
el rango de tiempo (horas) , como se muestra en la Figura 3-32 .
Figura 3-32 Personalización del acceso

6. Seleccione RDP , deje las otras opciones con la selección
predeterminada y haga clic en el botón Abrir puertos .
Ahora puede iniciar una sesión RDP en esta máquina virtual. Cuando lo
haga, vuelva al Centro de seguridad y observe que el estado de la máquina
virtual cambió para mostrar que la conexión está actualmente activa y
quién inició esta sesión. Vea la Figura 3-33 .
Figura 3-33 Estado de la máquina virtual que muestra detalles sobre la

conexión
El icono de conexión de la punta puede variar
El icono que aparece en la columna Detalles de conexiones puede variar porque
también puede ser el icono de Azure Firewall.
En un escenario en el que una máquina virtual tiene JIT habilitado y está

ubicada en una subred con una ruta definida por el usuario que apunta a
un Firewall de Azure como puerta de enlace predeterminada, es posible
que experimente problemas para acceder a la máquina virtual mediante
JIT. Este problema ocurre debido al comportamiento de enrutamiento
asimétrico, lo que significa que la solicitud llega a través del uso de la
dirección IP pública de la máquina virtual, donde JIT ha abierto el
acceso. Sin embargo, la respuesta (ruta de retorno) se realiza a través de
Azure Firewall, que evalúa la solicitud y, como no hay una conexión
establecida, descarta el paquete. En escenarios como este, debe mover el
recurso a una subred que no tiene una ruta definida por el usuario.
Configurar la administración de políticas

centralizada mediante Azure Security Center
Las recomendaciones de Security Center se derivan de Azure Policy. De
forma predeterminada, Security Center tiene una iniciativa llamada ASC
Default, que se asigna a la suscripción una vez que activa Security Center
por primera vez. El proceso de activación ocurre en segundo plano y se
activa cuando visita el panel de Security Center por primera vez.
Para recapitular algunos conceptos importantes sobre la directiva de
Azure y cómo estas directivas se correlacionan con Security Center, revise
el diagrama que se muestra en la figura 3-34 .
Figura 3-34 Correlación entre la iniciativa del Centro de seguridad y la

Política de Azure
La iniciativa ASC Default tiene varias definiciones de políticas a las que se
puede acceder individualmente mediante Azure Policy. Las definiciones
de políticas se usan para comparar las propiedades de los recursos de
Azure con las reglas comerciales, que en este caso se implementan en
JSON. Cada definición de política en Azure Policy tiene un único efecto,
también llamado efecto de política. Ese efecto determina lo que sucede
cuando se evalúa la coincidencia de la regla de política. Centro de
seguridad utiliza los siguientes efectos: Audit, AuditIfNotExists,
y Disabled. Esto significa que Security Center no se utiliza para la
aplicación de políticas, pero se utiliza para la supervisión de la seguridad
y la visualización del cumplimiento. La aplicación de políticas se trata en
“Destreza 3.4 Configurar políticas de seguridad”, más adelante en este
capítulo.
Las políticas de Security Center se pueden personalizar, lo que significa
que si tiene un escenario en el que la organización usa una solución de
autenticación multifactor (MFA) de terceros en lugar de Azure MFA,
puede deshabilitar la recomendación de MFA en Security Center porque
esta recomendación es basado en una comprobación para determinar si
está utilizando Azure MFA. Si bien se recomienda usar siempre la
configuración predeterminada para estas políticas, habrá escenarios en
los que es posible que deba personalizar y cambiar el efecto
de AuditIfNotExistsa Disabled.
Implementación de la gestión de políticas centralizada

Comencemos a revisar un escenario ficticio para Fabrikam: considere un
escenario en el que Fabrikam tiene un solo inquilino de Azure con varias
unidades de negocio en toda la empresa. Cada unidad de negocio tiene su
propia suscripción y sigue los estándares de política que se establecieron
según su sucursal, que se basa en la geolocalización de Fabrikam en todo
el mundo. En este escenario, Fabrikam quiere tener una gestión de
políticas centralizada para todas sus unidades de negocio de acuerdo con
los estándares seguidos por la sucursal y el país de cada unidad.
Para adaptarse a los requisitos de este escenario, debe crear un Grupo de
administración para representar la sucursal en cada país y mover las
suscripciones de cada unidad de negocios en esa sucursal para que esté
bajo este grupo de administración. Una vez que tenga esta estructura,
puede asignar la política del Centro de seguridad al nivel del grupo de
administración. Sería similar al diagrama que se muestra en la Figura 3-
35 .
Figura 3-35 Estructura de gestión centralizada

Para realizar cambios en la iniciativa Security Center, debe tener
privilegios de rol de administrador de seguridad. También puede realizar
cambios si es el propietario de la suscripción. Tanto Colaborador como
Lector tienen acceso a todas las operaciones de Azure Policy en las que se
requiere acceso de lectura. Los colaboradores pueden activar la
remediación de recursos, pero no pueden crear definiciones o
asignaciones. Utilizando el escenario descrito anteriormente en el que se
requerían varias unidades de negocio, si desea restringir a los usuarios en
cada unidad de negocio para que solo puedan ver (operación de solo
lectura) las políticas, puede asignarlas al rol de lector de seguridad.
Dado que las recomendaciones de seguridad en Security Center se
derivan de la directiva de Azure, es posible que tenga una situación en la
que necesite personalizar la directiva para que el efecto predeterminado
sea Deshabilitado . Considere un escenario en el que Fabrikam está
utilizando una solución de protección de endpoints que no es compatible
con Security Center. Fabrikam sigue recibiendo la recomendación de
seguridad Instalar Endpoint Protection Solution en máquinas
virtuales . Fabrikam entiende que esta recomendación es un falso
positivo para su entorno porque Fabrikam tiene instalada una protección
de punto final. Sin embargo, debido a que Security Center no lo admite,
esta recomendación se sigue activando. En este escenario, Fabrikam
puede cambiar el efecto predeterminado a Desactivado. Utilice los
siguientes pasos para configurar este cambio en Security Center:
3. En el panel principal de Security Center, en la sección Política y
cumplimiento , haga clic en Política de seguridad .
4. Haga clic en la suscripción para la que desea cambiar la política.
5. En la página Política de seguridad , haga clic en el botón Ver
política efectiva , como se muestra en la Figura 3-36 .
Figura 3-36 Visualización de la política de seguridad en Security

Center
6. En la siguiente página de Política de seguridad que aparece, verá
todas las políticas que están actualmente en uso. Esta página es
principalmente para fines de solo lectura; si necesita realizar
cambios en la política, haga clic en el enlace [Vista previa]:
Habilitar supervisión en el Centro de seguridad de Azure para
la política, como se muestra en la Figura 3-37 .
Figura 3-37 Acceso a la política predeterminada
7. En la página siguiente, haga clic en la pestaña Parámetros , como se
Figura 3-38 Acceso a la política predeterminada

8. En esta pestaña hay una lista de parámetros para esta iniciativa,
que representa las recomendaciones del Centro de seguridad. El
objetivo, en este caso, es deshabilitar la recomendación de
protección de punto final que falta. Haga clic en el menú
desplegable Monitor Missing Endpoint Protection en Azure
Security Center y seleccione Deshabilitado .
9. Haga clic en el botón Revisar + Guardar y luego haga clic en
el botón Guardar para confirmar los cambios.
Asegúrese de documentar los cambios que realizó en la iniciativa
predeterminada del Centro de seguridad, específicamente con respecto a
las políticas que se han deshabilitado. Documente la justificación detrás
de su razonamiento para deshabilitar la política y quién la deshabilitó.
Configure las políticas de cumplimiento y evalúe

el cumplimiento mediante el uso de Azure
Security Center
Si bien las recomendaciones de Security Center cubrirán las mejores
prácticas de seguridad para diferentes cargas de trabajo en Azure, hay
algunas organizaciones que también deben cumplir con diferentes
estándares de la industria. El nivel Estándar de Security Center ayuda a
simplificar el proceso para cumplir con los requisitos de cumplimiento
normativo mediante el uso del panel de Cumplimiento normativo.
La vista del panel de Cumplimiento normativo puede ayudarlo a centrar
sus esfuerzos en las brechas en el cumplimiento de un estándar o
regulación que sea relevante para su organización. De forma
predeterminada, Security Center proporciona compatibilidad con los
siguientes estándares normativos: Azure CIS, PCI DSS 3.2, ISO 27001 y
SOC TSP. Utilice los siguientes pasos para acceder al panel
de Cumplimiento normativo :
3. En el panel principal de Security Center, en la sección Política y
cumplimiento , haga clic en Cumplimiento
normativo ; el cumplimiento de normativas aparece tablero de
instrumentos, como se muestra en la figura 3-39 .
Figura 3-39 Panel de cumplimiento de normativas
La parte superior del tablero muestra un breve resumen del estado de la
evaluación y el estado individual del cumplimiento de cada estándar
regulatorio. En la segunda parte del tablero hay cuatro pestañas. La
selección de pestaña predeterminada es Azure CIS 1.1. Los otros son PCI
DSS 3.2, ISO 27001 y SOC TSP. Puede navegar por los elementos para ver
cuáles necesitan atención (se muestran en rojo) y cuáles aprobaron con
éxito la evaluación (se muestran en verde). Además, observe que algunos
controles no están disponibles. Estos controles no tienen evaluaciones de
Security Center asociadas y no se requiere ninguna acción adicional.
Para mejorar su estado de cumplimiento, debe seguir el mismo enfoque
que utilizó para las recomendaciones de seguridad. En otras palabras,
debe corregir la evaluación para cumplir con los requisitos. Las
evaluaciones se actualizan aproximadamente cada 12 horas, por lo que si
corrige una evaluación, solo verá el efecto en sus datos de cumplimiento
después de la ejecución de las evaluaciones.
En algunos escenarios, la organización deberá cumplir con diferentes
estándares de la industria. Microsoft revisa constantemente nuevos
estándares y los pone a disposición en la plataforma Azure, lo que
significa que, además de los estándares de la industria que vienen de
fábrica en Security Center, puede agregar NIST SP 800-53 R4, SWIFT CSP
CSCF-v2020, Oficial del Reino Unido y NHS del Reino Unido, PBMM
federal de Canadá y Azure CIS 1.1.0 (nuevo): una versión actualizada de
Azure CIS 1.1.0.
Para agregar un nuevo estándar de cumplimiento, debe ser el propietario
de la suscripción o el contribuyente de la política. Suponiendo que tiene el
privilegio correcto, puede simplemente hacer clic en el
botón Administrar políticas de cumplimiento en el panel
de Cumplimiento normativo y luego, en la página Política de seguridad,
hacer clic en la suscripción a la que desea agregar el estándar. En la
página resultante, haga clic en el botón Agregar más estándares , como
Figura 3-40 Adición de más estándares al panel de Cumplimiento

normativo
Después de hacer clic en el botón Agregar más estándares , tendrá la
opción de hacer clic en el botón Agregar para cada nuevo estándar de la
industria disponible en la lista, como se muestra en la Figura 3-41 .
Figura 3-41 Estándares de cumplimiento normativo disponibles
Los estándares importantes no se pueden eliminar
No puede eliminar los estándares de la industria listos para usar del panel de
control; solo puede agregar más estándares al tablero.
Una vez que agregue el nuevo estándar, se creará una nueva pestaña en el
panel principal de Cumplimiento normativo. Hay algunos escenarios en
los que es posible que deba enviar un informe resumido de su estado de
cumplimiento normativo a alguien. Si necesita hacer esto, puede usar
el botón Descargar informe en el panel principal de Cumplimiento
normativo .
HABILIDAD 3.3: SUPERVISAR LA

SEGURIDAD MEDIANTE AZURE SENTINEL
Azure Sentinel es una solución de Microsoft Security Information and
Event Management (SIEM) y Security Orchestration, Automation, and
Response (SOAR). Puede usar esta solución para ingerir datos de
diferentes fuentes de datos, crear alertas personalizadas, monitorear
incidentes y responder a alertas. Esta sección del capítulo cubre las
habilidades necesarias para configurar la seguridad del contenedor de
acuerdo con el esquema del Examen AZ-500.
Introducción a la arquitectura de Azure Sentinel

Para ayudarlo a comprender mejor la arquitectura de Azure Sentinel,
primero debe comprender los diferentes componentes de la solución. Los
principales componentes de Azure Sentinel se muestran en un diagrama
en la Figura 3-42 .
Figura 3-42 Componentes principales de Azure Sentinel

Los componentes que se muestran en la Figura 3-42 se presentan con
más detalle en la siguiente lista:
• Paneles de control Los paneles de control integrados
proporcionan visualización de datos para sus fuentes de datos
conectadas, lo que le permite profundizar en los eventos generados
en esos servicios.
• Casos Una suma de todas las pruebas relevantes para una
investigación específica. Puede contener una o varias alertas, que
se basan en los análisis que defina.
• Hunting Una herramienta poderosa para investigadores y
análisis de seguridad que necesitan buscar amenazas de seguridad
de forma proactiva. La capacidad de búsqueda está impulsada por
Kusto Query Language (KQL).
• Portátiles Al integrarse con los cuadernos de Jupyter, Azure
Sentinel amplía el alcance de lo que puede hacer con los datos
recopilados. Combina la capacidad de programación completa con
una colección de bibliotecas para el aprendizaje automático, la
visualización y el análisis de datos.
• Conectores de datos Hay conectores integrados disponibles
para facilitar la ingestión de datos de Microsoft y las soluciones de
sus socios.
• Playbook Una colección de procedimientos que se pueden
ejecutar automáticamente ante una alerta que es activada por
Azure Sentinel. Los Playbooks aprovechan Azure Logic Apps, que lo
ayudan a automatizar y orquestar tareas y flujos de trabajo.
• Analytics Le permite crear alertas personalizadas utilizando
Kusto Query Language (KQL).
• Comunidad La página de la comunidad de Azure Sentinel se
encuentra en GitHub ( https://aka.ms/ASICommunity ) y contiene
detecciones basadas en diferentes tipos de fuentes de datos que
puede aprovechar para crear alertas y responder a amenazas en su
entorno. También contiene ejemplos de consultas de caza, libros de
jugadas y otros artefactos.
• Espacio de trabajo Esencialmente, un espacio de trabajo de
Log Analytics es un contenedor que incluye datos e información de
configuración. Azure Sentinel usa este contenedor para almacenar
los datos que recopila de los diferentes orígenes de datos.
En las secciones siguientes se asume que ya tiene un área de trabajo
configurada para usar con Azure Sentinel.
Sentinel importante no está cubierto en profundidad
Este libro no cubre completamente Azure Sentinel; solo cubre los temas que son
relevantes para el examen AZ-500. Para obtener más información, consulte Microsoft
Azure Sentinel: planificación e implementación de la solución SIEM nativa de la nube
de Microsoft , publicado por Microsoft Press.
Configurar fuentes de datos en Azure Sentinel

El primer paso para configurar una solución SIEM como Azure Sentinel es
asegurarse de que se ingieran los datos relevantes para sus
requisitos. Por ejemplo, si necesita recopilar datos relacionados con las
políticas de acceso condicional y los detalles relacionados con la
autenticación heredada mediante registros de inicio de sesión, debe
configurar el conector de Azure Active Directory (AD). Azure Sentinel
viene con una variedad de conectores que le permiten comenzar a ingerir
datos de esas fuentes de datos con solo un par de clics. Tenga en cuenta
que debe tener esos servicios habilitados para comenzar a ingerir datos
mediante estos conectores. Utilice la Tabla 3-1 para identificar algunos
escenarios de casos de uso y para determinar qué conector está
disponible para cada escenario:
Tabla 3-1 Conectores de Azure Sentinel y escenarios de casos de uso
Guión Co
Necesita obtener información sobre el uso de la aplicación; políticas de acceso Az

condicional; detalles relacionados con la autenticación heredada; y actividades
como la gestión de usuarios, grupos, roles y aplicaciones.
Debe obtener detalles de operaciones como descargas de archivos, solicitudes de Of

acceso enviadas y cambios en eventos de grupo, y debe configurar el buzón y los
detalles del usuario que realizó las acciones.
Necesita obtener visibilidad de sus aplicaciones en la nube; obtener análisis Se

sofisticados para identificar y combatir las ciberamenazas; y controle cómo viajan ap
sus datos. nu
Necesita obtener información sobre los eventos de nivel de suscripción que Ac

ocurren en Azure, incluidos los eventos de los datos operativos de Azure Resource
Manager; eventos de salud del servicio; escribir operaciones tomadas en los
recursos en su suscripción; y el estado de las actividades realizadas en Azure.
Necesita obtener visibilidad sobre los usuarios en riesgo, los eventos de riesgo y Pr
las vulnerabilidades. ide
AD
Necesita conocer su estado de seguridad en las cargas de trabajo de la nube Ce

híbrida; reduzca su exposición a los ataques; y responder rápidamente a las de
amenazas detectadas.
Los conectores que se muestran en esta tabla se consideran integraciones
de servicio a servicio. Además, hay conectores para soluciones externas
que utilizan API y otros que pueden realizar la transmisión de registros
en tiempo real utilizando el protocolo Syslog a través de un agente. A
continuación, se muestran algunos ejemplos de conectores externos (que
no son de Microsoft) que utilizan agentes:
• Punto de control
• Cisco ASA
• Soluciones DLP
• Máquinas DNS: agente instalado directamente en la máquina
DNS
• Revelación de ExtraHop (x)
• F5
• Productos Forcepoint
• Fortinet
• Servidores Linux
• Palo Alto Networks
• Una salvaguarda de identidad
• Otros electrodomésticos CEF
• Otros dispositivos Syslog
• Trend Micro Deep Security
• Zscaler
Para configurar los conectores de datos, necesitará el nivel de privilegio
adecuado. Los roles necesarios para cada conector se determinan por tipo
de conector. Por ejemplo, para configurar el conector de Azure AD,
necesitará los siguientes permisos:
• Espacio de trabajo Se requieren permisos de lectura y
escritura.
• Configuración de diagnóstico Se requieren permisos de
lectura y escritura para la configuración de diagnóstico de AAD.
• Permisos de inquilino Se requieren roles de administrador
global o administrador de seguridad en el inquilino del espacio de
trabajo.
Nota Registros de Azure AD
Para ingerir registros de Azure AD en el área de trabajo de Azure Sentinel, también
necesitará una licencia de Azure AD P1 / P2.
Si bien este conector tiene una lista decente de requisitos de permisos,
algunos otros serán más simples. Por ejemplo, para configurar el conector
de actividad de Azure, solo necesita permisos de lectura y escritura en el
área de trabajo. Los requisitos para cada conector estarán disponibles en
la página del conector en Azure Sentinel.
Para este escenario inicial, digamos que Fabrikam quiere asegurarse de
que todos los eventos de los datos operativos de Azure Resource
Manager; eventos de salud del servicio; operaciones de escritura tomadas
en los recursos de suscripción de Fabrikam; y el estado de las actividades
realizadas en Azure se ingiere en Azure Sentinel. Para lograrlo, debe
configurar el conector de actividad de Azure. Sigue estos pasos:
2. En la barra de búsqueda, escriba centinela y, en Servicios , haga
clic en Azure Sentinel .
3. En la página de áreas de trabajo de Azure Sentinel, haga clic en el
área de trabajo que desea usar con Azure Sentinel; el Azure
Sentinel | Aparece la página de descripción general (consulte
la Figura 3-43 ).
Figura 3-43 Página de descripción general de Azure Sentinel

Importante panel de Azure Sentinel
Si es la primera vez que inicia Azure Sentinel después de configurar el área de
trabajo, su panel no tendrá ningún dato porque la recopilación de datos aún no
está configurada.

en Conectores de datos .
5. En la página Conectores de datos , haga clic en Actividad de
Azure .
6. En la hoja Actividad de Azure , haga clic en el botón Abrir página
de conector , como se muestra en la figura 3-44 .
Figura 3-44 Hoja de actividad de Azure
7. En la página Actividad de Azure , haga clic en
el vínculo Configurar registros de actividad de Azure , como se
Figura 3-45 Configuración del conector de datos de actividad de
Azure
8. En la hoja Registro de actividad de Azure , haga clic en la
suscripción que desea conectar y, en la hoja Suscripción que
aparece, haga clic en el botón Conectar , como se muestra en
la Figura 3-46 .
Figura 3-46 Hoja de suscripción

9. Una vez que termine de conectarse, haga clic en
el botón Actualizar para actualizar el estado del botón. Verá que
ahora el botón Desconectar está disponible.
10. Cierre la hoja Suscripción , cierre la hoja Registro de
actividad de Azure y cierre la página del conector de actividad de
Azure .
11. Cuando regrese a Azure Sentinel | Página Conectores de
datos , asegúrese de hacer clic en el botón Actualizar para
actualizar el estado del conector de datos de actividad de Azure.
Los pasos principales para configurar los conectores de datos de Azure
Sentinel son muy similares, aunque, según el conector, es posible que
deba ejecutar más pasos. Esto es cierto principalmente para los
conectores y servicios externos en diferentes proveedores de nube. Por
ejemplo, si necesita conectarse a Amazon AWS para transmitir todos los
eventos de AWS CloudTrail, deberá realizar algunos pasos en la cuenta de
AWS.

Una vez que las diferentes fuentes de datos están conectadas a Azure
Sentinel, puede crear alertas personalizadas, que se denominan
Análisis. Hay dos tipos de análisis que se pueden crear: una regla de
consulta programada y una regla de creación de incidentes de
Microsoft. Una regla de consulta programada le permite personalizar
completamente los parámetros de la alerta, incluida la lógica de la regla y
el umbral de alerta. Una regla de creación de incidentes de Microsoft le
permite crear automáticamente un incidente en Azure Sentinel parauna
alerta que fue generada por un servicio conectado. Este tipo de regla está
disponible para alertas generadas por Azure Security Center, Azure
Security Center for IoT, Microsoft Defender Advanced Threat Protection,
Azure AD Identity Protection, Microsoft Cloud App Security y Azure
Advanced Threat Protection.
Al considerar cuál necesita utilizar, asegúrese de comprender los
requisitos previos para el escenario porque esos requisitos determinarán
el tipo de regla que debe crear. Por ejemplo, si el requisito es personalizar
la alerta con parámetros que determinarán la programación de la
consulta y el umbral de alerta, entonces la mejor opción es la regla de
consulta programada. Para este escenario, Fabrikam desea crear una
alerta de gravedad media cada vez que se elimina una máquina virtual y
se debe crear un incidente para una mayor investigación. Siga estos pasos
para crear una regla de consulta programada:
Sentinel | Aparece la página de descripción general .
en Análisis .
5. Haga clic en el botón Crear y seleccione la opción Regla de
consulta programada . El asistente de la regla analítica - Crear
nueva regla aparece la página, como se muestra en la figura 3-47 .
Figura 3-47 Página Crear nueva regla
6. En el campo Nombre , escriba un nombre para esta analítica.
7. Opcionalmente, puede escribir una descripción completa para esta
analítica y seleccionar la táctica. El menú
desplegable Tácticas contiene una lista de las diferentes fases
disponibles en la cadena de muerte cibernética. Debe seleccionar la
fase adecuada para el tipo de alerta que desea crear; para este
ejemplo, seleccione Impacto .
8. El menú desplegable Severidad contiene una lista de todos los
niveles de criticidad disponibles para la alerta. Para este ejemplo,
déjelo configurado en Medio .
9. Debido a que desea activar la regla después de crearla, deje
el Estado configurado en Habilitado .
10. Haga clic en el botón Siguiente: Establecer lógica de
regla ; el conjunto de reglas de lógica aparece pestaña, como se
Figura 3-48 Configuración de la lógica de la regla

11. En el campo Consulta de regla , debe escribir la consulta
KQL. Debido a que Fabrikam desea recibir una alerta cuando se
eliminan las VM, escriba la siguiente consulta de muestra:
AzureActivity
| donde OperationNameValue contiene "Microsoft.Compute /

virtualMachines / delete"
12. En algunos escenarios, es posible que deba personalizar

las opciones de Entidades del mapa para permitir que Azure
Sentinel reconozca las entidades que forman parte de las alertas
para un análisis más detallado. Para este escenario, puede dejar la
configuración predeterminada.
13. En Programación de consultas , la primera opción es
personalizar la frecuencia con la que desea ejecutar esta
consulta. Debido a que este escenario no tiene una frecuencia
definida específicamente, déjelo configurado para que se ejecute
cada 5 horas.
14. A continuación, puede personalizar la línea de tiempo en la
que desea ejecutar esta consulta, en la opción Buscar datos desde
el último . De forma predeterminada, la consulta se ejecutará en
función de las últimas 5 horas de datos recopilados. Dado que en
este escenario no se especificó específicamente, déjelo como está.
15. En Umbral de alerta , tiene el menú desplegable Generar
alerta cuando el número de resultados de la consulta . Debido a
que este escenario requiere que se genere una alerta cada vez que
se elimina una máquina virtual, debe dejar esta configuración en la
configuración predeterminada, Es mayor que 0 .
16. En Supresión , puede optar por detener la consulta después
de que se genere la alerta. En este escenario, deje la selección
predeterminada, que es Desactivada .
17. Haga clic en el botón Siguiente: Configuración de
incidentes (vista previa) ; la Configuración de
incidentes aparece pestaña, como se muestra en la figura 3-49 .
Figura 3-49 Configuración de la configuración de incidentes
18. Deje seleccionada la opción Crear incidentes a partir de
alertas activadas por esta regla de análisis (que es la
configuración predeterminada) porque el escenario requiere la
creación de un incidente.
19. En Agrupación de alertas , puede configurar cómo se
agrupan en incidentes las alertas activadas por esta regla de
análisis. Para este escenario, deje la selección predeterminada, que
es Desactivada .
20. Haga clic en el botón Siguiente: Respuesta
automática ; la Tab de Respuestas Automáticas aparece, como se
Figura 3-50 Configuración de una respuesta automatizada

21. La pestaña Respuesta de automatización contiene una lista
de todas las aplicaciones lógicas de Azure disponibles. En una nueva
implementación, es común ver una pestaña vacía porque no habrá
aplicaciones lógicas disponibles. Aprenderá más sobre las
respuestas automáticas en la siguiente sección de este capítulo.
22. Haga clic en el botón Siguiente: Revisar , revise las opciones
y haga clic en el botón Crear .
23. Una vez creada la regla, volverá a Azure Sentinel | Página
de análisis ; la regla aparece en la lista Reglas activas . Si hace clic
en él, verá los parámetros de la regla, como se muestra en la Figura
3-51 .
Figura 3-51 Alerta personalizada después de la creación
Si bien esta regla se creó específicamente para un escenario en particular,
puede utilizar las plantillas existentes, que se encuentran en
la pestaña Plantillas de reglas en la página principal de Azure Sentinel
| Página de análisis . Puede crear un tipo de regla programada en función
de diferentes tipos de ataques conocidos. Por ejemplo, si tiene un
escenario en el que necesita detectar intentos de descifrado de
contraseñas distribuidas en Azure AD, puede simplemente crear una regla
basada en la plantilla disponible, como se muestra en la Figura 3-52 .
Figura 3-52 Creación de una alerta basada en una plantilla

Existen otros escenarios en los que es posible que deba simplemente
crear un incidente en Azure Sentinel en función de una alerta
desencadenada por un servicio conectado. Por ejemplo, es posible que
desee crear un incidente cada vez que se active una alerta desde Azure
Security Center. Los pasos iniciales son los mismos. La diferencia es que
en el paso 5 de las instrucciones anteriores, seleccionaría la regla
de creación de incidentes de Microsoft . Cuando se selecciona esta
opción, verá la página Crear nueva regla del Asistente para reglas
analíticas , como se muestra en la Figura 3-53 .
Figura 3-53 Creación de una alerta basada en un servicio conectado
En el menú desplegable Servicio de seguridad de Microsoft , puede
seleccionar el servicio conectado que desea usar como fuente de
datos. Por ejemplo, si selecciona Azure Security Center de la lista y no
personaliza las alertas incluidas o excluidas, Azure Sentinel creará un
incidente para todas las alertas activadas por Azure Security Center.
Configurar una guía para un evento de seguridad

con Azure Sentinel
Los manuales de seguridad le permiten crear una colección de
procedimientos que se pueden ejecutar desde Azure Sentinel cuando se
activa una determinada alerta de seguridad. Azure Logic Apps es el
mecanismo de automatización detrás de los Playbooks de
seguridad. Antes de crear un libro de jugadas, debe tener en cuenta lo que
desea automatizar. Antes de comenzar a configurar un libro de jugadas,
asegúrese de responder al menos las siguientes preguntas:
• ¿Para qué alerta debo automatizar una respuesta?
• ¿Qué pasos deben automatizarse si se cumplen las
condiciones para esta alerta?
• ¿Qué pasos deben automatizarse si las condiciones para esta
alerta son falsas?
Tenga en cuenta que se aplican cargos adicionales
Los libros de jugadas aprovechan Azure Logic Apps, por lo que se aplican cargos
además de los precios de Azure Sentinel.
Puede utilizar la función Colaborador de la aplicación lógica o la función

Operador de la aplicación lógica para asignar un permiso explícito para
usar Playbooks. Para crear una guía, necesitará privilegios de
Colaborador de Azure Sentinel y Colaborador de aplicaciones
lógicas. Para este escenario, Contoso desea enviar un correo electrónico a
una lista de distribución que alerta a los destinatarios si se ha eliminado
una máquina virtual. Siga estos pasos para crear un libro de jugadas que
se utilizará para esta automatización:
Sentinel | Aparece la página de descripción general .
en Playbooks .
5. Haga clic en el botón Agregar libro de jugadas; la lógica de la
aplicación aparece la página, como se muestra en la figura 3-54 .
Figura 3-54 Configuración de una aplicación lógica

6. Seleccione la suscripción y el grupo de recursos donde se ubicará la
aplicación lógica.
7. En el campo Nombre de la aplicación lógica , escriba un nombre
para esta automatización.
8. En el campo Ubicación , seleccione la ubicación de Azure donde
residirá esta aplicación lógica.
9. Opcionalmente, puede enviar los eventos de tiempo de ejecución de
la aplicación lógica a un espacio de trabajo de Log Analytics. Para
este escenario, deje la selección predeterminada y haga clic en el
botón Revisar + Crear .
10. En la pestaña Revisar + Crear , haga clic en el botón Crear .
11. Haga clic en el botón Ir a recurso para abrir la página
del Diseñador de aplicaciones lógicas .
12. En Plantillas , haga clic en el mosaico Aplicación lógica en
blanco .
13. En el campo Buscar conectores y activadores ,
escriba Azure Sentinel y seleccione Cuando se activa una
respuesta a una alerta de Azure Sentinel .
Activadores importantes de aplicaciones lógicas
Aunque Logic Apps tiene muchos desencadenantes, solo se pueden usar
desencadenadores específicos del producto de Azure Sentinel al crear su
Playbook.
14. Haga clic en el botón Nuevo paso ; aparece una lista de

acciones, como se muestra en la Figura 3-55 .
Figura 3-55 Elección de la acción inicial a ejecutar
15. En el campo Buscar conectores y acciones , escriba correo
electrónico y seleccione Office 365 .
16. Seleccione Enviar un correo electrónico (v2) ; aparecerán
las opciones que se muestran en la Figura 3-56 .
Figura 3-56 Ingresar las opciones de correo electrónico
17. Ingrese los parámetros Para y Asunto para este correo
electrónico.
18. Haga clic en el campo Cuerpo y haga clic en Agregar
contenido dinámico ; aparece un menú flotante que contiene las
opciones para agregar contenido dinámico, como se muestra en
la Figura 3-57 .
Figura 3-57 Opciones de contenido dinámico
19. Puede seleccionar cualquier contenido dinámico que desee
agregar al cuerpo del correo electrónico. Esto ayuda a enriquecer el
contenido del correo electrónico agregando información
relacionada con las alertas. Por ejemplo, puede ingresar Severidad
de alerta: y agregar el campo Severidad del contenido dinámico
junto al texto.
20. Una vez que termine de agregar el contenido dinámico, haga
clic en el botón Guardar .
21. Cierre el Diseñador de aplicaciones lógicas.
22. Abra Azure Sentinel nuevamente y haga clic en Analytics .
23. Haga clic en la regla analítica que creó y, en el lado derecho,
haga clic en el botón Editar .
24. Haga clic en la pestaña Respuesta automática y observe que
la aplicación lógica que creó aparece en la lista, como se muestra en
la Figura 3-58 .
Figura 3-58 Selección del libro de jugadas para una regla existente
25. Seleccione la Guía que creó y haga clic en el botón Siguiente:
Revisar> .
Evaluar los resultados de Azure Sentinel

Además del panel de información general principal disponible en Azure
Sentinel que ofrece gráficos y un resumen de cómo se producen los
eventos y las alertas, también puede realizar consultas directas en el área
de trabajo de Log Analytics o visualizar los datos recopilados mediante
Workbooks. Si necesita visualizar rápidamente los eventos de seguridad,
solo necesita hacer clic en la opción SecurityEvent en
el mosaico Eventos y alertas a lo largo del tiempo ; aparece el espacio
de trabajo de Log Analytics con el resultado de la consulta, como se
Figura 3-59 Eventos de seguridad
Al acceder a la información directamente desde el espacio de trabajo de
Log Analytics, puede aprovechar la búsqueda KQL para explorar más la
información que está tratando de encontrar. Este tipo de enfoque para
consultar datos libremente utilizando el espacio de trabajo de Log
Analytics se usa más en escenarios de investigación (reactivo).
Importante No hay investigación automatizada en Sentinel
Aunque Azure Sentinel tiene capacidades de investigación, no tiene investigación
automatizada. Esta característica solo está disponible en Microsoft Defender
Advanced Threat Protection (ATP).
Para escenarios más proactivos, una opción es usar Azure

Workbooks. Los libros de trabajo de Azure Sentinel proporcionan
informes interactivos que se pueden usar para visualizar sus datos de
seguridad y cumplimiento. Los libros de trabajo combinan texto,
consultas y parámetros para facilitar a los desarrolladores la creación de
visualizaciones maduras, filtrado avanzado, capacidades de desglose,
navegación avanzada en el tablero y más. Para aprovechar una plantilla
de libro de trabajo específica, debe tener al menos permisos de Lector de
libro o Colaborador de libro en el grupo de recursos del área de trabajo de
Azure Sentinel.
Usar un libro de trabajo es una excelente opción para monitorear
escenarios en los que necesita visualización de datos a través de un
tablero con análisis específicos para cada fuente de datos. Otro escenario
de caso de uso es cuando desea crear su panel de control personalizado
con datos que provienen de múltiples fuentes de datos.
Por ejemplo, si necesita evaluar los datos del registro de actividad de
Azure que se están ingiriendo en Azure Sentinel mediante el conector
de actividad de Azure , puede usar el libro de actividad de Azure . En el
panel principal de Azure Sentinel, en Administración de amenazas ,
haga clic en Libros de trabajo . A continuación, haga clic en
la opción Actividad de Azure y haga clic en el botón Ver plantilla a la
derecha; Aparece el Libro de actividades de Azure, como se muestra en
la Figura 3-60 .
Figura 3-60 Eventos de seguridad

Aprovechar la opción correcta para evaluar los resultados en Azure
Sentinel puede ayudarlo a ahorrar tiempo en la identificación de la
información relevante.
Incidentes
Otra forma de evaluar los resultados en Azure Sentinel es observar los
incidentes. Cuando se crea un incidente en función de una alerta que se
activó, puede revisar este incidente en el panel de control y puede
remediar el incidente utilizando un libro de jugadas que creó
anteriormente. Además, puede investigar el incidente.
Para acceder al panel de incidentes, haga clic en Incidentes en
la sección Administración de amenazas en la página principal de Azure
Sentinel. La Figura 3-61 muestra un ejemplo de un incidente que se creó
en función de la alerta que creó anteriormente en este capítulo.
Figura 3-61 Visualización de un incidente en Azure Sentinel

Cuando se selecciona un incidente, verá un resumen de los detalles del
incidente en el panel derecho. A medida que clasifica el incidente, puede
cambiar la gravedad del incidente, el estado del incidente (por ejemplo,
cambiar a Activo , si es una investigación en curso) y asignar el incidente
a un propietario. (De forma predeterminada, el propietario se muestra
como Sin asignar ). Para ver más detalles sobre el incidente, haga clic en
el botón Ver detalles completos . La Figura 3-62 muestra un ejemplo de
un incidente completo.
Figura 3-62 Un incidente completo
Dependiendo de los artefactos que estén disponibles sobre el incidente,
también tendrá acceso al panel de Investigación. Observe que en la Figura
3-62 , el botón Investigar está desactivado porque no hay nada más que
investigar sobre este incidente. (Eliminar una alerta es una sola acción).
Caza de amenazas
La búsqueda de amenazas es el proceso de búsqueda iterativa a través de
una variedad de datos con el objetivo de identificar amenazas en los
sistemas. La caza de amenazas implica crear hipótesis sobre el
comportamiento de los atacantes e investigar las hipótesis y técnicas que
se utilizaron para determinar los artefactos que quedaron atrás.
En un escenario en el que un administrador de Contoso desea revisar de
forma proactiva los datos recopilados por Azure Sentinel para identificar
indicios de un ataque, la capacidad de búsqueda de amenazas es la forma
recomendada de realizar esta tarea. La búsqueda de amenazas proactiva
puede ayudar a identificar comportamientos de amenazas sofisticados
utilizados por los actores de amenazas, incluso cuando aún se encuentran
en las primeras etapas del ataque. Para acceder al panel
de Threat Hunting , haga clic en Hunting en la sección Threat
Management de la página principal de Azure Sentinel. La Figura 3-
63 muestra un ejemplo de este tablero.
Figura 3-63 Capacidad de búsqueda en Azure Sentinel
Para comenzar a buscar, solo necesita seleccionar la consulta predefinida,
que se creó para un escenario específico, y hacer clic en el botón Ejecutar
consulta en el panel de la derecha. Este panel muestra un resumen de los
resultados. Haga clic en el botón Ver resultados para ver los detalles
completos de la consulta.
HABILIDAD 3.4: CONFIGURAR POLÍTICAS

DE SEGURIDAD
Si bien el monitoreo de la seguridad es fundamental para cualquier
organización que desee continuar mejorando su postura de seguridad, la
gobernanza es fundamental para cualquier organización que desee
establecer estándares de implementación y garantizar que la seguridad se
aplique al comienzo de la canalización de implementación. Esta sección
del capítulo cubre las habilidades necesarias para configurar los ajustes
de seguridad mediante Azure Policy y Azure Blueprint de acuerdo con el
esquema del Examen AZ-500.
Configure las opciones de seguridad mediante
Azure Policy
El primer paso para lograr la gobernanza en Azure es asegurarse de que
está aprovechando Azure Policy para la aplicación de políticas. También
puede hacer cumplir la soberanía y la residencia de datos mediante Azure
Policy. Por ejemplo, si necesita exigir que todos los recursos nuevos se
creen para usar una región específica, usará Azure Policy para hacer
cumplir eso. Como se mencionó anteriormente en este capítulo, desde la
perspectiva de la administración centralizada, siempre se recomienda que
asigne una política a un grupo de administración y mueva las
suscripciones que desea heredar esa política a ese grupo de
administración.
Hay muchos roles integrados que otorgan permiso a los recursos de
Azure Policy. Puede usar el rol Colaborador de políticas de recursos, que
incluye la mayoría de las operaciones de Azure Policy. El rol de
propietario tiene todos los derechos para realizar todas las acciones y los
roles de colaborador y lector tienen acceso a todas las operaciones de
lectura de la directiva de Azure. Puede utilizar la función Colaborador
para activar la corrección de recursos, pero no puede utilizarla para crear
definiciones o asignaciones.
Cuando esté aplicando políticas, debe asegurarse de que su iniciativa de
política esté utilizando el tipo de efecto correcto. Si el requisito del
escenario es que evite que se aprovisionen determinadas cargas de
trabajo si no se establecen determinados atributos, el efecto de su política
debería ser Denegar . El atributo Denegar se utiliza para evitar una
solicitud de recurso que no coincide con los estándares definidos a través
de una definición de política y falla la solicitud.
Si el requisito de su escenario es cambiar los parámetros si no se
establecieron durante el tiempo de provisión, entonces el efecto de su
política debería serlo DeployIfNotExists. Por ejemplo, si un administrador
de Contoso desea implementar Azure Network Watcher cuando se crea
una red virtual, el administrador debe aplicar el DeployIfNotExistsefecto
para esa política. DeployIfNotExistsse ejecuta aproximadamente 15
minutos después de que un proveedor de recursos haya manejado una
solicitud de creación o actualización de recursosy ha devuelto un código
de estado de éxito. Cuando configura una política con este tipo de efecto,
también crea una tarea de remediación, y el objetivo de esta tarea de
remediación es configurar el recurso con el parámetro que desee.
Otro escenario común es actualizar etiquetas en un recurso durante la
creación o actualización. Por ejemplo, el administrador de Contoso debe
actualizar el centro de costos de todos los recursos durante el tiempo de
creación. Para este escenario necesitas usar el Modifyefecto. Al igual que
el DeployIfNotExistsefecto, también debe configurar una tarea de
corrección para ejecutar el cambio deseado. Tenga en cuenta que cuando
cree esta tarea de corrección para ambos efectos, deberá marcar
la opción Crear una identidad administrada . Puede usar la identidad
para autenticarse en cualquier servicio que admita la autenticación de
Azure AD, incluido Key Vault, sin ninguna credencial en su código.
Siga los pasos a continuación para configurar la aplicación de políticas
mediante Azure Policy:
2. En la barra de búsqueda, escriba política y, en Servicios , haga clic
en Política .
3. En la página Política , haga clic en Asignaciones en Creación en el
panel izquierdo. La Figura 3-64 muestra un ejemplo de la página
Asignaciones.
Figura 3-64 Página de asignaciones de políticas

4. Tenga en cuenta que en esta página puede asignar una iniciativa o
una política. Para este ejemplo, haga clic en el botón Asignar
política . La Asignar política aparece la página (ver Figura 3-65 ).
Figura 3-65 Selección de la política para asignar
5. En la pestaña Básicos , tiene la opción de seleccionar el Alcance en
el que se debe asignar esta política. Si su escenario requiere una
administración centralizada, puede cambiarlo aquí para asignarlo a
un grupo de administración. Si el escenario requiere que asigne solo
al nivel de suscripción, deje la selección predeterminada.
6. En el campo Exclusión , puede seleccionar opcionalmente los
recursos que desea excluir de esta política. Por ejemplo, si tiene
ciertos grupos de recursos que deberían estar exentos de esta
política, agregue esos grupos de recursos en esta lista.
7. En el campo Definición de política , haga clic en los puntos
suspensivos para abrir las políticas que están disponibles.
8. En la hoja Definiciones disponibles , se muestra una lista de todas
las definiciones de políticas. Para este ejemplo, escriba SQL en
el campo de búsqueda .
9. Seleccione la política Implementar cifrado de datos
transparente de SQL DB y haga clic en el botón Seleccionar .
10. Tenga en cuenta que los campos Definición de
política y Nombre de la asignación se han completado con el
nombre de la política.
11. Haga clic en la pestaña Parámetros y observe que para esta
política, no hay parámetros ni efectos.
12. Haga clic en la pestaña Remediación para configurar las
opciones adicionales. La Figura 3-66 muestra las opciones
disponibles.
Figura 3-66 Configuración de tareas de reparación
13. Haga clic en la casilla de verificación Crear una tarea de
corrección .
14. La política para remediar menú desplegable selecciona
automáticamente la política que debe utilizarse para la
remediación.
15. Observe que Crear una identidad administrada se
selecciona automáticamente y que también se selecciona
la Ubicación de la identidad administrada .
16. La sección Permiso también muestra automáticamente que la
identidad que se utiliza recibirá el permiso de colaborador de la
base de datos SQL .
17. Haga clic en el botón Revisar + Crear .
Ahora que se han creado la política y la tarea de corrección, tiene todo el
alcance de la aplicación de políticas. Puede supervisar el cumplimiento de
esta directiva mediante el panel de información general en la directiva de
Azure y, a continuación, hacer clic en la directiva para ver más detalles
sobre la asignación. La Figura 3-67 muestra el panel Detalles
de la asignación .
Figura 3-67 Panel de detalles de la asignación

En la Figura 3-67 , observe que el Tipo de efecto es DeployIfNotExists,
aunque no tuvo que configurarlo manualmente. Esto se debe a que esta
política ya está preconfigurada con este efecto únicamente, y si abre el
código JSON para esta política, verá que este efecto está codificado allí.
Configure las opciones de seguridad mediante
Azure Blueprint
Los Blueprints de Azure le permiten definir un conjunto repetible de
recursos de Azure que implementan y cumplen los estándares, patrones y
requisitos de una organización. Es muy importante que comprenda
cuándo utilizar un plano en lugar de una política. Los blueprints se usan
para organizar la implementación de varias plantillas de recursos y otros
artefactos, como asignaciones de roles, asignaciones de políticas,
plantillas de Azure Resource Manager y grupos de recursos.
La principal diferencia entre un plan y una política es que un plan es un
paquete para componer conjuntos de estándares, patrones y requisitos
específicos de enfoque relacionados con la implementación de los
servicios, la seguridad y el diseño de la nube de Azure. Otra característica
del plan es que puede reutilizarlos para mantener la coherencia y el
cumplimiento. Se puede incluir una política en este paquete como un
artefacto para el plano. Ambos se pueden utilizar en escenarios en los que
tiene varias suscripciones y desea mantener la gobernanza. Desde la
perspectiva del ciclo de vida, un plano tiene estas etapas principales:
• Creación de planos En este paso inicial se crea el plano
desde cero (en blanco) o utilizando una muestra.
• Borrador Después de crear un nuevo plano, el estado del
plano cambia a draft, lo que significa que se creó, pero aún no se ha
publicado.
• Publicado Después de finalizar el borrador, puede publicar la
primera versión del plan.
• Asignación Una vez publicado un plano, puede asignarlo a su
suscripción.
• Revisiones Puede cambiar las versiones de los planos, lo que
le permite mantener su plano actualizado.
• Eliminación Si ya no necesita un plano, puede eliminar la
asignación y luego eliminar el plano.
Puede crear un nuevo plano basado en los requisitos de su escenario, o
puede crear uno basado en las muestras existentes disponibles. Siga estos
pasos para crear un nuevo plano y publicarlo:
2. En la barra de búsqueda, escriba blueprint y, en Servicios , haga
clic en Blueprints .
3. Sobre los planos | En la página de Inicio , haga clic en
el botón Crear en la sección Crear un plano . El Crear
Blueprint aparece la página, como se muestra en la figura 3-68 .
Figura 3-68 Crear plano

4. Haga clic en la opción Comenzar con plano en blanco ; Aparece la
pantalla que se muestra en la Figura 3-69 .
Figura 3-69 Creación de un nuevo plano en blanco
5. En el campo Blueprint Name , escriba el nombre del blueprint.
6. Haga clic en los puntos suspensivos en la opción Ubicación de
definición y seleccione la suscripción que desea utilizar para este
plan.
7. Haga clic en el botón Siguiente: Artefactos .
8. En la pestaña Artefactos , haga clic en el botón + Agregar
artefacto .
9. En la hoja Agregar artefacto , seleccione Asignación de
políticas en el menú desplegable Tipo de artefacto .
10. En la pestaña Definiciones de políticas ,
seleccione Implementar agente de Log Analytics para máquinas
virtuales Windows y haga clic en el botón Agregar .
11. Vuelva a hacer clic en Agregar artefacto y
seleccione Asignación de funciones .
12. En el menú desplegable Rol , seleccione Colaborador y haga
clic en el botón Agregar .
13. Haga clic en el botón Guardar: borrador .
14. En el panel principal de Blueprint , haga clic en
el botón Aplicar en la sección Aplicar a un alcance .
15. En la opción Alcance , haga clic en los puntos suspensivos y
seleccione la suscripción de destino. Verá la página Definiciones
de planos con el plano que creó, que actualmente se encuentra en
modo borrador, como se muestra en la Figura 3-70 .
Figura 3-70 Plano existente en modo borrador

16. Haga clic en el plano que creó y, en la página que se abre, haga
clic en el botón Publicar plano .
17. En el campo Versión , escriba un control de versión para este
modelo. Opcionalmente, puede escribir una nota sobre los cambios
en esta versión en el campo Notas de cambio .
18. Haga clic en el botón Publicar .
Ahora que el plano está creado y publicado, puede asignarlo a la
suscripción. Para hacerlo, haga clic en el botón Asignar plano en las
propiedades del plano. La Figura 3-71 muestra un ejemplo de esta página.
Figura 3-71 Asignar plano
Entre las opciones disponibles en esta página, la configuración de
la sección Bloquear asignación es muy importante porque la selección
dependerá de los requisitos del escenario. Las cerraduras disponibles son
• No bloquear Esto significa que los recursos no están
bloqueados por este plan. Los usuarios, grupos y entidades de
servicio con permisos pueden modificar y eliminar recursos
implementados.
• No eliminar Aunque este tipo de bloqueo no es compatible
con todos los recursos, este bloqueo permite que los recursos sean
modificados pero no eliminados, incluso por los propietarios de
suscripciones. Tenga en cuenta que pueden pasar hasta 30 minutos
para que se aplique este bloqueo de planos.
• Solo lectura Como su nombre lo indica, los recursos no se
pueden modificar de ninguna manera, ni se pueden eliminar, ni
siquiera por el propietario de la suscripción. Este tipo de bloqueo
no es compatible con todos los recursos.
Los bloqueos de recursos implementados por Azure Blueprints solo se
aplican a los recursos implementados por la asignación de blueprint. Esto
significa que los recursos existentes, como los de los grupos de recursos
existentes, no se ven afectados porque no tienen bloqueos
agregados. Puede eliminar los estados de bloqueo cambiando el modo de
bloqueo de la asignación del plano a No bloquear o eliminando la
asignación del plano.
La configuración de Parámetros de artefactos proporciona una opción
para escribir los parámetros que se establecieron durante la creación del
plano. Cuando termine de llenar todos esos parámetros, puede hacer clic
en el botón Asignar . Cuando haya terminado de realizar las asignaciones,
podrá ver la asignación en Blueprints asignados en el panel de navegación
izquierdo, como se muestra en la Figura 3-71 .
Figura 3-72 Planos asignados

Experimento mental
Supervisión de la seguridad en Tailwind Traders

para el hogar. Como parte de sus deberes para Tailwind Traders, debe
trabajar con el Centro de operaciones de seguridad (SOC) para asegurarse
de que las alertas generadas por el Centro de seguridad de Azure se
transfieran a Azure Sentinel. El equipo SOC también necesita información
de auditoría sobre la creación de máquinas virtuales, y esta información
debe transmitirse a Azure Sentinel.
Tailwind Traders ha estado utilizando el nivel estándar de Azure Security
Center durante un tiempo, principalmente para obtener alertas. La
compañía ahora quiere usar otras capacidades en Security Center para
reducir la superficie de ataque de sus máquinas virtuales IaaS. Uno de los
requisitos es garantizar que los puertos de administración estén cerrados
de forma predeterminada y solo se abrirán cuando se realice una solicitud
explícita durante un período de tiempo específico. Debido a algunas
auditorías internas, los administradores de la base de datos de Tailwind
Traders también deben tener una evaluación de vulnerabilidad
disponible para la base de datos Azure SQL de la empresa. Con esta
información en mente, responda las siguientes preguntas:
1. 1. ¿Qué conectores deben usarse en Azure Sentinel para habilitar
este escenario?
2. 2. ¿Qué característica de Azure Security Center ayudará a reducir la
superficie de ataque según los requisitos de Tailwind Traders?
3. 3. ¿Qué se debe hacer primero antes de habilitar la Evaluación de
vulnerabilidad de SQL para las bases de datos de Tailwind Traders?
Esta sección contiene la solución al experimento mental.
1. 1. Centro de seguridad de Azure y registro de actividad de Azure.
2. 2. Acceso a máquina virtual justo a tiempo.
3. 3. Primero, debe habilitar Advanced Data Security (ADS) en sus
bases de datos SQL.

• Los registros de recursos de Azure registran operaciones que
se ejecutaron en el nivel del plano de datos, mientras que los
registros de actividad en el nivel de suscripción registran las
operaciones que se ejecutaron en el plano de administración.
• Puede personalizar alertas en Azure Monitor para diferentes
tipos de datos, incluidas métricas, consultas de búsqueda de
registros y eventos de registros de actividad.
• Las soluciones de supervisión aprovechan los servicios en
Azure para proporcionar información adicional sobre el
funcionamiento de una aplicación o servicio.
• El nivel estándar de Azure Security Center proporciona una
evaluación de vulnerabilidades incorporada mediante la
integración nativa con Qualys.
• Para habilitar la evaluación de vulnerabilidades para SQL,
primero debe habilitar la función SQL Advanced Data Security
(ADS).
• Para implementar la administración de políticas centralizada
en Azure Security Center, debe asignar la iniciativa predeterminada
de ASC al nivel del grupo de administración.
• El panel de cumplimiento normativo en Azure Security Center
se puede personalizar para agregar otros estándares que no están
disponibles de forma inmediata.
• Para ingerir datos de diferentes orígenes de datos en Azure
Sentinel, puede usar conectores de servicio a servicio o conectores
externos.
• Los Blueprints de Azure le permiten definir un conjunto
repetible de recursos de Azure que implementa y se adhiere a los
estándares, patrones y requisitos de una organización
Capítulo 4
Datos y aplicaciones seguros

La seguridad de los datos almacenados en Azure, la seguridad de SQL y la
seguridad de sus secretos, claves y certificados son tan importantes como
la seguridad de cualquier otro elemento de su implementación en la
nube. Uno de los tipos de violación de datos en la nube más comúnmente
reportados es el contenedor de almacenamiento lleno de datos
importantes de clientes que se deja abierto al mundo. También es
probable que haya oído hablar de contraseñas de aplicaciones y cadenas
de conexión que quedaron expuestas en repositorios de código fuente y
datos de bases de datos SQL extraídos por atacantes inteligentes que
aprovecharon las vulnerabilidades de inyección de SQL que no fueron
detectadas hasta que los datos violados comenzaron a aparecer en la web
oscura. En este capítulo, aprenderá cómo proteger las implementaciones
de Azure Storage de su organización, los pasos que puede seguir para
proteger las instancias de SQL Server de su organización,

• Habilidad 4.1: Configurar la seguridad para el
almacenamiento
• Habilidad 4.2: Configurar la seguridad para bases de datos
• Habilidad 4.3: Configurar y administrar Key Vault
HABILIDAD 4.1: CONFIGURAR LA

SEGURIDAD PARA EL ALMACENAMIENTO
Los contenedores de almacenamiento de datos no seguros son la fuente
de muchas violaciones de datos en la nube. Estas infracciones ocurren
porque los contenedores de almacenamiento que los administradores
creen que solo son accesibles para un grupo selecto de personas
autorizadas, de hecho, están configurados para que sean accesibles para
todos en el mundo que conocen la dirección del contenedor de
almacenamiento. Este objetivo trata sobre cómo proteger el
almacenamiento en Azure, desde cómo configurar el control de acceso
para las cuentas de almacenamiento hasta cómo administrar las claves de
las cuentas de almacenamiento. Aprenderá acerca de las firmas de acceso
compartido, las directivas de acceso compartido de cifrado del servicio de
almacenamiento y el uso de Azure AD para autenticar el acceso de los
usuarios a los recursos de almacenamiento en Azure.
Configurar el control de acceso para las cuentas

de almacenamiento
Las cuentas de almacenamiento son contenedores para objetos de datos
de Azure Storage, como blobs, archivos, colas, tablas y discos. Azure
admite los siguientes tipos de cuentas de almacenamiento:
• Cuentas V2 de uso general Almacena blobs, colas de
archivos y tablas. Recomendado para la mayoría de escenarios de
almacenamiento. Las cuentas de uso general V2 reemplazan las
cuentas de uso general V1, que no debe usar para nuevas
implementaciones y debe migrar si se usan en implementaciones
existentes.
• Cuentas BlockBlobStorage Cuentas de almacenamiento
recomendadas para escenarios en los que existen altas tasas de
transacción para blobs en bloque y blobs anexos. También se
recomienda para escenarios que requieren objetos más pequeños o
latencia de almacenamiento constantemente baja.
• Cuentas de FileStorage Cuentas de almacenamiento de solo
archivos de alto rendimiento. Recomendado para aplicaciones de
alto rendimiento.
• Cuentas de BlobStorage Tipo de cuenta de almacenamiento
heredado que no debe usar para nuevas implementaciones y debe
migrar si se usan en implementaciones existentes.
El método recomendado para administrar el control de acceso para las
cuentas de almacenamiento en el plano de administración es utilizar roles
RBAC. Los roles de RBAC para el almacenamiento se pueden asignar en
los siguientes niveles:
• Las asignaciones de roles de contenedor individuales en
este ámbito se aplican a todos los blobs del contenedor. Las
asignaciones de roles también se aplican a las propiedades y
metadatos del contenedor cuando se accede al contenedor en el
plano de administración.
• Las asignaciones de roles de cola individuales en este
ámbito se aplican a todos los mensajes de la cola. Las asignaciones
de roles también se aplican a las propiedades y metadatos de la
cola cuando se accede a la cola en el plano de administración.
• Las asignaciones de roles de cuentas de almacenamiento en
este ámbito se aplican a todos los contenedores, todos los blobs
dentro de esos contenedores, todas las colas y todos los mensajes.
• Grupo de recursos Las asignaciones de roles en este ámbito
se aplican a todas las cuentas de almacenamiento del grupo de
recursos, así como a todos los elementos dentro de esas cuentas de
almacenamiento.
• Las asignaciones de roles de suscripción en este ámbito se
aplican a todas las cuentas de almacenamiento, en la suscripción,
así como a todos los elementos dentro de esas cuentas de
almacenamiento.
• Grupo de administración Las asignaciones de roles en este
ámbito se aplican a todas las cuentas de almacenamiento, así como
a todos los elementos dentro de esas cuentas de almacenamiento
dentro de todas las suscripciones en el grupo de administración.
Al asignar un rol RBAC, recuerde la regla del privilegio mínimo y asigne el
rol con el alcance más estrecho posible. Esto significa que si un usuario
individual o una aplicación solo requiere acceso a una cuenta de
almacenamiento específica y hay varias cuentas de almacenamiento en un
grupo de recursos, solo debe asignar el rol en el nivel de la cuenta de
almacenamiento. Además de la regla del privilegio mínimo, recuerde
asignar roles a grupos en lugar de a usuarios individuales. De esta
manera, la asignación de roles se convierte en una cuestión de agregar y
eliminar cuentas de usuario de un grupo específico.En lugar de asignar
roles a usuarios o aplicaciones individuales, debe asignar el rol a un grupo
y luego agregar las cuentas de usuario y aplicación a ese grupo como una
forma de administrar las asignaciones de roles. La Tabla 4-1 enumera los
roles de RBAC que son apropiados para las cuentas de almacenamiento:
Tabla 4-1 Funciones de RBAC de la cuenta de almacenamiento
Rol de RBAC relacionado con el Descripción del rol de RBAC
almacenamiento
Colaborador de la cuenta de Permite la gestión de cuentas de almacenamien

almacenamiento la clave de la cuenta y puede acceder a los datos
autorización de clave compartida.
Función de servicio del operador Puede enumerar y regenerar claves de acceso a

principal de la cuenta de almacenamiento.
almacenamiento
Colaborador de datos de Storage Puede leer, escribir y eliminar blobs y contened

Blob Storage.
Propietario de datos de Storage Blob Permite el acceso completo a los datos y los con
blobs de software de Azure.
Lector de datos de Storage Blob Puede ver y enumerar los contenedores y blobs
Delegador de blobs de Puede generar una clave de delegación de usuar

almacenamiento puede usar para crear una firma de acceso comp
contenedores o blobs firmados con credenciales
Colaborador de recurso compartido Permite el acceso de lectura, escritura y elimina

de SMB de archivos de directorios en recursos compartidos de Azure.
almacenamiento
Colaborador elevado de recursos Además de leer, escribir y eliminar el acceso a a

compartidos de SMB de datos de directorios en recursos compartidos de Azure, m
archivos de almacenamiento de control de acceso en archivos y directorios.
Lector de recursos compartidos SMB Tiene acceso de solo lectura a archivos y directo
de datos de archivos de compartidos de Azure.
almacenamiento
Rol de RBAC relacionado con el Descripción del rol de RBAC
almacenamiento
Colaborador de datos de la cola de Leer, escribir y eliminar colas de Azure Storage,

almacenamiento mensajes en cola.
Procesador de mensajes de datos de Realice, espíe, recupere y elimine mensajes de l

la cola de almacenamiento Storage.
Remitente del mensaje de datos de Puede agregar mensajes a una cola de Azure Sto
la cola de almacenamiento
Lector de datos de la cola de Puede leer y enumerar el contenido de una cola

almacenamiento y los mensajes de la cola.
Para asignar un rol a una cuenta de almacenamiento en Azure Portal,
1. En Azure Portal, abra la cuenta de almacenamiento a la que desea
asignar un rol de RBAC.
2. En la página de la cuenta de almacenamiento, seleccione Control de
acceso (IAM) en el menú, como se muestra en la Figura 4-1 .
Figura 4-1 Nodo de control de acceso (IAM) de una cuenta de
almacenamiento
3. En la hoja Control de acceso (IAM) , seleccione Asignaciones de
funciones y luego haga clic en Agregar > Asignación de
funciones , como se muestra en la Figura 4-2 . Esto abrirá
la página Agregar asignación de funciones .
Figura 4-2 Página de asignaciones de roles
4. En la página Agregar asignación de rol que se muestra en
la Figura 4-3 , seleccione la entidad de seguridad, preferiblemente
un grupo de Azure AD, al que desea asignar el rol y haga clic
en Guardar .
Figura 4-3 Asignación de roles de colaborador de la cuenta de
almacenamiento
Más información Funciones de Rbac para datos de blobs y colas
Puede obtener más información sobre el acceso a la función RBAC para blob y datos
de cola en https://docs.microsoft.com/en-us/azure/storage/common/storage-auth-aad-
rbac-portal .
Configurar la administración de claves para

cuentas de almacenamiento
Las claves de acceso a la cuenta de almacenamiento le permiten autorizar
el acceso a los datos de la cuenta de almacenamiento. Cada cuenta de
Azure Storage tiene un par asociado de claves de acceso a la cuenta de
almacenamiento de 512 bits. Si alguien tiene acceso a una clave de cuenta
de Azure Storage, tiene acceso a la cuenta de almacenamiento asociada
con esa clave. La mejor práctica es utilizar solo la primera clave y
mantener la segunda clave en reserva. Luego, cambia al uso de la segunda
tecla cuando realiza la rotación de teclas. Esto le permite generar una
nueva clave principal, a la que cambiará cuando realice la rotación de
claves en el futuro. La ubicación recomendada para almacenar las claves
de acceso a la cuenta de almacenamiento es Azure Key Vault. Aprenderá
más sobre Azure Key Vault más adelante en este capítulo.
Debido a que solo hay un par de claves de acceso asociadas con una
cuenta de almacenamiento, debe rotar y regenerar las claves de acceso
periódicamente. La rotación de las claves de acceso a la cuenta de
almacenamiento garantiza que, si se produce una fuga de la clave de una
cuenta de almacenamiento, la fuga se solucionará automáticamente
cuando las claves de la cuenta de almacenamiento existentes lleguen al
final de su vida útil. Por ejemplo, si rota las claves cada seis semanas, la
cantidad máxima de tiempo que una clave filtrada permanece válida es de
seis semanas. Incluso si no lo hacesSi tiene motivos para creer que se ha
filtrado una clave de cuenta de almacenamiento, la mejor práctica es
rotarlas periódicamente. El hecho de que no tenga motivos para creer que
la clave de una cuenta de almacenamiento no se ha filtrado no significa
que no sea accesible para alguien que no debería tener acceso a ella.
Ver claves de acceso a la cuenta de almacenamiento

Ver una clave de acceso a la cuenta de almacenamiento requiere roles de
Administrador de servicio, Propietario, Colaborador o Operador clave de
la cuenta de almacenamiento en la cuenta de almacenamiento con la que
está asociada la clave. También puede acceder a la clave si se le ha
asignado un rol de RBAC que incluye
el Microsoft.Storage/storageAccounts/listkeys/actionpermiso en un ámbito
que incluye la cuenta de almacenamiento.
Para ver las claves de la cuenta de almacenamiento de una cuenta de
almacenamiento en Azure Portal, realice los siguientes pasos:
1. En Azure Portal, navegue hasta la cuenta de almacenamiento para
la que está interesado en conocer los detalles de la clave de acceso a
la cuenta de almacenamiento.
2. En la página Cuenta de almacenamiento, seleccione Claves de
acceso en Configuración , como se muestra en la Figura 4-4 .
Figura 4-4 Claves de acceso en el menú de claves de la cuenta de
almacenamiento
3. En la página Claves de acceso que se muestra en la Figura 4-5 ,
puede ver y copiar la primera y la segunda claves.
Figura 4-5 Claves de acceso a la cuenta de almacenamiento

Para ver las claves de acceso a la cuenta de almacenamiento con
PowerShell, use el siguiente comando de PowerShell:
$ storageAccountKey = `
(Get-AzStorageAccountKey `
-ResourceGroupName <recurso-grupo> `
-Nombre <cuenta-almacenamiento>) .Valor [0]
Para ver las claves de acceso a la cuenta de almacenamiento a través de la

CLI de Azure, use el siguiente comando:
lista de claves de cuentas de almacenamiento az \
--resource-group <grupo de recursos> \
--ccount-name <storage-account>
Más información Administrar las claves de acceso de la cuenta de almacenamiento

Puede obtener más información sobre cómo administrar las claves de acceso a la
cuenta de almacenamiento en https://docs.microsoft.com/en-
us/azure/storage/common/storage-account-keys-manage .
Rotar manualmente las claves de acceso a la cuenta de

almacenamiento
La mejor práctica es rotar las claves de acceso a la cuenta de
almacenamiento de forma periódica. Solo debe usar una clave de cuenta
de almacenamiento a la vez. Usar solo una clave a la vez le permitirá
cambiar cualquier aplicación a la segunda clave de cuenta de
almacenamiento del par antes de rotar la primera. Como se mencionó
anteriormente, después de que haya pasado algún tiempo, repita el
proceso, cambiando la aplicación a la clave de la cuenta de
almacenamiento recién rotada antes de volver a generar la segunda clave
en el par. Para rotar manualmente las claves de acceso de su cuenta de
almacenamiento mediante Azure Portal, realice los siguientes pasos:
1. Asegúrese de haber actualizado las cadenas de conexión en
cualquier código de aplicación que haga referencia a la clave de
acceso a la cuenta de almacenamiento que reemplazará.
2. Navegue a la página de Claves de acceso para la cuenta de
almacenamiento.
3. Para regenerar la clave, seleccione el icono Regenerar que se
muestra en la Figura 4-6 . Esto generará una nueva clave de acceso
a la cuenta de almacenamiento y una nueva cadena de conexión. (El
icono de regeneración aparece como un par de flechas curvas).
Figura 4-6 El icono Regenerar
Para volver a generar la clave de la cuenta de almacenamiento con
PowerShell, use el siguiente comando, sustituyendo el nombre del grupo
de recursos y el nombre de la cuenta de almacenamiento y key1o key2,
según corresponda.
New-AzStorageAccountKey -ResourceGroupName <grupo de
recursos> `
-Nombre <cuenta-almacenamiento> `
-KeyName key1
Para volver a generar la clave de la cuenta de almacenamiento mediante

la CLI de Azure, use el siguiente comando, sustituya el nombre del grupo
de recursos y el nombre de la cuenta de almacenamiento y especifique si
la clave que desea volver a generar es la clave principal o secundaria.
Renovar las claves de la cuenta de almacenamiento az \
--resource-group <grupo de recursos> \
--ccount-name <storage-account>
- clave primaria
Existen mecanismos que le permiten automatizar la rotación de las claves
de acceso a la cuenta de almacenamiento. Aprenderá sobre estos
mecanismos más adelante en este capítulo.
Crear y administrar firmas de acceso compartido

(SAS)
Las firmas de acceso compartido (SAS) le permiten proporcionar acceso
seguro, granular y delegado a las cuentas de almacenamiento. Con un SAS,
puede controlar a qué recursos puede acceder un cliente, los permisos
que el cliente tiene para esos recursos y el tiempo que persistirá el
acceso. Un SAS esun identificador uniforme de recursos (URI) firmado
que proporciona la dirección de uno o más recursos de almacenamiento e
incluye un token que determina cómo el cliente puede acceder al recurso.
Azure Storage admite los siguientes tipos de SAS:
• SAS de delegación de usuarios SAS de delegación de usuarios
solo se puede utilizar con Blob Storage. Las SAS de delegación de
usuarios están protegidas por Azure AD y los permisos
configurados para SAS.
• Service SAS Service SAS está protegido con claves de cuenta
de almacenamiento. Este SAS delega el acceso a un tipo de recursos
de almacenamiento. Service SAS se puede configurar para archivos
de Azure, almacenamiento de blobs, almacenamiento en cola o
almacenamiento de tabla.
• Cuenta SAS Cuenta SAS está protegida con las claves de la
cuenta de almacenamiento. Estas claves se pueden utilizar para
delegar el acceso. Además de todas las operaciones que pueden
estar disponibles mediante la delegación de usuarios SAS o Service
SAS, Account SAS le permite delegar el acceso a las operaciones que
se aplican al nivel de servicio, como Obtener / Establecer
propiedades del servicio. La cuenta SAS también le permite delegar
el acceso para leer, escribir y eliminar operaciones en
contenedores de blobs, recursos compartidos de archivos, tablas y
colas que no son posibles con una SAS de servicio.
SAS viene en las siguientes dos formas:
• SAS ad hoc SAS ad hoc incluye la hora de inicio, la hora de
vencimiento y los permisos de recursos dentro del URI de
SAS. Todos los tipos de SAS pueden ser SAS ad hoc.
• Servicio SAS con política de acceso almacenado Las
políticas de acceso almacenado se configuran en contenedores de
recursos, que incluyen contenedores de blobs, tablas, colas o
archivos compartidos. Las SAS de servicio con políticas de acceso
almacenadas permiten que SAS herede la hora de inicio, la hora de
vencimiento y los permisos que se han configurado para la política
de acceso almacenada.
Como es el caso de las claves de acceso a la cuenta de almacenamiento, si
se filtra un SAS, cualquiera que tenga acceso al SAS tiene acceso a los
recursos de almacenamiento a los que tiene acceso el SAS. Los
desarrolladores de aplicaciones también deben recordar que los SAS
caducan periódicamente, y si la aplicación no está configurada para
obtener automáticamente un nuevo SAS, la aplicación perderá acceso a
los recursos de almacenamiento a los que media el SAS.
Microsoft tiene una lista de mejores prácticas para el uso de SAS, que
incluye
• Utilice SAS de delegación de usuarios cuando sea
posible. Este tipo de SAS tiene la mejor seguridad porque está
protegido mediante las credenciales de Azure AD de un
usuario. Esto significa que las claves de la cuenta no se
almacenarán con el código de la aplicación.
• Esté preparado para revocar un SAS cuando sea
necesario Si determina que un SAS ha sido comprometido,
asegúrese de que puede revocar rápidamente el SAS y
reemplazarlo por uno que no esté comprometido.
• Configurar las políticas de acceso almacenado para el
servicio SAS Una ventaja de las políticas de acceso almacenado es
que puede revocar los permisos para un servicio SAS sin tener que
volver a generar las claves de acceso de la cuenta de
almacenamiento.
• Configure tiempos de vencimiento cortos para SAS ad-
hoc Si un SAS ad hoc se ve comprometido, el tiempo de
vencimiento corto garantizará que el SAS comprometido no sea
válido durante mucho tiempo.
• Si es necesario, asegúrese de que los clientes renueven
SAS. Si los clientes realizan solicitudes de almacenamiento con SAS
con regularidad, configure la aplicación para que el cliente pueda
solicitar la renovación de SAS antes de que expire SAS.
Más información Firmas de acceso compartido
Puede obtener más información sobre las firmas de acceso compartido
en https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview .
Crear SAS de delegación de usuarios

Para crear un SAS de delegación de usuarios para un contenedor de
almacenamiento con PowerShell, primero cree un objeto de contexto de
almacenamiento sustituyendo los valores apropiados en el siguiente
código de PowerShell:
$ ctx = New-AzStorageContext -StorageAccountName <storage-
account> -UseConnectedAccount
Luego, cree un token SAS de delegación de usuarios sustituyendo los

valores apropiados en el siguiente código de PowerShell:
New-AzStorageContainerSASToken -Context $ ctx `
-Nombre <contenedor> `
-Permiso racwdl `
-ExpiryTime <fecha-hora>
Para crear un SAS de delegación de usuarios para un blob, sustituya los

valores adecuados en el siguiente código de PowerShell:
New-AzStorageBlobSASToken -Context $ ctx `
-Contenedor <contenedor> `
-Blob <blob> `
-Permiso racwd `
-ExpiryTime <fecha-hora>
-FullUri
Puede revocar una SAS de delegación de usuarios mediante el Revoke-

AzStorageAccountUserDelegationKeyscomando. Por ejemplo, use el siguiente
código de PowerShell, sustituyendo los valores apropiados cuando sea
necesario:
Revoke-AzStorageAccountUserDelegationKeys -ResourceGroupName
<resource-group> `
-StorageAccountName <storage-ccount>
Para crear una SAS de delegación de usuarios para un contenedor de

almacenamiento mediante la CLI de Azure, ejecute el siguiente comando
de la CLI de Azure, sustituyendo los valores adecuados cuando sea
necesario:
contenedor de almacenamiento az generate-sas \
--ccount-name <storage-account> \
--name <contenedor> \
--permisos acdlrw \
--expiry <fecha-hora> \
--auth-mode login \
--como usuario
Para crear una SAS de delegación de usuarios para un blob mediante la

CLI de Azure, ejecute el siguiente comando de la CLI de Azure y sustituya
los valores adecuados cuando sea necesario:
az storage blob generate-sas \
--container-name <container> \
--nombre <blob> \
--permisos acdrw \
--expiry <fecha-hora> \
--auth-mode login \
--como usuario
--full-uri
Para revocar un SAS de delegación de usuarios mediante la CLI de Azure,

ejecute el siguiente comando, sustituyendo los valores apropiados cuando
sea necesario:
az cuenta de almacenamiento revocar-delegar-claves \
--name <cuenta-almacenamiento> \
--resource-group <grupo de recursos>
Es importante tener en cuenta que debido a que Azure Storage almacena

en caché las claves de delegación de usuarios y las asignaciones de roles
de Azure, es posible que el proceso de revocación no se produzca de
inmediato.
Más información Crear delegación de usuarios SAS
Puede obtener más información sobre cómo crear un SAS de delegación de usuarios
en https://docs.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas .
Crea una cuenta SAS

El primer paso al crear una cuenta SAS es la creación de una cuenta SAS
URI. El URI de SAS de la cuenta incluye el URI del recurso de
almacenamiento al que SAS proporciona acceso, así como el token de
SAS. Los tokens SAS son cadenas de consulta especiales que incluyen los
datos utilizados para autorizar las solicitudes de recursos y para
determinar el servicio, el recurso y los permisos de acceso. Los tokens
SAS también incluyen el período durante el cual la firma será válida.
La Tabla 4-2 enumera los parámetros obligatorios y opcionales para el
token SAS.
Tabla 4-2 Parámetros de token SAS
Parámetro de consulta Descripción
SAS
Versión api Opcional Le permite especificar la versión del servicio de alm

se utilizará al ejecutar la solicitud.
SignedVersion (sv) Obligatorio Especifique la versión del servicio de almacenam

para autorizar solicitudes. Debe estar configurado para 2015-
SignedServices (ss) Requerido Le permite especificar los servicios accesibles con

SAS. Las opciones incluyen
• Gota
• Cola
• Mesa
• Archivo
SignedResourceTypes Requerido Le permite especificar a qué tipos de recursos pro

(srt) SAS. Las opciones incluyen
• Servicio de acceso a las API de nivel de servicio.
• Recipiente de acceso a las API de nivel de conten
• Objeto de acceso a las API de nivel de objeto.
Permiso firmado (sp) Permisos necesarios para la cuenta SAS. Los permisos incluy
• Leer Válido para todos los tipos de recursos.
• Escritura Válida para todos los tipos de recursos.
• Eliminar Válido para los tipos de recursos de obje
contenedores, sin incluir los mensajes en cola.
• Lista Válida para tipos de recursos de contenedor
Parámetro de consulta Descripción
SAS
• Agregar Válido para mensajes en cola, entidades

blobs.
• Crear Válido para blobs y archivos.
• Actualización Válida para mensajes en cola y enti
• Proceso Solo válido para mensajes en cola.
SignedStart (st) Opcional El momento en que el SAS se vuelve válido.
SignedExpiry (se) Obligatorio El momento en el que SAS deja de ser válido.
SignedIP (sorbo) Opcional Le permite especificar un rango permitido de direcc
Protocolo firmado Opcional Determina qué protocolos se pueden usar para soli
(spr) con la cuenta SAS. Las opciones son HTTPS y HTTP o solo HTT
Firma (sig) Requerido Se utiliza para autorizar la solicitud realizada con

son códigos de autenticación de mensajes basados en hash qu
sobre la cadena firmada y la clave de acceso a la cuenta de alm
mediante el algoritmo SHA256. Luego, esta firma se codifica u
codificación Base64.
Para construir la cadena de firma, debe codificar la cadena como UTF-8
que desea firmar a partir de los campos que ha incluido en la solicitud y
calcular la firma utilizando el algoritmo HMAC-SHA256.
Más información Crear una cuenta SAS
Puede obtener más información sobre cómo crear una cuenta SAS
en https://docs.microsoft.com/en-us/rest/api/storageservices/create-account-sas .
Crear una política de acceso almacenada para
un blob o contenedores de blobs
Las políticas de acceso almacenado le permiten controlar específicamente
las firmas de acceso compartido a nivel de servicio. Puede configurar
políticas de acceso almacenadas para contenedores de blobs, recursos
compartidos de archivos, colas y tablas. Las políticas de acceso
almacenadas consisten en la hora de inicio, la hora de vencimiento y los
permisos para un SAS. Cadade estos parámetros se pueden especificar en
el URI de firma en lugar de en una política de acceso
almacenada. También puede especificar todos estos parámetros en la
política de acceso almacenada o utilizar una combinación de los dos. Es
importante tener en cuenta que no es posible especificar el mismo
parámetro tanto en el token SAS como en la política de acceso
almacenada sin que se produzcan problemas.
Azure le permite establecer un máximo de cinco políticas de acceso
simultáneo en contenedores, tablas, colas o recursos compartidos
individuales. Para crear o modificar una política de acceso almacenada,
debe llamar a la Set ACLoperación del recurso que desea proteger con el
cuerpo de solicitud de la llamada que enumera los términos de la política
de acceso. La siguiente es una plantilla que puede utilizar para el cuerpo
de la solicitud en la que sustituye su propia hora de inicio, hora de
vencimiento, lista de permisos abreviada y un identificador único firmado
de su elección:
<? xml version = "1.0" encoding = "utf-8"?>
<Identificadores firmados>
<SignedIdentifier>
<Id> valor-de-64-caracteres-único </Id>
<AccessPolicy>
<Start> hora de inicio </Start>
<Expiry> fecha de expiración </Expiry>

<Permission> lista-de-permisos-abreviada </Permission>
</AccessPolicy>
</SignedIdentifier>
</SignedIdentifiers>
Para cambiar los parámetros de una política de acceso almacenada

existente, llame a la operación de lista de control de acceso para el tipo de
recurso y especifique nuevos parámetros mientras se asegura de que el
campo de ID único sigue siendo el mismo. Para eliminar todas las políticas
de acceso de un recurso de almacenamiento, llame a la Set ACLoperación
con una política de solicitud vacía.
Más información Políticas de acceso almacenado
Puede obtener más información sobre las políticas de acceso almacenadas
en https://docs.microsoft.com/en-us/rest/api/storageservices/define-stored-access-policy .
Configurar la autenticación de Azure AD para

Azure Storage
En lugar de depender de las claves de la cuenta de almacenamiento o las
firmas de acceso compartido, puede usar Azure AD para autorizar el
acceso a Blob y Queue Storage. Azure AD autentica la identidad de una
entidad de seguridad y luego devuelve un token de OAuth 2.0. El cliente
incluye este token en la solicitud al almacenamiento de blobs o cola al que
accede la entidad de seguridad. Debe registrar una aplicación con un
inquilino de Azure AD antes de que se puedan emitir tokens de esta
manera.
El método que utiliza para asignar derechos específicos al
almacenamiento de blobs o colas es configurar los permisos de RBAC en
el contenedor, la cola o la cuenta de almacenamiento adecuados. Usted
determina qué acceso necesita el usuario o la aplicación, crea un grupo de
Azure AD, asigna al grupo el permiso RBAC apropiado y luego agrega la
cuenta de usuario o la entidad de servicio al grupo de Azure AD.
Azure incluye los siguientes roles integrados para autorizar el acceso a
datos de blobs y colas:
• Propietario de datos de Storage Blob Permite que la
entidad de seguridad establezca la propiedad y administre el
control de acceso POSIX para Azure Data Lake Storage Gen2.
• Colaborador de datos de Storage Blob Otorga a la entidad
de seguridad permisos de lectura / escritura / eliminación a los
recursos de Blob Storage.
• Lector de datos de Storage Blob Permite a la entidad de
seguridad ver elementos en Blob Storage.
• Delegador de blobs de almacenamiento Permite que
la entidad de seguridad adquiera la clave de delegación de
usuarios, que a su vez se puede usar para crear una firma de acceso
compartido para un contenedor o blob. Esta firma de acceso
compartido está firmada con las credenciales de Azure AD de la
entidad de seguridad.
• Colaborador de datos de la cola de
almacenamiento Otorga a la entidad de seguridad permisos de
lectura / escritura y eliminación para las colas de Azure Storage.
• Lector de datos de la cola de almacenamiento Permite a la
entidad de seguridad ver los mensajes en las colas de Azure
Storage.
• Procesador de mensajes de datos de la cola de
almacenamiento Permite que la entidad de seguridad mire,
recupere y elimine mensajes en las colas de Azure Storage.
• Remitente de mensajes de datos de la cola de
almacenamiento Permite que la entidad de seguridad agregue
mensajes en las colas de almacenamiento de Azure.
Más información Azure AD para blobs y colas
Puede obtener más información sobre la autorización de Azure AD para blobs y colas
en https://docs.microsoft.com/en-us/azure/storage/common/storage-auth-aad .
Configurar la autenticación de Azure AD Domain

Services para Azure Files
Cuando habilita la autenticación de AD DS para Azure Files, sus equipos
unidos a un dominio de Servicios de dominio de Active Directory (AD DS)
pueden montar Azure File Shares con las credenciales de usuario de AD
DS. El acceso se produce a través de una conexión de protocolo de bloque
de mensajes de servidor (SMB) cifrada. Puede proteger Azure Files
mediante la autenticación basada en identidad sobre Server Message
Block (SMB) donde Azure AD DS o un dominio de servicios de dominio de
Active Directory local (AD DS)Funciona como proveedor de identidad. La
autenticación de Azure AD Domain Services para Azure Files actualmente
admite los siguientes escenarios:
• Si usa AD DS como su proveedor de identidad, debe usar
Azure AD Connect para sincronizar las identidades con Azure AD.
• Si está utilizando AD DS como su proveedor de identidad,
puede acceder al recurso compartido de archivos mediante una
computadora que sea miembro de un dominio de AD DS. No puede
acceder al recurso compartido de archivos mediante un equipo que
está unido al dominio de Azure AD DS.
• Si usa Azure AD DS como proveedor de identidad, deberá
acceder al recurso compartido de archivos con un equipo que sea
miembro del dominio de Azure AD DS.
• Cuando está habilitada, esta forma de autenticación admite
recursos compartidos de archivos de Azure que están integrados
con Azure File Sync
• Esta forma de autenticación admite el inicio de sesión único.
• Esta forma de autenticación solo admite el acceso desde
cuentas en el bosque de AD DS en el que está registrada la cuenta
de almacenamiento, a menos que exista una confianza de bosque
especialmente configurada.
El primer paso al habilitar la autenticación de AD para los recursos
compartidos de archivos de Azure es crear una cuenta de
almacenamiento que se encuentre en una región cercana a los usuarios
que accederán a los archivos almacenados en el recurso compartido de
archivos de esa cuenta de almacenamiento. Debe hacer esto simplemente
porque acceder a una cuenta de almacenamiento más cercana a usted
proporcionará una experiencia de usuario mucho mejor que intentar
abrir y guardar archivos en un recurso compartido ubicado en el otro
lado del mundo. Al comienzo del proceso, no necesitará crear archivos
compartidos desde la cuenta de almacenamiento. Antes de crear los
archivos compartidos, deberá habilitar la autenticación de Active
Directory en el nivel de la cuenta de almacenamiento en lugar de en el
nivel de los archivos compartidos individuales.
Habilitación de la autenticación de AD DS
El primer paso al habilitar la autenticación de AD DS es crear una
identidad para representar la cuenta de almacenamiento en su instancia
de Active Directory local. Para hacer esto, primero cree una nueva clave
Kerberos para la cuenta de almacenamiento con los siguientes comandos
de Azure PowerShell de Cloud Shell:
$ ResourceGroupName = "<recurso-grupo-nombre-aquí>"
$ StorageAccountName = "<storage-account-name-here>"
New-AzStorageAccountKey -ResourceGroupName $
ResourceGroupName -Name $ StorageAccountName
-KeyName kerb1
Get-AzStorageAccountKey -ResourceGroupName $
ResourceGroupName -Name $ StorageAccountName
-ListKerbKey | where-object {$ _. Keyname -contains "kerb1"}
Una vez que se haya generado la clave, cree una cuenta de servicio en su
dominio local y configure la cuenta con el siguiente nombre principal de
servicio (SPN): "cifs/your-storage-account-name-
here.file.core.windows.net"usando el comando setspn.exe. Establezca la
contraseña de la cuenta en la clave Kerberos y configure la contraseña de
la cuenta para que nunca caduque y anote el identificador de seguridad de
la cuenta (SID). Puede usar el Get-AdUsercmdlet de PowerShell para
determinar el SID de una cuenta de usuario.
El siguiente paso es usar Azure PowerShell para habilitar la autenticación
de Active Directory. Puede hacer esto con el siguiente comando,
sustituyendo los valores apropiados:
Set-AzStorageAccount `
-ResourceGroupName "<your-resource-group-name-here>"
`
-Nombre "<su-nombre-cuenta-de-almacenamiento-aquí>" `
-EnableActiveDirectoryDomainServicesForFile $ true `
-ActiveDirectoryDomainName "<your-domain-name-here>"
`
-ActiveDirectoryNetBiosDomainName "<your-netbios-
domain-name-here>" `
-ActiveDirectoryForestName "<su-nombre-bosque-aquí>"
`
-ActiveDirectoryDomainGuid "<tu-guía-aquí>" `
-ActiveDirectoryDomainsid "<your-domain-sid-here>" `
-ActiveDirectoryAzureStorageSid "<your-storage-
account-sid>"
También tiene la opción de usar el AzFilesHybridmódulo PowerShell para

realizar pasos similares a estos. El uso del AzFilesHybridmódulo
PowerShell implica descargar la versión más reciente del módulo del sitio
web de Microsoft e instalarlo en una computadora que está unida al
dominio y realizar los siguientes pasos:
1. Cambie la política de ejecución para permitir
la AzFilesHybridimportación del módulo de PowerShell:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope
CurrentUser
2. Cambie al directorio donde AzFilesHybridse descomprimió y copie

los archivos en su ruta para que los archivos se puedan llamar
directamente:
. \ CopyToPSPath.ps1
3. Importe el módulo a la sesión actual de PowerShell:

Import-Module -Name AzFilesHybrid
4. Inicie una sesión en su suscripción de Azure con una credencial de

Azure AD que tenga acceso de propietario o colaborador de la
cuenta de almacenamiento a la cuenta de almacenamiento que creó
para hospedar la instancia de recurso compartido de archivos de
Azure:
Connect-AzAccount
5. Complete la sesión de PowerShell con los valores de parámetro

adecuados y luego seleccione la suscripción adecuada si su cuenta
está asociada con varias suscripciones:
$ SubscriptionId = "<your-subscription-id-here>"
$ ResourceGroupName = "<recurso-grupo-nombre-aquí>"
$ StorageAccountName = "<storage-account-name-here>"
Select-AzSubscription -SubscriptionId $ SubscriptionId
6. El siguiente paso consiste en registrar la cuenta de almacenamiento

de destino con su entorno de AD local. Debe elegir una unidad
organizativa adecuada. Utilice el Get-ADOrganizationalUnitcmdlet
para determinar el nombre y DistinguishedNamela unidad
organizativa en la que desea alojar la cuenta registrada:
Join-AzStorageAccountForAuth `
-ResourceGroupName $ ResourceGroupName `
-StorageAccountName $ StorageAccountName `
-DomainAccountType "<ComputerAccount |
ServiceLogonAccount>" `
-OrganizationalUnitDistinguishedName "<ou-
distinguishedname-here>" #
Si no proporciona el nombre de la unidad organizativa como parámetro
de entrada, la identidad de AD que representa la cuenta de
almacenamiento se crea en el directorio raíz.
El AzStorageAccountAuthcmdlet Debug- le permite realizar un conjunto de
comprobaciones básicas en su configuración de AD con el usuario de AD
que inició sesión una vez que haya realizado el registro de la cuenta:
Debug-AzStorageAccountAuth -StorageAccountName $
StorageAccountName -ResourceGroupName
$ ResourceGroupName -Verbose
En caso de que no pueda configurar la cuenta de servicio local para que su

contraseña no caduque, deberá usar el Update-
AzStorageAccountADOjbectPasswordcmdlet para actualizar la cuenta de Azure
Storage cada vez que cambie la contraseña de su cuenta de servicio
local. Este cmdlet es parte del AzFilesHybridmódulo y debe ejecutarse en
un equipo en el entorno local unido a AD DS con una cuenta que tenga
permisos dentro de AD DS, así como permisos de propietario para la
cuenta de almacenamiento. El siguiente comando, con las sustituciones de
variables adecuadas, adquiere la segunda clave de la cuenta de
almacenamiento y actualiza la contraseña de la cuenta de servicio
registrada en AD DS:
# Actualice la contraseña de la cuenta de AD DS registrada
para la cuenta de almacenamiento
# Puede usar kerb1 o kerb2
Update-AzStorageAccountADObjectPassword `
-RotateToKerbKey kerb2 `
-ResourceGroupName "<your-resource-group-name-here>"
`
-StorageAccountName "<your-storage-ccount-name-here>"
Configuración de permisos a nivel de recursos
compartidos
El permiso de nivel de recurso compartido se configura asignando roles
RBAC en el recurso compartido de archivos de Azure. Los siguientes tres
roles están disponibles para asignar permisos de uso compartido de
archivos:
• Lector de recursos compartidos SMB de datos de archivos
de almacenamiento Este rol proporciona acceso de lectura a los
archivos compartidos de Azure a través de SMB a los usuarios que
tienen este rol.
• Colaborador de recurso compartido de SMB de datos de
archivo de almacenamiento Este rol permite a los usuarios que lo
tienen leer, escribir y eliminar acceso a los recursos compartidos
de almacenamiento de Azure a través de SMB.
• Colaborador elevado del recurso compartido SMB de
datos de archivos de almacenamiento Este rol permite el acceso
de lectura, escritura y eliminación, así como la capacidad de
modificar las Listas de control de acceso (ACL) de Windows de los
recursos compartidos de archivos de Azure Storage a través de
SMB.
Cuando se asignan varios roles, los permisos son acumulativos. La
excepción a esta regla es cuando se aplica un permiso de denegación; en
este caso, el permiso de denegación anula cualquier permiso permitido. Si
bien es posible asignar roles de RBAC y, por lo tanto, configurar permisos
de nivel de recurso compartido en el nivel de cuenta de almacenamiento,
en su lugar debe asignar roles de RBAC a nivel de recurso compartido de
archivos individual. El control administrativo total de los archivos
compartidos, que incluye la capacidad de tomar posesión de los archivos,
actualmente requiere la clave de la cuenta de almacenamiento. No puede
tomar posesión de un archivo con las credenciales de Azure AD.
Configuración de permisos de archivos y carpetas

Una vez que haya asignado permisos de nivel de recurso compartido a un
recurso compartido de archivos de Azure mediante RBAC, debe
configurar los permisos de archivo y carpeta en el contenido del recurso
compartido. Al leer la documentación de Azure, la mayoría de los
administradores de Windows Server reconocerán que los permisos NTFS
se conocen como ACL de Windows.
Puede configurar los permisos de archivos y carpetas con el Set-ACLcmdlet
de PowerShell, con el icacls.execomando o con el Explorador de archivos
de Windows si ha montado la carpeta compartida en una computadora
con un sistema operativo Windows Client o Windows Server.
Más información Autenticación de AD para archivos de Azure
Puede obtener más información sobre la autenticación de AD para Azure Files
en https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-active-
directory-domain-service-enable .
Autenticación de Azure AD DS
Anteriormente en este capítulo, aprendió sobre el uso de la autenticación
de AD DS local para proteger los recursos compartidos de archivos de
Azure. Además, puede usar Azure AD Domain Services para configurar la
autenticación para conexiones SMB a Azure File Shares. Azure AD Domain
Services es un servicio de Azure que funciona con Azure AD para
proporcionar la funcionalidad de los controladores de dominio en una
subred de Azure. Cuando habilita Azure AD DS, puede unirse a un
dominio de una máquina virtual de servidor o cliente de Windows
hospedada en una subred de Azure sin tener que implementar máquinas
virtuales que funcionen como controladores de dominio. No puede usar la
autenticación de Active Directory local y la autenticación de Azure AD DS
en la misma cuenta de almacenamiento o archivos compartidos.
Una vez que haya habilitado Azure AD DS en una suscripción, puede
habilitar el acceso basado en identidad a través de AD DS al crear la
cuenta de almacenamiento seleccionando la opción de identidad
de Azure Active Directory Domain Services (Azure AD DS) . También
puede habilitar esta opción en la página Configuración de la cuenta de
almacenamiento, como se muestra en la Figura 4-7 .
Figura 4-7 Habilitar la autenticación de Azure AD DS
También puede usar el Set-AzStorageAccountcmdlet de PowerShell con
el EnableAzureActiveDirectoryDomainServicesForFileparámetro para
habilitar la autenticación de Azure AD DS para un recurso compartido de
archivos de Azure. Por ejemplo, para habilitar la autenticación de Azure
AD DS para el recurso compartido de archivos de Azure
denominado tailwind-filesalmacenado en el grupo de recursos FilesRG,
ejecute este comando de PowerShell:
Set-AzStorageAccount -ResourceGroupName "FilesRG" `
-Nombre "archivos-viento-de-cola" `
-EnableAzureActiveDirectoryDomainServicesForFile $ true
Puede usar el az storage account updatecomando de la CLI de Azure con

la --enable-files-addsopción de habilitar la autenticación de Azure AD DS
para un recurso compartido de archivos de Azure. Por ejemplo, para
habilitar la autenticación de Azure AD DS para el recurso compartido de
archivos de Azure denominado tailwind-filesalmacenado en el grupo de
recursos FilesRG, ejecute el comando de la CLI de Azure:
actualización de la cuenta de almacenamiento az -n tailwind-
files -g FilesRG --enable-files-added $ true
Una vez que se ha habilitado la autenticación de Azure AD DS en la cuenta

de almacenamiento, puede usar la página de Control de acceso (IAM) de
las propiedades de la cuenta de almacenamiento para asignar uno de los
roles de RBAC de recursos compartidos de archivos de almacenamiento
descritos anteriormente en este capítulo como un permiso de nivel de
recurso compartido. En la figura 4-8 se muestra que el grupo de Azure AD
Tailwind-Engineers ha asignado el rol de colaborador de recursos
compartidos SMB de datos de archivos de almacenamiento al tailwind-
sharerecurso compartido de archivos de Azure.
Figura 4-8 Asignaciones de roles de archivos compartidos

El proceso para configurar permisos NTFS en archivos y carpetas es el
mismo que cuando habilita la autenticación para cuentas AD DS
locales. Primero monta el recurso compartido de archivos en una
computadora cliente o servidor de Windows, y luego usa herramientas
como el Explorador de archivos de Windows, PowerShell o
la icacls.exeutilidad para configurar los permisos.
Más información Autenticación de Azure AD DS
Puede obtener más información sobre la autenticación de Azure AD DS para Azure
Files en https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-
active-directory-domain-service-enable .
Configurar el cifrado del servicio de

almacenamiento
El cifrado de Azure Storage está habilitado de forma predeterminada para
todas las cuentas de almacenamiento, independientemente del
rendimiento o los niveles de acceso. Esto significa que no es necesario
modificar el código o las aplicaciones para habilitar Azure Storage
Encryption. Los datos almacenados en Azure se cifran y descifran de
forma transparente mediante el cifrado AES de 256 bits. No puede
deshabilitar el cifrado de Azure Storage y no es necesario modificar el
código o las aplicaciones para aprovechar el cifrado de Azure Storage.
Los blobs de bloques, los blobs de adición o los blobs de página escritos
en Azure Storage desde el 20 de octubre de 2017 están sujetos al cifrado
de Azure Storage. Microsoft ha emprendido un proceso en el que todos los
blobs creados antes de esta fecha se cifran retroactivamente. Si le
preocupa que un blob no esté cifrado, puede ver el estado de cifrado de
ese blob mediante la siguiente técnica:
1. En Azure Portal, navegue hasta la cuenta de almacenamiento que
desea verificar.
2. En la sección Contenedores de la página de la cuenta de Storage,
seleccione Contenedores en Blob Storage y luego ubique el
contenedor que aloja el blob que le interesa verificar. Abra ese
recipiente.
3. En el contenedor que abrió, seleccione el blob que desea verificar.
4. En la página Descripción general , verifique que
la configuración Servidor cifrado esté establecida en True, como se
Figura 4-9 Verificar el estado de cifrado de blob
Puede comprobar el estado de cifrado de un blob con el siguiente código
de PowerShell, sustituyendo los valores del código de ejemplo por los
valores del blob que desea comprobar:
$ cuenta = Get-AzStorageAccount -ResourceGroupName <resource-
group> `
-Nombre <cuenta-almacenamiento>
$ blob = Get-AzStorageBlob -Context $ cuenta.Context `
-Contenedor <contenedor> `
-Blob <blob>
$ blob.ICloudBlob.Properties.IsServerEncrypted
Para comprobar el estado de cifrado del blob mediante la CLI de Azure,
utilice el siguiente comando sustituyendo los valores del código de
ejemplo por los valores del blob que desea comprobar:
az Storage blob show \
--container-name <container> \
--nombre <blob> \
- consulta "properties.serverEncrypted"
Si tiene un blob en Azure que se creó antes del 20 de octubre de 2017 y

que no está cifrado, simplemente puede volver a escribir el blob, lo que
obligará a que se produzca el cifrado. Un método para hacer esto es
descargar el blob en su sistema de archivos local mediante AzCopy y
luego copiar el blob en Azure Storage.
Más información Cifrado del servicio de almacenamiento
Puede obtener más información sobre el cifrado del servicio de almacenamiento
en https://docs.microsoft.com/en-us/azure/storage/common/storage-service-encryption .
Gestión de claves de cifrado

De forma predeterminada, las cuentas de Azure Storage cifran los datos
almacenados mediante una clave de cifrado administrada por
Microsoft. En el caso de que se considere indeseable que Microsoft
administre las claves de cifrado de la cuenta de Azure Storage, puede
administrar el cifrado con sus propias claves, como se muestra en
la Figura 4-10 .
Figura 4-10 Configurar el tipo de cifrado
Cuando elige la opción de administrar el cifrado con las claves que
proporciona; tienes las siguientes opciones:
• Use una clave administrada por el cliente con Azure Key
Vault En este escenario, cargue su clave de cifrado en Azure Key
Vault o use las API de Azure Key Vault para generar claves. La
cuenta de almacenamiento y Key Vault deben estar en la misma
región de Azure y estar asociados con la misma tenencia de Azure
AD. No es necesario que la cuenta de almacenamiento y Key Vault
estén en la misma suscripción.
• Usar una clave proporcionada por el cliente en las
operaciones de Blob Storage En este escenario, las claves de
cifrado se proporcionan por solicitud. Las claves proporcionadas
por el cliente se pueden almacenar en Azure Key Vault o en un
almacén de claves alternativo.
Cifrado de infraestructura
Como aprendió anteriormente en este capítulo, Azure Storage cifra
automáticamente todos los datos de una cuenta de Azure Storage
mediante el cifrado AES de 265 bits. Cuando habilita el cifrado de
infraestructura, los datos de la cuenta de almacenamiento se cifrarán dos
veces. Los datos se cifran primero mediante un algoritmo de cifrado y una
clave en el nivel de servicio y luego se cifran en el nivel de infraestructura
mediante un algoritmo de cifrado y una clave de cifrado
independientes. Este doble cifrado protege los datos si uno de los
algoritmos o claves de cifrado se ve comprometido. Si bien el cifrado de
nivel de servicio le permite usar claves administradas por Microsoft o
administradas por el cliente, el cifrado de nivel de infraestructura solo usa
una clave administrada por Microsoft. El cifrado de infraestructura debe
estar habilitado durante la creación de la cuenta de almacenamiento.
Más información Cuenta de almacenamiento con cifrado de infraestructura
Puede obtener más información sobre el cifrado de infraestructura para cuentas de
almacenamiento en https://docs.microsoft.com/en-
us/azure/storage/common/infrastructure-encryption-enable .
Ámbitos de cifrado
Las cuentas de Azure Storage usan una única clave de cifrado para todas
las operaciones de cifrado en la cuenta de almacenamiento. Los ámbitos
de cifrado le permiten configurar claves de cifrado independientes en los
niveles de contenedor y blob. Esto permite escenarios como almacenar
datos de clientes de diferentes clientes en la misma cuenta de
almacenamiento mientras que los datos de cada cliente están protegidos
por una clave de cifrado diferente.
Para crear un nuevo alcance de cifrado, realice los siguientes pasos:
1. En Azure Portal, abra la cuenta de almacenamiento para la que
desea configurar los ámbitos de cifrado.
2. En la página de la cuenta de almacenamiento, seleccione Cifrado ,
como se muestra en la Figura 4-11 y luego seleccione Ámbitos de
cifrado .
Figura 4-11 Ámbitos de cifrado
3. En la página Ámbito de cifrado , haga clic en Agregar .
4. En la página Crear alcance de cifrado , proporcione un nombre de
alcance de cifrado y luego especifique si el alcance de cifrado
utilizará claves administradas por Microsoft o claves administradas
por el cliente, como se muestra en la Figura 4-12 .
Figura 4-12 Crear ámbito de cifrado
Una vez que tenga los alcances de cifrado presentes para una cuenta de
almacenamiento, puede especificar qué alcance de cifrado se usará para
blobs individuales cuando cree el blob o especificar un alcance de cifrado
predeterminado cuando cree un contenedor, como se muestra en
la Figura 4-13 .
Figura 4-13 Alcance de cifrado de contenedor nuevo
Puede modificar la clave de cifrado para un ámbito de cifrado realizando
los siguientes pasos:
1. En Azure Portal, abra la cuenta de almacenamiento para la que
desea configurar los ámbitos de cifrado.
2. En la página de la cuenta de almacenamiento,
seleccione Cifrado > Ámbitos de cifrado .
3. Seleccione el botón Más junto al ámbito de cifrado para el que
desea actualizar la clave de cifrado.
4. En la página Editar alcance de cifrado que se muestra en la Figura
4-14 , cambie el Tipo de cifrado y luego haga clic en Guardar .
Figura 4-14 Editar el alcance del cifrado

Más información Ámbitos de cifrado de cuentas de almacenamiento
Puede obtener más información sobre los alcances de cifrado de cuentas de
almacenamiento en https://docs.microsoft.com/en-us/azure/storage/blobs/encryption-
scope-manage .
Protección contra amenazas avanzada para

Azure Storage
Advanced Threat Protection (ATP) para Azure Storage le permite detectar
intentos inusuales y malintencionados de interactuar con las cuentas de
Azure Storage. Cuando habilita ATP para Azure Storage, las alertas de
seguridad se activarán cuando Azure detecte una actividad anómala de la
cuenta de almacenamiento. Estas detecciones se basan en patrones
reconocidos existentes de actividad maliciosa identificados por los
investigadores de seguridad de Microsoft. Estas alertas están integradas
con Azure Security Center y también se pueden reenviar por correo
electrónico a los administradores de la suscripción. La información de
alerta detallará la naturaleza de la actividad sospechosa y brindará
recomendaciones sobre cómo investigar más y remediar estos
problemas. Específicamente, una alerta de Azure Storage ATP le
informará de
• La naturaleza de la anomalía
• Nombre de la cuenta de almacenamiento
• Hora del evento
• Tipo de almacenamiento
• Causas probables
• Pasos de la investigación
• Pasos de remediación
ATP para Azure Storage está disponible para Blob Storage, archivos de
Azure y Azure Data Lake Storage Gen2. Las cuentas de uso general V2,
block blob y Blob Storage admiten este servicio.
Más información Protección contra amenazas avanzada de Azure Storage
Puede obtener más información sobre Azure Storage Advanced Threat Protection
en https://docs.microsoft.com/en-us/azure/storage/common/storage-advanced-threat-
protection?tabs=azure-security-center .

Recuerde que una SAS de cuenta o delegación de usuarios siempre
será una SAS ad-hoc. No puede utilizar políticas de acceso
almacenadas para los tipos SAS de delegación de usuarios o cuentas.
HABILIDAD 4.2: CONFIGURAR LA
SEGURIDAD PARA BASES DE DATOS
Este objetivo trata de los pasos que puede seguir para proteger las
instancias de la base de datos SQL de Azure. Para dominar este objetivo,
deberá comprender cómo configurar la autenticación de la base de datos,
cuáles son las opciones para la auditoría de la base de datos, cuáles son
los beneficios de la Protección contra amenazas avanzada de Azure SQL
Database, cómo configurar el cifrado de la base de datos y cómo habilitar
Azure SQL Database Always. Cifrado en columnas específicas de la tabla
de la base de datos.
Habilitar la autenticación de la base de datos

Cuando crea una instancia de servidor de base de datos de Azure SQL,
crea un inicio de sesión de administrador y una contraseña asociada con
ese inicio de sesión. Esta cuenta administrativa otorgó permisos
administrativos completos en todas las bases de datos hospedadas fuera
de la instancia de Azure SQL como principal de nivel de servidor. Este
inicio de sesión tiene todos los permisos posibles en la instancia de Azure
SQL y no se puede limitar
Se dbocrea una cuenta de usuario separada llamada para el inicio de
sesión del administrador para cada base de datos de
usuario. El dbousuario tiene todos los permisos de la base de datos y está
asignado a la db_ownerfunción de la base de datos. Puede determinar la
identidad de la cuenta de administrador para una base de datos de Azure
SQL en la página Propiedades de la base de datos en Azure Portal, como
Figura 4-15 Inicio de sesión del administrador del servidor

El identificador de inicio de sesión del administrador no se puede cambiar
una vez que se crea la base de datos. Puede restablecer la contraseña de
esta cuenta seleccionando el servidor SQL de Azure en el portal de Azure
y seleccionando Restablecer contraseña en la página Información
general , como se muestra en la Figura 4-16 .
Figura 4-16 Restablecer contraseña

Al agregar usuarios administrativos, las siguientes opciones están
disponibles:
• Puede crear una cuenta de administrador de Azure Active
Directory. Si habilita la autenticación de Azure Active Directory,
puede configurar una cuenta de usuario o grupo en Azure AD con
permisos administrativos. Puede hacer esto seleccionando
la sección Administrador de Active Directory en
la configuración Azure SQL Instances y luego configurando una
cuenta de administrador haciendo clic en el botón Establecer
administrador (consulte la Figura 4-17 ).
Figura 4-17 Configuración de Active Directory Admin para Azure SQL

Server
• Cree un inicio de sesión SQL adicional en la base de datos
maestra, cree una cuenta de usuario asociada con este inicio de
sesión en la base de datos maestra y luego agregue esta cuenta de
usuario al dbmanagerrol, el loginmanagerrol o ambos roles en la base
de datos maestra usando la ALTER ROLEdeclaración.
Para crear cuentas adicionales para usuarios no administrativos, cree
inicios de sesión SQL en la base de datos maestra y luego cree cuentas de
usuario en cada base de datos a la que el usuario requiera acceso y asocie
esa cuenta de usuario con el inicio de sesión SQL.
Más información inicios de sesión, cuentas de usuario, roles y permisos
us/azure/azure-sql/database/logins-create-manage .
Habilitar la auditoría de la base de datos

La auditoría le permite realizar un seguimiento de los eventos de la base
de datos, como la adición o eliminación de tablas. Los registros de
auditoría para las bases de datos de Azure SQL se pueden almacenar en
una cuenta de Azure Storage, en un área de trabajo de Log Analytics o en
Event Hubs. La auditoría para Azure SQL se puede definir tanto a nivel de
servidor como a nivel de base de datos. Las diferencias son las siguientes:
• Si configura una política de servidor, se aplicará a todas las
bases de datos existentes y creadas recientemente en la instancia
del servidor SQL de Azure.
• Cuando la auditoría del servidor está habilitada a nivel de
instancia, siempre se aplicará a la base de datos.
• Habilitar la auditoría en una base de datos SQL de Azure
individual no anulará ninguna configuración de auditoría del
servidor, ya que ambas auditorías existen en paralelo.
• Microsoft recomienda no habilitar tanto la auditoría del
servidor como la auditoría de blobs en la base de datos, a menos
que desee utilizar una cuenta de almacenamiento, un período de
retención o un espacio de trabajo de Log Analytics diferente para
una base de datos específica o si desea auditar un conjunto
separado de tipos de eventos de categorías para una base de datos
específica. .
Para habilitar la auditoría para una instancia de SQL, realice los siguientes
pasos:
1. En Azure Portal, abra la instancia de Azure SQL en la que desea
configurar la auditoría.
2. En el nodo Seguridad , seleccione Auditoría , como se muestra en
la Figura 4-18 .
Figura 4-18 Auditoría en una página de propiedades de Azure SQL
Server
3. Establezca el control deslizante Auditoría en Activado , como se
muestra en la Figura 4-19 . Especifique el destino del registro de
auditoría. Puede elegir entre Storage , Log Analytics o Event
Hub y hacer clic en Guardar .
Figura 4-19 Configuración de auditoría de Azure SQL

Puede configurar registros de auditoría para que se escriban en cuentas
de Azure Storage, Event Hubs y áreas de trabajo de Log Analytics, que
pueden consumir los registros de Azure Monitor. Puede elegir que los
datos se escriban en varias ubicaciones si así lo desea. Al auditar a un
destino de almacenamiento, el período de retención es ilimitado. Puede
modificar la configuración de retención para que los registros de
auditoría se mantengan durante un período de tiempo más corto. La
Figura 4-20 muestra la configuración de Retención (Días) configurada
en 14 días.
Figura 4-20 Auditoría de la retención de almacenamiento
Puede ver los registros de auditoría haciendo clic en el elemento Ver
registros de auditoría de la página de auditoría de la instancia del
servidor SQL de Azure. Desde esta página, puede ver la información de
auditoría desde el servidor o el nivel de la base de datos, como se muestra
en la Figura 4-21 .
Figura 4-21 Registros de auditoría
También tiene la opción de hacer clic en Log Analytics para ver los
registros en el espacio de trabajo de Log Analytics. Si hace clic en Ver
panel , podrá ver un panel de auditoría que incluirá acceso a datos
confidenciales e información de seguridad, como se muestra en la Figura
4-22 .
Figura 4-22 Panel de auditoría

Más información sobre auditoría para Azure SQL Database
Puede obtener más información sobre la auditoría de Azure SQL Database
en https://docs.microsoft.com/en-us/azure/azure-sql/database/auditing-overview .
Configurar la protección contra amenazas
avanzada de Azure SQL Database
La Protección contra amenazas avanzada de Azure SQL Database le
permite detectar actividad inusual que indica que un tercero podría estar
intentando atacar las bases de datos de Azure SQL de su
organización. Cuando habilita la Protección contra amenazas avanzada de
Azure SQL Database, se le notificará cuando se produzca una actividad
inusual en la base de datos, cuando haya posibles vulnerabilidades en la
base de datos dada la configuración actual y cuando se produzcan ataques
de inyección de SQL. Azure SQL Database Advanced Threat Protection se
integra con Azure Security Center, por lo que también se le
proporcionarán recomendaciones sobre cómo investigar más a fondo y
remediar las actividades sospechosas y las amenazas.
Para configurar la Protección contra amenazas avanzada de Azure SQL
Database, realice los siguientes pasos:
1. En Azure Portal, abra la instancia de Azure SQL Server para la que
desea configurar ATP.
2. En el nodo Seguridad , haga clic en Seguridad de datos avanzada ,
Figura 4-23 Sección de seguridad de datos avanzada
3. En la página Seguridad de datos avanzada que se muestra en
la Figura 4-24 , configure los siguientes ajustes:
1. Seguridad de datos avanzada Esta funcionalidad tiene
un costo mensual, que incluye descubrimiento de datos,
clasificación, evaluación de vulnerabilidades y protección
avanzada contra amenazas. Estos servicios le permiten
detectar datos que podrían estar en riesgo, como datos
personales almacenados en la base de datos, así como
vulnerabilidades que podrían no ser detectadas por otros
medios pero que se hacen evidentes a través del análisis de la
actividad de la base de datos.
2. Suscripción Esta configuración determina a qué
suscripción se facturará la configuración de evaluación de
vulnerabilidades.
3. Cuenta de almacenamiento Aquí es donde se
registrarán los datos de las evaluaciones.
4. Exploraciones periódicas periódicas Esta
configuración determina si las exploraciones periódicas de
evaluación de vulnerabilidades se ejecutan en la instancia de
Azure SQL. Puede especificar la dirección de correo
electrónico a la que se enviarán los informes de escaneo.
5. Configuración avanzada de protección contra
amenazas Puede configurar dónde se reenviará la
información avanzada sobre protección contra amenazas.
Figura 4-24 Opciones de seguridad de datos avanzada
4. En la página Tipos de protección avanzada contra amenazas
que se muestra en la Figura 4-25 , elija de cuáles de las siguientes
alertas de protección avanzada desea recibir notificaciones.
0. Inyección de SQL Se ha producido una inyección
de SQL en una instancia de SQL supervisada.
1. Vulnerabilidad de inyección de SQL Se detectó una
vulnerabilidad de aplicación a la inyección de SQL.
2. Los datos exfiltración se detectó actividad exfiltración
de datos que se asemeja.
3. Acción insegura Se detectó una acción potencialmente
insegura.
4. Fuerza bruta Se detectó un ataque de fuerza bruta.
5. Inicio de sesión de cliente anómalo Se detectó un
inicio de sesión con características sospechosas.
Figura 4-25 Opciones de protección contra amenazas avanzadas
Más información Protección contra amenazas avanzada para Azure SQL Database
Puede obtener más información sobre la protección contra amenazas avanzada de
Azure SQL Database en https://docs.microsoft.com/en-us/azure/azure-
sql/database/threat-detection-overview .
Implementar el cifrado de la base de datos

El cifrado de datos transparente (TDE) le permite proteger las bases de
datos de Azure SQL cifrando los datos en reposo. Cuando habilita TDS, las
bases de datos, las copias de seguridad asociadas y los archivos de
registro de transacciones se cifran y descifran automáticamente, según
sea necesario. TDE está habilitado de forma predeterminada para todas
las nuevas bases de datos de Azure SQL. TDE se configura en el nivel del
servidor y todas las bases de datos hospedadas en la instancia de Azure
SQL Server lo heredan.
Azure SQL TDE tiene una clave de cifrado de base de datos (DEK)
protegida por un certificado de servidor integrado que es único para cada
instancia de Azure SQL y aprovecha el algoritmo de cifrado AES
256. Microsoft rota automáticamente estos certificados de seguridad.
El TDE administrado por el cliente, también conocido como "Traiga su
propia clave" (BYOK), es compatible con Azure SQL. Cuando configura
BYOK, la clave de protección TDE se almacena en Azure Key
Vault. Cuando configura BYOK, configura Azure Key Vault con permisos
para que la instancia de Azure SQL pueda interactuar con Key Vault para
recuperar la clave. Si el Key Vault eseliminado o la instancia de Azure SQL
pierde los permisos para Key Vault en un escenario BYOK, la base de
datos será inaccesible.
Puede verificar que TDE está habilitado para una instancia de Azure SQL
seleccionando la sección Cifrado de datos transparente de la página de
propiedades de una instancia de servidor de base de datos en Azure
Portal, como se muestra en la Figura 4-26 .
Figura 4-26 Clave administrada por el servicio TDE
Si desea cambiar a una clave administrada por el cliente para una
instancia de Azure SQL, primero debe crear y configurar un almacén de
claves de Azure en la misma región que la instancia de Azure SQL. Luego,
puede usar el portal para crear una clave en Key Vault y configurar la
instancia de Azure SQL con los permisos adecuados. Para cambiar una
base de datos a una clave administrada por el cliente, realice los
siguientes pasos:
1. En la página Cifrado de datos transparente de la instancia de la
base de datos de Azure SQL, seleccione Clave administrada por el
cliente .
2. El método de selección de clave ofrece dos opciones: puede
elegir Ingresar un identificador de clave o puede
elegir Seleccionar una clave y luego hacer clic en
el enlace Cambiar clave , como se muestra en la Figura 4-27 .
Figura 4-27 Configurar la clave administrada por el cliente
3. En la página Seleccionar clave de Azure Key Vault , seleccione la
suscripción y el Key Vault que alojará la clave.
4. Si no hay una clave adecuada en Key Vault, puede hacer clic
en Crear nuevo . Esto le permitirá crear una clave, como se
Figura 4-28 Crear una clave para BYOK
5. En la página Seleccionar clave de Azure Key Vault , seleccione la
versión de la clave, como se muestra en la Figura 4-29 . Si acaba de
crear la clave, solo estará disponible la versión más reciente.
Figura 4-29 Selección de una tecla para BYOK

6. Haga clic en Guardar para configurar Azure SQL para usar su clave
de cliente.
Más información Cifrado de base de datos SQL de Azure
Puede obtener más información sobre el cifrado de Azure SQL Database
en https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/sql-
server-encryption?view=azuresqldb-current .
Implementar Azure SQL Database Always

Encrypted
Always Encrypted es una tecnología disponible para Azure SQL que le
permite proteger tipos específicos de datos confidenciales que tienen un
patrón reconocible conocido, como números de pasaporte, números de
identificación de archivos de impuestos y números de tarjetas de
crédito. Cuando Always Encrypted está habilitado, los clientes que
interactúan con el servidor de la base de datos cifrarán los datos
confidenciales dentro de las aplicaciones del cliente y no reenviarán las
claves de cifrado utilizadas para descifrar esos datos al servidor de la base
de datos que almacenará esos datos. Esto garantiza que los
administradores que administran los servidores de Azure SQL no puedan
ver los datos confidenciales protegidos por Always Encrypted.
Cifrado determinista o aleatorio

Always Encrypted admite dos formas de cifrado: cifrado determinista y
cifrado aleatorio:
• Cifrado determinista Cuando utiliza cifrado determinista,
siempre se generará el mismo valor cifrado para el mismo valor de
texto sin formato, aunque este valor será único para cada base de
datos. La implementación del cifrado determinista le permitirá
realizar búsquedas de puntos, uniones de igualdad, agrupación e
indexación en columnas cifradas. Sin embargo, puede permitir que
usuarios no autorizados adivinen información sobre valores
cifrados buscando patrones en columnas cifradas. Esto es
especialmente cierto si hay un pequeño conjunto de valores
posibles. El cifrado determinista requiere que la intercalación de
columnas esté configurada con un orden de clasificación binary2
para las columnas de caracteres.
• Cifrado aleatorio Cuando configura el cifrado aleatorio, los
datos se cifran de una manera menos predecible. Si bien el cifrado
aleatorio es más seguro que el cifrado determinista, habilitar el
cifrado aleatorio evita la búsqueda, agrupación, indexación y la
realización de uniones en columnas cifradas.
En general, debe planificar el uso de encriptación determinista si las
columnas se usarán para los buscadores o donde se agruparán los
parámetros. Un ejemplo de esto es donde necesitabusque un número de
pasaporte específico. El cliente podrá realizar el hash del valor de la
consulta y luego ubicar los valores dentro de la base de datos que
coincidan con ese hash cifrado. Debe utilizar el cifrado aleatorio si su base
de datos tiene información que no está agrupada con otros registros y que
no se utiliza para unir tablas, como notas médicas.
Configuración de Always Encrypted

Configurar Always Encrypted es una actividad que requiere el uso de
herramientas del lado del cliente. No puede usar instrucciones de
Transact SQL para configurar Always Encrypted y, en su lugar, debe
configurar Always Encrypted mediante SQL Server Management Studio o
PowerShell. La configuración de Always Encrypted requiere realizar las
siguientes tareas:
• Aprovisionamiento de claves maestras de columna, claves de
cifrado de columna y claves de cifrado de columna cifradas con las
claves maestras de columna correspondientes
• Creando metadatos clave en la base de datos
• Creando nuevas tablas con columnas encriptadas
• Cifrar datos existentes en columnas de base de datos
seleccionadas
Always Encrypted no es compatible con columnas que tienen las
siguientes características:
• Columnas
con xml, timestamp/rowversion, image, ntext, text, sql_variant, hierarchy
id, geography, geometry, aliastipos o tipos definidos por el usuario
• FILESTREAM columnas
• Columnas con la IDENTITYpropiedad
• Columnas con ROWGUIDCOLpropiedad
• Columnas de cadena sin bin2colecciones.
• Columnas que son claves para índices agrupados y no
agrupados (si usa cifrado aleatorio)
• Columnas que son claves para índices de texto completo (si
usa cifrado aleatorio)
• Columnas calculadas
• Columnas referenciadas por columnas calculadas
• Conjunto de columnas dispersas.
• Columnas a las que hacen referencia las estadísticas (si utiliza
cifrado aleatorio)
• Columnas que usan tipos de alias
• Partición de columnas
• Columnas con restricciones predeterminadas
• Columnas referenciadas por restricciones únicas (si está
utilizando cifrado aleatorio)
• Columnas de clave primaria (si está utilizando cifrado
aleatorio)
• Hacer referencia a columnas en restricciones de clave externa
• Columnas referenciadas por restricciones de verificación
• Seguimiento de columnas mediante captura de datos
modificados
• Columnas de clave primaria en tablas que tienen habilitado el
seguimiento de cambios
• Columnas enmascaradas mediante el enmascaramiento
dinámico de datos
• Columnas en tablas de bases de datos extensibles
Para configurar Always Encrypted en una base de datos de Azure SQL
mediante SQL Server Management Studio, realice los siguientes pasos:
1. Conéctese a la base de datos que aloja las tablas con columnas que
desea cifrar mediante el Explorador de objetos en SQL Server
Management Studio. Si la base de datos aún no existe, puede crear
la base de datos y luego crear las tablas que configurará para usar
Always Encrypted.
2. Haga clic con el botón derecho en la base de datos,
seleccione Tareas > Cifrar columnas . Esto abrirá el asistente
Always Encrypted . Haga clic en Siguiente .
3. En la página Selección de columnas , expanda las tablas de bases
de datos y luego seleccione las columnas que desea cifrar.
4. Para cada columna seleccionada, deberá establecer el atributo Tipo
de cifrado en Determinista o Aleatorio .
5. Para cada columna seleccionada, deberá elegir una clave de
cifrado . Si aún no tiene una clave de cifrado, puede hacer que se
genere una automáticamente.
6. En la página Configuración de la llave maestra , elija una
ubicación para almacenar la llave. A continuación, deberá
seleccionar una fuente de clave maestra.
7. En la página Validación , seleccione si desea ejecutar el script
inmediatamente o usar un script de PowerShell más tarde.
8. En la página Resumen , revise la opción seleccionada y haga clic
en Finalizar .
Más información Azure SQL Database Always Encrypted
Puede obtener más información sobre Azure SQL Database Always Encrypted
en https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/always-
encrypted-database-engine?view=sql-server-ver15 .

Recuerde la diferencia entre cifrado determinista y aleatorio.
HABILIDAD 4.3: CONFIGURAR Y

ADMINISTRAR KEY VAULT
Este objetivo trata de configurar y administrar Azure Key Vault, que se
puede considerar como un módulo de seguridad de hardware en la nube
(HSM). Puede usar Azure Key Vault para almacenar de forma segura
claves y secretos de cifrado, incluidos certificados, cadenas de conexión
de bases de datos y contraseñas de máquinas virtuales. En esta sección,
aprenderá a asegurarse de que los elementos almacenados en Azure Key
Vault solo sean accesibles para las aplicaciones y los usuarios
autorizados. Para dominar este objetivo,deberá comprender cómo
administrar el acceso a Key Vault, incluido cómo configurar permisos
para secretos, certificados y claves. También deberá comprender cómo
configurar RBAC para administrar Key Vault. También deberá
comprender cómo administrar los elementos dentro de Key Vault,
incluido cómo rotar claves y cómo realizar copias de seguridad y
recuperación en elementos seguros de Key Vault.
Administrar el acceso a Key Vault

Azure Key Vault le permite almacenar información que no debe hacerse
pública, como secretos, certificados y claves. Debido a que Key Vault
puede almacenar información confidencial, naturalmente desea limitar
quién tiene acceso a ella en lugar de permitir el acceso a todo el
mundo. Usted administra el acceso a Key Vault en el plano de
administración y en el plano de datos. El plano de administración
contiene las herramientas que usa para administrar Key Vault, como
Azure Portal, Azure CLI y Cloud Shell. Cuando controla el acceso en el
plano de administración, puede configurar quién puede acceder al
contenido de Key Vault en el plano de datos. Desde la perspectiva de Key
Vault, el plano de datos involucra los elementos almacenados dentro de
Key Vault, y los permisos de acceso permiten la capacidad de agregar,
eliminar y modificar certificados, secretos y claves. El acceso a Key Vault
tanto en el plano de gestión como en los planos de datos debe estar lo más
restringido posible. Si un usuario o aplicación no necesita acceso a Key
Vault, no debería tener acceso a Key Vault. Microsoft recomienda que
utilice Key Vaults independientes para los entornos de desarrollo,
preproducción y producción.
Cada Key Vault que cree está asociado con el arrendamiento de Azure AD
que está vinculado a la suscripción que hospeda Key Vault. Todos los
intentos de administrar o recuperar contenido de Key Vault requieren
autenticación de Azure AD. Una ventaja de requerir la autenticación de
Azure AD es que le permite determinar qué entidad de seguridad está
intentando acceder. El acceso a Key Vault no se puede otorgar en función
de tener acceso a un secreto o clave y requiere algún tipo de identidad de
Azure AD.
Más información Seguridad de Key Vault
Puede obtener más información sobre Key Vault Security
en https://docs.microsoft.com/en-us/azure/key-vault/general/overview-security .
Cortafuegos y redes virtuales de Key Vault

La página de red de la cámara acorazada de un Clave de red página, se
muestra en la Figura 4-30 , permite configurar las ubicaciones de red
desde la que se puede acceder a una clave específica Vault. Puede
configurar Key Vault para que sea accesible desde todas las redes o desde
redes virtuales específicas y conjuntos de rangos de direcciones IPv4.
Figura 4-30 Cortafuegos y redes virtuales
Al configurar las reglas de acceso a la red para Azure Key Vault, tenga en
cuenta lo siguiente:
• Cada Key Vault se puede configurar con un máximo de 127
reglas de red virtual y 127 reglas de IPv4.
• Las máscaras de subred CIDR / 31 y / 32 no son
compatibles. En lugar de direcciones IP individuales, se deben
permitir reglas al permitir el acceso desde estas subredes.
• Las reglas de red IP solo se pueden configurar para rangos de
direcciones IP públicas. Debe usar reglas de red virtual para rangos
de direcciones IP privadas.
• Actualmente, las reglas de firewall de Azure Key Vault no
admiten direcciones IPv6.
Puede configurar los firewalls de Key Vault y las redes virtuales en Azure
Portal realizando los siguientes pasos:
1. En Azure Portal, abra el Key Vault que desea configurar.
2. En Configuración , seleccione Redes . En la página Redes ,
seleccione Cortafuegos y redes virtuales .
3. De forma predeterminada, se podrá acceder a Key Vault desde
todas las redes. Seleccione la opción Punto final privado y redes
seleccionadas . Cuando habilita esta opción, los servicios
confiables de Microsoft pueden eludir el firewall. Puede
deshabilitar el acceso desde los servicios de confianza de Microsoft
si lo desea.
4. Para agregar una red virtual existente o una nueva red virtual, haga
clic en los elementos Agregar redes virtuales
existentes o Agregar nuevas redes virtuales , como se muestra
en la Figura 4-31 .
Figura 4-31 Punto final privado y redes seleccionadas

5. Cuando agrega una red virtual, debe seleccionar la suscripción, la
red virtual y las subredes a las que desea otorgar acceso a Key
Vault, como se muestra en la Figura 4-32 . Si un punto final de
servicio no está presente en la subred de la red virtual, puede
habilitar uno.
Figura 4-32 Agregar redes
6. Para agregar un rango de direcciones IPv4, ingrese la dirección IPv4
o el rango CIDR, como se muestra en la Figura 4-33 .
Figura 4-33 Cortafuegos de Key Vault.
7. Haga clic en Guardar para guardar la configuración de Firewall y
redes virtuales .
Puede utilizar la pestaña Conexiones de punto final privado para agregar
acceso de punto final privado a un Key Vault específico. Un punto de
conexión privado de Azure es una interfaz de red que permite una
conexión privada y segura a un servicio mediante un enlace privado de
Azure. Azure Private Link permite el acceso a los servicios Azure PaaS,
como Azure Key Vault, a través de una conexión privada en la red troncal
de Microsoft. Ningún tráfico que atraviesa un enlace privado pasa por la
Internet pública.
Más información Key Vault Firewalls y redes virtuales
Puede obtener más información sobre los firewalls y las redes virtuales de Key Vault
en https://docs.microsoft.com/en-us/azure/key-vault/general/network-security .
Gestionar permisos para secretos, certificados y

claves.
Utiliza las políticas de control de acceso de Key Vault para administrar los
permisos sobre secretos, certificados y claves en el nivel del plano de
datos. Cada política de control de acceso de Key Vault incluye entradas
que especifican qué acceso tiene el principal de seguridad designado a las
claves, secretos y certificados. Cada Key Vault admite un máximo de 1024
entradas de política de acceso.
Una entrada de política de acceso otorga un conjunto distinto de permisos
a una entidad de seguridad. Una entidad de seguridad puede ser un
usuario, una entidad de servicio, una identidad gestionada o un
grupo. Microsoft recomienda asignar permisos a grupos y luego agregar y
eliminar usuarios, entidades de servicio e identidades administradas
hacia y desde esos grupos como una forma de otorgar o revocar permisos.
Puede configurar los permisos para las claves, secretos y certificados
descritos en la Tabla 4-3 .
Tabla 4-3 Permisos del almacén de claves
Permisos de certificado Permisos clave Permisos
Obtener Ver la versión actual del certificado Descifrar Realice una Obtenga
en Key Vault. operación de descifrado
con la clave. Lista List
Lista Muestra los certificados actuales y las versiones
versiones de certificados en Key Vault. Encriptar Realiza una
operación de encriptación Establece
Eliminar Elimina un certificado de Key con la clave. secreto.
Vault.
UnwrapKey Utilice la Eliminar
Crear Crear un certificado de Key Vault. clave para descifrar la secreto.
Importar Importar material de certificado a clave. Copia de
un certificado de Key Vault. WrapKey Utilice la clave de segurid
para el cifrado de claves. Key Vault
Actualizar Actualiza un certificado en Key
Vault. Verificar Utilice la clave Restaura
para verificar una firma. secreto gu
Administrar contactos Administre los Vault.
contactos del certificado de Key Vault. Firmar Utilice la clave
para la operación de firma. Recupera
Getissuers Ver la autoridad emisora del secreto el
certificado Obtenga Leer las partes
públicas de una clave. Purgar E
Listissuers Muestra la información de la permanen
autoridad emisora de un certificado. Lista Lista todas las claves secreto el
Setissuers Actualizar una autoridad de de la bóveda.
certificación o emisores de Key Vault.
Permisos de certificado Permisos clave Permisos
Deleteissuers Elimina información sobre Actualizar Modifica los

las autoridades de certificación o los atributos / metadatos de la
emisores de Key Vault. clave.
Manageissuers Administre la lista de Crear Crea una clave en un
autoridades / emisores de certificados de Key Vault.
Key Vault.
Importar Importa una
Recuperar Recupera un certificado que se clave existente en un Key
ha eliminado de un Key Vault. Vault.
Copia de seguridad Realice una copia Eliminar Elimina una
de seguridad de un certificado almacenado clave de un Key Vault.
en Key Vault.
Copia de
Restaurar Restaurar un certificado de Key seguridad Exporta una
Vault con copia de seguridad. clave en forma protegida.
Purgar Elimina permanentemente un Restaurar Importar una
certificado eliminado. clave previamente
respaldada.
Recuperar Recupera una
clave eliminada.
Purgar Elimina
permanentemente una
clave eliminada.
Las políticas de acceso de Key Vault no le permiten configurar el acceso
granular a claves, secretos o certificados específicos. Solo puede asignar
un conjunto de permisos en los niveles de claves, secretos o
certificados. Si necesita permitir que una entidad de seguridad específica
acceda solo a algunas y no a todas las claves, secretos o certificados. En su
lugar, debe almacenar esas claves, secretos o certificados en Key Vaults
separados. Por ejemplo, si hay tres secretos que necesita proteger con
Key Vault, y un usuario solo debe tener acceso a dos de esos secretos,
deberá almacenar el tercero de esos secretos en un Key Vault separado de
los dos primeros. .
Se utiliza el Set-AzKeyVaultAccessPolicyAzure PowerShell para configurar
una política clave de bóveda usando Azure PowerShell. Al usar este
cmdlet, los parámetros importantes son el nombre de la bóveda, el
nombre del grupo de recursos, el identificador principal de seguridad,
que puede ser UserPrincipalName,ObjectID, ServicePrincipalNameY luego los
parámetros que definen los permisos a las claves, secretos y
certificados. El Set-AzKeyVaultACcessPolicycmdlet tiene el siguiente
formato:
Set-AzKeyVaultAccessPolicy -VaultName <your-key-vault-name> -
PermissionsToKeys
<permissions-to-keys> -PermissionsToSecrets <permissions-to-

secrets>
-PermissionsToCertificates <permissions-to-certificates> -
ObjectId <Id>
Si prefiere la CLI de Azure, puede usar el az keyvault set-policycomando

para configurar las políticas de acceso a los elementos de Key Vault. El az
keyvault set-policycomando tiene el siguiente formato:

az keyvault set-policy -n <your-unique-keyvault-name> --spn
<ApplicationID-of-your-
service-principal> --secret-permissions <secret-permissions>

--key-permissions <clave-
permisos> --certificate-permissions <certificate-permissions>
Más información Administrar permisos para elementos de Key Vault

us/azure/key-vault/general/group-permissions-for-apps .
Configurar el uso de RBAC en Azure Key Vault

RBAC le permite proteger Azure Key Vault en el plano de
administración. A mediados de 2020, Microsoft introdujo un nuevo
conjunto de roles RBAC que proporcionan una forma simplificada de
asignar permisos al contenido de Key Vaults. En el futuro, solo debe
configurar políticas de acceso cuando necesite configurar permisos
complejos que no estén cubiertos por los nuevos roles de RBAC. Usted
asigna roles de Key Vault RBAC en la página de Control de acceso (IAM)
de las propiedades de Key Vault, como se muestra en la Figura 4-34 . Si
bien también puede asignar roles de Key Vault RBAC a nivel de grupo de
recursos, suscripción y grupo de administración, la mejor práctica de
seguridad es asignar roles con el alcance más estrecho posible.
Figura 4-34 Agregar asignación de funciones

Los roles de RBAC para Azure Key Vault son los siguientes:
• Administrador de Key Vault Puede realizar cualquier acción
sobre secretos, certificados y claves en un Key Vault, excepto la
gestión de permisos
• Oficial de certificados de Key Vault Puede realizar
cualquier acción en los certificados de Key Vault, excepto la gestión
de permisos
• Colaborador de Key Vault Permite la administración de Key
Vault pero no permite el acceso a los elementos dentro de un Key
Vault
• Oficial de cifrado de Key Vault Puede realizar cualquier
acción en las claves de Key Vault, excepto la gestión de permisos
• Cifrado del servicio de cifrado de Key Vault Tiene acceso
de lectura a los metadatos de claves y puede realizar operaciones
de empaquetado y desencadenamiento
• Usuario criptográfico de Key Vault Puede realizar
operaciones criptográficas en claves y certificados
• Lector de Key Vault Puede leer los metadatos de los
elementos de Key Vault pero no el contenido de los elementos de
Key Vault
• Oficial de secretos de Key Vault Puede realizar todas las
acciones sobre los secretos de Key Vault, excepto la gestión de
permisos
• El usuario de Key Vault Secrets puede leer el contenido de
los secretos
Más información Importante Configurar RBAC en KEY Vault
Puede obtener más información sobre este tema en http://docs.microsoft.com/en-
us/azure/key-vault/general/secure-your-key-vault .
Administrar certificados
Azure Key Vault admite las siguientes acciones de administración para
certificados x509:
• Permite la creación de un certificado x509 o la importación de
un certificado x509
• Admite certificados generados por la autoridad de
certificación y certificados autofirmados
• Permite al propietario de un certificado de Key Vault
almacenar ese certificado de forma segura sin necesidad de acceder
a la clave privada.
• Permite al propietario de un certificado configurar políticas
que permitan a Key Vaults administrar los ciclos de vida de los
certificados.
• Permite a los propietarios de certificados proporcionar
información de contacto para que puedan ser notificados sobre
eventos del ciclo de vida, incluida la expiración y renovación de
certificados.
• Se puede configurar para admitir la renovación automática de
certificados con autoridades de certificación específicas del socio
de Key Vault x509
Las políticas de certificados brindan información a Key Vault sobre cómo
crear y administrar el ciclo de vida de un certificado almacenado en Key
Vault. Esto incluye información sobre si la clave privada del certificado es
exportable. Cuando crea un certificado en un Key Vault por primera
veztiempo, se debe proporcionar una póliza. Una vez que se establezca
esta política, no necesitará la política para las operaciones de creación de
certificados posteriores. Las políticas de certificados contienen los
siguientes elementos:
• Propiedades del certificado X509 Incluye el nombre del
sujeto, los nombres alternativos del sujeto y otras propiedades
utilizadas durante la creación de un certificado x509.
• Propiedades de la clave Especifica el tipo de clave, la
longitud de la clave, si la clave es exportable y cómo se debe tratar
la clave en los campos de renovación. Estas propiedades
proporcionan instrucciones sobre cómo Key Vault genera una clave
de certificado.
• Propiedades secretas Especifica propiedades secretas,
incluido el tipo de contenido utilizado para generar el valor secreto,
al recuperar un certificado como secreto de Key Vault.
• Acciones de por vida Especifica la configuración de por vida
para el certificado de Azure Key Vault. Esto incluye el número de
días antes del vencimiento y una opción de acción, que envía
correos electrónicos a los contactos especificados o activa la
renovación automática del certificado.
• Emisor Incluye información sobre el emisor del certificado
x509.
• Atributos de la política Enumera los atributos asociados con
la política.
Actualmente, Azure Key Vault puede trabajar con dos proveedores de
emisión de certificados para certificados TLS / SSL: DigiCert y
GlobalSign. Cuando incorpora un proveedor de autoridad de certificación,
obtiene la capacidad de crear certificados TLS / SSL que incluyen al
proveedor de la autoridad de certificación como el vértice de la lista de
certificados de confianza. Esto garantiza que los certificados creados a
través de Azure Key Vault sean de confianza para terceros que confían en
el proveedor de la autoridad de certificación.
La información de contactos del certificado incluye las direcciones a las
que se envían las notificaciones cuando se producen eventos específicos
del ciclo de vida del certificado. La información de contacto del certificado
se comparte entre todos los certificados generados por Key Vault. Si ha
configurado la política de un certificado para que se produzca la
renovación automática, se enviarán notificaciones
• Antes de la renovación del certificado.
• Después de una renovación automática exitosa del certificado.
• Si ocurre un error durante la renovación automática.
• Si la renovación manual está configurada, se le proporciona
una advertencia de que debe renovar el certificado.
Más información Almacenamiento de certificados X509 en Key Vault
Puede obtener más información sobre el almacenamiento de certificados x509 en Key
Vault en https://docs.microsoft.com/en-us/azure/key-vault/certificates/about-certificates .
Creación e importación de certificados.

Puede agregar certificados a Key Vault importándolos o generándolos con
Key Vault. Al generar certificados, puede hacer que el certificado se
autofirme o que se genere como parte de una cadena de confianza de un
proveedor de CA de confianza.
Para crear un certificado autofirmado mediante Azure Portal, realice los
siguientes pasos:
1. En Azure Portal, abra la página de propiedades de Key Vault y haga
clic en Certificados , como se muestra en la Figura 4-35 .
Figura 4-35 Sección Certificados de Key Vault
2. Seleccione Generar / Importar . En la página Crear un certificado
que se muestra en la Figura 4-36 , configure el Método de
creación de certificado como Generar . También puede
configurarlo para Importar un certificado existente , sobre el cual
aprenderá más adelante en este capítulo. Asegúrese de que Tipo de
autoridad de certificación (CA) esté configurado
como Certificado autofirmado . Proporcione un nombre de
certificado , un asunto y cualquier nombre DNS y, a continuación,
haga clic en Crear .
Figura 4-36 Crear un certificado
Puede usar Azure Key Vault para crear certificados TLS / SSL que
aprovechan una cadena de confianza de un proveedor de CA de confianza
después de haber realizado los siguientes pasos para crear un objeto
emisor:
1. Realizó el proceso de incorporación con su proveedor de autoridad
de certificación (CA) elegido. En la actualidad, DigiCert y GlobalSign
están asociados con Microsoft para admitir la generación de
certificados TLS / SSL. Los certificados generados de esta manera
serán de confianza para clientes de terceros.
2. El proveedor de CA elegido proporcionará credenciales que Key
Vault puede utilizar para inscribir, renovar e implementar
certificados TLS / SSL. Puede ingresar estas credenciales en la
página Crear una autoridad de certificación en Azure Portal,
como se muestra en la Figura 4-37 . Puede acceder a esta página
seleccionando Autoridades de certificación en
la página Certificados de Key Vault y luego haciendo clic
en Agregar .
Figura 4-37 Crear una autoridad de certificación

3. Agregue el recurso del emisor del certificado a Key Vault.
4. Configure los contactos del certificado para las
notificaciones. Este paso no es obligatorio, pero se
recomienda. Puede hacer esto en
la página Contactos del certificado , disponible a través de
la página Certificados , como se muestra en la Figura 4-38 .
Figura 4-38 Contactos del certificado

Una vez que haya configurado la relación con la CA emisora, podrá crear
certificados TLS / SSL usando el portal o creando una solicitud usando
código JSON similar al siguiente. (Esto requiere
el CertificateIssuerrecurso creado anteriormente y este ejemplo asume
una asociación con DigiCert).
{
"política": {
"x509_props": {
"subject": "CN = TailwindCertSubject1"
},
"emisor": {
"nombre": "mydigicert",
"cty": "OV-SSL",
El método POST para enviar este URI de solicitud es similar al siguiente,

con la dirección de Key Vault sustituida según
corresponda: https://mykeyvault.vault.azure.net/certificates/mycert1/cre
ate?api-version={api-version} .
Para crear un certificado de Key Vault manualmente en lugar de depender
del proveedor de la autoridad de certificación del socio, utilice el mismo
método que se describió anteriormente, pero no incluya el campo del
emisor. Como alternativa, puede crear un certificado autofirmado
estableciendo el nombre del emisor en "Self"en la política de certificados,
como se muestra aquí:
"emisor": {
"nombre": "Yo"
Puede importar un certificado X509 en Key Vault que haya sido emitido
por otro proveedor, siempre que tenga el certificado en formato PEM o
PFX y tenga el certificado privado clave. Puede realizar una importación a
través de Azure Portal, como se muestra en la Figura 4-39 , mediante el az
certificate importcomando de la CLI de Azure o mediante el Import-
AzKeyVaultCertificatecmdlet de PowerShell.
Figura 4-39 Importar un certificado
Puede usar los cmdlets de PowerShell en la Tabla 4-4 para administrar los
certificados de Azure Key Vault.
Tabla 4-4 cmdlets de PowerShell para administrar las certificaciones de
Azure Key Vault
Cmdlet de PowerShell Descripción
Add-AzKeyVaultCertificate
Agrega un certificado a Azure Key Vault
Add-AzKeyVaultCertificateContact
Agrega un contacto para notificaciones de
Backup-AzKeyVaultCertificate
Realiza una copia de seguridad de un certif
en Azure Key Vault
Get-AzKeyVaultCertificate
Ver un certificado de Key Vault
Get-AzKeyVaultCertificateContact
Ver los contactos registrados con Key Vaul
notificaciones
Get-AzKeyVaultCertificateIssuer
Ver los emisores de certificados configurad
Vault
Get-AzKeyVaultCertificateOperation
Ver el estado de cualquier operación en Ke
Get-AzKeyVaultCertificatePolicy
Ver la política de certificados en un Key Va
New-AzVaultCertificateAdministratorDetail
Crear un objeto de detalles de administrad
en memoria
New-
AzKeyVaultCertificateOrganizationDetail Crea un objeto de detalles de organización
New-AzKeyVaultCertificatePolicy
Crea un objeto de política de certificado en
Remove-AzKeyVaultCertificate
Remota un certificado desde un Key Vault
Remove-AzKeyVaultCertificateContact
Elimina un contacto registrado para notific
Vault
Remove-AzKeyVaultCertificateIssuer
Elimina una autoridad de certificación emi
de Key Vault
Remove-AzKeyVaultCertificateOperation
Elimina una operación que se está ejecutan
Vault
Restore-AzKeyVaultCertificate
Restaura un certificado a partir de una cop
Set-AzKeyVaultCertificateIssuer
Configura una autoridad de certificación d
Key Vault
Set-AzKeyVaultCertificatePolicy
Crea o modifica una política de certificados
Stop-AzKeyVaultCertificateOperation
Cancela una operación pendiente en un Ke
Undo-AzKeyVaultCertificateRemoval
Recupera un certificado eliminado y lo colo
activo
Update-AzKeyVaultCertificate
Modifica los atributos editables de un certi
Si prefiere usar la CLI de Azure para administrar certificados en Azure
Key Vault, puede usar los comandos que se muestran en la Tabla 4-5 .
Tabla 4-5 Comandos de la CLI de Azure para administrar las
certificaciones de Azure Key Vault
Mando Descripción
Az keyvault certificate backup
Copia de seguridad de un certificado x509 en Azure K
Az keyvault certificate contact

Administra contactos informativos para certificados e
Vault

add Agrega contactos informativos para certificados en A

delete Elimina los contactos informativos de los certificados
Vault

list Enumera los contactos informativos para los certifica
Vault.
Az keyvault certificate create

Crea un certificado en Azure Key Vault
Mando Descripción
Az keyvault certificate delete
Elimina un certificado de Azure Key Vault
Az keyvault certificate
download Descarga la parte pública de un certificado de Azure K
Az keyvault certificate get-

default-policy Le permite ver las propiedades de la política de certif
predeterminada de Key Vault.
Az keyvault certificate import

Importa un certificado a un Key Vault
Az keyvault certificate issuer

Gestiona las autoridades de certificación del emisor

admin Gestiona administradores para las autoridades de cer
emisor.

admin add Le permite agregar un administrador para una autori
certificación emisora

admin delete Elimina un administrador configurado para una autor
certificación emisora específica

admin list Enumera los administradores configurados para una
de certificados específica.

create Configura una autoridad de certificación del emisor p
Vault

delete Elimina una autoridad de certificación del emisor de A

list Enumera las autoridades de certificación del emisor p
Vault específico.
Mando Descripción
show Le permite ver información sobre una autoridad de c
emisora específica

update Actualiza la información sobre la autoridad de certific
Az keyvault certificate list

Enumera los certificados en Azure Key Vault
Az keyvault certificate list-

deleted Le permite ver una lista de certificados eliminados qu
recuperar
Az keyvault certificate list-

versions Le permite ver las versiones de un certificado.
Az keyvault certificate pending

Gestiona las operaciones de creación de certificados.

delete Termina la creación pendiente de un certificado

merge Fusiona un certificado o una cadena de certificados co
claves que está presente en Key Vault

show Le permite ver el estado de la operación de creación d
Az keyvault certificate purge

Elimina de forma permanente un certificado eliminad
Az keyvault certificate recover

Recupera un certificado eliminado
Az keyvault certificate restore

Restaura un certificado respaldado en un Key Vault
Az keyvault certificate set

attributes Actualiza los atributos de un certificado.
Az keyvault certificate show

Le permite ver la información del certificado.
Mando Descripción
Az keyvault certificate show-
deleted Le permite ver información sobre un certificado elim
Más información Introducción a los certificados de Key Vault
Puede obtener más información sobre cómo comenzar con los certificados de Key
Vault en https://docs.microsoft.com/en-us/azure/key-vault/certificates/certificate-
scenarios .
Gestionar secretos
Los secretos, en el contexto de Azure KeyVault, le permiten almacenar de
forma segura elementos como contraseñas y cadenas de conexión de
bases de datos. Key Vault cifra automáticamente todos los secretos
almacenados. Este cifrado es transparente. Key Vault cifrará un secreto
cuando lo agregue y lo descifrará cuando un usuario autorizado acceda al
secreto desde la bóveda. Cada clave de cifrado de Key Vault es única para
Azure Key Vault.
Los secretos de Key Vault se almacenan con un identificador y el secreto
en sí. Cuando desee recuperar el secreto, especifique el identificador en la
solicitud a Key Vault. Puede agregar un secreto a un Key Vault usando
el az keyvault secret setcomando. Por ejemplo, para agregar un secreto al
Key Vault nombrado TailwindKVdonde está el nombre del identificador
secreto Alphay el valor del secreto Omega, debe ejecutar este comando:
conjunto secreto az keyvault \
--nombre Alpha \
--valor Omega \
--nombre de la bóveda TailwindKV
Puede ver un secreto con el azure keyvault secret showcomando de la CLI

de Azure y puede eliminar un secreto con el azure keyvault secret
deletecomando de la CLI de Azure. Para agregar el mismo secreto al
mismo Azure Key Vault que se usó en el ejemplo anterior con PowerShell,
ejecute el comando:
$ valorsecreto = ConvertTo-SecureString 'Omega' -AsPlainText
-Force
$ secret = Set-AzKeyVaultSecret -VaultName 'TailwindKV' -Name

'Omega' -SecretValue
$ valorsecreto
Puede ver un secreto de Azure Key Vault con el Get-

AzureKeyVaultSecretcmdlet. Puede modificar un secreto de Azure Key Vault
existente con el Update-AzureKeyVaultSecretcmdlet de Azure PowerShell y
puede eliminar un secreto de Azure Key Vault con el Remove-
AzureKeyVaultSecretcmdlet.
Puede administrar secretos mediante Azure Portal desde
la sección Secretos de la página de propiedades de Key Vault, como se
Figura 4-40 Secretos de Key Vault

Más allá del ID secreto y el secreto en sí, puede configurar los siguientes
atributos para los secretos de Azure Key Vault.
• Tiempo de vencimiento (exp) Le permite especificar un
tiempo específico después del cual el secreto no debe recuperarse
de Key Vault. El uso de este atributo no bloquea el uso del secreto,
al igual que la fecha de vencimiento de los alimentos no le impide
comerlos después de esa fecha. El atributo de tiempo de
vencimiento simplemente proporciona al guardián del secreto un
método para recomendar que un secreto está más allá de su fecha
de caducidad.
• No antes (nbf) Similar al atributo de tiempo de vencimiento,
el not beforeatributo permite al guardián del secreto especificar el
momento en el que un secreto se vuelve válido. Por ejemplo, puede
almacenar un secreto en un Key Vault y establecer el not
beforeatributo en 2030, lo que informaría a cualquiera que recupere
el secreto de que la información secreta en sí no será útil hasta
2030.
• Habilitado Le permite especificar si los datos secretos se
pueden recuperar. Este atributo se utiliza junto con
los atributos expy nbf. Cualquier operación que involucre
el Enabledatributo que no incluya los atributos expo nbfno será
permitida.
Puede usar los cmdlets de Azure PowerShell en la Tabla 4-6 para
administrar secretos en Azure Key Vault.
Tabla 4-6 cmdlets de PowerShell para administrar secretos de Key Vault
Backup-AzKeyVaultSecret
Realiza una copia de seguridad segura de un secreto de K
Get-AzKeyVaultSecret
Ver los secretos en un Key Vault
Remove-AzKeyVaultSecret
Elimina un secreto de Key Vault
Restore-AzKeyVaultSecret
Restaura un secreto de Key Vault a partir de una copia de
Set-AzKeyVaultSecret
Crea o modifica un secreto en un Key Vault
Undo-
AzKeyVaultSecretRemoval Recupera un secreto eliminado que no se ha eliminado d
permanente
Update-AzKeyVaultSecret
Actualiza los atributos de un secreto en un Key Vault.
Puede usar los comandos de la CLI de Azure en la Tabla 4-7 para
administrar los secretos de Key Vault.
Tabla 4-7 Comandos de la CLI de Azure para administrar secretos de Key
Vault
Comando de la CLI de Descripción
Azure
Az keyvault secret backup
Realiza una copia de seguridad de un secreto específico d
Az keyvault secret delete

Elimina un secreto específico de Key Vault
Az keyvault secret download

Descarga un secreto de Key Vault
Az keyvault secret list

Enumera secretos en un Key Vault específico
Az keyvault secret list-

deleted Enumera los secretos que se han eliminado pero no purga
Az keyvault secret list-

versions Enumera todas las versiones de secretos almacenados en
Az keyvault secret purge

Elimina de forma permanente un secreto específico para
recuperar de Key Vault
Az keyvault secret recover

Recupera un secreto eliminado a la última versión
Az keyvault secret restore

Restaura un secreto guardado
Az keyvault secret set

Crea o actualiza un secreto en Key Vault
Az keyvault secret set-

attributes Modifica los atributos asociados con un secreto específico
Az keyvault secret show

Recupera un secreto específico de Azure Key Vault
Az keyvault secret show-

deleted Visualiza un secreto específico eliminado, pero no purgad
Más información Key Vault Secrets
Puede obtener más información sobre los secretos de Key Vault
en https://docs.microsoft.com/en-us/azure/key-vault/secrets .
Configurar la rotación de claves
La rotación de claves es el proceso de actualizar una clave o un secreto
existente con una nueva clave o secreto. Debe hacer esto con regularidad
en caso de que la clave o el secreto existente se haya comprometido
accidental o deliberadamente. La frecuencia con la que lo hace depende
de las necesidades de su organización; algunas organizaciones rotan las
claves cada 28 días y otras las rotan cada seis meses.
Administrar claves
Las claves criptográficas almacenadas en Azure Key Vault se almacenan
como objetos JSON Web Key (JWK). Azure Key Vault solo admite claves
RSA y de curva elíptica (EC). Azure Key Vault admite dos tipos de
protección para claves, protección de software y protección de módulo
seguro de hardware (HSM). Estas diferencias se manifiestan de la
siguiente manera:
• Claves protegidas por software Azure Key Vault procesa la
clave en software. La clave está protegida mediante cifrado en
reposo, con la clave del sistema almacenada en un HSM de
Azure. Las claves RSA o EC se pueden importar a Azure Key Vault
configurado para protección de software. También puede
configurar Azure Key Vault para crear una clave que use estos
algoritmos.
• Claves protegidas por HSM La clave se almacena en un HSM
especialmente asignado. Los clientes pueden importar claves RSA o
EC desde una fuente protegida por software o desde un dispositivo
HSM compatible. También puede usar el plano de administración
de Azure para solicitar que Key Vault genere una clave con estos
algoritmos. Cuando utiliza claves protegidas por HSM,
el key_hsmatributo se agrega al JWK.
Azure Key Vault permite realizar las siguientes operaciones en objetos
clave:
• Crear Esta operación permite que un principal de seguridad
cree una clave. El valor de la clave será generado por Key Vault y
almacenado en la bóveda. Key Vault admite la creación de claves
asimétricas.
• Importar Permite a la entidad de seguridad importar una
clave existente en Key Vault. Key Vault admite la importación de
claves asimétricas.
• Actualizar Permite que una entidad de seguridad modifique
los atributos de clave (metadatos) asociados con una clave
almacenada en Key Vault.
• Eliminar Permite que una entidad de seguridad elimine una
clave de Key Vault.
• Lista Permite que una entidad de seguridad enumere todas
las claves de un Key Vault.
• Listar versiones Permite que una entidad de seguridad vea
todas las versiones de una clave específica en un Key Vault.
• Obtener Permite que una entidad de seguridad vea los
elementos públicos de una clave específica almacenada en un Key
Vault.
• Copia de seguridad Exporta una clave de Key Vault en forma
protegida.
• Restaurar Importa una clave de Key Vault exportada
anteriormente.
Puede usar claves almacenadas en Azure Key Vault para realizar las
siguientes operaciones criptográficas:
• Firmar y verificar
• Encriptación / envoltura de claves
• Cifrar y descifrar
Puede administrar las claves de Key Vault mediante Azure Portal
navegando hasta Key Vault y seleccionando Claves en Configuración ,
Figura 4-41 Página de teclas
Para crear una clave con Azure Key Vault en Azure Portal, realice los
siguientes pasos:
1. En Azure Portal, abra el Key Vault en el que desea crear la clave y
navegue hasta Claves en la sección Configuración .
2. En la página Claves , haga clic en Generar / Importar . Esto abrirá
la página Crear una clave .
3. En la página Crear una clave que se muestra en la Figura 4-42 ,
asegúrese de que el menú desplegable Opciones esté configurado
en Generar . Proporcione un nombre para la clave, especifique las
propiedades de la clave, especifique si la clave tiene una fecha de
activación o de vencimiento y especifique si la clave está
habilitada. Azure Key Vault generará la clave cuando haga clic
en Crear .
Figura 4-42 Creación de una clave
Puede usar los cmdlets de Azure PowerShell en la Tabla 4-8 para
administrar las claves de Azure Key Vault.
Tabla 4-8 PowerShell cmdlets para administrar claves de Azure Key Vault
Add-AzKeyVaultKey
Crea o importa una clave en Azure Key Vault
Backup-AzKeyVaultKey
Realiza una copia de seguridad de una clave almacenada en A
Get-AzKeyVaultKey
Visualiza las claves almacenadas en Azure Key Vault
Remove-AzKeyVaultKey
Elimina una clave almacenada en Azure Key Vault
Restore-AzKeyVaultKey
Recupera una clave del almacén de claves de Azure desde un
seguridad
Undo-
AzKeyVaultKeyRemoval Recuperar una clave eliminada de Azure Key Vault
Update-AzKeyVaultKey
Le permite actualizar los atributos de una clave almacenada
claves de Azure.
Puede usar los comandos de la CLI de Azure en la Tabla 4-9 para
administrar las claves de Azure Key Vault.
Tabla 4-9 Comandos de la CLI de Azure para administrar claves de Azure
Key Vault
Mando Descripción
Az keyvault key backup
Realiza una copia de seguridad de una clave de Azure Key
Az keyvault key create

Crea una nueva clave de Azure Key Vault
Az keyvault key decrypt

Usa una clave de Azure Key Vault para descifrar datos
Az keyvault key delete

Elimina una clave de Azure Key Vault
Mando Descripción
Az keyvault key download
Descarga la parte pública de una clave almacenada
Az keyvault key encrypt

Cifra datos con una clave almacenada en Azure Key Vault
Az keyvault key import

Importa una clave privada
Az keyvault key list

Muestra las claves de Azure Key Vault en un almacén espe
Az keyvault key list-

deleted Enumera las claves de Azure Key Vault que se han elimina
pueden recuperar
Az keyvault key list-

versions Muestra las versiones de claves de Azure Key Vault
Az keyvault key purge

Elimina de forma permanente una clave de Azure Key Vau
Az keyvault key recover

Recupera una clave eliminada
Az keyvault key restore

Restaura una clave desde una copia de seguridad
Az keyvault key set-

attributes Le permite configurar los atributos de una clave de Azure
Az keyvault key show

Ver la parte pública de una clave de Azure Key Vault
Az keyvault key show-

deleted Ver la parte pública de una clave de Azure Key Vault elimin
Más información Key Vault Keys
Puede obtener más información sobre las claves de Key Vault
en https://docs.microsoft.com/en-us/azure/key-vault/keys .
Girar secretos
Anteriormente en este capítulo, aprendió sobre el concepto de rotación
de claves que siguió a este proceso:
1. Las claves de acceso a una cuenta de almacenamiento se rotaron a
través de un proceso mediante el cual las aplicaciones que
utilizaron la primera clave se cambiaron a la segunda clave.
2. La primera llave fue retirada y reemplazada.
3. Finalmente, las aplicaciones se volvieron a migrar para usar la
primera clave.
4. Una vez que las aplicaciones se volvieron a migrar a la primera
clave, se reemplazó la segunda clave y el proceso pudo comenzar de
nuevo.
Si bien Microsoft recomienda el uso de la identidad en lugar de los
secretos para la autenticación, hay cargas de trabajo que se ejecutan en
Azure que no pueden aprovechar la autenticación basada en identidad y,
en su lugar, deben depender de claves y secretos para la autenticación.
Cuando publica un secreto en Azure Key Vault, puede especificar una
fecha de vencimiento para ese secreto, como se muestra en la Figura 4-
43 . Puede usar la publicación de un evento de "casi caducidad" en Azure
Event Grid como disparador de una aplicación de funciones que generaría
una nueva versión del secreto y que luego actualiza la carga de trabajo
relevante para usar el secreto recién generado, permitiendo el secreto
existente. para ser descartado.
Figura 4-43 Creación de un secreto
Más información Rotate Secrets
Puede obtener más información sobre la automatización de la rotación secreta
en https://docs.microsoft.com/en-us/azure/key-vault/secrets/tutorial-rotation .
Copia de seguridad y restauración de elementos

de Key Vault
Los elementos almacenados en Key Vault son valiosos por naturaleza y
algo a lo que no desea perder acceso. Como los elementos de Key Vault
son valiosos, debe asegurarse de que estos elementos tengan una copia de
seguridad y se puedan recuperar si algo sale mal. "Algo sale mal" puede
incluir elementos que se eliminan o dañan accidentalmente, o puede
significar un error administrativo que hace que pierda el acceso a Key
Vault. Por ejemplo, podría perder el acceso a Key Vault si un actor
malintencionado obtiene el control de su suscripción o si un
administrador distraído reconfigura incorrectamente los permisos de
RBAC o la política de acceso de Key Vault. A diferencia de los módulos de
seguridad de hardware locales que almacenan secretos,
Cuando realiza una copia de seguridad de un elemento de Key Vault, el
elemento estará disponible para su descarga como un blob cifrado. La
recuperación implica recuperar este blob cifrado en el mismo Key Vault o
en otro dentro de la misma suscripción. Es importante tener en cuenta
que este blob cifrado solo se puede descifrar dentro de un Key Vault
dentro de la misma suscripción de Azure y la misma geografía de Azure
que el Key Vault desde el que se realizó la primera copia de seguridad del
elemento. Por ejemplo, si realizó una copia de seguridad de un secreto
almacenado en un Key Vault alojado en Australia en la suscripción A, no
podrá restaurar ese secreto en un Key Vault en una geografía de Azure
fuera de Australia o en un Key Vault asociado con cualquier suscripción
que no sea la suscripción A.
En el momento de redactar este documento, Azure Key Vault no permite
la totalidad de un Key Vault en una única operación de copia de
seguridad. Microsoft advierte que debe realizar las operaciones de copia
de seguridad de Key Vault manualmente en lugar de
automáticamente. Esto se debe a que es probable que las operaciones
automáticas que utilizan las herramientas disponibles actualmente
produzcan errores. También es posible, mediante operaciones
automáticas, superar los límites de servicio de Key Vault en términos de
solicitudes por segundo. Si esto ocurre, Key Vault se ralentizará, lo que
provocará que falle cualquier operación de respaldo. Microsoft o el
equipo de desarrollo de Azure Key Vault no admiten el uso de scripts o
acciones automatizadas para realizar copias de seguridad de elementos
de Key Vault.
Para realizar una copia de seguridad de los objetos en Azure Key Vault, se
deben cumplir las siguientes condiciones:
• Permisos de nivel de colaborador o superiores en Key Vault
• Un Key Vault principal que contiene elementos de los que
desea realizar una copia de seguridad
• Un Key Vault secundario donde se restaurarán los secretos
Para realizar una copia de seguridad de un elemento en Azure Portal,
1. En Azure Portal, abra Key Vault. En la página Configuración ,
seleccione el tipo de elemento del que desea realizar una copia de
seguridad y luego seleccione el elemento del que desea realizar una
copia de seguridad. En la Figura 4-44 , se selecciona la
sección Secretos .
Figura 4-44 Secretos en Key Vault

2. Seleccione el elemento del que desea realizar una copia de
seguridad en la página del elemento, que se muestra en la Figura 4-
45 , y seleccione Descargar copia de seguridad .
Figura 4-45 Descargar copia de seguridad
3. Seleccione Descargar para descargar el blob cifrado.
Para restaurar un elemento mediante Azure Portal, realice los siguientes
pasos:
1. En Azure Portal, abra el Key Vault en el que desea restaurar el
elemento. En la página Configuración , seleccione el tipo de
elemento que desea restaurar.
2. Haga clic en Restaurar copia de seguridad (consulte la Figura 4-
46 ).
Figura 4-46 Restaurar copia de seguridad
3. En la página Carga de archivos , seleccione el blob cifrado que
desea restaurar en Key Vault y luego seleccione Abrir . El blob
cifrado se cargará en Key Vault. UnEl elemento se restaurará
siempre que Key Vault se encuentre en la misma suscripción y
región geográfica que el Key Vault que alojó el elemento
originalmente respaldado.
Puede usar los comandos de la CLI de Azure en la Tabla 4-10 para realizar
una copia de seguridad de los elementos de Key Vault.
Tabla 4-10 Comandos de la CLI de Azure para realizar copias de
seguridad de elementos de Key Vault
Azure
Az keyvault
certificate backup Utilice este comando para realizar una copia de seguridad de
específicos almacenados en Azure Key Vault.
Az keyvault key backup

Utilice este comando para realizar una copia de seguridad de
almacenadas en Azure Key Vault.
Azure
Az keyvault secret
backup Use este comando para realizar una copia de seguridad de sec
almacenados en Azure Key Vault.
Puede usar los comandos de la CLI de Azure que se muestran en la Tabla
4-11 para restaurar elementos de Key Vault.
Tabla 4-11 Comandos de la CLI de Azure para restaurar elementos de
Key Vault
Comando de la CLI de Azure Descripción
Az keyvault certificate
restore Utilice este comando para restaurar un certificado espe
Key Vault.
Az keyvault key restore

Utilice este comando para restaurar una clave específica
Vault.
Az keyvault secret restore

Use este comando para restaurar un secreto específico
Vault.
Puede usar los comandos de Azure PowerShell que se muestran en
la Tabla 4-12 para realizar una copia de seguridad de los elementos de
Key Vault.
Tabla 4-12 Comandos de Azure PowerShell para realizar copias de
seguridad de elementos de Key Vault
Comando de Azure Descripción
PowerShell
Backup-
AzureKeyVaultCertificate Use este cmdlet para realizar una copia de seguridad de
específicos almacenados en Azure Key Vault.
Backup-AzureKeyVaultKey
Use este cmdlet para realizar una copia de seguridad de
Azure Key Vault.
PowerShell
Backup-AzureKeyVaultSecret
Use este cmdlet para realizar una copia de seguridad de
específico que está almacenado en Azure Key Vault.
Puede usar los comandos de Azure PowerShell en la Tabla 4-13 para
restaurar elementos de Key Vault.
Tabla 4-13 Comandos de Azure PowerShell para restaurar elementos de
Key Vault
PowerShell
Restore-
AzureKeyVaultCertificate Use este cmdlet para restaurar certificados específicos
Azure Key Vault.
Restore-AzureKeyVaultKey
Use este cmdlet para restaurar una clave de Azure Key
Restore-AzureKeyVaultSecret
Use este cmdlet para restaurar un secreto específico qu
almacenado en Azure Key Vault.
Más información Copia de seguridad y recuperación de elementos de Key Vault
Puede obtener más información sobre la copia de seguridad y la recuperación de Key
Vault en https://docs.microsoft.com/en-us/azure/key-vault/general/backup .

Recuerde que solo puede restaurar elementos de Key Vault si el Key
Vault que está utilizando en la operación de restauración se
encuentra en la misma suscripción y región geográfica que el Key
Vault donde se realizó la copia de seguridad original.
Experimento mental
Protección de datos en Tailwind Traders

Tailwind Traders ha migrado algunas de sus operaciones a Azure y ahora
están intentando mejorar la seguridad de los datos almacenados en su
suscripción de Azure. Con esta información en mente, Tailwind Traders
tiene los siguientes desafíos que deben abordar:
• Los miembros del equipo de investigación de productos
deben poder agregar y eliminar datos en Blob Storage en varias
cuentas de almacenamiento. No se les debe asignar ningún permiso
innecesario.
• Para cumplir con la regulación del gobierno local, Tailwind
Traders necesita administrar las claves utilizadas para el cifrado de
datos transparente en su instancia de Azure SQL. Estarán
configurando BYOK.
• Los miembros del equipo de ventas de Tailwind Traders
deben poder realizar operaciones criptográficas con regularidad
con claves y certificados almacenados en Azure Key Vault, pero no
se les debe asignar ningún permiso innecesario.
Con esta información, responda las siguientes preguntas:
1. 1. ¿Qué función de RBAC debería asignar al equipo de investigación
de productos?
2. 2. ¿Dónde deben almacenar los comerciantes de viento de cola su
clave TDE?
3. 3. ¿Qué función de RBAC debería asignarse al equipo de ventas a
Key Vault?

1. 1. Al equipo de investigación de productos se le debe asignar la
función de colaborador de datos de Storage Blob porque esto
proporciona los permisos mínimos necesarios para agregar y
eliminar datos de Blob Storage.
2. 2. Los comerciantes de Tailwind deben almacenar la clave TDE en
un almacén de claves de Azure porque esta es la única ubicación en
la que puede almacenar una clave en un escenario BYOK.
3. 3. El equipo de ventas debe tener asignado el rol de RBAC de
usuario criptográfico de Key Vault porque esto les permite realizar
operaciones criptográficas en claves y certificados.

• Hay dos claves de acceso a la cuenta de almacenamiento que
se pueden utilizar para proporcionar acceso a una cuenta de
almacenamiento. Solo debe usar una a la vez para que pueda
realizar la rotación de claves de forma regular:
• Las firmas de acceso compartido (SAS) le permiten
proporcionar acceso delegado granular seguro a las cuentas
de almacenamiento.
• Las políticas de acceso almacenado le permiten
controlar específicamente las firmas de acceso compartido a
nivel de servicio.
• En lugar de depender de las claves de la cuenta de
almacenamiento o las firmas de acceso compartido, puede usar
Azure AD para autorizar el acceso a Blob y Queue Storage. Azure
AD autentica la identidad de una entidad de seguridad y luego
devuelve un token de OAuth 2.0.
• Cuando habilita la autenticación de AD DS para Azure Files,
los equipos unidos al dominio de Active Directory Domain Services
(AD DS) pueden montar Azure File Shares con las credenciales de
usuario de AD DS.
• El permiso de nivel de recurso compartido se configura
asignando roles RBAC en el nivel de recurso compartido de
archivos de Azure. Una vez que haya asignado permisos de nivel de
recurso compartido a un recurso compartido de archivos de Azure
mediante RBAC, debe configurar los permisos de archivo y carpeta
en el contenido del recurso compartido.
• El cifrado de Azure Storage está habilitado de forma
predeterminada para todas las cuentas de almacenamiento,
independientemente del nivel de rendimiento o el nivel de
acceso. Esto significa que no es necesario modificar el código o las
aplicaciones para habilitar Azure Storage Encryption.
• Los ámbitos de cifrado le permiten configurar claves de
cifrado independientes a nivel de contenedor y de blob.
• La protección avanzada contra amenazas para Azure Storage
le permite detectar intentos inusuales y malintencionados de
interactuar con las cuentas de Azure Storage.
• Cuando crea una instancia de servidor de base de datos de
Azure SQL, crea un inicio de sesión de administrador y una
contraseña asociada con ese inicio de sesión. Esta cuenta
administrativa otorgó permisos administrativos completos en
todas las bases de datos hospedadas fuera de la instancia de Azure
SQL como entidad de seguridad a nivel de servidor.
• La auditoría le permite realizar un seguimiento de los eventos
de la base de datos, como la adición o eliminación de tablas. Los
registros de auditoría para las bases de datos de Azure SQL se
pueden almacenar en una cuenta de Azure Storage, un área de
trabajo de Log Analytics o Event Hubs.
• La Protección contra amenazas avanzada de Azure SQL
Database le permite detectar actividad inusual que podría indicar
que un tercero podría estar intentando atacar las bases de datos de
Azure SQL de su organización.
• El cifrado de datos transparente (TDE) le permite proteger las
bases de datos de Azure SQL cifrando los datos en reposo. Cuando
habilita TDS, las bases de datos, las copias de seguridad asociadas y
los archivos de registro de transacciones se cifran y descifran
automáticamente, según sea necesario.
• Always Encrypted es una tecnología disponible para Azure
SQL que le permite proteger tipos específicos de datos
confidenciales que tienen un patrón reconocible conocido, como
números de pasaporte, números de identificación de archivos de
impuestos y números de tarjetas de crédito.
• Azure Key Vault le permite almacenar información que no
debe hacerse pública, como secretos, certificados y claves.
• Utiliza las políticas de control de acceso de Key Vault para
administrar los permisos sobre secretos, certificados y claves en el
nivel del plano de datos. Cada política de control de acceso de Key
Vault incluye entradas que especifican qué acceso tiene el principal
de seguridad designado a las claves, secretos y certificados
Índice
A
control de acceso, 38 - 63 , 74 - 85
Revisiones de acceso, 40 - 42
activar / configurar PIM, 43 - 45
administrar usuarios de MFA, 54 - 60
configuración de bloqueo de cuenta, 57
bloquear / desbloquear usuarios, 58
configuración de alerta de fraude, 58
Fichas de OATH, 59
configuración de llamadas telefónicas, 59
utilización de informes, 60
acceso a aplicaciones, 64 - 73
Políticas de gestión de API, 73
asignación, 66 - 70
permiso consentimiento, 71 - 73
alcances de permisos, 70 - 71
registro de aplicaciones, 64 - 66
para Azure Key Vault, 282 - 285
mejores prácticas, 81
políticas de acceso condicional, 46 - 54
creando, 47 - 49
implementación de MFA, 49 - 54
tipos de, 46 - 47
configurar la protección de la identidad, 60 - 63
roles personalizados, 81 - 84
identificación de roles, 81
permisos de interpretación, 84
monitoreo de acceso privilegiado, 38 - 40
principio de privilegio mínimo, 81
Roles de RBAC
niveles de, 244
lista de, 245
permisos de grupo de recursos, 79 - 80
permisos de suscripción y recursos, 74 - 79
ver los permisos de recursos del usuario, 84 - 85
para máquinas virtuales (máquinas virtuales), 155
accediendo
Registro de actividad de Azure, 182
Consola administrativa de Azure AD, 6
claves de acceso para cuentas de almacenamiento, 247
llaves giratorias, 247 - 250
teclas de visualización, 248 - 249
configuración de bloqueo de cuenta para MFA, 57
cuenta SAS, 251 - 254
ACR (Registro de contenedores de Azure)
configuración de seguridad, 167 - 168
gestión de vulnerabilidades, 164 - 165
grupos de acción para alertas de Azure Monitor, 185 - 186
Servicios de federación de Active Directory (AD FS) en Azure AD
Connect, 28
registros de actividad en Azure Monitor, 180
accediendo, 182
Cmdlet Add-AzKeyVaultCertificate, 293
Cmdlet Add-AzKeyVaultCertificateContact, 293
Cmdlet Add-AzKeyVaultKey, 300
Cmdlet Add-AzRouteConfig, 97
Cmdlet Add-AzureADDirectoryRoleMember, 79
Cmdlet Add-AzureADGroupMember, 8
Cmdlet Add-AzureADGroupOwner, 8
Cmdlet Add-AzVirtualNetworkPeering, 99
agregando
certificados a Azure clave Bóveda, 289 - 293
estándares de cumplimiento para el panel de cumplimiento
normativo, 210 - 211
miembros del grupo, 10
ADE (Azure Disk Encryption), 168 - 169 de la
SAS ad hoc, 251
consola administrativa (Azure AD), accediendo, 6
ADS (seguridad de datos avanzada), 199
Protección contra amenazas avanzada (ATP) para Azure
Storage, 267 - 268
AKS (Servicio de Azure Kubernetes)
autenticación, 159 - 161
configuración de aislamiento, 166 - 167
alertas
en Azure Monitor
creación / personalización, 183 - 189
ver / cambiar, 188
en Azure Sentinel, creación / personalización, 217 - 224
Siempre cifrado, 279 - 281
análisis en Azure Sentinel, 213
Función de administrador de aplicaciones, 75
Rol de desarrollador de aplicaciones, 75
pasarelas de aplicaciones
Azure Puerta principal, 126 - 133
capacidades, 126
configuración, 127 - 133
topología, 127
WAF (Web Application Firewall) de configuración, 133 - 135
objetos de aplicación, 2
permisos de aplicación, 71
reglas de aplicación, creando, 120 - 122
aplicaciones
asignar roles, 3-6
registrarse, 2, 64 - 66
grupos de seguridad de aplicaciones (SsG), 114 - 117
contraseñas de aplicaciones, 32
Función ArcDelete ACR, 167
Función ArcImageSigner ACR, 167
Función de ArcPull ACR, 167
Función ArcPush ACR, 167
SsG (grupos de seguridad de aplicaciones), 114 - 117
asignar
permisos a los directores de servicio, 3-6
Roles RBAC, 245 - 247
roles a aplicaciones, 3-6
usuarios a roles, 78 - 79
ATP (Protección contra amenazas avanzada) para Azure
Storage, 267 - 268
bases de datos de auditoría, 270 - 273
registros de auditoría, visualización, 271 - 273
en Azure Aplicación de servicio, configuración, 174 - 176
para Azure Files, 256 - 261
habilitación, 257 - 261
permisos de archivos y carpetas, 260
permisos de nivel compartido, 259
basado en certificado, 33
para recipientes, 159 - 161
para bases de datos, 268 - 269
MFA (autenticación multifactor), 49 , 54
administrar usuarios, 54 - 60
sin contraseña, 33 - 36
representa el almacenamiento, 255 - 256
tipos de, 31 - 32
para pasarelas VPN, 104 - 106
Función de administrador de autenticación, 75
autorización en Azure App de servicio, configuración, 174 - 176
Azure Active Directory (Azure AD)
control de acceso, 38 - 63 , 74 - 85
activar / configurar PIM, 43 - 45
administrar usuarios de MFA, 54 - 60
mejores prácticas, 81
consola administrativa, accediendo, 6
aplicaciones, registro, 2
métodos de autenticación, 30 - 36
basado en certificado, 33
sin contraseña, 33 - 36
representa el almacenamiento, 255 - 256
tipos de, 31 - 32
autenticación recipiente, 159 - 161
identidades
grupos, 6- 12
directores de servicio, 2-6
tipos de, 1
usuarios, 13 - 15
escritura diferida de contraseña, 15 - 30
habilitar el restablecimiento de contraseña de autoservicio, 28 - 30
Instalación / Configuración Azure AD Connect, 15 - 28 de
transferencia de suscripciones, 36 - 37
Azure Active Directory Connect, 15 - 28 de
requisitos de conectividad, 16
requisitos de la cuenta de implementación, 17
instalación, 17 - 25
inscribirse en las opciones, 27 de - 28 de
Requisitos de SQL Server, 16 - 17
requisitos del sistema, 15 - 16
Sufijos UPN y dominios nonroutable, 25 - 27
Servicios de dominio de Azure Active Directory (Azure AD DS),
autenticación para archivos de Azure, 256 - 261
Registros de Azure Active Directory en Azure Monitor, 181
Registro de actividad de Azure, accediendo, 182
Servicio de aplicaciones de Azure
cortafuegos, 143 - 144
actualizaciones de software, 176
SSL / TLS, los certificados 172 - 174
Puerta de enlace de aplicaciones de Azure
como balanceador de carga, 126
WAF (Web Application Firewall) de configuración, 133 - 135
Azure Automatización administración de actualizaciones, 156 - 159
Azure Bastion, 135 - 137
Azure configuración de seguridad, la configuración de
Blueprint, 236 - 240
Registro de contenedores de Azure (ACR)
Azure DDoS, 147 - 151
Azure Disk Encryption (ADE), 168 - 169 de la
Autenticación de Azure Files, 256 - 261
Cortafuegos de Azure
reglas de aplicación, 120 - 122
configurar, 119 - 120
tala, 123 - 125
reglas de red, 122 - 123
topología, 117 - 118
capacidades, 126
configuración, 127 - 133
topología, 127
Integración con WAF (Web Application Firewall), 133
Azure Key Vault
control de acceso, 282 - 285
con ADE (Azure Disk Encryption), 168
copia de seguridad y restauración, 303 - 307
gestión de certificados, 288 - 296
rotación de llave, 298 - 303
acceso a la red, 282 - 285
gestión de permisos, 285 - 287
Uso de RBAC, 287 - 288
gestión secretos, 296 - 298
Rotación de secretos, 302 - 303
claves de cifrado de la cuenta de almacenamiento, 264
Servicio de Azure Kubernetes (AKS)
Playbooks de Azure Logic Apps, configuración, 224 - 228
Azure Monitor, 179 - 196
registros de actividad, 180
alertas
creación / personalización, 183 - 189
ver / cambiar, 188
Registros de Azure Active Directory, 181
habilitante, 179
capas en, 180 - 181
recolección de registros
IaaS VM registra, 192 - 194
búsqueda de eventos en el espacio de trabajo de Log Analytics, 195 - 196
Seguridad y solución de Auditoría, 194 - 195
métricas, 181 - 184
resumen operativo, 180 - 183
registros de recursos (diagnóstico), 180
la configuración de opciones, 189 - 192
recursos en, 181
Política de Azure
gestión centralizada de políticas en Azure Centro de seguridad, 206 - 209
ajustes de seguridad, configuración, 232 - 236
Capa de recursos de Azure (Azure Monitor), 180
Azure Centro de seguridad, 196 - 211
para AKS (Azure Servicio Kubernetes), 163 - 164
Azure App Servicio recomendaciones de seguridad en, 171 - 172
gestión centralizada de políticas, 206 - 209
Acceso a VM JIT (Just In Time), 201 - 205
Tablero de Cumplimiento Normativo, 209 - 211
visualización de protección de terminales, 151 - 154
Detección de amenazas VM, 155 - 156
evaluación de la vulnerabilidad, 196 - 200
Azure Sentinel, 212 - 232
alertas, creación / personalización, 217 - 224
componentes de, 212 - 213
conectores de datos, configurar, 213 - 217
libros de jugadas, configuración, 224 - 228
resultados, evaluación, 228 - 232
Base de datos SQL Azure avanzada protección contra amenazas, 273 - 276
Bases de datos de Azure SQL. Ver bases de datos
Azure Storage. Ver cuentas de almacenamiento
Capa de suscripción de Azure (Azure Monitor), 180
Capa de inquilino de Azure (Azure Monitor), 181
B
Copia de seguridad de los elementos clave Azure Vault, 303 - 307
Cmdlet Backup-AzKeyVaultCertificate, 293
Cmdlet Backup-AzKeyVaultKey, 300
Cmdlet Backup-AzKeyVaultSecret, 297
Cmdlet Backup-AzureKeyVaultCertificate, 306
Cmdlet Backup-AzureKeyVaultKey, 306
Cmdlet Backup-AzureKeyVaultSecret, 306
mejores prácticas
control de acceso, 81
para SAS (firmas de acceso compartido), 251 - 252
Función de administrador de facturación, 75
manchas
cifrado, estado de visualización, 262 - 263
políticas de acceso almacenadas, 255
Cuentas de BlobStorage, 244
Cuentas BlockBlobStorage, 244
bloqueo de usuarios de MFA, 58
planos, 236 - 240
BYOK (Traiga su propia llave), 276
C
casos en Azure Sentinel, 212
CDS (servicio de datos comunes), 176
autoridades de certificación para Azure clave Bóveda, 289 - 292
políticas de certificado, elementos de, 288 - 289
autenticación basada en certificados, 33
certificados
en Azure Key Vault
añadiendo, 289 - 293
importación, 289 - 293
gestión, 288 - 296
permisos, 286
información de contactos, 289
SSL / TLS, configuración, 172 - 174
cambiar las alertas de Azure Monitor, 188
Rol de administrador de aplicaciones en la nube, 75
Función de administrador de dispositivos en la nube, 75
Servicio de datos comunes (CDS), 176
Página de la comunidad en Azure Sentinel, 213
Rol de administrador de cumplimiento, 75
políticas de cumplimiento en Azure Security Center, 209 - 211
seguridad informática
para ACR (Azure Container Registro), 167 - 168
de autenticación para contenedores, 159 - 161
Azure para la aplicación de servicio, 170 - 176
seguridad de los contenedores, 161 - 164
cifrado de disco, 168 - 169 de la
seguridad de punto final, 151 - 156
aislamiento, 166 - 167
actualizaciones del sistema para máquinas virtuales, 156 - 159
Rol de administrador de acceso condicional, 75
creando, 47 - 49
implementación de MFA, 49 - 54
tipos de, 46 - 47
Cmdlet Connect-AzAccount, 95
requisitos de conectividad para Azure AD Connect, 16
conectores. Ver conectores de datos
contenedores
Rol de colaborador ACR, 167
Rol de colaborador, 77
Rol de aprobador de acceso de caja de seguridad del cliente, 75
rutas personalizadas, creación, 97
D
paneles en Azure Sentinel, 212
bases de datos
auditoría, 270 - 273
Base de datos SQL Azure avanzada protección contra amenazas, 273 - 276
cifrado
TDE (cifrado de datos transparente), 276 - 279
servidores de seguridad para, 140 - 142
conectores de datos en Azure Sentinel, 213 - 217
plano de datos para el control de acceso de Key Vault, 282
registros del plano de datos, 192
DDoS (denegación de servicio) de protección, 147 - 151
Cmdlet Debug-AzStorageAccountAuth, 259
permisos delegados, 71
borrando
grupos anidados, 12
usuarios, 14
requisitos de la cuenta de implementación para Azure AD Connect, 17
Traducción de direcciones de red de destino (DNAT), 118
modo de detección (WAF en Application Gateway), 134
cifrado determinista, 279
Rol de administradores de dispositivos, 75
registros de diagnóstico en Azure Monitor, 180
Función de lectores de directorio, 75
Función Cuentas de sincronización de directorios, 75
Rol de Escritores de directorio, 75
denegación de protección de servicio (DDoS), 147 - 151
DNAT (traducción de direcciones de red de destino), 118
membresía de grupo dinámico, 7
Rol de administrador de Dynamics 365 / administrador de CRM, 75
MI
direcciones de correo electrónico para autenticación, 32
alcance del correo electrónico (acceso a la aplicación), 71
habilitando
Autenticación de AD DS, 257 - 259
Autenticación de Azure AD DS, 260 - 261
Monitor Azure, 179
auditoría de base de datos, 270 - 273
autenticación de base de datos, 268 - 269
el registro del cortafuegos, 124 - 125
MFA (autenticación multifactor), 50 - 54
autenticación sin contraseña, 34 - 35
autoservicio de restablecimiento de contraseña, 28 de - 30 de
políticas de riesgo de inicio de sesión, 61 - 63
políticas de riesgo del usuario, 61 - 63
cifrado
de bases de datos
ExpressRoute, 106 - 107
de cuentas de almacenamiento, 262 - 267
cifrado de infraestructura, 264
gestión de claves, 263 - 264
visores, 264 - 267
estado de visualización, 262 - 263
tipos de, 279 - 280
para máquinas virtuales (máquinas virtuales), 156
cifrado en reposo, 168 - 169 de la
seguridad de punto final dentro de las máquinas virtuales, 151 - 156
evaluación de los resultados en Azure Sentinel, 228 - 232
eventos, buscando en Log Analytics espacio de trabajo (Azure
Monitor), 195 - 196
Función de administrador de Exchange, 76
ExpressRoute, 92 , 104 - 107
conectores externos en Azure Sentinel, 214
F
Llaves de seguridad FIDO2, 34
Cuentas de FileStorage, 244
cortafuegos
Cortafuegos de Azure
tala, 123 - 125
cortafuegos de recursos, 138 - 144
en Azure Aplicación de servicio, 143 - 144
en Azure Key Vault, 142 - 143
en bases de datos Azure SQL, 140 - 142
en Azure Storage, 138 - 140
WAF (firewall de aplicaciones web)
Integración de Azure Front Door, 133
configurar en Azure Application Gateway, 133 - 135
protección HTTP / S entrante, 118 , 122
configuración de alerta de fraude para MFA, 58
Puerta principal. Ver puerta de entrada azul
GRAMO
Cuentas V2 de uso general, 244
Cmdlet Get-ADOrganizationalUnit, 258
Cmdlet Get-AdUser, 257
Cmdlet Get-AzAdServicePrincipal, 3
Cmdlet Get-AzKeyVaultCertificate, 293
Cmdlet Get-AzKeyVaultCertificateContact, 293
Cmdlet Get-AzKeyVaultCertificateIssuer, 293
Cmdlet Get-AzKeyVaultCertificateOperation, 293
Cmdlet Get-AzKeyVaultCertificatePolicy, 293
Cmdlet Get-AzKeyVaultKey, 300
Cmdlet Get-AzKeyVaultSecret, 297
Cmdlet Get-AzRouteTable, 97
Cmdlet Get-AzureADDirectoryRole, 78
Cmdlet Get-AzureADDirectoryRoleMember, 78
Cmdlet Get-AzureADGroup, 8
Cmdlet Get-AzureKeyVaultSecret, 296
Cmdlet Get-AzVirtualNetworkGatewayConnectionSharedKey, 105
Cmdlet Get-AzVmDiskEncryptionStatus, 169
Función de administrador global / administrador de la empresa, 76
grupos, 6- 12
agregar / eliminar miembros, 10
asignación de acceso a la aplicación, 67 - 70
asignar roles a, 244
creando 8- 10
membresía dinámica, 7
nombrar 9
anidados, 10 - 12
tipos de, 6-7
Función de invitado invitado, 76
HOLA
Protección de clave HSM (módulo seguro de hardware), 299
cazando en Azure Sentinel, 212 , 231 - 232
IaaS (Infraestructura como Servicio) los registros de seguridad de
máquinas virtuales, la recogida de Azure con monitor, 192 - 194
identidades
grupos, 6- 12
agregar / eliminar miembros, 10
creando 8- 10
membresía dinámica, 7
nombrar 9
anidados, 10 - 12
tipos de, 6-7
asignar permisos, 3-6
componentes de, 3
creando 3
lista de visualización de, 3
tipos de, 1
usuarios, 13 - 15
creando, 13 - 14
borrar, 14
recuperándose, 14
proveedores de identidad para Azure App Service, 176
Cmdlet Import-AzKeyVaultCertificate, 293
importar certificados a Azure Key Vault, 289 - 293
reglas de entrada para NSG (grupos de seguridad de red), 110
incidentes en Azure Sentinel, 230 - 231
Función de administrador de protección de la información, 76
Registros de seguridad de VM de infraestructura como servicio (IaaS),
recopilación con Azure Monitor, 192 - 194
instalación de Azure AD Connect, 17 - 25 de
Función de administrador de Intune, 76
Cifrado IPSec, 107
J–K
Acceso a VM JIT (Just In Time), 201 -205
gestión de claves para cuentas de almacenamiento, 247 . Ver
también Azure Key Vault
cifrado, 263 - 264
Bóveda de llaves. Ver Azure Key Vault
Función de administrador de Key Vault, 288
Función de oficial de certificados de Key Vault, 288
Función de colaborador de Key Vault, 288
Función de Oficial de cifrado de Key Vault, 288
Función de cifrado del servicio de cifrado de Key Vault, 288
Función de usuario criptográfico de Key Vault, 288
Función de lector de Key Vault, 288
Función de oficial de secretos de Key Vault, 288
Función de usuario de Key Vault Secrets, 288
claves en Azure Key Vault
permisos, 286
giratorio, 298 - 303
KQL (lenguaje de consulta Kusto), 125
Kubernetes. Consulte AKS (Servicio de Azure Kubernetes)
L
capas en Azure monitor, 180 - 181
privilegio mínimo, principio de, 81 , 155 , 166
Función de administrador de licencias, 76
requisitos de licencia, PIM (Privileged Identity Management), 45
balanceadores de carga, Azure Application Gateway como, 126
bloqueos en Azure Blueprint, 240
Área de trabajo de Log Analytics (Azure Monitor), búsqueda de
eventos, 195 - 196
Espacio de trabajo de Log Analytics (Azure Sentinel), 228 - 229
recopilación de registros con Azure Monitor
IaaS VM registra, 192 - 194
búsqueda de eventos en el espacio de trabajo de Log Analytics, 195 - 196
Seguridad y solución de Auditoría, 194 - 195
registrar la retención en Azure monitor, configuración, 189 - 192
inicio de sesión en Azure Firewall, 123 - 125
aislamiento lógico, 166
Aplicaciones lógicas. Ver aplicaciones lógicas de Azure
METRO
MACsec, 106 - 107
plano de gestión para el control de acceso de Key Vault, 282
Función de lector del centro de mensajes, 76
métricas en Azure monitor, 181 - 183
creando alertas desde, 184
MFA (autenticación multifactor), 49 - 60
administrar usuarios, 54 - 60
configuración de bloqueo de cuenta, 57
bloquear / desbloquear usuarios, 58
configuración de alerta de fraude, 58
Fichas de OATH, 59
configuración de llamadas telefónicas, 59
utilización de informes, 60
para pasarelas VPN, 105
Aplicación Microsoft Authenticator, 32 - 34
Reglas de creación de incidentes de Microsoft en Azure
Sentinel, 217 , 223 - 224
Inteligencia de amenazas de Microsoft, 119
números de teléfono móvil para autenticación, 32
Monitor. Ver Azure Monitor
autenticación multifactor. Ver MFA (autenticación multifactor)
VPN de varios sitios, 104
NORTE
nombres de grupos, 9
NAT (Network Address Translation), 100 - 103
Puerta de enlace NAT
facturación, 101
crear, 101 - 103
grupos anidados, 10 - 12
acceso a la red para Azure clave Vault, 282 - 285
componentes de red, 89 - 103
peering, 97 - 100
enrutamiento, 95 - 97
subredes, 91
pasarelas de red virtuales, 91
VNets (redes virtuales), configuración, 90 - 95
reglas de red, creación, 122 - 123
Seguridad de la red
Cortafuegos Azure, 117 - 125
Grupos directivos nacionales (grupos de seguridad de
red), 91 , 109 - 114 , 201
puntos finales de servicio, 145 - 147
Puertas de enlace VPN, 104 - 108
Cifrado ExpressRoute, 106 - 107
punto a sitio (P2S), 107 - 108
sitio a sitio (S2S), 108
tipos de, 104
WAF (Web Application Firewall), 133 - 135
grupos de seguridad de red (grupos directivos
nacionales), 91 , 109 - 114 , 201
Cmdlet New-AzADServicePrincipal, 3
Cmdlet New-AzFirewallApplicationRule, 122
Cmdlet New-AzFirewall, 120
Cmdlet New-AzFirewallNetworkRule, 123
Cmdlet New-AzKeyVaultCertificateOrganizationDetail, 294
Cmdlet New-AzKeyVaultCertificatePolicy, 294
Cmdlet New-AzNatGateway, 104
Cmdlet New-AzNetworkSecurityGroup, 112
Cmdlet New-AzNetworkSecurityRuleConfig, 114
Cmdlet New-AzRoleAssignment, 5
Cmdlet New-AzRouteTable, 97
Cmdlet New-AzureADGroup, 8
New-AzVaultCertificateAdministratorDetail cmdlet, 294
Cmdlet New-AzVirtualNetwork, 95
Cmdlet New-AzVM, 95
dominios nonroutable, UPN sufijos y, 25 - 27
cuadernos en Azure Sentinel, 213
red), 91 , 109 - 114 , 201
O
Fichas OATH, 32
para usuarios de MFA, 59
OAuth, 32 años
Grupos de Office 365, 6-7
alcance del acceso sin conexión (acceso a la aplicación), 71
alcance abierto (acceso a la aplicación), 71
sistemas operativos compatibles con máquinas virtuales, 197
reglas de salida para NSG (grupos de seguridad de red), 111
Rol de propietario ACR, 167
Rol de propietario, 77
PAG
VPN P2S (punto a sitio), 104 , 107 - 108
autenticación de paso en Azure AD Connect, 27 de - 28 de
Función de administrador de contraseña / administrador del servicio de
asistencia, 76
autenticación de contraseña, 31
autenticación sin contraseña, 33 - 36
sincronización de contraseña en Azure AD Connect, 27
escritura diferida de contraseña, 15 - 30
Azure AD Connect, 15 - 28 de
instalación, 17 - 25
inscribirse en las opciones, 27 de - 28 de
Sufijos UPN y dominios nonroutable, 25 - 27
habilitar el restablecimiento de contraseña de autoservicio, 28 - 30
redes virtuales igualitarios, 97 - 100
consentimiento de permiso para el acceso a la aplicación, 71 - 73
ámbitos de permisos para el acceso de aplicaciones, 70 - 71
permisos, 74 - 85
asignando a los directores de servicio, 3-6
archivo y carpeta, 260
interpretación, 84
nivel de acciones, 259
configuración de llamadas telefónicas para MFA, 59
aislamiento físico, 167
PIM (gestión de identidad privilegiada)
activar / configurar, 43 - 45
requisitos de licencia, 45
ver el historial de auditoría de recursos, 38 - 40
libros de jugadas en Azure Sentinel, 213
VPN de punto a sitio (P2S), 104 , 107 - 108
politicas
planos versus 236
definiciones de políticas, 206
efecto de política, 206
aplicación de políticas, configuración
en Azure Blueprint, 236 - 240
en Azure Policy, 232 - 236
Rol de administrador de Power BI, 76
modo de prevención (WAF en Application Gateway), 135
niveles de precios, ACR (Azure Container Registry), 167
principio de privilegio mínimo, 81 , 155 , 166
conexiones de punto de conexión privadas para Azure Key Vault, 284
acceso privilegiado, monitoreo, 38 - 40
Gestión de identidad privilegiada (PIM)
activar / configurar, 43 - 45
requisitos de licencia, 45
ver el historial de auditoría de recursos, 38 - 40
Rol de administrador de roles privilegiados, 76
alcance del perfil (acceso a la aplicación), 71
protocolos para VPN P2S (punto a sitio), 108
Q–R
Extensión de Qualys, 196 - 198
autentificación de almacenamiento de colas, 255 - la tecnología 256
RADIO, 105 - 106
cifrado aleatorio, 279
RBAC (control de acceso basado en roles)
con Azure Key Vault, 287 - 288
configurar, 77
autenticación recipiente, 159 - 161
roles
para almacenamiento de blobs y colas, 256
niveles de, 244
lista de, 245
Función del lector ACR, 167
Función de lector, 77
recuperación de usuarios, 14
registrando aplicaciones, 2, 64 - 66
Panel de cumplimiento normativo (Azure Security Center), 209 - 211
Cmdlet Remove-AzKeyVaultCertificate, 294
Cmdlet Remove-AzKeyVaultCertificateContact, 294
Cmdlet Remove-AzKeyVaultCertificateIssuer, 294
Cmdlet Remove-AzKeyVaultCertificateOperation, 294
Cmdlet Remove-AzKeyVaultKey, 300
Cmdlet Remove-AzKeyVaultSecret, 297
Cmdlet Remove-AzureADDirectoryRoleMember, 79
Cmdlet Remove-AzureADGroup, 8
Cmdlet Remove-AzureADGroupMember, 8
Cmdlet Remove-AzureADGroupOwner, 8
Cmdlet Remove-AzureKeyVaultSecret, 296
quitando
grupos anidados, 12
usuarios, 14
informes, utilización de MFA, 60
Función de lector de informes, 76
requisitos
Azure AD Connect
autenticación basada en certificados, 33
PIM (Privileged Identity Management), requisitos de licencia, 45
historial de auditoría de recursos, visualización, 38 - 40
en Azure Aplicación de servicio, 143 - 144
en Azure Key Vault, 142 - 143
en bases de datos Azure SQL, 140 - 142
en Azure Storage, 138 - 140
registros de recursos en Azure Monitor, 180
permisos de recursos, 74 - 79
visualización, 84 - 85
recursos en Azure Monitor, 181
Cmdlet Restore-AzKeyVaultCertificate, 294
Cmdlet Restore-AzKeyVaultKey, 300
Cmdlet Restore-AzKeyVaultSecret, 297
Cmdlet Restore-AzureKeyVaultCertificate, 306
Cmdlet Restore-AzureKeyVaultKey, 306
Cmdlet Restore-AzureKeyVaultSecret, 306
Restauración de elementos clave Azure Vault, 303 - 307
resultados, evaluando en Azure Sentinel, 228 - 232
revocar la delegación de usuario SAS, 252 - 253
control de acceso basado en roles. Ver RBAC (control de acceso basado en
roles)
roles
asignar
a las aplicaciones, 3-6
usuarios a, 78 - 79
personalizado, 81 - 84
definido, 74
identificando, 81
lista de, 75 - 76
RBAC
para almacenamiento de blobs y colas, 256
niveles de, 244
lista de, 245
ver asignaciones, 77 - 78
giratorio
llaves en Azure clave Bóveda, 298 - 303
secretos en Azure clave Bóveda, 302 - 303
claves de acceso a la cuenta de almacenamiento, 247 - 250
regla del privilegio mínimo, 244
reglas, creando
S
VPN S2S (sitio a sitio), 104 , 108
SAS (firmas de acceso compartido), 251 - 254
mejores prácticas, 251 - 252
fichas, 253 - 254
tipos de, 251
delegación de usuarios SAS, 252 - 253
reglas de consulta programadas en Azure Sentinel, 217 - 223
alcance
para permisos, 74
para el cifrado de la cuenta de almacenamiento, 264 - 267
buscar eventos en el registro de Analytics espacio de trabajo (Azure
Monitor), 195 - 196
secretos en Azure Key Vault
gestión, 296 - 298
permisos, 286
giratorio, 302 - 303
seguridad
seguridad informática
para ACR (Azure Container Registro), 167 - 168
de autenticación para contenedores, 159 - 161
Azure para la aplicación de servicio, 170 - 176
seguridad de los contenedores, 161 - 164
aislamiento, 166 - 167
gestión de vulnerabilidades, 164 -165
Seguridad de la red
Cortafuegos Azure, 117 - 125
red), 91 , 109 - 114 , 201
los extremos de servicio, 145 - 147
Puertas de enlace VPN, 104 - 108
WAF (firewall de aplicaciones web), 133 -135
Rol de administrador de seguridad, 76
Seguridad y solución de auditoría (Azure Monitor), 194 - 195
Centro de Seguridad. Ver Azure Security Center
grupos de seguridad, 6-7
Gestión de eventos e información de seguridad (SIEM), 212
inicio de sesión con llave de seguridad, 34
Orquestación, automatización y respuesta de seguridad (SOAR), 212
directores de seguridad, 74 , 285
preguntas de seguridad, 31 - 32
Rol de lector de seguridad, 76
configuración de servicios de seguridad. Ver Azure Monitor
ajustes de seguridad, configurar
con Azure Blueprint, 236 - 240
con Azure Policy, 232 - 236
restablecimiento de contraseña de autoservicio (SSPR), 15
objetos de entidad de servicio, 2
asignar permisos, 3-6
componentes de, 3
creando 3
lista de visualización de, 3
servicio SAS, 251
Función de administrador de soporte de servicio, 76
Cmdlet Set-ACL, 260
Cmdlet Set-AzDiagnosticSetting, 125
Cmdlet Set-AzKeyVaultAccessPolicy, 286
Cmdlet Set-AzKeyVaultCertificateIssuer, 294
Cmdlet Set-AzKeyVaultCertificatePolicy, 294
Cmdlet Set-AzKeyVaultSecret, 296 , 298
Cmdlet Set-AzRouteTable, 97
Cmdlet Set-AzStorageAccount, 261
Cmdlet Set-AzureADGroup, 8
Cmdlet Set-AzVirtualNetwork, 97
Cmdlet Set-AzVirtualNetworkGatewayConnectionSharedKey, 105
Cmdlet Set-AzVirtualNetworkSubnetConfig, 97
Cmdlet Set-AzVmDiskEncryptionExtensions, 169
El acceso compartido Firmas (SAS), 251 - 254
fichas, 253 - 254
tipos de, 251
modelo de responsabilidad compartida, 89
Rol de administrador de SharePoint, 76
SIEM (Gestión de eventos e información de seguridad), 212
de sesión de opciones en Azure AD Connect, 27 de - 28 de
políticas de riesgo de inicio de sesión, 61 - 63
inicio de sesión único, 15
VPN de sitio a sitio (S2S), 104 , 108
Rol de administrador de Skype Empresarial / Lync, 76
SOAR (orquestación, automatización y respuesta de seguridad), 212
claves protegidas por software, 299
actualizaciones de software en Azure App Service, 176
Bases de datos SQL. Ver bases de datos
Requisitos de SQL Server, Azure AD Connect, 16 - 17
Servidores SQL, evaluación de la vulnerabilidad, 199 - 200
Certificados SSL / TLS, la configuración, 172 - 174
SSPR (restablecimiento de contraseña de autoservicio), 15
Cmdlet Stop-AzKeyVaultCertificateOperation, 294
Función de colaborador de la cuenta de almacenamiento, 245
Función de servicio del operador principal de la cuenta de
almacenamiento, 245
cuentas de almacenamiento
ATP (Protección contra amenazas avanzada) para Azure
Storage, 267 - 268
autentificación con Azure AD, 255 - la tecnología 256
Autenticación de Azure Files, 256 - 261
cifrado, 262 - 267
gestión de claves, 263 - 264
visores, 264 - 267
estado de visualización, 262 - 263
gestión de claves, 247
Roles de RBAC
niveles de, 244
lista de, 245
SAS (firmas de acceso compartido), 251 - 254
tipos de, 251
políticas de acceso almacenadas, 255
tipos de, 244
Rol de colaborador de datos de Storage Blob, 245 , 256
Rol de propietario de datos de Storage Blob, 245 , 256
Función de lector de datos de Storage Blob, 245 , 256
Rol de delegador de blobs de almacenamiento, 245 , 256
Rol de colaborador de recursos compartidos de SMB de datos de archivos
de almacenamiento, 259
Almacenamiento de datos de archivos SMB Compartir rol de colaborador
elevado, 245 , 259
Almacenamiento de datos de archivos Función de lector de recursos
compartidos de SMB, 245 , 259
Rol de colaborador de recursos compartidos de SMB de archivos de
almacenamiento, 245
Rol de colaborador de datos de la cola de almacenamiento, 245 , 256
Rol de procesador de mensajes de datos de cola de
almacenamiento, 245 , 256
Función de remitente de mensajes de datos de la cola de
almacenamiento, 245 , 256
Función de lector de datos de cola de almacenamiento, 245 , 256
políticas de acceso almacenadas
para contenedores de blobs, 255
con servicio SAS, 251
subredes, 91
permisos de suscripción, 74 - 79
suscripciones (Azure), transferencia, 36 - 37
requisitos del sistema, Azure AD Connect, 15 - 16 de
T
Rol de administrador de equipos, 76
Rol de administrador de comunicaciones de Teams, 76
Rol de ingeniero de soporte de comunicaciones de Teams, 76
Rol de especialista en soporte de comunicaciones de Teams, 76
Plantillas para reglas de consultas programadas en Azure
Sentinel, 222 - 223
inquilinos (Azure), transferencia de suscripciones, 36 - 37
detección de amenazas para VMS (máquinas virtuales), 155 - 156
caza amenaza en Azure Sentinel, 231 - 232
protección contra amenazas para SQL, 199
interrupciones de tráfico, 91
transferencia de suscripciones (Azure), 36 - 37
cifrado transparente de datos (TDE), 276 - 279
solución de problemas de acceso a máquinas virtuales JIT (Just In
Time), 205
U
desbloquear usuarios de MFA, 58
Cmdlet Undo-AzKeyVaultCertificateRemoval, 294
Cmdlet Undo-AzKeyVaultKeyRemoval, 300
Cmdlet Undo-AzKeyVaultSecretRemoval, 298
Cmdlet Update-AzKeyVaultCertificate, 294
Cmdlet Update-AzKeyVaultKey, 300
Cmdlet Update-AzKeyVaultSecret, 298
Update-AzStorageAccountADOjbectPassword cmdlet, 259
Update-AzStorageAccountNetworkRuleSet cmdlet, 140
Cmdlet Update-AzureKeyVaultSecret, 296
La administración de actualizaciones (en Azure Automation), 156 - 159
actualizaciones
actualizaciones de software en Azure App Service, 176
Sufijos UPN, dominios nonroutable y, 25 - 27
Función de administrador de acceso de usuario, 77
Función de administrador de cuentas de usuario, 76
objetos principales de usuario, 2
permisos de recursos de usuario, visualización, 84 - 85
políticas de riesgo del usuario, 61 - 63
usuarios, 13 - 15
asignación de acceso a la aplicación, 67 - 70
asignación de roles, 78 - 79
creando, 13 - 14
borrar, 14
recuperándose, 14
ver asignaciones de roles, 77 - 78
V
visita
registros de auditoría, 271 - 273
Alertas de Azure Monitor, 188
estado de cifrado de blob, 262 - 263
protección de terminales, 151 - 154
historial de auditoría de recursos, 38 - 40
lista de entidades de servicio, 3
claves de acceso a la cuenta de almacenamiento, 248 - 249
permisos de recursos de usuario, 84 - 85
asignaciones de roles de usuario, 77 - 78
pasarelas de red virtuales, 91 , 104 - 108
tipos de, 104
VM (máquinas virtuales)
actualizaciones del sistema, 156 - 159
VNets (redes virtuales)
configurar, 90 - 95
peering, 97 - 100
seguridad, 104 - 108
VPN de red virtual a red virtual, 104
Puertas de enlace VPN, 91 , 104 - 108
tipos de, 104
evaluación de la vulnerabilidad con Azure Centro de seguridad, 196 - 200
W–Z
WAF (firewall de aplicaciones web)
Integración de Azure Front Door, 133
configurar en Azure Application Gateway, 133 - 135
protección HTTP / S entrante, 118 , 122
Windows Hello para empresas, 34
libros en Azure Sentinel, 229 - 230
espacios de trabajo en Azure Sentinel, 213
x509 certificados, gestión de Azure clave Bóveda, 288 - 296
Ref. De examen AZ-500:
Tecnologías de seguridad de
Microsoft Azure
LISTA DE URL
Capítulo 1
https://docs.microsoft.com/en-us/azure/active-
directory/develop/app-objects-and-service-principals
https://docs.microsoft.com/en-us/powershell/azure/create-azure-
service-principal-azureps
https://docs.microsoft.com/en-us/azure/role-based-access-
control/built-in-roles
directory/fundamentals/active-directory-groups-view-azure-portal
directory/fundamentals/active-directory-manage-groups
directory/fundamentals/active-directory-groups-membership-azure-
portal
https://docs.microsoft.com/en-us/powershell/azure/active-
directory/new-user-sample
directory/authentication/tutorial-enable-sspr-writeback
https://secure.aadcdn.microsoftonline-p.com
directory/connect/active-directory-aadconnect-user-signin
https://passwordreset.microsoftonline.com
directory/authentication/concept-sspr-howitworks
directory/authentication/concept-authentication-methods
directory/authentication/active-directory-certificate-based-
authentication-get-started
directory/authentication/concept-authentication-passwordless
https://docs.microsoft.com/en-us/azure/active-directory/b2b/add-
users-administrator
directory/fundamentals/active-directory-how-subscriptions-
associated-directory
https://docs.microsoft.com/en-us/azure/active-directory/privileged-
identity-management/pim-how-to-use-audit-log
identity-management/pim-how-to-perform-security-review
identity-management/pim-configure
identity-management/subscription-requirements
identity-management/pim-security-wizard
https://docs.microsoft.com/en-us/azure/active-directory/conditional-
access/overview
https://docs.microsoft.com/en-us/office365/admin/security-and-
compliance/multi-factor-authentication-plan
directory/authentication/concept-mfa-howitworks
https://docs.microsoft.com/en-us/office365/admin/security-and-
compliance/setup-multi-factor-authentication
directory/authentication/howto-mfa-mfasettings
directory/authentication/howto-mfa-reporting
https://docs.microsoft.com/en-us/azure/active-directory/identity-
protection/overview-identity-protection
directory/develop/quickstart-register-app
https://docs.microsoft.com/en-us/azure/active-directory/manage-
apps/what-is-access-management
https://docs.microsoft.com/en-us/azure/active-directory/manage-
apps/methods-for-assigning-users-and-groups
https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-
permissions-and-consent
https://docs.microsoft.com/en-us/azure/api-management/api-
management-policies
control/overview
https://docs.microsoft.com/en-us/azure/active-directory/users-
groups-roles/directory-assign-admin-roles
groups-roles/roles-concept-delegation
groups-roles/directory-manage-roles-portal
https://docs.microsoft.com/en-
us/rest/api/authorization/permissions/listforresourcegroup
control/built-in-roles
us/azure/security/fundamentals/identity-management-best-practices
control/custom-roles
control/role-definitions#management-and-data-operations
control/check-access
Capitulo 2
https://shell.azure.com
http://aka.ms/az500mfa
http://aka.ms/az500vpnsku
http://aka.ms/az500vpnexpressroute
https://aka.ms/az500s2sdevices
https://aka.ms/az500s2svpn
http://aka.ms/wafdecisionflow
https://owasp.org/www-project-top-ten
https://aka.ms/az500wafag
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-
network-service-endpoints-overview
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-
network-service-endpoint-policies-overview
http://aka.ms/az500DDoS
https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster
https://kubernetes.io/docs/concepts/configuration/secret
http://aka.ms/az500kvfw
http://aka.ms/az500ADELinux
http://aka.ms/az500ADEWin
https://aka.ms/az500AppCertificates
http://aka.ms/az500AppServiceAuth
https://docs.microsoft.com/en-us/powerapps/maker/common-data-
service/data-platform-intro
https://github.com/projectkudu/kudu/wiki/Kudu-console
Capítulo 3
https://aka.ms/ASICommunity
Capítulo 4
https://docs.microsoft.com/en-us/azure/storage/common/storage-
auth-aad-rbac-portal
account-keys-manage
sas-overview
https://docs.microsoft.com/en-us/rest/api/storageservices/create-
user-delegation-sas
https://docs.microsoft.com/en-us/rest/api/storageservices/create-
account-sas
https://docs.microsoft.com/en-us/rest/api/storageservices/define-
stored-access-policy
auth-aad
https://docs.microsoft.com/en-us/azure/storage/files/storage-files-
identity-auth-active-directory-domain-service-enable
service-encryption
us/azure/storage/common/infrastructure-encryption-enable
https://docs.microsoft.com/en-us/azure/storage/blobs/encryption-
scope-manage
advanced-threat-protection?tabs=azure-security-center
https://docs.microsoft.com/en-us/azure/azure-sql/database/logins-
create-manage
https://docs.microsoft.com/en-us/azure/azure-sql/database/auditing-
overview
https://docs.microsoft.com/en-us/azure/azure-sql/database/threat-
detection-overview
https://docs.microsoft.com/en-us/sql/relational-
databases/security/encryption/sql-server-
encryption?view=azuresqldb-current
https://docs.microsoft.com/en-us/sql/relational-
databases/security/encryption/always-encrypted-database-
engine?view=sql-server-ver15
https://docs.microsoft.com/en-us/azure/key-vault/general/overview-
security
https://docs.microsoft.com/en-us/azure/key-vault/general/network-
security
https://docs.microsoft.com/en-us/azure/key-vault/general/group-
permissions-for-apps
http://docs.microsoft.com/en-us/azure/key-vault/general/secure-
your-key-vault
https://docs.microsoft.com/en-us/azure/key-vault/certificates/about-
certificates
https://mykeyvault.vault.azure.net/certificates/mycert1/create?api-
version={api-version}
https://docs.microsoft.com/en-us/azure/key-
vault/certificates/certificate-scenarios
https://docs.microsoft.com/en-us/azure/key-vault/secrets
https://docs.microsoft.com/en-us/azure/key-vault/keys
https://docs.microsoft.com/en-us/azure/key-vault/secrets/tutorial-
rotation
https://docs.microsoft.com/en-us/azure/key-vault/general/backup
Fragmentos de código
Muchos títulos incluyen código de programación o ejemplos de
configuración. Para optimizar la presentación de estos elementos, vea
el libro electrónico en modo horizontal de una sola columna y ajuste el
tamaño de fuente al valor más pequeño. Además de presentar el código
y las configuraciones en el formato de texto ajustable, hemos incluido
imágenes del código que imitan la presentación que se encuentra en el
libro impreso; por lo tanto, cuando el formato reajustable pueda
comprometer la presentación del listado de código, verá un enlace
"Haga clic aquí para ver la imagen del código". Haga clic en el enlace
para ver la imagen del código de fidelidad de impresión. Para volver a
la página anterior vista, haga clic en el botón Atrás en su dispositivo o
aplicación.

Az 500 - Español PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Az 500 - Español PDF

Cargado por

Copyright:

Formatos disponibles

Examen Ref AZ-500 Tecnologías de

seguridad de Microsoft Azure

Capítulo 1 Gestionar la identidad y el acceso

Capítulo 2 Implementar la protección de la plataforma

Capítulo 3 Gestionar operaciones de seguridad

Capítulo 4 Datos y aplicaciones seguros

Capítulo 1 Gestionar la identidad y el acceso

Capítulo 2 Implementar la protección de la plataforma

Capítulo 3 Gestionar operaciones de seguridad

Orin Thomas es un defensor principal de operaciones en la nube en

ORGANIZACIÓN DE ESTE LIBRO

PREPARÁNDOSE PARA EL EXAMEN

ACCESO RÁPIDO A REFERENCIAS EN LÍNEA

ERRATAS, ACTUALIZACIONES Y ASISTENCIA

Gestionar la identidad y el acceso

Habilidades en este capítulo:

Configurar la seguridad para los principales de

Las entidades de servicio son análogas a una cuenta de servicio de Active

Crear una entidad de servicio

Los directores de servicio pueden utilizar dos tipos diferentes de

Más información Crear director de servicio

Asignar permisos a los principales de servicio a través

New-AzRoleAssignment -RoleDefinitionName "Reader" -

Trabajar con entidades de servicio en entornos de línea de comandos

Figura 1-3 Comprobación de las asignaciones de roles para los

Administrar grupos de directorios de Azure AD

Figura 1-4 Crear grupo de Azure AD

Figura 1-5 Membresía de grupo dinámico de Office 365

Figura 1-6 hoja de menú de Azure Active Directory

Más información Creación de grupos

Agregar y eliminar miembros del grupo

Puede determinar el ID de objeto de un usuario utilizando el az ad user

Figura 1-8 Lista de grupos de Azure AD

Figura 1-10 Selección de un grupo para anidar

Administrar usuarios de Azure AD

Figura 1-11 Página de propiedades del usuario

Configurar la escritura diferida de contraseñas

Instalar y configurar Azure AD Connect

Requisitos de SQL Server

Requisitos para cuentas de implementación

Instalación de Azure AD Connect

Figura 1-13 Página de instalación de componentes necesarios

Usar sufijos UPN y dominios no enrutables

Figura 1-22 Configuración del sufijo UPN para un dominio

Figura 1-23 Configurar UPN

"DC = epistémico, DC = interno" |

Set-ADUser $ _ -UserPrincipalName $ UPN

Opciones de inicio de sesión

Federación de Active Directory

Implementar y administrar el restablecimiento de

Figura 1-24 Centro de administración de Azure Active Directory

Figura 1-26 Restablecer contraseña

Contraseña Autenticación multifactor y restablecimiento de con

Preguntas de seguridad Solo restablecimiento de contraseña de autoservicio

Dirección de correo electrónico Solo restablecimiento de contraseña de autoservicio

Aplicación Microsoft Autenticación multifactor y restablecimiento de con

Tokens de hardware OATH Autenticación multifactor y restablecimiento de con

SMS Autenticación multifactor y restablecimiento de con

Llamada de voz Autenticación multifactor y restablecimiento de con

Contraseñas de la aplicación Autenticación multifactor en algunos casos

Autenticación basada en certificados

Autenticación sin contraseña

Transferir suscripciones de Azure entre inquilinos