En el capítulo anterior, hemos hablado de los servicios de datos de Azure. A medida que tratamos con datos confidenciales, la seguridad es una gran preocupación. La seguridad es, sin duda, el requisito no funcional más importante que deben implementar los arquitectos. Las empresas ponen mucho énfasis en que su estrategia de seguridad se implemente correctamente. De hecho, la seguridad es una de las principales preocupaciones para casi todas las partes interesadas en el desarrollo, la implementación y la administración de una aplicación. Y adquiere aún más importancia cuando una aplicación se crea para implementarla en el cloud.
Para que entiendas cómo puedes proteger tus aplicaciones en Azure en función de la
naturaleza de la implementación, en este capítulo abordaremos los siguientes temas:

• Descripción de la seguridad en Azure
• Seguridad en el nivel de infraestructura
• Seguridad en el nivel de la aplicación
• Autenticación y autorización en aplicaciones de Azure
• Trabajar con OAuth, Azure Active Directory y otros métodos de autenticación mediante
  identidad federada, incluidos proveedores de identidades de terceros como Facebook
• Describir identidades administradas y usarlas para acceder a los recursos

Seguridad
Como se ha mencionado anteriormente, la seguridad es un elemento importante para
cualquier software o servicio. Se debe implementar una seguridad suficiente para que solo
puedan usar una aplicación personas que tengan permiso para acceder a ella y los usuarios
no deben poder realizar operaciones que no se les permita ejecutar. Del mismo modo, todo
el mecanismo de solicitud-respuesta debe construirse utilizando métodos que garanticen
que solo las partes previstas puedan comprender los mensajes y para garantizar que sea
fácil detectar si los mensajes se han manipulado o no.
La seguridad en Azure es incluso más importante por los motivos siguientes. En primer
lugar, las organizaciones que implementan sus aplicaciones no tienen el control total del
hardware y las redes subyacentes. En segundo lugar, la seguridad tiene que integrarse en
todas las capas, incluidos el hardware, las redes, los sistemas operativos, las plataformas
y las aplicaciones. Cualquier omisión o error de configuración puede hacer que una
aplicación sea vulnerable a los intrusos. Por ejemplo, es posible que hayas oído hablar
de la vulnerabilidad reciente que afectó a las reuniones de Zoom y permitió a los hackers
grabar las reuniones incluso cuando el anfitrión de la reunión había deshabilitado la
grabación para los asistentes. Las fuentes afirman que se han vendido millones de
cuentas de Zoom en la «dark web». La empresa ha tomado las medidas necesarias
para hacer frente a esta vulnerabilidad.
Hoy en día, la seguridad es una gran preocupación, especialmente cuando se hospedan
aplicaciones en el cloud, y puede tener consecuencias graves si se gestionan mal. Por lo
tanto, es necesario comprender las prácticas recomendadas implicadas en la protección
de tus cargas de trabajo. Estamos progresando en el área de DevOps, donde los equipos
de desarrollo y operaciones colaboran eficazmente con la ayuda de herramientas
y prácticas, y la seguridad también ha sido una gran preocupación en este ámbito.

Para adaptarse a los principios y prácticas de seguridad como parte esencial de DevOps sin
afectar a la productividad general y la eficiencia del proceso, se ha introducido una nueva
cultura conocida como DevSecOps. DevSecOps nos ayuda a identificar los problemas de
seguridad al principio de la etapa de desarrollo en lugar de mitigarlos después del envío.
En un proceso de desarrollo que tiene la seguridad como principio clave de cada etapa,
DevSecOps reduce el coste de la contratación de profesionales de seguridad en una
etapa posterior para encontrar defectos de seguridad con el software.
La seguridad de una aplicación implica que entidades desconocidas y no autorizadas no
puedan acceder a ella. También significa que la comunicación con la aplicación es segura
y no puede manipularse. Esto incluye las siguientes medidas de seguridad:

• Autenticación: la autenticación comprueba la identidad de un usuario y garantiza que
  dicha identidad puede acceder a la aplicación o el servicio. La autenticación se realiza
  en Azure mediante OpenID Connect, que es un protocolo de autenticación basado
  en OAuth 2.0.
• Autorización: la autorización permite y establece permisos que una identidad
  concreta puede realizar dentro de la aplicación o servicio. La autorización se lleva
  a cabo en Azure mediante OAuth.
• Confidencialidad: la confidencialidad garantiza que la comunicación entre el usuario y
  la aplicación permanece segura. El intercambio de carga entre entidades está cifrado,
  por lo que solo tiene sentido para el remitente y el receptor, y para nadie más. La
  confidencialidad de los mensajes se garantiza mediante cifrado simétrico y asimétrico.
  Se utilizan certificados para implementar criptografía, es decir, para el cifrado y
  descifrado de los mensajes.
  El cifrado simétrico utiliza una sola clave, que se comparte con el remitente y el receptor,
  mientras que el cifrado asimétrico utiliza un par de claves privadas y públicas para el
  cifrado, que es más seguro. Los pares de claves SSH en Linux, que se utilizan para la
  autenticación, son un buen ejemplo de cifrado asimétrico.
• Integridad: la integridad garantiza que el intercambio de carga y de mensajes entre el
  remitente y el receptor no se manipula. El receptor recibe el mismo mensaje que envió
  el remitente. Las firmas digitales y los hashes son los mecanismos de implementación
  para verificar la integridad de los mensajes entrantes.

La seguridad es una asociación entre el proveedor de servicios y el consumidor del servicio.
Ambas partes tienen diferentes niveles de control sobre las pilas de implementación
y cada una debe implementar las prácticas recomendadas de seguridad para garantizar
la identificación y mitigación de todas las amenazas. En el capítulo 1, Introducción a Azure,
hemos visto que el cloud ofrece tres paradigmas (IaaS, PaaS y SaaS), cada uno de ellos
con diferentes niveles de control colaborativo sobre la pila de implementación. Cada parte
debe implementar prácticas de seguridad para los componentes que se encuentran bajo
su control y dentro de su ámbito. El hecho de no implementar las prácticas de seguridad
en cualquier capa de la pila o por parte de cualquier parte haría que la implementación
completa y la aplicación fueran vulnerables a un ataque. Todas las organizaciones deben
tener un modelo de ciclo de vida para la seguridad, al igual que para cualquier otro proceso.
Esto garantiza que las prácticas de seguridad se mejoren continuamente para evitar
cualquier error de seguridad. En la siguiente sección, analizaremos el ciclo de vida
de la seguridad y cómo se puede usar.
Ciclo de vida de la seguridad
A menudo, la seguridad se considera un requisito no funcional para una solución. Sin embargo,
actualmente y debido al número cada vez mayor de ciberataques, se considera un requisito
funcional de cualquier solución.
Para sus aplicaciones, cada organización sigue algún tipo de administración del ciclo de
vida de la aplicación. Cuando la seguridad se trata como un requisito funcional, debe seguir
el mismo proceso de desarrollo de aplicaciones. La seguridad no debe ser una ocurrencia
de última hora, sino que debe formar parte de la aplicación desde el principio. En la fase
de planificación general de una aplicación, también se debe planificar la seguridad. En
función de la naturaleza de la aplicación, se deben identificar diferentes tipos y categorías
de amenazas y, en función de estas identificaciones, se deben documentar en términos de
enfoque y alcance para mitigarlas. Se debe realizar un ejercicio de simulación de amenazas
para ilustrar la amenaza de la que podría ser objeto cada componente. Esto llevará al diseño
de estándares y políticas de seguridad para la aplicación. Normalmente, esta es la fase
de diseño de seguridad. La fase siguiente se denomina mitigación de amenazas o fase
de compilación. En esta fase, la implementación de la seguridad en términos de código
y configuración se ejecuta para mitigar los riesgos y las amenazas de seguridad.
Un sistema no puede ser seguro hasta que se prueba. Deben realizarse pruebas de
penetración apropiadas y otras pruebas de seguridad para identificar posibles medidas
de mitigación de amenazas que no se han implementado o que se han pasado por alto.
Los errores de las pruebas se corrigen y el ciclo continúa durante toda la vida de la
aplicación. Por motivos de seguridad, debe seguirse este proceso de administración
del ciclo de vida de la aplicación, mostrado en la Figura 8.1:

La planificación, la simulación de amenazas, la identificación, la mitigación, las pruebas
y la corrección son procesos iterativos que continúan incluso cuando una aplicación o un
servicio están operativos. Debería haber una supervisión activa de entornos y aplicaciones
completos para identificar proactivamente las amenazas y mitigarlas. La supervisión
también debe habilitar alertas y registros de auditoría para ayudar en el diagnóstico
reactivo, la solución de problemas y la eliminación de amenazas y vulnerabilidades.
El ciclo de vida de la seguridad de cualquier aplicación comienza con la fase de planificación,
que finalmente conduce a la fase de diseño. En la fase de diseño, la arquitectura de la
aplicación se divide en componentes granulares con comunicación discreta y límites de
hosting. Las amenazas se identifican en función de su interacción con otros componentes
dentro y fuera de los límites de hosting. Dentro de la arquitectura general, las amenazas se
mitigan mediante la implementación de características de seguridad adecuadas y, una vez
se ha aplicado la mitigación, se realizan pruebas adicionales para verificar si la amenaza aún
existe. Una vez que la aplicación se implementa en producción y se pone en funcionamiento,
se supervisa para detectar cualquier infracción de seguridad y vulnerabilidad y se lleva
a cabo una corrección proactiva o reactiva.
Como se ha mencionado anteriormente, las diferentes organizaciones tienen diferentes
procesos y métodos para implementar el ciclo de vida de la seguridad; del mismo modo,
Microsoft proporciona orientación e información exhaustivas sobre el ciclo de vida de la
seguridad, disponibles en https://www.microsoft.com/securityengineering/sdl/practices.
Con las prácticas que Microsoft ha compartido, todas las organizaciones pueden centrarse
en crear soluciones más seguras. Conforme avanzamos en la era de la computación en el
cloud y migramos nuestros datos corporativos y de clientes al cloud, aprender a proteger
estos datos es vital. En la siguiente sección, exploraremos la seguridad de Azure y los
diferentes niveles de seguridad, lo que nos ayudará a crear soluciones seguras en Azure.

