domingo, 9 de junio de 2019

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ánsitoLos escaneos AzSK deben usar la última versión del módulo AzSK
ControlSeverityAltoAlto
IsBaselineControlNOSI
Razón fundamentalEl 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ónCon 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ónAsegú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
AutomatizadoNOSI
Soporta AutoFixNONO
Etiquetas SDL, información, manual, DP, servicios de análisisSDL, 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 NoSegú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_PublicIPsVerifique 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



No hay comentarios.:

Publicar un comentario