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