- 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
No hay comentarios.:
Publicar un comentario