Seguridad de Azure
Azure proporciona todos sus servicios a través de centros de datos que se encuentran
en varias regiones de Azure. Estos centros de datos están interconectados no solo dentro
de una misma región, sino también entre las diversas regiones. Azure entiende que aloja
aplicaciones, servicios y datos esenciales para sus clientes. Debe garantizar que la seguridad
es de suma importancia para sus centros de datos y regiones.
Los clientes implementan aplicaciones en el cloud confiando en que Azure protegerá sus
aplicaciones y datos frente a vulnerabilidades e infracciones. Los clientes no se trasladarán
al cloud si esta confianza se rompe y, por lo tanto, tal como se muestra en la Figura 8.2,
Azure implementa la seguridad en todas las capas, desde el perímetro físico de los centros
de datos hasta los componentes lógicos del software. Todas las capas están protegidas
y ni siquiera el equipo del centro de datos de Azure tiene acceso a ellas:

La seguridad es de suma importancia tanto para Microsoft como para Azure. Microsoft se
asegura de generar confianza en sus clientes y, para ello, garantiza que las implementaciones,
las soluciones y los datos de sus clientes estén completamente seguros, tanto física
como virtualmente. La gente no utilizará una plataforma de cloud si no es segura física
y digitalmente.
Para garantizar que los clientes confíen en Azure, cada actividad en el desarrollo de
Azure se planifica, documenta, audita y supervisa desde una perspectiva de seguridad.
Los centros de datos físicos de Azure están protegidos contra cualquier intrusión y acceso
no autorizado. De hecho, ni siquiera el personal de Microsoft ni los equipos de operaciones
tienen acceso a las soluciones y los datos de los clientes. A continuación, se enumeran
algunas de las características de seguridad «out-of-the-box» proporcionadas por Azure:

• Acceso seguro de usuario: solo el cliente puede acceder a sus datos, solución e
  implementación. Ni siquiera el personal del centro de datos de Azure tiene acceso
  a los artefactos del cliente. Los clientes pueden permitir el acceso a otras personas,
  según consideren oportuno.
• Cifrado en reposo: Azure cifra todos sus datos de administración, lo que incluye
  una variedad de soluciones de almacenamiento de nivel empresarial para adaptarse
  a diferentes necesidades. Microsoft también proporciona cifrado a servicios
  administrados como Azure SQL Database, Azure Cosmos DB y Azure Data Lake
  Storage. Puesto que los datos están cifrados en reposo, nadie los puede leer.
  También proporciona esta funcionalidad a sus clientes, así como a aquellos
  que pueden cifrar sus datos en reposo.
• Cifrado en tránsito: Azure cifra todos los datos que fluyen desde su red. También
  garantiza que la red troncal de su red está protegida contra cualquier acceso no
  autorizado.
• Supervisión activa y auditoría: Azure supervisa activamente todos sus centros
  de datos de forma continua. Identifica activamente cualquier infracción, amenaza
  o riesgo y los mitiga.

Azure cumple con las normas de cumplimiento locales, internacionales y sectoriales
específicas de cada país. Puedes explorar la lista completa de ofertas de cumplimiento de
Microsoft en https://www.microsoft.com/trustcenter/compliance/complianceofferings.
Úsala como referencia mientras implementas soluciones conformes con las normativas
en Azure. Ahora que conocemos las características de seguridad clave de Azure, vamos
a profundizar en la seguridad de IaaS. En la siguiente sección, analizaremos cómo los
clientes pueden aprovechar las características de seguridad disponibles para IaaS en Azure.
Seguridad de IaaS
Azure es una plataforma madura para la implementación de soluciones de IaaS. Son muchos
los usuarios de Azure que desean tener el control completo de sus implementaciones
y generalmente usan la IaaS para sus soluciones. Es importante que estas implementaciones
y soluciones sean seguras, de forma predeterminada y por diseño. Azure proporciona
funciones de seguridad enriquecidas para proteger soluciones de IaaS. En esta sección,
se tratarán algunas de las características principales.
Grupos de seguridad de red
El mínimo indispensable de implementación de la IaaS consta de máquinas y redes virtuales.
Una máquina virtual puede estar expuesta a Internet al aplicar una IP pública a su interfaz
de red o puede estar disponible solo para recursos internos. Algunos de esos recursos
internos pueden, a su vez, exponerse a Internet. En cualquier caso, es necesario proteger
las máquinas virtuales de modo que las solicitudes no autorizadas ni siquiera lleguen a ellas.
Las máquinas virtuales deben protegerse mediante instalaciones que puedan filtrar las
solicitudes en la propia red, en lugar de que las solicitudes lleguen a una máquina virtual
y sea esta la que tenga que actuar.

El cercado es uno de los mecanismos de seguridad que utilizan las máquinas virtuales. Esta
cerca puede permitir o denegar solicitudes según su protocolo, IP de origen, IP de destino,
puerto de origen y puerto de destino. Esta característica se implementa con el recurso
Azure Network Security Groups (NSG). Los NSG se componen de reglas que se evalúan
para las solicitudes de entrada y de salida. Según la ejecución y evaluación de estas reglas,
se determina si se debe permitir o denegar el acceso de las solicitudes.
Los NSG son flexibles y pueden aplicarse a una subred de red virtual o interfaces de red
individuales. Cuando se aplican a una subred, las reglas de seguridad se aplican a todas las
máquinas virtuales hospedadas en la subred. Por otro lado, la aplicación a una interfaz de
red afecta exclusivamente a las solicitudes enviadas a una máquina virtual determinada
asociada a esa interfaz de red. También es posible aplicar NSG a subredes de red e
interfaces de red simultáneamente. Normalmente, este diseño debe usarse para aplicar
reglas de seguridad comunes en el nivel de la subred de red y reglas de seguridad únicas
en el nivel de la interfaz de red. Esto ayuda en el diseño de reglas de seguridad modulares.
El flujo para evaluar los NSG se muestra en la Figura 8.3:

Cuando una solicitud llega a un host de Azure, se cargan las reglas apropiadas en función
de si se trata de una solicitud entrante o saliente, y cada una de ellas se ejecuta según la
solicitud/respuesta. Si la regla coincide con la solicitud/respuesta, se permite o deniega
la solicitud/respuesta. La coincidencia de reglas consta de información importante de
solicitud/respuesta, como la dirección IP de origen, la dirección IP de destino, el puerto
de origen, el puerto de destino y el protocolo utilizado. Además, los NSG admiten las
etiquetas de servicio. Una etiqueta de servicio indica un grupo de prefijos de direcciones
IP de un servicio de Azure determinado. Microsoft administra los prefijos de direcciones
y los actualiza automáticamente. Esto elimina la molestia de actualizar las reglas de
seguridad cada vez que se cambia el prefijo de la dirección.
El conjunto de etiquetas de servicio disponibles para su uso puede consultarse en https://
docs.microsoft.com/azure/virtual-network/service-tags-overview#available-service-tags.
Las etiquetas de servicio se pueden utilizar con los NSG, así como con Azure Firewall. Ahora
que has aprendido cómo funcionan los NSG, examinemos al diseño de NSG, lo que te ayudará
a determinar los puntos principales que debes tener en cuenta al crear reglas de NSG para
mejorar la seguridad.
Diseño de NSG
En el diseño de un NSG, el primer paso es determinar los requisitos de seguridad del
recurso. Es preciso determinar o considerar lo siguiente:

• ¿Se puede acceder al recurso solo desde Internet?
• ¿Se puede acceder al recurso tanto desde los recursos internos como desde Internet?
• ¿Se puede acceder al recurso solo desde recursos internos?
• En función de la arquitectura de la solución que se esté implementando, determina
  los recursos dependientes, los equilibradores de carga, las puertas de enlace y las
  máquinas virtuales utilizadas.
• Configurar una red virtual y su subred.

partir de los resultados de estas investigaciones, debe crearse un diseño válido de NSG.
Idealmente, debería haber varias subredes de red para cada carga de trabajo y tipo de
recurso. No se recomienda implementar equilibradores de carga y máquinas virtuales
en la misma subred.
En función de los requisitos del proyecto, es necesario determinar las reglas que son
comunes para diferentes cargas de trabajo de máquinas virtuales y subredes. Por ejemplo,
para una implementación de SharePoint, la aplicación front-end y los servidores SQL Server
se implementan en subredes separadas y, por tanto, es preciso determinar las reglas de
cada subred.
Después de identificar las reglas comunes del nivel de la subred, se deben identificar las reglas
de los recursos individuales que, a continuación, deben aplicarse en el nivel de la interfaz de
red. Es importante comprender que si una regla permite una solicitud entrante en un puerto,
ese puerto también se puede utilizar para solicitudes salientes sin ninguna configuración.

Si se puede acceder a los recursos desde Internet, se deben crear reglas con intervalos IP
y puertos específicos siempre que sea posible, en lugar de permitir el tráfico procedente
de todos los intervalos IP (normalmente se representan como 0.0.0.0/0). Se deben realizar
pruebas funcionales y de seguridad minuciosas para garantizar que se abren y se cierran
las reglas de NSG necesarias y óptimas.
Firewalls
NSG proporciona perímetros de seguridad externos para las solicitudes. Sin embargo,
esto no significa que las máquinas virtuales no deban implementar medidas de seguridad
adicionales. Siempre es mejor implementar la seguridad tanto interna como externamente.
Ya sea en Linux o en Windows, las máquinas virtuales proporcionan un mecanismo para
filtrar solicitudes en el nivel del sistema operativo. Esto se conoce como firewall tanto
en Windows como en Linux.
Es recomendable implementar firewalls para sistemas operativos. Ayudan a levantar
un muro de seguridad virtual que permite el acceso solo a aquellas solicitudes que se
consideran de confianza. Se deniega el acceso de cualquier solicitud que no sea de
confianza. Aunque existen incluso dispositivos de firewall físicos, en el cloud se utilizan
firewalls de sistema operativo. En la Figura 8.4 se muestra la configuración del firewall
para un sistema operativo Windows:

