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.