Cómo controlar la seguridad de su aplicación Azure con el kit de Secure DevOps

Este 4º post relacionado con el marco del Kit de Desarrollo Seguro para el Azure (AzSK) se centrará en cómo aprovechar sus controles incorporados para desarrollar, desplegar y mantener seguras sus aplicaciones basadas en el Azure a lo largo de las etapas de desarrollo.

Este artículo tratará principalmente los paquetes 2 y 3 de azsk ilustrados en la siguiente figura de Microsoft:

Para complementar su comprensión de este 4º post de la serie de marcos AzSK, les recomiendo que también echen un vistazo a mis posts anteriores

• Introducción al Secure DevOps Kit for Azure
• Comprensión de los controles incorporados del Kit de Seguridad para Azure
• Cómo controlar la seguridad de tu suscripción a Azure con el kit de Secure DevOps

En este post, hablaré de cómo se puede aprovechar AzSK para desarrollar y desplegar aplicaciones seguras basadas en la nube de Azure.

Para este propósito, el marco de trabajo de AzSK proporciona 3 componentes principales para el desarrollo de aplicaciones seguras:

Pruebas de verificación de seguridad (SVT) de los recursos Azure involucrados
Codificación segura con Security IntelliSense
Seguridad en la extensión del CICD para Visual Studio
1) Pruebas de verificación de seguridad (SVT)

Como aprendimos para la seguridad de la Suscripción en el post anterior, AzSK incluye scripts que pueden ser usados para comprobar la seguridad de los recursos de Azure involucrados en su aplicación.

Puedes usar AzSK SVT de varias maneras:

1.1) Comprobando la seguridad de todos los recursos de una suscripción

El cmdlet de AzSK PowerShell que se utilizará para escanear la salud de la seguridad de todos los recursos de Azure en una suscripción específica es el siguiente:

Get-AzSKAzureServicesSecurityStatus -SubscriptionId <SubscriptionId>

Al contrario que el comando (Get-AzSKSubscriptionSecurityStatus -SubscriptionId <SubscriptionId>) usado para la salud de seguridad de la suscripción que vimos en el post anterior; este comando no ejecutará los 19 controles incorporados para la seguridad de la suscripción, sino que ejecutará los controles incorporados de AzSK para todos los recursos Azure incluidos en su suscripción (por ejemplo, Máquina Virtual, Base de Datos SQL, Aplicaciones Lógicas, Bóveda de Claves, Red Virtual, etc.). El número de controles incorporados de AzSK que se ejecutarán dependerá del tipo y el número de recursos presentes en su suscripción.


Como recordatorio, la actual versión 3.7.0 de AzSK soporta 336 controles incorporados, de los cuales 19 son para la suscripción. El número de controles incorporados soportados puede ser obtenido usando el cmdlet Get-AzSKInfo como se muestra en la siguiente captura de pantalla:

Los resultados de los SVT están en el mismo formato que para la suscripción (informe de seguridad en CSV, archivos de registro que explican el resultado, etc.). Sólo los controles AzSK cambian porque dependen de los recursos Azure involucrados. En cuanto a la comprobación de la seguridad de la suscripción, se comprobarán los controles de seguridad del AzSK para cada recurso implicado y el estado del resultado será Aprobado, Fallido, Manual, Verificar o Error.


La lista de los 35 tipos de recursos en azul que actualmente soporta AzSK se resume en la siguiente tabla:

Nombre del tipo de recurso	Descripción del tipo de recurso o propósito
AnalysisServices	Motor de análisis de nivel empresarial como servicio
APIConnection	API administrada para aplicaciones de lógica
AppService	Creación rápida de potentes aplicaciones en la nube para la web y el móvil
Automation	Simplificar la gestión de la nube con la automatización de los procesos
AzSKCfg	Configuración del AzSK
Batch	Programación de trabajos a escala de la nube y gestión de la computación
BotService	Un servicio de bot inteligente, sin servidores, que escala según la demanda
CDN	Garantizar la entrega de contenido seguro y fiable con un amplio alcance mundial
CloudService	Crear aplicaciones y API de nube altamente disponibles e infinitamente escalables
ContainerInstances	Es fácil hacer funcionar los contenedores en Azure sin tener que administrar los servidores.
ContainerRegistry	Almacenar y gestionar imágenes de contenedores en todos los tipos de despliegues de Azure
CosmosDB	Base de datos multimodal distribuida globalmente para cualquier escala
Databricks	Una plataforma de análisis basada en Apache Spark, rápida, fácil y colaborativa
DataFactory	La integración de datos híbridos a escala empresarial, facilitada
DataFactoryv2	Servicio híbrido de integración de datos con patrones de ejecución muy flexibles
DataLakeAnalytics	Servicio de análisis distribuido que facilita el Big Data
DataLakeStore	Almacenamiento de datos a escala masiva en el lago
ERvNet (Express Route-connected Virtual Networks)	Conexiones de fibra de red privada dedicada a Azure
EventHub	Recibir la telemetría de millones de dispositivos
HDInsight	Provision cloud Hadoop, Spark, R Server, HBase, and Storm clusters
KeyVault	Salvaguardar y mantener el control de las llaves y otros secretos
LoadBalancer	Ofrecer alta disponibilidad y rendimiento de la red a sus aplicaciones
LogicAppS	Automatizar el acceso y uso de los datos a través de las nubes sin escribir código
NotificationHub	Envía notificaciones push a cualquier plataforma desde cualquier back end
ODG (On-premises Data Gateways)	Puente que proporciona transferencia de datos segura entre orígenes de datos locales y sus servidores de Azure Analysis Services en la nube
RedisCache	Potencia las aplicaciones con acceso a datos de alto rendimiento y baja latencia
Search	Búsqueda como servicio totalmente gestionada
ServiceBus	Conéctese en entornos de nube pública y privada
ServiceFabric	Desarrollar microservicios y orquestar contenedores en de Windows o Linux
SQLDatabase	Base de datos SQL relacional gestionada como servicio
StorageAccount	Almacenamiento en la nube duradero, altamente disponible y masivamente escalable
StreamAnalytics	Procesamiento de flujo de datos en tiempo real desde millones de dispositivos IoT
TrafficManager	Dirige el tráfico entrante para obtener un alto rendimiento y disponibilidad
VirtualMachine	Aprovisione máquinas virtuales Windows y Linux en segundos
VirtualNetwork	Aprovisione redes privadas, opcionalmente conéctese a centros de datos locales