Los firewalls filtran paquetes de red e identifican puertos entrantes y direcciones IP. A partir
de la información de estos paquetes, el firewall evalúa las reglas y decide si debe permitir
el acceso o denegarlo.

Cuando se trata de Linux, hay diferentes soluciones de firewall disponibles. Algunas de las
ofertas de firewall son muy específicas de la distribución que se utiliza; por ejemplo, SUSE
utiliza SuSefirewall2 y Ubuntu utiliza ufw. Las implementaciones más utilizadas son firewalls
e iptables, que están disponibles en todas las distribuciones.
Diseño de firewall
Como práctica recomendada, los firewalls deben evaluarse para cada sistema operativo
individual. Cada máquina virtual tiene una responsabilidad distinta en la implementación
y la solución generales. Las reglas para estas responsabilidades individuales deben
identificarse y los firewalls deben abrirse y cerrarse en consecuencia.
Al evaluar las reglas del firewall, es importante tener en cuenta las reglas de NSG, tanto
en el nivel de la subred como en el nivel de la interfaz de red individual. Si esto no se realiza
correctamente, es posible que las reglas se denieguen en el nivel de NSG, pero que se dejen
abiertas en el nivel del firewall y viceversa. Si una solicitud se permite en el nivel de la regla
de NSG y se deniega en el nivel del firewall, la aplicación no funcionará del modo previsto;
a su vez, si una solicitud se deniega en el nivel de la regla de NSG y se permite en el nivel
del firewall, los riesgos de seguridad aumentarán.
Un firewall ayuda a generar múltiples redes aisladas por sus reglas de seguridad. Se deben
realizar pruebas funcionales y de seguridad de forma cuidadosa para garantizar que se
abran y cierren las reglas de firewall válidas y óptimas.
Tiene más sentido utilizar Azure Firewall, que es un servicio de red basado en el cloud
sobre los NSG. Es muy fácil de configurar, proporciona una administración centralizada
y no requiere mantenimiento. Azure Firewall y los NSG combinados pueden proporcionar
seguridad entre máquinas virtuales, redes virtuales e incluso suscripciones de Azure
diferentes. Dicho esto, si una solución requiere ese nivel adicional de seguridad, podemos
plantearnos la implementación de un firewall de nivel de sistema operativo. Hablaremos
de Azure Firewall con más detalle en una de las próximas secciones, Azure Firewall.
Grupos de seguridad de aplicaciones
Los NSG pueden aplicarse en el nivel de subred de la red virtual o directamente a interfaces
de red individuales. Aunque es suficiente aplicar NSG en el nivel de subred, hay ocasiones en
los que esto no es suficiente. Hay diferentes tipos de cargas de trabajo disponibles dentro de
una única subred y cada una de ellas requiere un grupo de seguridad diferente. Es posible
asignar grupos de seguridad a tarjetas de interfaz de red (NIC) individuales de las máquinas
virtuales, pero puede convertirse fácilmente en una pesadilla de mantenimiento si hay un
gran número de máquinas virtuales.

Azure tiene una característica relativamente nueva conocida como grupos de seguridad de
aplicaciones. Podemos crear grupos de seguridad de aplicaciones y asignarlos directamente
a varias NIC, incluso cuando esas NIC pertenezcan a máquinas virtuales en diferentes
subredes y grupos de recursos. La funcionalidad de los grupos de seguridad de aplicaciones
es similar a los NSG, con la excepción de que proporcionan una forma alternativa de asignar
grupos a recursos de red, lo que proporciona flexibilidad adicional cuando se asignan a
través de grupos de recursos y subredes. Los grupos de seguridad de aplicaciones pueden
simplificar los NSG; sin embargo, hay una limitación principal. Podemos tener un grupo
de seguridad de aplicaciones en el origen y el destino de una regla de seguridad, aunque
tener varios grupos de seguridad de aplicaciones en un origen o destino no es compatible
en este momento.
Una de las prácticas recomendadas para crear reglas es minimizar siempre el número de
reglas de seguridad que necesitas, para evitar el mantenimiento de reglas explícitas. En la
sección anterior, hemos explicado el uso de etiquetas de servicio con NSG para eliminar la
molestia de mantener los prefijos de direcciones IP individuales de cada servicio. Del mismo
modo, al utilizar grupos de seguridad de aplicaciones, podemos reducir la complejidad de
las direcciones IP explícitas y múltiples reglas. Esta práctica se recomienda siempre que sea
posible. Si tu solución exige una regla explícita con una dirección IP individual o un intervalo
de direcciones IP, solo en ese caso debes optar por ella.
Azure Firewall
En la sección anterior, hemos explicado el uso de Azure Firewall dentro de un sistema
operativo Windows/Linux para permitir o no permitir solicitudes y respuestas a través
de puertos y servicios concretos. Aunque los firewalls del sistema operativo desempeñan
un papel importante desde el punto de vista de la seguridad y deben implementarse
para cualquier implementación empresarial, Azure proporciona un recurso de seguridad
conocido como Azure Firewall que tiene una funcionalidad similar de filtrado de solicitudes
basadas en reglas y determinación de si se debe permitir o rechazar una solicitud.
La ventaja de usar Azure Firewall es que evalúa una solicitud antes de esta llegue a un
sistema operativo. Azure Firewall es un recurso de red y es un servicio independiente
que protege recursos en el nivel de red virtual. Cualquier recurso, incluidos las máquinas
virtuales y los equilibradores de carga que estén directamente asociados con una red
virtual, se puede proteger mediante Azure Firewall.
Azure Firewall es un servicio altamente disponible y escalable que puede proteger no solo
las solicitudes basadas en HTTP, sino cualquier tipo de solicitud que entra y sale de una
red virtual, incluido FTP, SSH y RDP. Azure Firewall también puede abarcar varias zonas
de disponibilidad durante la implementación para proporcionar una mayor disponibilidad.

Es muy recomendable que Azure Firewall se implemente para cargas de trabajo esenciales
en Azure, junto con otras medidas de seguridad. También es importante tener en cuenta
que Azure Firewall debe utilizarse incluso si se utilizan otros servicios, como Azure
Application Gateway y Azure Front Door, ya que todas estas herramientas tienen diferentes
ámbitos y características. Además, Azure Firewall proporciona soporte para etiquetas de
servicio e inteligencia de amenazas. En la sección anterior, hemos explicado las ventajas
de usar etiquetas de servicio. La inteligencia sobre amenazas se puede utilizar para generar
alertas cuando el tráfico procede o se dirige a direcciones IP y dominios malintencionados
conocidos, que se registran en la fuente de inteligencia sobre amenazas de Microsoft.
Reducir el área de superficie de ataques
Los NSG y los firewalls ayudan a administrar solicitudes autorizadas al entorno. Sin
embargo, el entorno no debe exponerse abiertamente a ataques de seguridad. El área
de superficie del sistema debe estar habilitada de manera óptima para poder lograr su
funcionalidad, pero lo suficientemente deshabilitada para que los atacantes no puedan
encontrar lagunas ni áreas de acceso que se abran sin ningún uso previsto o sin estar
suficientemente protegidas. La seguridad debe reforzarse en la medida suficiente para
dificultar el acceso al sistema de cualquier atacante.
Algunas de las configuraciones que deben definirse son:

• Eliminar todos los usuarios y grupos innecesarios del sistema operativo.
• Identificar la pertenencia al grupo de todos los usuarios.
• Implementar políticas de grupo utilizando servicios de directorio.
• Bloquear la ejecución del script a menos que esté firmado por autoridades de confianza.
• Registrar y auditar todas las actividades.
• Instalar software antivirus y antimalware, programar análisis y actualizar las definiciones
  con frecuencia.
• Deshabilitar o apagar servicios que no son necesarios.
• Bloquear el sistema de archivos de modo que solo se permita el acceso autorizado.
• Bloquear cambios en el registro.
• Configurar un firewall de acuerdo con los requisitos aplicables.
• La ejecución del script de PowerShell debe establecerse en restringida o RemoteSigned.
  Esto se puede hacer mediante los comandos de PowerShell Set-ExecutionPolicy
  -ExecutionPolicy Restricted o Set-ExecutionPolicy -ExecutionPolicy RemoteSigned.
• Habilitar protección mejorada a través de Internet Explorer.
• Restringir la capacidad de crear nuevos usuarios y grupos.
• Quitar el acceso a Internet e implementar servidores de acceso para RDP.
• Prohibir el inicio de sesión en servidores utilizando RDP a través de Internet. En su
  lugar, utilizar una VPN de sitio a sitio, una VPN de punto a sitio o rutas rápidas a RDP
  en máquinas remotas desde la red.
• Implementar periódicamente todas las actualizaciones de seguridad.
• Ejecutar la herramienta del administrador de cumplimiento de seguridad en el entorno
  e implementar todas sus recomendaciones.
• Supervisar el entorno activamente utilizando Security Center y Operations
  Management Suite.
• Implementar dispositivos virtuales de red para enrutar el tráfico a los proxies internos
  e inversos.
• Toda la información confidencial, como la configuración, las cadenas de conexión
  y las credenciales, debe estar cifrada.

