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.
jueves, 25 de julio de 2019
miércoles, 17 de julio de 2019
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:
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:
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:
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:
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:
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:
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:
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
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
miércoles, 10 de julio de 2019
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.
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.
sábado, 29 de junio de 2019
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
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:
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.
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:
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
- 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
jueves, 2 de mayo de 2019
Introducción al Secure DevOps Kit for Azure
El 27 de abril del 2019 tuvimos una excelente jornada de #DevSecOps en Microsoft "GLOBAL AZURE BOOTCAMP 2019" Desde DevSecOps AR brindamos la charla "DevSecOps con Azure DevOps" de Luciano Moreira y Christian Ibiri.
Luego de nuestra charla tuvimos muchas consultas sobre Secure DevOps Kit for Azure en esta serie vamos a tratar de explicar sus principales características.
ASC es muy útil para que los especialistas en Seguridad y Propietarios de cargas de trabajo en la nube monitoreen continuamente la higiene de seguridad de sus cargas de trabajo. Sin embargo, ASC es una herramienta de seguridad central para los recursos ya implementados.
Como sabemos, las aplicaciones en la época de la nube se están desarrollando en métodos ágiles y con la cultura DevOps. Esto significa que las aplicaciones no se implementan una sola vez como en el modo tradicional, sino en varias oleadas (por ejemplo, en sprints). Los equipos de desarrollo y operaciones ya no trabajan en silos, sino que cooperan a lo largo de todo el ciclo de vida de desarrollo de las aplicaciones.
En el contexto de la nube, las aplicaciones se despliegan en modo continuo (Integración continua/entrega continua, también conocida como CICD) y deben ser seguras desde la fase de codificación hasta el despliegue en producción.
Para lograrlo, no sólo los equipos de operaciones deben conocer y/o ser responsables de la seguridad de las aplicaciones de la nube. Los equipos de desarrollo también deberían contribuir a la seguridad de las aplicaciones de la nube e integrar la seguridad desde el principio y durante cada etapa. Para ello, una herramienta de seguridad como el Centro de Seguridad Azure no es apropiada para ser utilizada por los equipos de desarrollo para validar el estado de seguridad de sus aplicaciones antes de pasar a producción.
El Kit de Desarrollo Seguro para Azure (también conocido como AzSK) está ahí para complementar este vacío del Centro de Seguridad Azure.
Microsoft define AzSK como "un conjunto de automatización, extensiones, plugins, plantillas, módulos y otras herramientas que se combinan para ofrecer un flujo de trabajo de desarrollo enfocado en la seguridad para nuestros equipos de ingeniería de DevOps que trabajan en la nube". El objetivo del kit es capacitar a nuestros equipos para construir y utilizar soluciones basadas en Azure de manera consistente, repetible y eficiente con seguridad integrada en cada etapa".
AzSK ha sido desarrollado inicialmente para los equipos internos de Microsoft y liberado después para los usuarios de Azure. No es un producto comercial con soporte de usuario, pero es una solución gratuita para ser usada como tal, sin soporte de Microsoft.
La siguiente figura muestra cómo las 6 principales herramientas del kit de herramientas de DevOps se unen para permitir un desarrollo seguro en la nube.
El Kit de Desarrollo Seguro para el Azul es un marco que permite a los usuarios/clientes del azul:
En este post, aprenderás las capacidades principales del Kit de Desarrollo Seguro para Azure (también conocido como AzSK).
1) Interesados en el Kit de Desarrollo Seguro para Azure (AzSK)
Los principales interesados que pueden utilizar AzSK en un ecosistema de Azure DevOps son los siguientes:
2) Preparando el Kit de Desarrollo Seguro para Azure (AzSK)
La instalación de AzSK es muy sencilla. Consiste en los siguientes pasos sencillos:
Lanzar PowerShell ISE en lugar de la consola estándar de PowerShell
Verifique los prerrequisitos de PowerShell: verifique que PowerShell 5.0 o superior esté instalado con el comando $PSVersionTable
Instale el módulo AzSK PowerShell: Instalar-Módulo AzSK -Scope CurrentUser
El módulo AzSK PowerShell requiere los módulos AzureRM. Si los módulos AzureRM PowerShell no están instalados todavía, se instalarán durante la instalación del AzSK.
AzureRM es un conjunto de módulos de PowerShell que permite a los usuarios de Azure administrar (crear, leer, actualizar, eliminar, etc.) sus recursos de Azure desde PowerShell.
Después de la instalación de AzSK, puede comprobar lo que se ha instalado con el comando Get-InstalledModule de PowerShell de la siguiente manera:
Como puedes ver, para beneficiarte de AzSK, necesitas tener los permisos apropiados de Azure (Azure RBAC), dependiendo de tu papel en el ecosistema de DevOps:
Conclusión
En este artículo, centrado en la introducción del Kit de Desarrollo Seguro para Azure (AzSK), describí las capacidades básicas necesarias para comenzar con AzSK. Aprendiste los siguientes aspectos:
En el próximo artículo, no centraremos en los controles del AzSK y en cómo aprovecharlos para asegurar sus aplicaciones en la nube a lo largo de las etapas de DevOps.
Luego de nuestra charla tuvimos muchas consultas sobre Secure DevOps Kit for Azure en esta serie vamos a tratar de explicar sus principales características.
ASC es muy útil para que los especialistas en Seguridad y Propietarios de cargas de trabajo en la nube monitoreen continuamente la higiene de seguridad de sus cargas de trabajo. Sin embargo, ASC es una herramienta de seguridad central para los recursos ya implementados.
Como sabemos, las aplicaciones en la época de la nube se están desarrollando en métodos ágiles y con la cultura DevOps. Esto significa que las aplicaciones no se implementan una sola vez como en el modo tradicional, sino en varias oleadas (por ejemplo, en sprints). Los equipos de desarrollo y operaciones ya no trabajan en silos, sino que cooperan a lo largo de todo el ciclo de vida de desarrollo de las aplicaciones.
En el contexto de la nube, las aplicaciones se despliegan en modo continuo (Integración continua/entrega continua, también conocida como CICD) y deben ser seguras desde la fase de codificación hasta el despliegue en producción.
Para lograrlo, no sólo los equipos de operaciones deben conocer y/o ser responsables de la seguridad de las aplicaciones de la nube. Los equipos de desarrollo también deberían contribuir a la seguridad de las aplicaciones de la nube e integrar la seguridad desde el principio y durante cada etapa. Para ello, una herramienta de seguridad como el Centro de Seguridad Azure no es apropiada para ser utilizada por los equipos de desarrollo para validar el estado de seguridad de sus aplicaciones antes de pasar a producción.
El Kit de Desarrollo Seguro para Azure (también conocido como AzSK) está ahí para complementar este vacío del Centro de Seguridad Azure.
Microsoft define AzSK como "un conjunto de automatización, extensiones, plugins, plantillas, módulos y otras herramientas que se combinan para ofrecer un flujo de trabajo de desarrollo enfocado en la seguridad para nuestros equipos de ingeniería de DevOps que trabajan en la nube". El objetivo del kit es capacitar a nuestros equipos para construir y utilizar soluciones basadas en Azure de manera consistente, repetible y eficiente con seguridad integrada en cada etapa".
AzSK ha sido desarrollado inicialmente para los equipos internos de Microsoft y liberado después para los usuarios de Azure. No es un producto comercial con soporte de usuario, pero es una solución gratuita para ser usada como tal, sin soporte de Microsoft.
La siguiente figura muestra cómo las 6 principales herramientas del kit de herramientas de DevOps se unen para permitir un desarrollo seguro en la nube.
El Kit de Desarrollo Seguro para el Azul es un marco que permite a los usuarios/clientes del azul:
- Asegurar sus suscripciones
- Asegurar su desarrollo
- Comprobar la seguridad en los oleoductos de Integración Continua/Entrega Continua
- Rastrear la deriva de la seguridad en la producción (Garantía continua)
- Monitorizar la seguridad en todas las etapas de DevOps (Alerta y Monitoreo)
- Riesgos de nubes agregados en toda la empresa (Gobernanza de riesgos de nubes/Telemetría de seguridad)
En este post, aprenderás las capacidades principales del Kit de Desarrollo Seguro para Azure (también conocido como AzSK).
1) Interesados en el Kit de Desarrollo Seguro para Azure (AzSK)
Los principales interesados que pueden utilizar AzSK en un ecosistema de Azure DevOps son los siguientes:
| Partes interesadas | Capacidades relevantes de AzSK |
| Propietarios de suscripciones | Comprueba la salud de la seguridad general de las suscripciones de Azure Asegurarse de que los artefactos como las alertas de actividades importantes, la política de ARM, los bloqueos de recursos, las funciones del RBAC, etc., estén debidamente aprovisionados |
| Equipos de desarrollo o ingeniería | Obtén soporte en línea con consejos de seguridad y correcciones mientras escribes código para aplicaciones Azure Pruebe que los recursos Azure que están usando para las aplicaciones/soluciones están configurados y desplegados de forma segura Habilitar la seguridad en el CICD incluyendo varios ensayos de seguridad en los build/release pipelines |
| Equipos de implementación | Asegurar que una solución que se está desplegando en un entorno azul tiene un nivel de seguridad asegurado. |
| Equipos de operaciones | Rastree el estado de seguridad de una manera 'continua' y asegúrese de que no haya una 'deriva' descendente desde un estado seguro |
| Equipos de cumplimiento | Asegurar que se cumplan varios requisitos de cumplimiento, a menudo difíciles, (por ejemplo, SOX) para las soluciones basadas en el azufre |
| Equipos de seguridad | Usar todo lo anterior dependiendo de su dominio de InfoSec (Arquitecto, Analista, etc.) |
2) Preparando el Kit de Desarrollo Seguro para Azure (AzSK)
La instalación de AzSK es muy sencilla. Consiste en los siguientes pasos sencillos:
Lanzar PowerShell ISE en lugar de la consola estándar de PowerShell
Verifique los prerrequisitos de PowerShell: verifique que PowerShell 5.0 o superior esté instalado con el comando $PSVersionTable
Instale el módulo AzSK PowerShell: Instalar-Módulo AzSK -Scope CurrentUser
El módulo AzSK PowerShell requiere los módulos AzureRM. Si los módulos AzureRM PowerShell no están instalados todavía, se instalarán durante la instalación del AzSK.
AzureRM es un conjunto de módulos de PowerShell que permite a los usuarios de Azure administrar (crear, leer, actualizar, eliminar, etc.) sus recursos de Azure desde PowerShell.
Después de la instalación de AzSK, puede comprobar lo que se ha instalado con el comando Get-InstalledModule de PowerShell de la siguiente manera:
Pueden ver que la última versión de AzSK (3.7.0) al momento de escribir este post ha sido instalada. También está la versión de los módulos dependientes de AzureRM PowerShell que han sido instalados.
El Kit de Desarrollo Seguro para Azure está evolucionando con el tiempo. Se recomienda utilizar siempre la última versión para escanear su entorno Azure para asegurarse de que está aprovechando los últimos controles de seguridad del módulo AzSK.
El módulo AzSK proporciona diferentes capacidades de auto-actualización con respecto a las diferentes etapas de DevOps:
Escaneos Adhoc: si está ejecutando la versión más antigua del escaneo AzSK desde su máquina local, recibirá una advertencia así como las instrucciones necesarias para actualizar el módulo. Puede registrarse para la actualización automática (a partir de la versión AzSK 2.8.x) e ir con la actualización manual ejecutando el siguiente comando: Set-AzSKPolicySettings -AutoUpdate On. Luego, durante la ejecución de cualquier comando de AzSK, si se libera una nueva versión, el flujo de trabajo de actualización automática se inicia automáticamente como sigue:
- El usuario es informado de la disponibilidad de una nueva versión y debe decidir si se actualiza o no. Si el usuario decide actualizarse, el flujo de trabajo de actualización continúa con los siguientes pasos
- Se pide al usuario que guarde su trabajo en todas las sesiones activas de PowerShell incluyendo la actual
- Se solicita al usuario que cierre todas las sesiones activas de PowerShell incluyendo la actual
Escáneres de Aseguramiento Continuo (CA): El módulo AzSK ejecuta los escaneos a través de CA, se actualiza automáticamente. Cada escaneo comprueba inicialmente si se ha lanzado alguna nueva versión y auto actualiza el módulo instalado a la última versión. No se requiere ninguna acción por parte del usuario.
Extensión AzSK CICD: el comportamiento por defecto de la extensión AzSK CICD es ejecutar siempre el escaneo usando el último módulo de AzSK de la galería.
3) Tipos de recursos Azure soportados
AzSK comenzó con el apoyo de sólo unos pocos tipos de recursos de Azure, pero actualmente (versión 3.7.0) soporta más de 35 tipos de recursos de Azure, incluyendo la suscripción.
A diferencia del Centro de Seguridad Azure, que permite monitorear la seguridad de algunos recursos básicos, incluyendo la suscripción, la computación y las aplicaciones, la red y el almacenamiento ya desplegados, AzSK permite a los clientes escanear la seguridad de más recursos Azure en diferentes etapas de DevOps.
Para tener la lista de todos los tipos de recursos de los servicios Azure que actualmente son soportados por su módulo AzSK PowerShell instalado, puede ejecutar el comando Get-AzSKSupportedResourceTypes de la siguiente manera:
Todos estos recursos Azure soportados tienen disponibles las Pruebas de Verificación de Seguridad (SVT) y estas SVT serán invocadas cada vez que se ejecute el comando Get-AzSKAzureServicesSecurityStatus.
Dependiendo de sus necesidades, puede ejecutar las pruebas de verificación de seguridad o los escaneos de todos los recursos de su entorno Azure o sólo de un subconjunto de recursos. Veremos cómo se hace en la siguiente sección o post, usando las capacidades de filtrado de los comandos de AzSK.
4) Comandos AzSK soportados
El actual AzSK (versión 3.7.0) proporciona más de 40 comandos de PowerShell que pueden ser listados con el comando de PowerShell Get-Help AzSK de la siguiente manera:
Como para cualquier cmdlet de PowerShell, puedes obtener los detalles de cada comando de AzSK escribiendo Get-Help <AzSK function/command>.
Por ejemplo, los detalles sobre el comando Get-AzSKSubscriptionSecurityStatus de AzSK se pueden obtener de la siguiente manera:
Es muy importante saber que algunos comandos de AzSK requieren más privilegios en Azure que otros. La siguiente tabla proporciona los permisos necesarios para algunos comandos clave de AzSK:
| Comando | Alias | Descripción | Permiso requerido |
| Get-AzSKAzureServicesSecurityStatus | GRS | Escanea un conjunto de RG (o la suscripción completa) | Lector con suscripción o RG respectivos |
| Get-AzSKContinuousAssurance | GCA | Valida el estado de la cuenta de automatización de Continuous Assurance , incluida la condición de varios artefactos, como la cuenta de almacenamiento, horarios, runbooks, etc. | Lector en suscripción |
| Get-AzSKControlsStatus | GACS | Cmdlet único que combina Get-AzSKSubscriptionSecurityStatus, Get-AzSKAzureServicesSecurityStatus | Unión de permisos |
| Get-AzSKSubscriptionSecurityStatus | GSS | Escanea una suscripción de Azure en busca de mejores prácticas de seguridad y líneas de base de configuración para cosas como alertas, políticas ARM, RBAC, ASC, etc. | Lector en suscripción |
| Get-AzSKInfo | GAI | Ayuda a los usuarios a obtener detalles de varios componentes de AzSK | Lector en suscripción, Colaborador en AzSKRG |
| Install-AzSKContinuousAssurance | ICA | Configura la garantía continua de una suscripción. Esto crea varios artefactos, como el grupo de recursos, la cuenta de almacenamiento y la cuenta de automatización. | Propietario en suscripción |
| Install-AzSKOMSSolution | IOM | Crea e implementa una vista de OMS en una suscripción que tiene un espacio de trabajo de OMS | Lector en suscripción |
| Install-AzSKOrganizationPolicy | IOP | Este comando está destinado a ser utilizado por el equipo central de la Organización para configurar políticas específicas de la Organización | Colaborador en suscripción |
| Remove-AzSKAlerts | RAL | Elimina las alertas configuradas por AzSK | Propietario en suscripción |
| Remove-AzSKARMPolicies | RAP | Elimina la política ARM configurada por AzSK | Propietario en suscripción |
| Remove-AzSKSubscriptionRBAC | RRB | Elimina la configuración RBAC de AzSK. Por defecto, las cuentas centrales "obligatorias" no se eliminan y las cuentas "obsoletas" siempre se eliminan | Propietario en suscripción |
| Remove-AzSKSubscriptionSecurity | RSS | Elimina la configuración realizada a través de Set-AzSKSubscriptionSecurity | Propietario en suscripción |
| Repair-AzSKAzureServicesSecurity | RRS | Soluciona los controles de seguridad para varios recursos de Azure utilizando los scripts de reparación automatizados generados al ejecutar el comando de exploración AzSK "Get-AzSKAzureServicesSecurityStatus" con el indicador '-GenerateFixScript' | Colaborador en suscripción o respectivos RG |
| Repair-AzSKSubscriptionSecurity | RASS | Soluciona los controles relacionados con la seguridad de la suscripción utilizando los scripts de reparación automatizados generados al ejecutar el comando de escaneo AzSK "Get-AzSKSubscriptionSecurityStatus" con el indicador '-GenerateFixScript' | Colaborador en suscripción |
| Set-AzSKAlerts | SAA | "Configura alertas de actividad para la suscripción. Las alertas pueden tener un alcance de suscripción o RG. Esto se llama internamente por Set-AzSKSubscriptionSecurity" | Propietario en suscripción |
| Set-AzSKARMPolicies | SAP | "Configura un conjunto básico de políticas ARM en una suscripción. Esto se llama internamente por Set-AzSKSubscriptionSecurity" | Propietario en suscripción |
| Set-AzSKAzureSecurityCenterPolicies | SSC | Establece políticas de ASC y puntos de contacto de seguridad. | Lector en suscripción |
| Set-AzSKOMSSettings | SOS | Configura AzSK para enviar resultados de escaneo al espacio de trabajo de OMS proporcionado | Lector en suscripción |
| Set-AzSKPolicySettings | SPS | Configura la URL del servidor que utiliza AzSK para descargar controles y configurar JSON. Si no se llama a esto, AzSK se ejecuta en modo 'org-neutral' utilizando una política genérica | Lector en suscripción |
| Set-AzSKSubscriptionRBAC | SRB | Configura RBAC para una suscripción | Propietario en suscripción |
| Set-AzSKSubscriptionSecurity | SSS | Comando maestro que toma entradas combinadas e invoca los comandos de configuración individuales para RBAC, política ARM, Alertas y ASC | Propietario en suscripción |
Como puedes ver, para beneficiarte de AzSK, necesitas tener los permisos apropiados de Azure (Azure RBAC), dependiendo de tu papel en el ecosistema de DevOps:
- Lector en suscripción o grupos de recursos respectivos (RG)
- Controlador en suscripción o en los respectivos RG
- Propietario en suscripción
Conclusión
En este artículo, centrado en la introducción del Kit de Desarrollo Seguro para Azure (AzSK), describí las capacidades básicas necesarias para comenzar con AzSK. Aprendiste los siguientes aspectos:
- Los principales interesados en AzSK
- La guía de configuración del AzSK
- El AzSK apoyó los tipos de recursos de Azure
- Los comandos soportados por AzSK
- Los principales permisos requeridos por el RBAC de Azure para AzSK
En el próximo artículo, no centraremos en los controles del AzSK y en cómo aprovecharlos para asegurar sus aplicaciones en la nube a lo largo de las etapas de DevOps.
Suscribirse a:
Entradas (Atom)