La lista de tipos de recursos soportados continúa creciendo, y puede usar el siguiente comando AzSK (Get-AzSKS SupportedResourceTypes) para confirmar los tipos de recursos Azure soportados por su AzSK instalado.

En general, una suscripción incluye varias aplicaciones y cada aplicación puede organizarse en uno o varios grupos de recursos.

AzSK admite la comprobación de seguridad para grupos de recursos específicos.

1.2) Comprobación de seguridad de grupos de recursos específicos

El escaneo de seguridad de grupos de recursos específicos se puede realizar usando el siguiente comando AzSK:

Get-AzSKAzureServicesSecurityStatus -SubscriptionId <SubscriptionId> -ResourceGroupNames <ResourceGroupNames> donde ResourceGroupNames es una lista separada por comas de grupos de recursos que contienen recursos relacionados para una suscripción Azure (por ejemplo, "RG1, RG2, RG3").

AzSK comprobará entonces el estado de los controles de seguridad incorporados aplicables a todos los recursos incluidos en los grupos de recursos seleccionados. Como un grupo de recursos puede contener varios recursos, AzSK permite reducir sus controles de seguridad a un tipo de recurso específico, dependiendo de sus necesidades.

1.3) Escanear la seguridad de un tipo de recurso específico

Además del escaneo de seguridad de grupos de recursos específicos, AzSK también proporciona la capacidad de escanear la seguridad de un tipo de recurso específico.

Esto se hace aprovechando dos parámetros adicionales: ResourceType o ResourceTypeName. Los comandos relacionados de AzSK son los siguientes:

Get-AzSKAzureServicesSecurityStatus -SubscriptionId <SubscriptionId> [-ResourceGroupNames <ResourceGroupNames>] -ResourceType <ResourceType> o

Get-AzSKAzureServicesSecurityStatus -SubscriptionId <SubscriptionId> [-ResourceGroupNames <ResourceGroupNames>] -ResourceTypeName <ResourceTypeName>.

Por ejemplo, si quiere comprobar el estado de seguridad de todas las Máquinas Virtuales usadas en su aplicación (SubscriptionID = Subs-100, ResourceGroupNames=RG-App1-Dev & RG-App1-QA & RG-App1-Prod), el comando AzSK relacionado tendrá el aspecto siguiente:

Get-AzSKAzureServicesSecurityStatus -SubscriptionId "Subs-100" -ResourceGroupNames "G-App1-Dev, RG-App1-QA, RG-App1-Prod" -ResourceType "Microsoft.Compute/virtualMachines" o

Get-AzSKAzureServicesSecurityStatus -SubscriptionId 'Subs-100' -ResourceGroupNames 'RG-App1-Dev, RG-App1-QA, RG-App1-Prod' -ResourceTypeName 'VirtualMachine'.

Los valores soportados que se pueden utilizar para los parámetros ResourceType y ResourceTypeName se pueden obtener utilizando el siguiente comando AzSK Get-AzSKSupportedResourceTypes como en la siguiente captura de pantalla:

Como puede ver, AzSK proporciona una amplia lista de formas de realizar las pruebas de verificación de seguridad (SVT) de los recursos de Azure utilizados en sus aplicaciones. Estas pruebas de verificación de seguridad se basan en las mejores prácticas de seguridad y en las recomendaciones de Microsoft. Para cualquier detalle adicional, el cmdlet PS Get-Help Get-AzSKAzureServicesSecurityStatus será su "amigo".

Además de los 19 controles de seguridad incorporados para la seguridad de la suscripción, AzSK proporciona actualmente más de 317 controles de seguridad incorporados para ayudarle a construir aplicaciones seguras basadas en Azure.

En la siguiente tabla se enumeran los controles de seguridad admitidos por AzSK para el tipo de recurso Máquina virtual Azure:

N°	CONTROL	RAZÓN FUNDAMENTAL	GRAVEDAD
1	La máquina virtual debe tener instalada la última versión del sistema operativo	Estar en la última versión del sistema operativo reduce significativamente los riesgos de los problemas de diseño de seguridad y los errores de seguridad que pueden estar presentes en las versiones más antiguas	Media
2	Las actualizaciones automáticas del sistema operativo deben estar habilitadas en la máquina virtual de Windows	Las máquinas virtuales en las que las actualizaciones automáticas están desactivadas pueden perder importantes parches de seguridad debido a un error humano.	Alta
3	El antimalware debe estar habilitado con protección en tiempo real en la máquina virtual de Windows	Habilitar la protección antimalware minimiza los riesgos de los ataques existentes y nuevos de varios tipos de malware	Alta
4	El NSG debe estar configurado para la Máquina Virtual	Restringir el tráfico entrante y saliente a través de los NSG limita la exposición de la red de una VM reduciendo la superficie de ataque	Media
5	La IPs públicas en una máquina virtual debe ser revisada cuidadosamente	Las IPs públicas proveen acceso directo a través de Internet exponiendo a la VM a ataques a través de la red pública	Alta
6	La encriptación del disco debe estar habilitada tanto en el sistema operativo como en los discos de datos para la Máquina Virtual de Windows	Esto minimiza el riesgo de pérdida de datos por robo físico y también ayuda a cumplir los requisitos de cumplimiento normativo	Alta
7	La máquina virtual debe estar en un estado saludable en el Centro de Seguridad Azure	El Centro de Seguridad Azure emite alertas (que son típicamente indicativas de recursos que no cumplen con alguna protección de seguridad de base)	Alta
8	La máquina virtual debe tener instalados todos los parches necesarios del sistema operativo	Las máquinas virtuales sin parches son blancos fáciles para comprometerse con varios ataques de malware y troyanos.	Alta
9	La Máquina Virtual debe implementar todas las recomendaciones del ASC marcadas	El Centro de Seguridad Azure ofrece varias recomendaciones de seguridad para los recursos que no cumplen con alguna protección de seguridad de base	Alta
10	Los diagnósticos (extensión IaaSDiagnostics en Windows; extensión LinuxDiagnostic en Linux) deben estar habilitados en la máquina virtual	Los registros de diagnóstico son necesarios para crear un rastro de actividad mientras se investiga un incidente o un compromiso	Media
11	No deje los puertos de gestión abiertos en las máquinas virtuales	Los puertos de gestión remota abiertos exponen a un nodo de VM/computadora a un alto nivel de riesgo de ataques basados en Internet	Critica