Las configuraciones mencionadas anteriormente son algunos de los puntos clave que se
deben tener en cuenta desde el punto de vista de la seguridad. La lista seguirá creciendo
y tenemos que mejorar constantemente la seguridad para evitar cualquier tipo de infracción
de seguridad.
Implementar servidores de acceso
Es una buena idea quitar el acceso a Internet de las máquinas virtuales. También es una
buena práctica limitar la accesibilidad de los servicios de escritorio remoto de Internet
pero, en ese caso, ¿cómo se puede acceder a las máquinas virtuales? Una buena opción es
permitir únicamente que los recursos internos para RDP accedan a las máquinas virtuales
que utilicen opciones de VPN de Azure. Sin embargo, también hay otra forma: mediante
servidores de acceso.
Los servidores de acceso son servidores que se implementan en la red perimetral (DMZ).
Esto significa que no se encuentran en la red que aloja las soluciones y aplicaciones
principales. En su lugar, están en una red o subred separada. El objetivo principal del servidor
de acceso es aceptar solicitudes RDP de los usuarios y ayudarles a iniciar sesión. Desde
este servidor de acceso, los usuarios pueden navegar a otras máquinas virtuales usando
RDP. Tiene acceso a dos o más redes: una que tiene conectividad con el mundo exterior
y otra interna con la solución. El servidor de acceso implementa todas las restricciones de
seguridad y proporciona un cliente seguro para la conexión a otros servidores. Normalmente,
el acceso a correos electrónicos e Internet está deshabilitado en los servidores de acceso.
Hay un ejemplo de implementación de un servidor de acceso con conjuntos de escalado
de máquinas virtuales (VMSS), usando plantillas del administrador de recursos de Azure,
disponible en https://azure.microsoft.com/resources/templates/201-vmss-windowsjumpbox.

Azure Bastion
En la sección anterior, hemos explicado la implementación de servidores de acceso. Azure
Bastion es un servicio totalmente administrado que se puede aprovisionar en una red
virtual para proporcionar acceso de RDP/SSH a tus máquinas virtuales directamente en
Azure Portal a través de TLS. El host de Bastion actúa como servidor de acceso y elimina
la necesidad de direcciones IP públicas para tus máquinas virtuales. El concepto de uso
de Bastion es el mismo que el de implementar un servidor de acceso; sin embargo, como
se trata de un servicio administrado, lo administra completamente Azure.
Como Bastion es un servicio totalmente administrado de Azure y se refuerza internamente,
no necesitamos aplicar NSG adicionales en la subred de Bastion. Además, dado que no
estamos asociando ninguna IP pública a nuestras máquinas virtuales, están protegidas
contra el escaneo de puertos.
Seguridad de aplicaciones
Las aplicaciones web se pueden hospedar en soluciones basadas en IaaS además de
en máquinas virtuales y se pueden hospedar en servicios administrados proporcionados
por Azure, como App Service. App Service forma parte del paradigma de implementación
de PaaS y lo analizaremos en la siguiente sección. En esta sección, vamos a examinar la
seguridad en el nivel de aplicación.
SSL/TLS
Capa de socket seguro (SSL) está actualmente en desuso y ha sido sustituido por Seguridad
de la capa de transporte (TLS). TLS proporciona seguridad de extremo a extremo mediante
criptografía. Proporciona dos tipos de criptografía:

• Simétrica: la misma clave está disponible tanto para el remitente del mensaje como
  para el receptor, y se utiliza tanto para el cifrado como para el descifrado del mensaje.
• Asimétrica: cada parte interesada tiene dos claves, una clave privada y una pública.
  La clave privada permanece en el servidor o con el usuario y se mantiene en secreto,
  mientras que la clave pública se distribuye libremente a todo el mundo. Los titulares
  de la clave pública la utilizan para cifrar el mensaje, que solo puede descifrarse mediante
  la clave privada correspondiente. Como la clave privada permanece con el propietario,
  solo este puede descifrar el mensaje. Rivest–Shamir–Adleman (RSA) es uno de los
  algoritmos utilizados para generar estos pares de claves públicas-privadas.
• Las claves también están disponibles en los certificados conocidos popularmente
  como certificados X.509, aunque los certificados tienen más detalles además de
  las claves y los emiten generalmente autoridades de certificación de confianza.

Las aplicaciones web deben utilizar TLS para garantizar que el intercambio de mensajes
entre los usuarios y el servidor sea seguro y confidencial y que las identidades estén
protegidas. Estos certificados deben adquirirse en una entidad de certificación de
confianza en lugar de ser certificados autofirmados.

Identidades administradas
Antes de examinar las identidades administradas, es importante saber cómo se creaban las
aplicaciones sin ellas.
La forma tradicional de desarrollo de aplicaciones es usar secretos, como un nombre
de usuario, una contraseña o cadenas de conexión SQL, en los archivos de configuración.
Al poner estos secretos en archivos de configuración, los cambios de las aplicaciones en
estos secretos son fáciles y flexibles sin modificar el código. Nos ayuda a seguir el principio
«abierto para la extensión, cerrado para la modificación». Sin embargo, este enfoque tiene
una desventaja desde el punto de vista de la seguridad. Cualquiera que tenga acceso a
archivos de configuración puede ver los secretos, ya que generalmente estos secretos
se indican en esos archivos en texto sin formato. Hay algunos trucos para cifrarlos,
pero no son infalibles.
Una forma mejor de usar secretos y credenciales dentro de una aplicación es almacenarlos
en un repositorio de secretos como Azure Key Vault. Azure Key Vault proporciona seguridad
completa mediante el módulo de seguridad de hardware (HSM) y los secretos se almacenan
de forma cifrada con descifrado bajo demanda mediante claves almacenadas en hardware
independiente. Los secretos se pueden almacenar en Key Vault y cada secreto tiene una clave
y un nombre para mostrar. La clave tiene la forma de un URI que se puede utilizar para hacer
referencia al secreto desde las aplicaciones, como se muestra en la Figura 8.5:

Dentro de los archivos de configuración de la aplicación, podemos hacer referencia
al secreto usando el nombre o la clave. Sin embargo, esto presenta otro problema.
¿Cómo se conecta la aplicación y se autentica con el almacén de claves?

Los almacenes de claves tienen políticas de acceso que definen los permisos de un usuario
o grupo con respecto al acceso a secretos y credenciales dentro del almacén de claves.
Los usuarios, grupos o aplicaciones de servicio a los que se puede proporcionar acceso
se aprovisionan y hospedan en Azure Active Directory (Azure AD). Aunque se puede
proporcionar acceso a cuentas de usuario individuales mediante políticas de acceso de
Key Vault, es una práctica recomendada utilizar una entidad de servicio para acceder
al almacén de claves. Una entidad de servicio tiene un identificador, también conocido
como id. de aplicación o id. de cliente, junto con una contraseña. El id. de cliente, junto
con su contraseña, se pueden utilizar para autenticarse con Azure Key Vault. Esta entidad
de servicio puede tener permiso para acceder a los secretos. Las políticas de acceso de
Azure Key Vault se conceden en el panel Directivas de acceso del almacén de claves. En la
Figura 8.6, puedes ver que la entidad de servicio —https://keyvault.book.com— tiene acceso
concedido al almacén de claves denominado keyvaultbook:

Esto genera otro problema: para acceder al almacén de claves, necesitamos usar el id.
de cliente y el secreto en nuestros archivos de configuración para conectarnos al almacén
de claves, obtener el secreto y recuperar su valor. Esto casi equivale a usar un nombre de
usuario, una contraseña y una cadena de conexión SQL en archivos de configuración.
Aquí es donde pueden ayudar las identidades administradas. Azure lanzó las identidades de
servicio administradas y posteriormente les cambió el nombre a identidades administradas.
Las identidades administradas son identidades administradas por Azure. En segundo
plano, las identidades administradas también crean una entidad de servicio junto con una
contraseña. Con las identidades administradas, no es necesario colocar las credenciales
en los archivos de configuración.

Las identidades administradas solo se pueden utilizar para autenticarse con servicios que
admiten Azure AD como proveedor de identidades. Las identidades administradas están
destinadas únicamente a la autenticación. Si el servicio de destino no proporciona permiso
de control de acceso basado en roles (RBAC) a la identidad, es posible que la identidad
no pueda realizar la actividad prevista en el servicio de destino.
Las identidades administradas tienen dos tipos:

• Identidades administradas asignadas por el sistema
• Identidades administradas asignadas por el usuario

El propio servicio genera las identidades asignadas por el sistema. Por ejemplo, si un
servicio de aplicaciones desea conectarse a Azure SQL Database, puede generar la identidad
administrada asignada por el sistema como parte de sus opciones de configuración. Estas
identidades administradas también se eliminan cuando se elimina el recurso o servicio
principal. Como se muestra en la Figura 8.7, App Service puede utilizar una identidad
asignada por el sistema para conectarse a Azure SQL Database:

Las identidades administradas asignadas por el usuario se crean como identidades
independientes y posteriormente se asignan a servicios de Azure. Pueden aplicarse
y reutilizarse con varios servicios de Azure, ya que sus ciclos de vida no dependen
del recurso al que están asignados.

Una vez que se crea una identidad administrada y se le conceden permisos de acceso o RBAC
en el recurso de destino, se puede utilizar en las aplicaciones para acceder a los recursos
y servicios de destino.
Azure proporciona un SDK y una API de REST para comunicarse con Azure AD y obtener
un token de acceso para identidades administradas y, a continuación, usar el token para
acceder a los recursos de destino y utilizarlos.
El SDK se incluye en el paquete NuGet Microsoft.Azure.Services.AppAuthentication
para C#. Una vez que el token de acceso está disponible, se puede utilizar para consumir
el recurso de destino.
El código necesario para obtener el token de acceso es el siguiente:
var tokenProvider = new AzureServiceTokenProvider();
string token = await tokenProvider.GetAccessTokenAsync(«https://vault.azure.
net»);
Como alternativa, utiliza esto:
string token = await tokenProvider.GetAccessTokenAsync(«https://database.
windows.net»);
Cabe señalar que el código de la aplicación debe ejecutarse en el contexto de App Service
o una aplicación de función porque la identidad está asociada a ellos y solo está disponible
en el código cuando se ejecuta desde dentro de ellos.
El código anterior tiene dos casos prácticos diferentes. Los códigos para acceder al almacén
de claves y a Azure SQL Database se muestran juntos.
Es importante tener en cuenta que las aplicaciones no proporcionan ninguna información
relacionada con identidades administradas en el código y toda la administración se realiza
mediante configuración. Los desarrolladores, administradores de aplicaciones individuales
y operadores no encontrarán ninguna credencial relacionada con identidades administradas
y, además, tampoco se menciona ninguna en el código. La rotación de credenciales está
completamente regulada por el proveedor de recursos que hospeda el servicio de Azure.
La rotación predeterminada se produce cada 46 días. En caso necesario, el proveedor
de recursos puede pedir nuevas credenciales, por lo que podría esperar más de 46 días.
En la siguiente sección, hablaremos sobre una plataforma de información de seguridad
y administración de eventos (SIEM) nativa del cloud: Azure Sentinel.