Los controles de seguridad incorporados completos cubiertos por el recurso AzSK por Azure se pueden encontrar aquí.

AzSK también le permite controlar la seguridad de sus aplicaciones con otras herramientas que no sean PowerShell.

2) Codificación segura con Security IntelliSense

Security IntelliSense es una extensión que aumenta la característica estándar de Visual Studio IntelliSense con el conocimiento de la codificación segura. Te ayuda a obtener asistencia "en línea" para arreglar posibles problemas de seguridad mientras escribes el código.

Las características soportadas incluyen:


Aproximadamente 80 reglas (disponibles aquí) que cubren escenarios como:

• Varias reglas de codificación segura relacionadas con el Azure PaaS API
• Mejores prácticas de autenticación basadas en ADAL
• Errores de criptografía comunes
• Problemas de seguridad de la aplicación clásica y de la aplicación web

Reglas auto-actualizadas: El plug-in comprueba periódicamente si se han publicado nuevas reglas en un almacén central de reglas y actualiza su conjunto de reglas locales

Indicaciones de error y advertencia para un código incorrecto y posiblemente vulnerable: (Por ejemplo, el uso de la caché de fichas personalizadas en el escenario ADAL)

Sugerencias para correcciones/prácticas de codificación conformes: (Por ejemplo, en lugar de aleatorio, la clase RNGCryptoServiceProvider debería utilizarse en un contexto de criptografía).

3) Seguridad en CICD (extensión para Visual Studio)

Todas las pruebas de verificación de seguridad del AzSK (SVT) de las que hemos hablado hasta ahora pueden ser ejecutadas en cualquier momento en modo ad hoc (usando comandos Powershell) dependiendo de sus necesidades.

AzSK proporciona una extensión CICD que le ayuda a automatizar e integrar dichas pruebas de verificación de seguridad como parte de los flujos de trabajo de desarrollo y de liberación de tuberías.

La función de extensiones CICD de AzSK hace posible la aplicación automatizada de la configuración de seguridad al hacer que los SVT estén disponibles como una extensión de Visual Studio.

La guía para habilitar las pruebas de verificación de seguridad (SVT) en los canales de lanzamiento de Visual Studio Team Services (VSTS) se puede encontrar aquí. VSTS se conoce actualmente como Azure DevOps Services.

Conclusión

En este artículo (el cuarto relacionado con el Kit de Desarrollo Seguro para Azure - AzSK), traté de cómo este marco de trabajo AzSK puede ser aprovechado para desarrollar e implementar aplicaciones seguras basadas en la nube de Azure. Esto se hace gracias a las siguientes características:

• Pruebas de verificación de seguridad (SVT) para los recursos de Azure utilizados en sus aplicaciones (35 tipos de recursos actualmente soportados con 317 controles de seguridad incorporados)
• Prácticas de codificación de seguridad usando el Security IntelliSence
• Integración de seguridad en la Integración Continua/ Entrega Continua (CICD) a través de una extensión de Visual Studio AzSK

Referencias clave y recursos adicionales

• Getting started with the Secure DevOps Kit for Azure
• Building cloud apps using the Secure DevOps Kit for Azure
• AzSK Control Coverage
• Security IntelliSense Rules
• Security in CICD

On-Premises vs. Azure Security Stack

Antes vimos un diagrama que presenta un mapeo de controles de seguridad locales frente a los servicios ofrecidos por los principales proveedores de servicios en la nube. 

El siguiente diagrama sigue un patrón similar, centrado solo en las tecnologías de seguridad de Azure e incluye información adicional como servicios de Azure gratuitos versus facturables, disponibilidad de herramientas de terceros en Azure Marketplace e integración entre estas tecnologías y otros servicios de Azure, incluidas herramientas de monitoreo. 

La intención del diagrama es proporcionar a los profesionales de seguridad una vista consolidada de toda la pila de seguridad de Azure.

Componentes y relaciones de Azure Security Center con otros servicios

Una de las preguntas más comunes sobre Azure Sentinel es sobre su funcionalidad en comparación con Azure Security Center. 

El siguiente diagrama es un intento de describir los diversos componentes de Azure Security Center, su relación con otros servicios de Azure, incluido Azure Sentinel, así como la interacción con servicios y dispositivos que no son de Azure. 

Como se puede deducir de este diagrama, Azure Sentinel es un consumidor de registros y alertas generados por Azure Security Center y Microsoft está haciendo un esfuerzo para eliminar algunas áreas que parecen superponerse, como el procesamiento de registros y alertas en el propio Azure Security Center. 

Sin embargo, la mayor parte de la funcionalidad del Centro de seguridad de Azure es totalmente distinta de Azure Sentinel y agrega una amplia gama de controles y controles de seguridad tanto para puntos finales como para dispositivos de red, Azure y no Azure.

Cómo controlar la seguridad de tu suscripción a Azure con el kit de Secure DevOps

Después del primer post relacionado con el Kit de Seguridad para Azure (AzSK), donde describí sus capacidades principales, y el segundo post centrado en sus controles incorporados, continuaré sobre cómo aprovechar estos controles de seguridad incorporados para construir y mantener seguras sus aplicaciones basadas en Azure a lo largo de las etapas de DevOps.

Este 3er artículo de la serie Azsk se centrará en el primer paquete AzSK (Subscription Security features) ilustrado en la siguiente figura de Microsoft:

Una suscripción es la base para las solicitudes de Azure. Las características de AzSK para la seguridad de la suscripción incluyen los siguientes aspectos:

• Comprobación de la seguridad de la suscripción
• Provisión de seguridad de suscripción
• Configuración de la alerta
• Configuración de políticas del Administrador de Recursos Azules (ARM)
• Configuración del Centro de Seguridad Azul (ASC)
• Control de acceso (RBAC) Higiene

1) Chequeo de seguridad de la suscripción

AzSK incluye un guión que puede comprobar su suscripción e indicar si hay algunos problemas de seguridad en comparación con las mejores prácticas. Los aspectos de seguridad que se pueden comprobar incluyen:

• Configuración del control de acceso: cuestiones relacionadas con la identidad y la gestión de acceso en la suscripción
• Configuración de alertas: configuración de alertas de actividad para acciones sensibles o críticas para la suscripción y varios recursos de la nube
• Configuración del Centro de Seguridad Azure - configuración de ASC (punto de contacto de seguridad, varios ajustes de política ASC, etc.)
• Configuración de Política ARM y Bloqueos de Recursos - presencia del conjunto deseado de reglas de política ARM y bloqueos de recursos

El comando PowerShell (PS) para el chequeo de salud de la seguridad de la suscripción es el siguiente: Get-AzSKSubscriptionSecurityStatus -SubscriptionId <SubscriptionId> donde <SubscriptionId> es el ID de la suscripción que quieres escanear. Como se ha explicado en el post anterior centrado en las capacidades centrales de AzSK, necesitas al menos el permiso de Azure RBAC Reader en la suscripción que quieres escanear.


Cuando la exploración de seguridad de la suscripción está en curso, su progreso se muestra en la pantalla de salida del PS como en la siguiente captura de pantalla:

Los 19 controles de seguridad incorporados en el AzSK para la suscripción se comprueban progresivamente y el resumen del análisis se muestra al final.

En el ejemplo de la captura de pantalla PS anterior, de los 19 controles de seguridad incorporados en el AzSK para la suscripción, 10 pasaron la prueba de verificación, 4 fallaron, 2 están en estado de "Verificación" mientras que 3 están en estado de "Manual". Los posibles estados de verificación de cada control son los siguientes:

• Pasado: el control ha pasado la prueba de verificación no tiene nada que hacer
• Fallado: el control ha fallado la prueba. Necesitas echar un vistazo a los detalles en el archivo LOG para entender por qué
• Verificar: el juicio humano es necesario para decidir si el control ha pasado o ha fallado. Necesitas echar un vistazo al archivo LOG para tomar una decisión informada
• Manual: AzSK no cubre actualmente este control o AzSK no puede obtener datos (por ejemplo, debido a los permisos de usuario limitados). Deberías mirar el archivo LOG para más detalles
• Error: Se produjo un error por el cual no se pudo determinar el estado de control

Además de la salida del PS, también se genera un conjunto de archivos (informe de seguridad, Log, Readme, etc.) para ayudar a comprender cómo tratar los resultados de la verificación de seguridad.

Un archivo importante entre estos archivos generados es el informe de seguridad en formato CSV. Además de todos los detalles de los controles que ya hemos discutido en el post anterior, el estado de cada control está disponible.


El informe de seguridad correspondiente, por ejemplo, que se muestra en la captura de pantalla anterior del PS (formateado de CSV a XLS) es el siguiente:

Una vez que obtenga este informe de seguridad para su suscripción, deberá trabajar con su equipo de seguridad de TI para ver si es aceptable con respecto a la política de seguridad y la línea base de su organización.

Ya he hablado en algunos de mis artículos anteriores sobre cómo definir e implementar una política de seguridad en la nube efectiva, así como sobre la línea base de seguridad en la nube para una plataforma de nube específica como Azure.

Si ha definido e implementado esas políticas y líneas de base de seguridad en la nube, será fácil para las partes interesadas en el desarrollo (y principalmente el personal de seguridad de TI) decidir cómo tratar este informe de seguridad de suscripción y especialmente los controles no aprobados.

De forma predeterminada, AzSK utiliza las recomendaciones de seguridad y las mejores prácticas de Microsoft para realizar las pruebas de verificación de seguridad. Pero puede adaptar las configuraciones de AzSK a su contexto específico. Esta adaptación está fuera del alcance de este post.

Basándome en mi experiencia, puede ser muy difícil abordar los controles de seguridad de AzSK para los cuales el resultado de las pruebas de verificación es "Verificar" o "Manual".

Por un lado, es necesario conocer y comprender correctamente la política de seguridad en la nube y la línea de base de su organización. Estas habilidades y competencias pueden esperarse del equipo de Seguridad de TI.

Por otra parte, usted necesita entender el contexto de cada prueba de verificación. Como de costumbre, todas sus suscripciones no tendrán la misma criticidad o requisitos de seguridad. Necesita encontrar una manera de adaptar sus pruebas de verificación de seguridad al contexto de sus suscripciones. La colaboración entre los equipos de seguridad, desarrollo y operaciones es clave para una decisión informada. Trabajar en el modo Devops ayuda significativamente aquí, ya que rompe los silos entre los diferentes equipos. Todos los interesados en Devops contribuyen a la seguridad de la solución.

Siguiendo los principios de gestión de riesgos (por ejemplo, ISO 27005), para un determinado control de salud de la seguridad de una suscripción, todos los controles de seguridad de AzSK no tienen por qué pasar necesariamente las pruebas de verificación. Esto debe ser parte del apetito de riesgo de su organización y debe reflejarse en su política y línea de base de seguridad en la nube.

De forma predeterminada, todos los controles incorporados de AzSK para la seguridad de suscripción se comprueban, pero puede restringir sus pruebas de verificación en función de sus necesidades.


Además del SubscriptionID, el comando de comprobación de la salud de la suscripción de AzSK admite varios otros parámetros:

• Filtros de bolsas: Etiquetas separadas por comas para filtrar las categorías requeridas de controles de seguridad. Por ejemplo, RBAC, SOX, AuthN, etc.
• ExcluirEtiquetas: Etiquetas separadas por comas para excluir algunas categorías de controles de seguridad. Por ejemplo, RBAC, SOX, AuthN, etc.
• ControlIds: Identificaciones de control AzSK separadas por comas para filtrar los controles de seguridad. Por ejemplo, Azure_Subscription_AuthZ_Limit_Admin_Owner_Count, Azure_Subscription_Config_Azure_Security_Center, Azure_Subscription_Audit_Configure_Critical_Alerts, etc.

El comando relacionado con el chequeo de seguridad de PS se verá como:

Get-AzSKSubscriptionSecurityStatus -SubscriptionId <SubscriptionId> [-ControlIds <ControlIds>] [-FilterTags <FilterTags>] [-ExcludeTags <ExcludeTags>]


La lista completa de etiquetas actualmente soportadas por AzSK, así como su propósito se puede encontrar es la siguiente:

TAG	Descripción
Access	Actividades de acceso
ACLS	Actividades de control de acceso.
AppService	Servicios de aplicaciones de Azure
Audit	Actividades de auditoria
AuthN	Actividades de autenticación
AuthZ	Actividades de autorizacion
Automated	Controles que son automatizados por AzSK
Availability	Disponibilidad
BCDR	Copia de seguridad y recuperación ante desastres
Best Practice	Controles que deben implementarse para garantizar la seguridad de su aplicación
Classic	Servicios clásicos
Config	Configuraciones
Deploy	Actividades de implementación
Diagnostics	Actividades diagnósticas
Dp	Protección de Datos
FunctionApp	Azure FunctionApp
Information	Controles que son el comportamiento predeterminado de Azure pero verificación adicional para notificación
KeyRotation	Rotación de la llave
Linux	Máquina virtual Linux
Manual	Controles que no están automatizados y debe verificarlo manualmente
NetSec	Seguridad de la red
OwnerAccess	Controles que requieren permiso del propietario / coadministrador para obtener la salida requerida
RBAC	Controles de acceso basados ​​en roles
SDL	Ciclo de vida del desarrollo de programas
SecIntell	Intellisense de seguridad
SOX	Controles impuestos por SOX
SqlDatabase	Azure SQL Database
TCP	Controles que deben implementarse para garantizar la seguridad de su aplicación
Windows	Máquina virtual de Windows

Por ejemplo, si sólo le interesan los controles de seguridad de las mejores prácticas para los aspectos de configuración y control de acceso para una suscripción determinada, el comando AzSK apropiado será el siguiente:

Get-AzSKSubscriptionSecurityStatus -SubscriptionId "ValueOfSubscriptionId" -FilterTags "ACLS, Config, Best Practice"

Además del chequeo de seguridad de la suscripción, AzSK le permite configurar algunos aspectos adicionales de sus suscripciones a Azure.

2) Provisión de seguridad de la suscripción

Con AzSK, puedes proveer los contactos de seguridad para tu suscripción. Esto se hace usando el siguiente comando de AzSK: Set-AzSKSubscriptionSecurity -SubscriptionId <subscriptionId> -SecurityContactEmails <SecurityContactEmails> -SecurityPhoneNumber <SecurityPoCPhoneNumber>.


3) Configuración de la alerta

Con AzSK puedes configurar y gestionar las alertas por suscripción y por actividad de recursos en azul. El comando relacionado con AzSK es el siguiente:

Set-AzSKAlerts -SubscriptionId <subscriptionid> -SecurityContactEmails <SecurityContactEmails> [-SecurityPhoneNumbers <SecurityPhoneNumbers>].

AzSK actualmente soporta alertas para las siguientes actividades de suscripción:

Actividades de suscripción que generan alertas

Microsoft.Authorization/elevateAccess/action

Microsoft.Authorization/classicAdministrators/write

Microsoft.Authorization/classicAdministrators/delete

Microsoft.Authorization/locks/write

Microsoft.Authorization/locks/delete

Microsoft.Authorization/policyAssignments/delete

Microsoft.Authorization/policyAssignments/write

Microsoft.Authorization/policyDefinitions/delete

Microsoft.Authorization/roleAssignments/write

Microsoft.Authorization/roleAssignments/delete

Se requiere el permiso del propietario del RBAC azul en la suscripción para este comando de ajuste de alerta.

4) Configuración de la política de ARM

AzSK le permite establecer una línea base de políticas de ARM correspondientes a ciertas acciones que se consideran inseguras.

El comando PS relacionado es Set-AzSKARMPolicies -SubscriptionId <subscriptionid> y se requiere el permiso del propietario en la suscripción.

Las políticas ARM actualmente soportadas por AzSK incluyen lo siguiente:

Nombre de la política	Descripción de la política
AzSK_ARMPol_Audit_SQL_Basic_Create	Generar un evento de auditoría al crear una base de datos SQL con el tipo de edición 'Basic'.
AzSK_ARMPol_Audit_NonGRS_Storage_SKU	Generar un evento de auditoría al crear una cuenta de almacenamiento con LRS estándar (sin Geo-Replicación)
AzSK_ARMPol_Audit_Job_Scheduler_Free_Tier	Generar un evento de auditoría al crear un planificador de trabajo con nivel libre
AzSK_ARMPol_Audit_Old_SQL_Version	Generate an audit event upon creation of a sql server with version less than 12.0
AzSK_ARMPol_Audit_NonHBI_Resource_Create	Generate an audit event upon creation of resource types which have not been ratified for critical enterprise data
AzSK_ARMPol_Audit_Classic_Resource_Create	Generar un evento de auditoría al crear recursos clásicos/v1 (es decir, basados en ASM)

5) Configuración del Centro de Seguridad Azul (ASC)

Con AzSK, puedes definir la configuración de la política empresarial por defecto para el Azure Security Center (ASC).

El comando relacionado con AzSK es Set-AzSKAzureSecurityCenterPolicies -SubscriptionId <SubscriptionId> -SecurityContactEmails <ContactEmails> -SecurityPhoneNumber <ContactPhone>

Este comando requiere el permiso del Lector de RBAC Azul en la suscripción.

6) Control de acceso (RBAC) higiene

AzSK finalmente le permite configurar un conjunto de cuentas obligatorias que se requieren para las funciones centrales de escaneo/auditoría/cumplimiento. El comando relacionado de AzSK es el siguiente: Set-AzSKSubscriptionRBAC -SubscriptionId <subscriptionId> y se requiere el permiso del propietario en la suscripción.

Como puedes ver, AzSK proporciona un conjunto completo de scripts automatizados que pueden ser aprovechados para controlar la seguridad de tus suscripciones a Azure a lo largo del ciclo de vida de tus desarrollos. Algunos de estos scripts requieren altos privilegios (por ejemplo, el permiso del propietario de Azure RBAC en la suscripción). Decidir quién puede o debe ejecutar qué scripts y cuándo, es una decisión crítica que debe tomarse como parte de sus actividades de gobierno de la nube Azure.

Conclusión

En este artículo, aprendiste a aprovechar el Kit de Desarrollo Seguro para Azure (AzSK) para controlar la seguridad de tus suscripciones. Un beneficio clave de AzSK es que el control de seguridad de la suscripción puede ser realizado por cualquier interesado en DevOps en cualquier etapa.

Pero como las suscripciones a Azure son los cimientos de las aplicaciones en la nube de Azure, deberían ser los primeros componentes de Azure en asegurar, para garantizar que la aplicación en la nube alojada se basará en fundamentos seguros. La verificación de la seguridad de la suscripción debería iniciarse entonces en la etapa muy temprana del desarrollo de la aplicación en la nube con la plataforma en la nube Azure.

En el próximo artículo, me centraré en cómo aprovechar el kit de desarrollo seguro para Azure para asegurar el desarrollo de sus aplicaciones en la nube, cubriendo otros recursos de Azure además de la suscripción.

Referencias clave y recursos adicionales

Getting started with the Secure DevOps Kit for Azure

Building cloud apps using the Secure DevOps Kit for Azure

Subscription Security with AzSK

Mapeo de los controles de seguridad locales frente a los principales servicios de proveedores de la nube

La migración de aplicaciones locales a la nube invariablemente es seguida por la replicación de la funcionalidad de los controles de seguridad a equivalentes basados ​​en la nube. Sin embargo, la demarcación de estos controles tiende a difuminarse en la nube, con la superposición de funcionalidades, volviéndose más granular y ofrecida en diferentes niveles.

Este gráfico debe usarse como una vista de alto nivel de los controles de seguridad en la nube que podrían usarse para replicar la funcionalidad local.

Azure Security Stack vs. NIST Cybersecurity Framework

En mayo de 2019, Managed Sentinel lanzó un diagrama que presenta una asignación de los servicios de seguridad de Azure frente a los controles de seguridad locales. La comunidad de seguridad cibernética expresó su interés en tener los mismos controles de seguridad asignados contra las funciones del Marco de Seguridad Cibernética del NIST: Identificar, Detectar, Proteger, Responder y Recuperar.

El diagrama a continuación proporciona una vista de alto nivel de cómo varios controles de seguridad de Azure caen dentro de las funciones del NIST Cybersecurity Framework, así como los flujos de datos de seguridad entre ellos. El signo $ indica que un control es un servicio pago. El icono de escudo identifica la conectividad entre el control de seguridad de Azure y el SIEM de Azure Sentinel a través de los conectores de datos integrados. Algunos servicios proporcionan cobertura para varias funciones NIST y se muestran cruzando dos funciones NIST adyacentes o con una etiqueta codificada por colores en el fondo.

Azure Cloud Security NIST ciberseguridad

Versión PDF -  Versión SVG

Comprensión de los controles incorporados del Kit de Seguridad para Azure

En mi anterior post sobre la introducción del Kit de Desarrollo Seguro para Azure (AzSK), describí algunas capacidades básicas de este marco. Se han discutido los siguientes aspectos:

• Los principales interesados
• La guía de configuración
• Los tipos de recursos de azufre apoyados
• Los comandos soportados, y
• Los principales permisos RBAC requeridos de Azure

A modo de recordatorio, la siguiente figura muestra cómo las principales herramientas de AzSK se unen para permitir un desarrollo de software seguro con Azure.

Seguridad de suscripción: este paquete ayuda a los usuarios de Azure a construir sus aplicaciones sobre suscripciones seguras. Permite a los usuarios de Azure desplegar y configurar la seguridad en sus suscripciones incluyendo elementos como alertas, políticas ARM, RBAC, políticas del Centro de Seguridad, bloqueo de recursos, etc. Usando estas capacidades, pueden establecer y configurar una suscripción segura y compatible desde el principio y tener una base sólida.

Desarrollo seguro: este paquete proporciona la capacidad de escribir código seguro y de probar la configuración segura de sus aplicaciones en la nube durante la codificación y las primeras etapas de desarrollo. Este paquete incluye dos módulos principales:

• Pruebas de verificación de seguridad (SVT). Estas pruebas verifican automáticamente la mayoría de los controles de seguridad incorporados para los servicios Azure admitidos (más de 35 en la actual versión 3.7.0 de AzSK), incluyendo Azure Storage, Azure SQL Database, Azure Key Vault, Azure Virtual Machines o Azure Virtual Network.

• Seguridad IntelliSense: Aumenta el IntelliSense tradicional con las mejores prácticas de codificación segura y ofrece correcciones, consejos y directrices mientras un desarrollador escribe el código. Esto se hace mediante reglas de codificación segura que cubren las mejores prácticas para las API de la plataforma Azure como servicio (PaaS), la seguridad de las aplicaciones web tradicionales y la criptografía.

Seguridad en CI/CD: Consiste en tareas de construcción/liberación para flujos de trabajo de CI/CD que permiten a los usuarios de Azure comprobar la seguridad de la suscripción y los recursos durante los flujos de construcción/despliegue automatizados. Proporciona la capacidad de ejecutar SVT como parte de la tubería CICD de Visual Studio Team Services (VSTS).

Garantía continua: este paquete permite a los usuarios de Azure evitar la deriva del estado de seguridad y mantenerse al día con las mejoras de las características de seguridad de Azure. Es útil para un entorno de desarrollo en constante cambio que es diferente de una mentalidad de seguridad que es un hito. Incluye herramientas como:

• Azure Automation Runbooks: identificar y corregir la deriva de la configuración de seguridad
• Azure Resource Manager (ARM): se utilizan para desplegar de forma segura recursos azules preconfigurados.
• Conjunto de scripts de PowerShell: utilizado para crear la cuenta de Automatización, aplicar las plantillas, e instalar y configurar los Runbooks

Alerta y vigilancia: Este paquete utiliza el paquete de gestión de operaciones (OMS) para ofrecer un tablero central donde los diferentes equipos pueden ver el estado de la seguridad y las tendencias de sus suscripciones y aplicaciones Azure, según lo informado por los diferentes componentes de AzSK. Con sus vistas integradas, salva la brecha entre el equipo de desarrollo y el equipo de operaciones desde el punto de vista de la seguridad.

Gobernanza de los riesgos de la nube: AzSK genera eventos de telemetría de todas las etapas que utilizan automatización, scripts o extensiones. Estos eventos son procesados por una cuenta de Application Insights y vistos en un dashboard de Power BI. Este módulo de AzSK proporciona tres vistas principales:

• Adopción y uso del DevOps Kit en toda la empresa (imagen de la madurez segura de DevOps de la empresa en la nube)
• Agregación de los riesgos relacionados con las nubes a través de las líneas de servicio (información importante para la remediación o reducción de riesgos mediante la priorización)
• Visibilidad de los errores y desafíos comunes que los desarrolladores enfrentan al usar el kit

En las siguientes secciones, exploraremos los controles de seguridad incorporados soportados por AzSK para habilitar las pruebas de verificación de seguridad (SVT).

Los controles de seguridad incorporados en AzSK

AzSK proporciona actualmente 336 controles de seguridad que pueden ser verificados en cualquier etapa de DevOps. El número de controles soportados se puede obtener con el siguiente comando de PowerShell: Get-AzSKInfo -InfoType ControlInfo.

Con este comando de PowerShell se obtienen dos informaciones principales:

1) El número resumido de controles de seguridad por servicio Azure y por severidad:

La severidad de cada control por servicio Azure está definida por Microsoft, pero puede cambiarla según sus políticas de seguridad.

2) Los detalles de cada control en un archivo CSV que puede ser formateado como un archivo XSL

Cada control de seguridad de AzSK incluye los siguientes detalles:

• Nombre del elemento: nombre del servicio Azure como Máquina Virtual, Almacenamiento, Bóveda de Llaves, etc.
• ControlID: identificación única del control con el recurso Azure como prefijo
• Descripción: descripción del control
• ControlSeverity: la severidad del control según lo definido por Microsoft. Los posibles valores son: crítico, alto, medio o bajo.
• IsBaselineControl: si el control se considera como parte de la línea de base o no (Sí o No)
• Justificación: Explicación del papel de este control
• Recomendación: guía detallada sobre cómo arreglar el control si no pasa la prueba
• Automatizado: si el control puede ser automatizado o no por AzSK
• Apoya el AutoFix: si AzSK puede generar el script para arreglar el control cuando la prueba falla
• Etiquetas: etiquetas que pueden ser usadas para filtrar ciertos controles. Los valores posibles incluyen SDL, Información, Mejor Práctica, Automatizado, Manual, DP, AuthZ, AuthN, RBAC, SOX, NetSec, Auditoría, BCDR, etc.

Como ejemplo, aquí están los detalles de dos controles de seguridad de AzSK:

AzSK Security Control	Example 1	Example 2
FeatureName	Servicios de análisis	AzSKCfg
ID de control	Azure_AnalysisServices_DP_Encrypt_In_ transit	Azure_AzSKCfg_Check_Presence_of_Latest_AzSK_Module
Descripción	Los datos confidenciales deben estar encriptados en tránsito	Los escaneos AzSK deben usar la última versión del módulo AzSK
ControlSeverity	Alto	Alto
IsBaselineControl	NO	SI
Razón fundamental	El uso de HTTPS garantiza la autenticación del servidor / servicio y protege los datos en tránsito de los ataques de secuestro de sesión de hombre en el medio de la capa de red , espionaje y secuestro de sesión	Con cada lanzamiento se agregan nuevas actualizaciones de seguridad . El uso del último módulo AzSK garantiza que su suscripción en la nube y sus recursos se escaneen con los últimos controles
Recomendación	Asegúrese de que los datos confidenciales se transmitan solo en un canal cifrado en todo el Servicio de análisis . Consulte: https://blogs.msdn.microsoft.com/jason_howell/2013/02/26/how-do-i-ensure-analysis-services-client-tcp-connectivity-is-encrypted/	Vuelva a ejecutar el comando de instalación para obtener el último módulo AzSK
Automatizado	NO	SI
Soporta AutoFix	NO	NO
Etiquetas	SDL, información, manual, DP, servicios de análisis	SDL, TCP , automatizado, AzSKCfgControl

Como la suscripción al Azure es la base de otros recursos del Azure, detallaré los controles de seguridad proporcionados por AzSK para comprobar el estado de seguridad de una suscripción al Azure dada, en cualquier etapa de los DevOps.

Controles incorporados de AzSK para la seguridad de la suscripción a Azure

AzSK apoya actualmente 19 controles de seguridad para la suscripción de Azure que se enumeran en el siguiente cuadro, clasificados por orden alfabético de identificación de control:

N °	ID de control	Descripción	Controlar la gravedad	Is Baseline	Razón fundamental
1	Azure_Subscription_AuthZ_Limit_Admin_Owner_Count	Minimiza la cantidad de administradores / propietarios	Medio	No	Cada persona adicional en el rol Propietario / Colaborador aumenta la superficie de ataque para toda la suscripción. El número de miembros en estos roles debe mantenerse lo más bajo posible
2	Azure_Subscription_AuthZ_Justify_Admins_Owners	Justifique todas las identidades que se otorgan con acceso de administrador / propietario en su suscripción	Medio	No.	Las cuentas que son miembros de estos grupos sin una razón comercial legítima aumentan el riesgo de su suscripción. Al revisar y eliminar cuidadosamente las cuentas que no deberían estar allí en primer lugar, puede evitar ataques si esas cuentas se ven comprometidas
3	Azure_Subscription_AuthZ_Add_Required_Central_Accounts	Las cuentas centrales obligatorias deben estar presentes en la suscripción	Alto	Si	Se espera que ciertas cuentas centrales estén presentes en todas las suscripciones para admitir funciones de toda la empresa (por ejemplo, escaneo de seguridad , optimización de costos, etc.). Ciertas otras cuentas también pueden ser necesarias dependiendo de la funcionalidad especial habilitada en una suscripción (p. Ej., Gestión de red Express Route)
4	Azure_Subscription_AuthZ_Remove_Deprecated_Accounts	Las cuentas obsoletas / obsoletas no deben estar presentes en la suscripción	Critico	Si	Las cuentas en desuso son aquellas que alguna vez se implementaron en su suscripción para alguna iniciativa de prueba / piloto (o algún otro propósito). Ya no se requieren y son un riesgo permanente si están presentes en algún rol de la suscripción
5	Azure_Subscription_AuthZ_Dont_Use_NonAD_Identities	No otorgue permisos a cuentas externas (es decir, cuentas fuera del directorio nativo para la suscripción)	Alto	Si	Las cuentas que no son de AD (como xyz@hotmail.com, pqr@outlook.com, etc.) presentes en cualquier alcance dentro de una suscripción someten sus activos en la nube a un riesgo indebido. Estas cuentas no se administran con los mismos estándares que las identidades de inquilinos empresariales
6	Azure_Subscription_AuthZ_Dont_Use_SVC_Accounts_No_MFA	Las cuentas de servicio no pueden admitir MFA y no deben usarse para la actividad de suscripción	Alto	No	Las cuentas de servicio generalmente no tienen capacidad de autenticación multifactor . Muy a menudo, los equipos que poseen estas cuentas no tienen el debido cuidado (p. Ej., Alguien puede iniciar sesión de forma interactiva en los servidores utilizando una cuenta de servicio exponiendo sus credenciales a ataques como pasar el hash, phishing , etc.)
7	Azure_Subscription_AuthZ_Limit_ClassicAdmin_Count	No debe haber más de 2 administradores clásicos.	Alto	No	La versión v1 (basada en ASM) del modelo de acceso a recursos de Azure no tenía mucho en términos de granularidad RBAC. Como resultado, todos los que necesitaban acceso a una suscripción o sus recursos tuvieron que agregarse a la función de coadministrador.
8	Azure_Subscription_AuthZ_Remove_Management_Certs	No se permite el uso de certificados de gestión.	Alto	Si	Al igual que los administradores clásicos, los certificados de administración se usaron en el modelo v1 para la automatización basada en scripts / herramientas en suscripciones de Azure
9	Azure_Subscription_Config_Azure_Security_Center	Azure Security Center (ASC) debe estar configurado correctamente en la suscripción	Alto	Si	La característica Centro de seguridad de Azure ayuda con configuraciones centrales importantes para la suscripción, como la configuración de un punto de contacto de seguridad. También es compatible con la configuración de políticas clave (por ejemplo, ¿el parcheo está configurado para máquinas virtuales ?, ¿está habilitada la detección de amenazas para SQL ?, etc.)
10	Azure_Subscription_Audit_Resolve_Azure_Security_Center_Alerts	Las alertas pendientes de Azure Security Center (ASC) deben resolverse	Alto	No	Según las políticas habilitadas en la suscripción, Azure Security Center genera alertas
11	Azure_Subscription_AuthZ_Dont_Add_SPNs_as_Owner	Los nombres principales de servicio (SPN) no deben ser propietarios o contribuyentes en la suscripción	Medio	No	Al igual que las cuentas de servicio basadas en AD, los SPN tienen una credencial única y la mayoría de los escenarios que los utilizan no pueden admitir la autenticación de múltiples factores
12	Azure_Subscription_SI_Lock_Critical_Resources	Los recursos críticos de la aplicación deben protegerse mediante un bloqueo de recursos	Medio	No	Un bloqueo de recursos protege un recurso para que no se elimine accidentalmente. Con RBAC adecuada configuración , es posible que los recursos críticos de configuración de una suscripción de tal manera que las personas pueden realizar la mayoría de las operaciones en ellos, pero no pueden eliminar las
13	Azure_Subscription_Config_ARM_Policy	Las políticas ARM deben usarse para auditar o denegar ciertas actividades en la suscripción que pueden afectar la seguridad	Medio	Si	La configuración de seguridad de la suscripción de AzSK configura un conjunto de políticas ARM que resultan en entradas de registro de auditoría sobre acciones que violan las políticas
14	Azure_Subscription_Audit_Configure_Critical_Alerts	Las alertas deben configurarse para acciones críticas sobre suscripción y recursos	Alto	Si	La configuración de seguridad de la suscripción de AzSK configura alertas basadas en Insights para operaciones confidenciales en la suscripción
15	Azure_Subscription_AuthZ_Custom_RBAC_Roles	No use roles RBAC personalizados	Medio	No	Las definiciones de roles de RBAC personalizadas suelen ser difíciles de entender
16	Azure_Subscription_SI_Classic_Resources	No use ningún recurso clásico en una suscripción	Medio	No	Debe usar nuevos recursos ARM / v2 ya que el modelo ARM proporciona varias mejoras de seguridad
17	Azure_Subscription_SI_Dont_Use_Classic_VMs	No use máquinas virtuales clásicas en su suscripción	Alto	No.	Lo mismo que arriba
18	Azure_Subscription_NetSec_Justify_PublicIPs	Verifique la lista de direcciones IP públicas en su suscripción	Alto	No	Las IP públicas proporcionan acceso directo a través de Internet exponiendo un recurso en la nube a todo tipo de ataques a través de la red pública
19	Azure_Subscription_AuthZ_Dont_Grant_Persistent_Access	No se debe otorgar acceso permanente para roles de nivel de suscripción privilegiado	Alto	No	El acceso permanente aumenta el riesgo de que un usuario malintencionado obtenga ese acceso e impacte inadvertidamente un recurso sensible

Estos 19 controles de seguridad son las recomendaciones de Microsoft que deben utilizarse para verificar la seguridad de la suscripción.

Como cliente de Azure, eres libre (y es muy recomendable) de adaptar estas recomendaciones de seguridad de Microsoft a tu contexto específico.

Por ejemplo, es posible que algunos de los controles de seguridad anteriores no sean aplicables a su contexto y/o que la gravedad de Microsoft sea diferente según sus requisitos. En ese caso, puede aumentar o disminuir la gravedad de cualquier control en función de sus requisitos y políticas de seguridad.

Todas estas adaptaciones deben ser realizadas por su equipo de seguridad informática y compartidas con todos los interesados en DevOps (propietario de la carga de trabajo en la nube, equipos de Dev y Ops, oficial de conformidad, etc.).

Conclusión

En este artículo, me centré en los controles de seguridad incorporados con el apoyo de AzSK para habilitar las pruebas de verificación de seguridad (SVT) de los servicios o recursos de Azure.

Aprendiste a obtener todos los controles de seguridad incorporados admitidos (336 para la versión actual de AzSK 3.7.0) y la descripción general de los 19 controles de seguridad para la seguridad de la suscripción a Azure.

En el próximo post, me centraré en cómo aprovechar estos controles de seguridad incorporados para comprobar la seguridad de sus aplicaciones en la nube de Azure a lo largo de las etapas de DevOps.

Referencias clave y recursos adicionales

[1] Getting started with the Secure DevOps Kit for Azure

[2] Building cloud apps using the Secure DevOps Kit for Azure

[3] Security controls covered by the Secure DevOps Kit for Azure