Azure Sentinel
Azure proporciona un sistema SIEM y una respuesta automatizada para la orquestación
de la seguridad (SOAR) como servicio independiente que se puede integrar con cualquier
implementación personalizada en Azure. En la Figura 8.8 se muestran algunas de las
características clave de Azure Sentinel:

Azure Sentinel recopila registros de información de implementaciones y recursos y realiza
análisis para encontrar patrones y tendencias relacionados con los diversos problemas de
seguridad que se extraen de los orígenes de datos.
Debe haber una supervisión activa del entorno, se deben recopilar registros y se debe separar
la información de estos registros como una actividad independiente de la implementación del
código. Aquí es donde entra en escena el servicio SIEM. Hay numerosos conectores que se
pueden usar con Azure Sentinel; cada uno de estos conectores se usará para agregar orígenes
de datos a Azure Sentinel. Azure Sentinel proporciona conectores para servicios de Microsoft
como Office 365, Azure AD y Azure Threat Protection. Los datos recopilados se enviarán a un
área de trabajo de Log Analytics y puedes escribir consultas para buscar en estos registros.
Las herramientas SIEM como Azure Sentinel pueden habilitarse en Azure para obtener
todos los registros de Log Analytics y Azure Security Center, que a su vez pueden obtenerlos
de varios orígenes, implementaciones y servicios. El SIEM puede entonces ejecutar
su inteligencia sobre estos datos recopilados y generar conocimientos. Puede generar
informes y paneles basados en la inteligencia descubierta para su consumo, pero también
puede investigar actividades y amenazas sospechosas y adoptar medidas sobre ellas.

Aunque Azure Sentinel puede parecer una funcionalidad muy similar a la de Azure Security
Center, Azure Sentinel puede hacer mucho más que Azure Security Center. Su capacidad
para recopilar registros de otras vías mediante conectores hace que sea diferente de Azure
Security Center.
Seguridad de PaaS
Azure proporciona varios servicios de PaaS, cada uno de ellos con sus propias características
de seguridad. En general, se puede acceder a los servicios PaaS con credenciales, certificados
y tokens. Los servicios de PaaS permiten la generación de tokens de acceso de seguridad de
corta duración. Las aplicaciones cliente pueden enviar estos tokens de acceso de seguridad
para representar a usuarios de confianza. En esta sección, cubriremos algunos de los
servicios de PaaS más importantes que se utilizan en prácticamente todas las soluciones.
Azure Private Link
Azure Private Link proporciona acceso a los servicios PaaS de Azure, así como a los
servicios propiedad del cliente/compartidos con el partner hospedados en Azure a través
de un punto de conexión privado de la red virtual. Mientras utilizamos Azure Private Link,
no tenemos que exponer nuestros servicios al Internet público, y todo el tráfico entre
nuestro servicio y la red virtual pasa a través de la red troncal de Microsoft.
Azure Private Endpoint es la interfaz de red que ayuda a conectarse de forma privada
y segura a un servicio basado en Azure Private Link. Dado que el punto de conexión privado
se asigna a la instancia del servicio PaaS, y no a todo el servicio, los usuarios solo pueden
conectarse al recurso. Se deniegan las conexiones a cualquier otro servicio y esto protege
frente a la filtración de datos. El punto de conexión privado también te permite acceder de
forma segura desde el entorno on-premises a través de ExpressRoute o túneles VPN. Esto
elimina la necesidad de establecer pares públicos o de pasar a través del Internet público
para llegar al servicio.
Azure Application Gateway
Azure proporciona un equilibrador de carga de nivel 7 conocido como Azure Application
Gateway que no solo puede equilibrar la carga, sino que también ayuda en el enrutamiento
mediante valores en URL. También tiene una característica conocida como Firewall de
aplicaciones web. Azure Application Gateway admite terminación TLS en la puerta de
enlace, por lo que los servidores back-end recibirán el tráfico sin cifrar. Esto tiene varias
ventajas, como un mejor rendimiento, una mejor utilización de los servidores back-end
y el enrutamiento inteligente de paquetes. En la sección anterior, hemos explicado Azure
Firewall y cómo protege los recursos en el nivel de red. Firewall de aplicaciones web,
por otra parte, protege la implementación en el nivel de la aplicación.

Cualquier aplicación implementada que esté expuesta a Internet se enfrenta a numerosos
desafíos de seguridad. Estas son algunas de las amenazas de seguridad más importantes:

• Scripting en sitios cruzados
• Ejecución de código remoto
• Inyección de SQL
• Ataques de denegación de servicio (DoS)
• Ataques distribuidos de denegación de servicio (DDoS)

Sin embargo, hay muchas más.
Los desarrolladores pueden abordar un gran número de estos ataques si escriben código
defensivo y siguen las prácticas recomendadas; sin embargo, no es solo el código el
que debe ser responsable de identificar estos problemas en un sitio activo. Firewall de
aplicaciones web configura reglas que pueden identificar estos problemas, como se ha
mencionado anteriormente, y denegar solicitudes.
Se recomienda utilizar las características de Application Gateway Web Application Firewall
para proteger las aplicaciones frente a las amenazas de seguridad en vivo. Firewall de
aplicaciones web permitirá que la solicitud pase por él o la detendrá, en función de cómo
esté configurado.
Azure Front Door
Azure ha lanzado un servicio relativamente nuevo conocido como Azure Front Door. El
rol de Azure Front Door es bastante similar al de Azure Application Gateway; sin embargo,
existe una diferencia en el ámbito. Mientras que Application Gateway funciona dentro de
una sola región, Azure Front Door funciona a nivel global en todas las regiones y centros de
datos. También tiene un firewall de aplicaciones web que se puede configurar para proteger
las aplicaciones implementadas en varias regiones frente a diversas amenazas de seguridad,
como la inyección de SQL, la ejecución de código remoto y el scripting en sitios cruzados.
Application Gateway se puede implementar detrás de Front Door para solucionar el vaciado
de conexiones. Además, la implementación de Application Gateway detrás de Front Door
ayudará con el requisito de equilibrio de carga, ya que Front Door solo puede realizar
un equilibrio de carga basado en ruta de acceso a nivel global. La adición de Application
Gateway a la arquitectura proporcionará un equilibrio de carga adicional a los servidores
back-end de la red virtual.

Azure App Service Environment
Azure App Service se implementa en redes compartidas en segundo plano. Todas las SKU de
App Service utilizan una red virtual, que también pueden utilizar otros inquilinos. Para tener
más control y una implementación segura de App Service en Azure, los servicios se pueden
hospedar en redes virtuales dedicadas. Esto se puede lograr mediante el uso de Azure App
Service Environment (ASE), que proporciona un aislamiento completo para ejecutar tu App
Service a gran escala. También proporciona seguridad adicional al permitirte implementar
Azure Firewall, Grupos de seguridad de aplicaciones, NSG, Application Gateway, Firewall
de aplicaciones web y Azure Front Door. Todos los planes de App Service creados en App
Service Environment estarán en un nivel de precios aislado y no podemos elegir ningún
otro nivel.
Todos los registros de esta red virtual y de la computación se pueden cotejar en Azure Log
Analytics y Security Center, y finalmente con Azure Sentinel.
Azure Sentinel puede proporcionar conocimientos y ejecutar workbooks y runbooks
para responder a las amenazas de seguridad de forma automatizada. Los cuadernos de
estrategias de seguridad se pueden ejecutar en Azure Sentinel como respuesta a las alertas.
Cada cuaderno de estrategias de seguridad consta de medidas que deben adoptarse en
caso de alerta. Los cuadernos de estrategias se basan en Azure Logic Apps y esto te dará
la libertad de usar y personalizar las plantillas integradas disponibles con Logic Apps.
Log Analytics
Log Analytics es una nueva plataforma de análisis para administrar implementaciones
de cloud, centros de datos on-premises y soluciones híbridas.
Proporciona varias soluciones modulares, una funcionalidad específica que ayuda a
implementar una función. Por ejemplo, las soluciones de seguridad y auditoría ayudan a
determinar una visión completa de la seguridad para la implementación de una organización.
Del mismo modo, hay muchas más soluciones, como la automatización y el seguimiento de
cambios, que deben implementarse desde una perspectiva de seguridad. Los servicios de
auditoría y seguridad de Log Analytics proporcionan información en las cinco categorías
siguientes:

• Dominios de seguridad: ofrecen la capacidad de ver registros de seguridad, evaluaciones
  de malware, evaluaciones de actualización, seguridad de red, información de acceso e
  identidad y equipos con eventos de seguridad. También proporciona acceso al panel de
  Azure Security Center.
• Evaluación antimalware: ayuda a identificar los servidores que no están protegidos
  contra malware y que tienen problemas de seguridad. Ofrece información sobre la
  exposición a posibles problemas de seguridad y evalúa la gravedad de cualquier riesgo.
  Los usuarios pueden tomar medidas proactivas basadas en estas recomendaciones.
  Las subcategorías de Azure Security Center proporcionan información recopilada
  por Azure Security Center.
• Problemas notables: identifica rápidamente los problemas activos y califica
  la gravedad de estos.
• Detecciones: esta categoría está en modo preview. Permite identificar patrones
  de ataque mediante la visualización de alertas de seguridad.
• Inteligencia sobre amenazas: ayuda a identificar patrones de ataque mediante la
  visualización de la cantidad total de servidores con tráfico IP malintencionado saliente,
  el tipo de amenaza malintencionada y un mapa que muestra de dónde proceden estas IP.

Los detalles anteriores, cuando se visualizan desde el portal, se muestran en la Figura 8.9:

Ahora que has aprendido más sobre la seguridad de los servicios PaaS, vamos a explorar
cómo proteger los datos almacenados en Azure Storage.
Azure Storage
Las cuentas de almacenamiento desempeñan una función importante en la arquitectura
general de la solución. Las cuentas de almacenamiento pueden almacenar información
importante, como datos de información de identificación personal del usuario (PII),
transacciones comerciales y otros datos sensibles y confidenciales. Es de suma importancia
que las cuentas de almacenamiento sean seguras y que solo permitan el acceso a
usuarios autorizados. Los datos almacenados están cifrados y se transmiten mediante
canales seguros. Storage y los usuarios y las aplicaciones cliente que usan la cuenta
de almacenamiento y sus datos desempeñan un papel crucial en la seguridad general
de los datos. Los datos se deben mantener cifrados en todo momento. Esto también
incluye las credenciales y las cadenas de conexión que se conectan a almacenes de datos.

Azure proporciona RBAC para controlar quién puede administrar las cuentas
de almacenamiento de Azure. Estos permisos RBAC se conceden a usuarios y grupos
en Azure AD. Sin embargo, cuando se crea una aplicación que se implementará en Azure,
esta tendrá usuarios y clientes que no están disponibles en Azure AD. Para permitir que
los usuarios accedan a la cuenta de almacenamiento, Azure Storage proporciona claves
de acceso de almacenamiento. Hay dos tipos de claves de acceso en el nivel de cuenta
de almacenamiento: principal y secundaria. Los usuarios que poseen estas claves pueden
conectarse a la cuenta de almacenamiento. Estas claves de acceso de almacenamiento se
utilizan en el paso de autenticación del proceso de acceso a la cuenta de almacenamiento.
Las aplicaciones pueden acceder a las cuentas de almacenamiento con la clave principal
o la secundaria. Se proporcionan dos claves, de modo que, si la clave principal se ve
comprometida, las aplicaciones se pueden actualizar para usar la clave secundaria mientras
la clave principal se vuelve a generar. Esto ayuda a minimizar el tiempo de inactividad de la
aplicación. Además, mejora la seguridad al eliminar la clave comprometida sin afectar a las
aplicaciones. Los detalles de las claves de almacenamiento, como se ven en Azure Portal,
se muestran en la Figura 8.10:

Azure Storage proporciona cuatro servicios en una cuenta: blob, archivos, colas y tablas.
Cada uno de estos servicios también proporciona infraestructura para su propia seguridad
mediante tokens de acceso seguro.
Una firma de acceso compartido (SAS) es un URI que otorga derechos de acceso
restringido a los servicios de Azure Storage: blobs, archivos, colas y tablas. Estos tokens
SAS pueden compartirse con clientes a los que no conviene confiar la clave de la cuenta
de almacenamiento completa, para restringir así el acceso a ciertos recursos de la cuenta
de almacenamiento. Al distribuir un URI de SAS a estos clientes, se les otorga acceso a los
recursos por un período determinado.
Los tokens SAS existen tanto en el nivel de la cuenta de almacenamiento como en los niveles
individuales de blob, archivo, tabla y cola. Una firma en el nivel de la cuenta de almacenamiento
es más potente y tiene potestad para permitir y denegar permisos en el nivel de cada servicio
individual. También se puede utilizar en lugar de niveles de servicio de recursos individuales.

Los tokens SAS brindan acceso granular a los recursos y también pueden combinarse.
Estos tokens incluyen leer, escribir, eliminar, enumerar, agregar, crear, actualizar y procesar.
Además, incluso el acceso a los recursos se puede determinar durante la generación de
los tokens SAS. Podría ser para blobs, tablas, colas y archivos individualmente o para una
combinación de ellos. Las claves de la cuenta de almacenamiento son para toda la cuenta
y no se pueden restringir para servicios individuales ni tampoco se pueden restringir desde
la perspectiva de los permisos. Es mucho más fácil crear y revocar tokens SAS que claves
de acceso de cuenta de almacenamiento. Los tokens SAS se pueden crear para permitir
el uso durante un período de tiempo determinado; concluido este tiempo, los tokens
dejan de ser válidos automáticamente.
Cabe señalar que, si las claves de la cuenta de almacenamiento se generan de nuevo,
el token SAS basado en estas dejará de ser válido y será necesario crear una nuevo token
y compartirlo con los clientes. En la Figura 8.11, puedes ver una opción para seleccionar
el ámbito, los permisos, la fecha de inicio, la fecha de fin, la dirección IP permitida, los
protocolos permitidos y la clave de firma para crear un token SAS:

Si regeneramos key1, que hemos utilizado para firmar el token SAS en el ejemplo anterior,
tenemos que crear un nuevo token SAS con key2 o la nueva key1.

El robo de cookies, la inserción de scripts y los ataques DoS son medios comunes utilizados
por los atacantes para alterar un entorno y robar datos. Los navegadores y el protocolo
HTTP implementan un mecanismo incorporado que garantiza que no se pueden realizar
estas actividades malintencionadas. En términos generales, cualquier cosa entre dominios
no está permitida ni por el protocolo HTTP ni por los navegadores. Un script que se ejecuta
en un dominio no puede solicitar recursos de otro dominio. Sin embargo, hay casos de uso
válidos en los que se deben permitir estas solicitudes. El protocolo HTTP implementa uso
compartido de recursos entre orígenes (CORS). Con la ayuda de CORS, es posible acceder
a los recursos de diversos dominios y hacer que funcionen. Azure Storage configura las
reglas de CORS para los recursos de blobs, archivos, colas y tablas. Azure Storage permite
la creación de reglas que se evalúan para cada solicitud autenticada. Si se cumplen las
reglas, se permite que la solicitud acceda al recurso. En la Figura 8.12, puedes ver cómo
agregar reglas de CORS a cada uno de los servicios de almacenamiento:

Los datos no solo deben protegerse mientras están en tránsito, sino también mientras están
en reposo. Si los datos en reposo no están cifrados, cualquier persona que tenga acceso
a la unidad física en el centro de datos puede leer los datos. Aunque la posibilidad de una
filtración de datos es insignificante, los clientes deben seguir cifrando sus datos. El cifrado
del servicio Storage también ayuda a proteger los datos en reposo. Este servicio funciona
de forma transparente y se inserta a sí mismo sin que los usuarios lo sepan. Cifra los datos
cuando se guardan en una cuenta de almacenamiento y los descifra automáticamente
cuando se leen. Todo este proceso ocurre sin que los usuarios tengan que realizar ninguna
actividad adicional.
Las claves de la cuenta de Azure deben cambiar periódicamente. Esto garantizará que
un atacante no pueda obtener acceso a las cuentas de almacenamiento.
También es una buena idea volver a generar las claves; sin embargo, esto debe evaluarse
con respecto a su uso en aplicaciones existentes. Si se rompe la aplicación existente, es
necesario priorizar estas aplicaciones para la administración de cambios y los cambios
deben aplicarse gradualmente.

Siempre se recomienda tener tokens SAS de nivel de servicio individuales con marcos
temporales limitados. Este token solo debe proporcionarse a los usuarios que deben
acceder a los recursos. Sigue siempre el principio de privilegios mínimos y proporciona
solo los permisos necesarios.
Las claves SAS y las claves de la cuenta de almacenamiento deben almacenarse en Azure
Key Vault. Esto permite que su almacenamiento y acceso sean seguros. Las aplicaciones
pueden leer estas claves en tiempo de ejecución desde el almacén de claves, en lugar de
almacenarlas en archivos de configuración.
Además, también puedes utilizar Azure AD para autorizar las solicitudes al almacenamiento
de blobs y colas. Usaremos RBAC para conceder los permisos necesarios a una entidad
de servicio y, una vez que autentiquemos la entidad de servicio mediante Azure AD, se
generará un token de OAuth 2.0. Este token se puede agregar al encabezado de autorización
de las llamadas a la API para autorizar una solicitud en el almacenamiento de blobs o colas.
Microsoft recomienda el uso de la autorización de Azure AD al trabajar con aplicaciones
de blobs y colas debido a la mejor seguridad proporcionada por Azure AD y su simplicidad
en comparación con los tokens SAS.
En la siguiente sección, vamos a evaluar las opciones de seguridad disponibles para Azure
SQL Database.
Azure SQL
SQL Server almacena datos relacionales en Azure, que es un servicio administrado de bases
de datos relacionales. También se conoce como una base de datos como servicio (DBaaS)
que proporciona una plataforma de alta disponibilidad, escalable, centrada en el rendimiento
y segura para almacenar datos. Es accesible desde cualquier lugar, mediante cualquier
lenguaje de programación y plataforma. Para conectarse a ella, los clientes necesitan una
cadena de conexión que incluya la información de servidor, de base de datos y de seguridad.
SQL Server proporciona configuración de firewall que impide el acceso a todo el mundo de
forma predeterminada. Los intervalos y las direcciones IP deben haberse incluido en la lista
blanca para acceder a SQL Server. Los arquitectos solo deben permitir direcciones IP en las
que confíen y que pertenezcan a clientes o partners. Hay implementaciones en Azure para
las que o bien hay muchas direcciones IP o las direcciones IP no son conocidas, como las
aplicaciones implementadas en Azure Functions o Logic Apps. Para que dichas aplicaciones
accedan a Azure SQL, Azure SQL permite incluir todas las direcciones IP en la lista blanca
de los servicios de Azure en todas las suscripciones.
Se debe tener en cuenta que la configuración del firewall está en el nivel del servidor y no
en el de la base de datos. Esto significa que cualquier cambio aquí afecta a todas las bases
de datos de un servidor. En la Figura 8.13, puedes ver cómo agregar IP de clientes al firewall
para conceder acceso al servidor:

Azure SQL también proporciona seguridad mejorada mediante el cifrado de los datos
en reposo. Esto garantiza que nadie, ni siquiera los administradores del centro de datos
de Azure, puede ver los datos almacenados en SQL Server. La tecnología que utiliza SQL
Server para cifrar datos en reposo se conoce como cifrado de datos transparente (TDE).
No se requieren cambios en el nivel de la aplicación para implementar TDE. SQL Server
cifra y descifra los datos de forma transparente cuando el usuario los guarda y los lee.
Esta característica está disponible en el nivel de la base de datos. También podemos
integrar TDE con Azure Key Vault para contar con Bring Your Own Key (BYOK). Con BYOK,
podemos habilitar TDE mediante una clave administrada por el cliente en Azure Key Vault.

SQL Server también proporciona enmascaramiento dinámico de datos (DDM), que
es especialmente útil para enmascarar ciertos tipos de datos, como tarjetas de crédito
o datos de identificación personal del usuario. El enmascaramiento no es lo mismo que
el cifrado. El enmascaramiento no cifra los datos, solo los enmascara, lo que garantiza que
los datos no se encuentran en un formato legible para el ser humano. Los usuarios deben
enmascarar y cifrar la información confidencial en Azure SQL Server.
SQL Server también proporciona un servicio de detección de amenazas y auditoría para
todos los servidores. Hay servicios avanzados de recopilación de datos y de inteligencia
que se ejecutan en la parte superior de estas bases de datos para detectar amenazas y
vulnerabilidades y alertar a los usuarios. Azure actualiza los registros de auditoría en las
cuentas de almacenamiento y los administradores pueden verlos y adoptar las medidas
oportunas. Las amenazas, como la inyección de código SQL y los inicios de sesión anónimos
de cliente, pueden generar alertas sobre las que se puede informar a los administradores
por correo electrónico. En la Figura 8.14, puedes ver cómo habilitar la detección de amenazas:

Los datos se pueden enmascarar en Azure SQL. Esto nos ayuda a almacenar datos
en un formato que no puede leerlo ninguna persona:

Azure SQL también proporciona TDE para cifrar datos en reposo, como se muestra
en la Figura 8.16:

Para realizar una evaluación de vulnerabilidades en SQL Server, puedes aprovechar
la evaluación de vulnerabilidades de SQL, que forma parte del paquete unificado para
funciones avanzadas de seguridad de SQL conocidas como Seguridad de datos avanzada.
Los clientes pueden utilizar la evaluación de vulnerabilidades de SQL de forma proactiva
para mejorar la seguridad de la base de datos mediante la detección, el seguimiento
y la ayuda para corregir posibles vulnerabilidades de la base de datos.

Hemos mencionado Azure Key Vault varias veces en las secciones anteriores, cuando hemos
hablado de las identidades administradas, la base de datos SQL, etc. Ya conoces la finalidad
de Azure Key Vault y, en la siguiente sección, exploraremos algunos métodos que pueden
ayudar a proteger el contenido de tu almacén de claves.
Azure Key Vault
Proteger los recursos mediante contraseñas, claves, credenciales, certificados e
identificadores únicos es un elemento importante de cualquier entorno y aplicación desde
el punto de vista de la seguridad. Los recursos deben estar protegidos y la garantía de que
permanecen seguros y no están en peligro en ningún momento es un pilar importante de
la arquitectura de seguridad. La administración y las operaciones que mantienen seguros
los secretos y las claves, al tiempo que hacen que estén disponibles cuando es necesario,
son aspectos importantes que es preciso tener en cuenta. Por lo general, estos secretos
se utilizan en todo el sitio: dentro del código fuente, en los archivos de configuración,
en trozos de papel y en otros formatos digitales. Para superar estos desafíos y almacenar
todos los secretos de manera uniforme en un lugar de almacenamiento seguro centralizado,
se debe usar una instancia de Azure Key Vault.
Azure Key Vault está bien integrado con otros servicios de Azure. Por ejemplo, sería fácil
usar un certificado almacenado en Azure Key Vault e implementarlo en el almacén de
certificados de una máquina virtual de Azure. En Azure Key Vault es posible almacenar
como secretos todo tipo de claves, incluidas claves de almacenamiento, claves de IoT
y eventos y cadenas de conexión. Se pueden recuperar y utilizar de forma transparente
sin que nadie las vea o las almacene temporalmente en cualquier lugar. Las credenciales
de SQL Server y otros servicios también se pueden almacenar en Azure Key Vault.
Azure Key Vault funciona por región. Lo que esto significa es que un recurso de Azure
Key Vault debe aprovisionarse en la misma región en la que se implementan la aplicación
y el servicio. Si una implementación consta de más de una región y necesita servicios
de Azure Key Vault, se deben aprovisionar múltiples instancias de Azure Key Vault.
Una característica importante de Azure Key Vault es que los secretos, las claves y
los certificados no se almacenan en el lugar de almacenamiento general. Estos datos
confidenciales los guarda el HSM. Esto significa que se almacenan en un hardware
independiente en Azure que solo puede desbloquearse con claves de los usuarios. Para
proporcionar mayor seguridad, también puedes implementar puntos de conexión de
servicio de red virtual para Azure Key Vault. Esto restringirá el acceso al almacén de
claves a redes virtuales específicas. También puedes restringir el acceso a un intervalo
de direcciones IPv4.

En la sección Azure Storage, hemos analizado el uso de Azure AD para autorizar solicitudes a
blobs y colas. Hemos mencionado que usamos un token OAuth, que se obtiene de Azure AD,
para autenticar las llamadas a la API. En la siguiente sección, aprenderás cómo se realizan
la autenticación y la autorización mediante OAuth. Una vez hayas completado la siguiente
sección, podrás relacionarla con lo que hemos comentado en la sección Azure Storage.
Autenticación y autorización mediante OAuth
Azure AD es un proveedor de identidades que puede autenticar usuarios en función de
los usuarios ya disponibles y de las entidades de servicio disponibles en el inquilino. Azure
AD implementa el protocolo OAuth y admite la autorización en Internet. Implementa
un servidor de autorización y servicios para habilitar el flujo de autorización OAuth,
el flujo implícito y el flujo de credenciales de cliente. Se trata de diferentes flujos de
interacción de OAuth bien documentados entre aplicaciones cliente, puntos de conexión
de autorización, usuarios y recursos protegidos.
Azure AD también admite el inicio de sesión único (SSO), que agrega seguridad y facilidad
al iniciar sesión en aplicaciones registradas con Azure AD. Puedes utilizar OpenID
Connect, OAuth, SAML, basado en contraseña o el método SSO vinculado o deshabilitado
al desarrollar nuevas aplicaciones. Si no estás seguro de cuál debes utilizar, consulta el
diagrama de flujo de Microsoft aquí: https://docs.microsoft.com/azure/active-directory/
manage-apps/what-is-single-sign-on#choosing-a-single-sign-on-method.
Las aplicaciones web, las aplicaciones basadas en JavaScript y las aplicaciones cliente
nativas (como las aplicaciones móviles y de escritorio) pueden usar Azure AD tanto para
la autenticación como para la autorización. Existen plataformas de redes sociales, como
Facebook, Twitter, entre otras, que admiten el protocolo OAuth para la autorización.
A continuación, se muestra una de las formas más sencillas de habilitar la autenticación para
aplicaciones web que usan Facebook. Hay otros métodos que utilizan binarios de seguridad,
pero quedan fuera del ámbito de este libro.
En este tutorial, se aprovisionará un Azure App Service junto con un plan de App Service
para hospedar una aplicación web personalizada. Como requisito previo, se necesita
una cuenta válida de Facebook para redirigir a los usuarios a ella para su autenticación
y autorización.

Se puede crear un nuevo grupo de recursos mediante Azure Portal, como se muestra
en la Figura 8.17:

Una vez creado el grupo de recursos, se puede crear un nuevo servicio de aplicaciones
mediante el portal, como se muestra en la Figura 8.18:

Es importante anotar la dirección URL de la aplicación web porque será necesaria más
adelante al configurar la aplicación de Facebook.
Una vez aprovisionada la aplicación web en Azure, el siguiente paso es crear una nueva
aplicación en Facebook. Esto es necesario para representar tu aplicación web dentro de
Facebook y para generar las credenciales de cliente apropiadas para la aplicación web.
Así es como Facebook sabe de la aplicación web.
Ve a developers.facebook.com e inicia sesión con las credenciales apropiadas. Para
crear una aplicación nueva, selecciona la opción Crear aplicación (Create App) en Mis
aplicaciones (My Apps) en la esquina superior derecha, como se muestra en la Figura 8.19:

La página web te pedirá que proporciones un nombre a la aplicación web para crear una
nueva aplicación dentro de Facebook:

Agrega un nuevo producto Inicio de sesión de Facebook (Facebook Login) y haz clic en
Configurar (Set Up) para configurar el inicio de sesión de la aplicación web personalizada
que se hospedará en Azure App Service:

El botón Configurar (Set Up) proporciona algunas opciones, como se muestra en la
Figura 8.22, y estas opciones configuran el flujo de OAuth, como el flujo de autorización, el
flujo implícito o el flujo de credenciales de cliente. Selecciona la opción Web porque eso es lo
que necesita autorización de Facebook:

Proporciona la dirección URL de la aplicación web que anotamos anteriormente después
de aprovisionar la aplicación web en Azure:

Haz clic en el elemento Configuración (Settings) del menú de la izquierda y proporciona la
URL de redirección de OAuth para la aplicación. Azure ya tiene direcciones URL de devolución
de llamada bien definidas para cada una de las plataformas de redes sociales más populares,
y la que se utiliza para Facebook es nombre de dominio/.auth/login/facebook/callback:

Ve a la configuración Básica del menú de la izquierda y anota los valores de Id. de aplicación
(App ID) y Secreto de aplicación (App Secret). Son necesarios para configurar la autenticación/
autorización de Azure App Services:

En Azure Portal, vuelve al Azure App Service creado en los primeros pasos de esta sección
y dirígete a la hoja de autenticación/autorización. Activa Autenticación de App Service,
selecciona Iniciar sesión con Facebook para la autenticación y haz clic en el elemento
Facebook en la lista:

En la página resultante, proporciona el id. de aplicación y el secreto de la aplicación
ya anotados y selecciona también el ámbito. El ámbito decide la información compartida
por Facebook con la aplicación web:

Haz clic en Aceptar y luego en el botón Guardar para guardar la configuración
de autenticación/autorización.
Ahora, si inicias una nueva sesión del navegador de incógnito y vas a la aplicación web
personalizada, la solicitud debe redirigirse a Facebook. Como puedes haber visto en otros
sitios web, al utilizar Iniciar sesión con Facebook, se te pedirá que facilites tus credenciales:

Una vez que hayas introducido tus credenciales, un cuadro de diálogo de consentimiento del
usuario pedirá permiso para que los datos de Facebook se compartan con la aplicación web:

Si se proporciona consentimiento, debe aparecer la página web de la aplicación web:
Figura

Se puede utilizar un enfoque similar para proteger tu aplicación web con Azure AD, Twitter,
Microsoft y Google. También puedes integrar tu propio proveedor de identidades si es
necesario.
El enfoque que se muestra aquí ilustra solo una de las formas de proteger un sitio web
utilizando credenciales almacenadas en otro lugar y la autorización de aplicaciones externas
para acceder a recursos protegidos. Azure también proporciona bibliotecas JavaScript y
ensamblados .NET para utilizar el método de programación imperativo y que este consuma
los puntos de conexión OAuth proporcionados por Azure AD y otras plataformas de redes
sociales. Se recomienda utilizar este enfoque para tener un mayor control y flexibilidad
en la autenticación y la autorización dentro de tus aplicaciones.
Hasta ahora, hemos hablado de las características de seguridad y de cómo se pueden
implementar. También es importante aplicar la supervisión y la auditoría. La implementación
de una solución de auditoría ayudará a tu equipo de seguridad a auditar los registros y adoptar
medidas de precaución. En la siguiente sección, analizaremos las soluciones de supervisión
y auditoría de seguridad de Azure.
Supervisión y auditoría de seguridad
Cada actividad de tu entorno, desde los correos electrónicos hasta el cambio de un firewall,
se puede clasificar como un evento de seguridad. Desde el punto de vista de la seguridad, es
necesario tener un sistema de registro central para supervisar y realizar un seguimiento de
los cambios realizados. Durante una auditoría, si encuentras actividades sospechosas, puedes
descubrir cuál es el defecto en la arquitectura y cómo se puede solucionar. Además, si se ha
producido una filtración de datos, los registros ayudarán a los profesionales de seguridad a
comprender el patrón de un ataque y cómo se ha ejecutado. Asimismo, se pueden adoptar
las medidas preventivas necesarias para evitar incidentes similares en el futuro. Azure
proporciona estos dos importantes recursos de seguridad para administrar todos los
aspectos de seguridad de la suscripción, los grupos de recursos y los recursos de Azure:

• Azure Monitor
• Azure Security Center

De estos dos recursos de seguridad, primero exploraremos Azure Monitor.
Azure Monitor
Azure Monitor es un servicio centralizado para supervisar recursos de Azure. Proporciona
información acerca de los recursos de Azure y su estado. También ofrece una completa
interfaz de consulta que utiliza información que se puede dividir y separar en segmentos
utilizando los datos en los niveles de suscripción, grupo de recursos, recurso individual y tipo
de recurso. Azure Monitor recopila datos de numerosos orígenes de datos, incluidas métricas
y registros de Azure, aplicaciones de clientes y los agentes que se ejecutan en máquinas
virtuales. Otros servicios, como Azure Security Center y Network Watcher, también ingieren
datos en el área de trabajo de Log Analytics, que se puede analizar desde Azure Monitor.
Puedes utilizar las API de REST para enviar datos personalizados a Azure Monitor.

Azure Monitor se puede utilizar a través de Azure Portal, PowerShell, la CLI y las API de REST.

Azure Monitor proporciona los registros enumerados a continuación:

• Registro de actividades: muestra todas las operaciones de nivel de administración
  realizadas en los recursos. Proporciona detalles de los recursos relativos a la hora
  de creación, el creador, el tipo de recurso y el estado.
• Registro de operaciones (clásico): proporciona detalles de todas las operaciones
  realizadas en los recursos en un grupo de recursos y una suscripción.
• Métricas: obtiene información sobre el nivel de rendimiento de los recursos
  individuales y crea alertas para ellos.
• Configuración de diagnóstico: ayuda a configurar los registros de efectos mediante
  la configuración de Azure Storage para que almacene los registros, los transmita
  en tiempo real a Azure Event Hubs y los envíe a Log Analytics.
• Búsqueda de registros: ayuda a integrar Log Analytics con Azure Monitor.

Azure Monitor puede ayudar a identificar los incidentes relacionados con la seguridad
y adoptar la medida adecuada. Es importante que solo las personas autorizadas puedan
acceder a Azure Monitor, ya que puede contener información confidencial.
Azure Security Center
Como su nombre indica, Azure Security Center es una plataforma centralizada para todas
las necesidades de seguridad. En general, existen dos actividades relacionadas con la
seguridad: la implementación de la seguridad y la supervisión de amenazas y vulneraciones.
Security Center se ha creado principalmente para ayudar con ambas actividades. Azure
Security Center permite a los usuarios definir sus políticas de seguridad y hacer que se
implementen en los recursos de Azure. En función del estado actual de los recursos de
Azure, Azure Security Center brinda recomendaciones de seguridad para fortalecer la
solución y los recursos individuales de Azure. Las recomendaciones incluyen casi todas
las prácticas recomendadas de seguridad de Azure, incluido el cifrado de datos y discos,
la protección de red, la protección de puntos finales, las listas de control de acceso, las
listas blancas de solicitudes entrantes y el bloqueo de solicitudes no autorizadas. Los
recursos varían desde componentes de infraestructura, como equilibradores de carga,
grupos de seguridad de red y redes virtuales, hasta recursos de PaaS, como Azure SQL
y Azure Storage. A continuación se muestra un fragmento del panel Información general
de Azure Security Center, en el que se muestra la puntuación de seguridad general de la
suscripción, la higiene de seguridad de los recursos y mucho más:

Azure Security Center es una completa plataforma que proporciona recomendaciones
para varios servicios, como se muestra en la Figura 8.33. Además, estas recomendaciones
se pueden exportar a archivos CSV para su referencia:

Como se ha mencionado al principio de esta sección, la supervisión y la auditoría son
esenciales en un entorno empresarial. Azure Monitor puede tener varios orígenes de
datos y se puede utilizar para auditar los registros de estos orígenes. Azure Security
Center proporciona evaluaciones continuas y recomendaciones de seguridad priorizadas
junto con la puntuación de seguridad general.
Resumen
La seguridad es siempre un aspecto importante de cualquier implementación o solución.
Se ha vuelto mucho más importante y relevante debido a la implementación en el cloud.
Además, la amenaza de ciberataques es cada vez mayor. En estas circunstancias, la
seguridad se ha convertido en una prioridad de las organizaciones. Independientemente
del tipo de implementación o solución —ya sea IaaS, PaaS o SaaS—, la seguridad es necesaria
en todas ellas. Los centros de datos de Azure son completamente seguros y cuentan
con una docena de certificaciones de seguridad internacionales. Son seguros de forma
predeterminada. Proporcionan recursos de seguridad de la IaaS, como NSG, traducción
de direcciones de red, puntos de conexión seguros, certificados, almacenes de claves,
almacenamiento, cifrado de máquinas virtuales y características de seguridad de PaaS
para recursos individuales de PaaS. La seguridad tiene un completo ciclo de vida propio
y se debe planificar, diseñar, implementar y probar adecuadamente, al igual que cualquier
otra funcionalidad de la aplicación.

Hemos hablado sobre los firewalls de sistemas operativos y Azure Firewall, y cómo se
pueden aprovechar para aumentar el panorama general de seguridad de tu solución.
También hemos explorado nuevos servicios de Azure, como Azure Bastion, Azure Front
Door y Azure Private Link.
La seguridad de las aplicaciones era otro aspecto clave y hemos explicado cómo realizar
la autenticación y la autorización mediante OAuth. Hemos realizado una demostración
rápida de cómo crear un servicio de aplicaciones e integrar el inicio de sesión de Facebook.
Facebook ha sido solo un ejemplo; podrías utilizar Google, Twitter, Microsoft, Azure AD
o cualquier proveedor de identidades personalizado.
También hemos explorado las opciones de seguridad que ofrece Azure SQL, que es un
servicio de base de datos administrado proporcionado por Azure. Hemos hablado de la
implementación de características de seguridad y, en la última sección, hemos concluido
con la supervisión y auditoría con Azure Monitor y Azure Security Center. La seguridad
desempeña un papel vital en tu entorno. Un arquitecto siempre debe diseñar y crear
soluciones con la seguridad como uno de los pilares principales de la arquitectura;
Azure proporciona muchas opciones para lograrlo.
Ahora que sabes cómo proteger tus datos en Azure, en el siguiente capítulo nos centraremos
en las soluciones de Big Data de Hadoop para continuar con Data Lake Storage, Data Lake
Analytics y Data Factory.