Pide tu presupuesto ya!

Automatice el cumplimiento de SOC 2 con PowerShell

Las auditorías SOC 2 pueden parecer una búsqueda del tesoro recurrente. Alguien solicita pruebas de que los recursos de la nube están etiquetados, el registro está habilitado, el almacenamiento está restringido y se están revisando los hallazgos de seguridad. Luego, el equipo de TI comienza a tomar capturas de pantalla del portal y a exportar archivos CSV únicos.

Ese enfoque funciona hasta que su presencia en Azure crece, su auditor solicita una muestra más grande o el propietario del control cambia de trabajo. Un mejor enfoque es tratar la evidencia de cumplimiento como cualquier otro artefacto operativo: definir el control, aplicarlo cuando sea posible, recopilar evidencia según un cronograma y mantener el resultado en un formato repetible.

En este tutorial, utilizará PowerShell, Azure Policy as Code y datos de cumplimiento de Azure para crear un flujo de trabajo práctico de automatización de cumplimiento de SOC 2 para Azure. No “será compatible con SOC 2” ejecutando un script. SOC 2 se basa en los Criterios de servicios de confianza de AICPA y requiere criterio del auditor, evidencia de procesos y controles organizacionales. Pero se puede automatizar una gran parte del trabajo de gobernanza y recopilación de evidencia en la nube que respalda esos controles.

Requisitos previos

Para seguir adelante, necesitará lo siguiente:

  • Una suscripción de Azure donde puede leer recursos y asignar Azure Policy.

  • PowerShell 7 o Windows PowerShell con el módulo Az PowerShell instalado.

  • Permiso para crear definiciones de políticas y asignaciones en el ámbito de suscripción o grupo de administración.

  • Una carpeta donde puede almacenar políticas como archivos de código y auditar las exportaciones.

Instale el módulo Az si aún no lo tiene.

Install-Module -Name Az -Repository PSGallery -Scope CurrentUser -Force
Import-Module Az
Connect-AzAccount

Después de iniciar sesión, configure la suscripción con la que desea trabajar.

$SubscriptionId = '00000000-0000-0000-0000-000000000000'
Set-AzContext -SubscriptionId $SubscriptionId

Reemplace el identificador de suscripción del marcador de posición con su propio identificador de suscripción de Azure antes de ejecutar cualquier ejemplo.

Asignación de controles SOC 2 a evidencia de Azure

Antes de escribir un guión, decida qué pruebas va a recopilar. Los informes SOC 2 se organizan en torno a criterios de servicios de confianza, como seguridad, disponibilidad, confidencialidad, integridad del procesamiento y privacidad. Azure no conocerá el texto de su control, pero puede proporcionar evidencia de muchas actividades de control centradas en la nube.

Por ejemplo, un mapa de evidencia práctica podría verse así:

Área de control SOC 2 Pruebas de Azure para recopilar
Gestión del cambio Definiciones y asignaciones de Azure Policy almacenadas en el control de código fuente
Inventario de activos Recursos de Azure etiquetados con propietario, entorno y clasificación de datos
Monitoreo de seguridad Puntaje seguro y recomendaciones de Microsoft Defender for Cloud
Gobernanza de la configuración Estado de cumplimiento de Azure Policy por recurso
Pista de auditoría Registros de actividad y archivos CSV de cumplimiento exportados

Empiece poco a poco. Elija de tres a cinco controles que produzcan pruebas claras de Azure. En este tutorial, aplicará el etiquetado, recopilará el estado de cumplimiento de Azure Policy y exportará datos de postura de seguridad de Defender for Cloud.

Crear una política como carpeta de código

Azure Policy como código significa que las definiciones, asignaciones y parámetros de sus políticas residen en archivos en lugar de crearse manualmente en el portal. La documentación de Azure Policy de Microsoft describe definiciones, iniciativas y asignaciones de políticas como los objetos principales utilizados para implementar la gobernanza.

Cree una estructura de repositorio simple.

New-Item -ItemType Directory -Path .\soc2-policy\definitions -Force
New-Item -ItemType Directory -Path .\soc2-policy\assignments -Force
New-Item -ItemType Directory -Path .\soc2-evidence -Force

Puede mantener esta carpeta en Git para que cada cambio de política tenga una solicitud de extracción, un revisor y un historial. Esa historia se convierte por sí sola en evidencia de la gestión del cambio.

Escribir una política de etiquetas requerida

Las etiquetas no son glamorosas, pero facilitan mucho la recopilación de pruebas. Si cada recurso de producción tiene una etiqueta de propietario, entorno y clasificación de datos, puede determinar el alcance de los informes por sistema y propietario del control.

Crea un archivo llamado .\soc2-policy\definitions\require-soc2-tags.json con la siguiente definición de política.

{
  "properties": {
    "displayName": "SOC 2 - Require owner, environment, and data classification tags",
    "policyType": "Custom",
    "mode": "Indexed",
    "description": "Audits resources missing required SOC 2 evidence tags.",
    "metadata": {
      "category": "SOC 2"
    },
    "parameters": {
      "effect": {
        "type": "String",
        "metadata": {
          "displayName": "Effect"
        },
        "allowedValues": [
          "Audit",
          "Deny",
          "Disabled"
        ],
        "defaultValue": "Audit"
      }
    },
    "policyRule": {
      "if": {
        "anyOf": [
          { "field": "tags['owner']", "exists": "false" },
          { "field": "tags['environment']", "exists": "false" },
          { "field": "tags['dataClassification']", "exists": "false" }
        ]
      },
      "then": {
        "effect": "[parameters('effect')]"
      }
    }
  }
}

Esta política utiliza Auditoría como efecto predeterminado. El modo de auditoría es un buen punto de partida porque puede medir la desviación antes de bloquear las implementaciones. Una vez que los equipos comprendan el requisito, puede asignar la misma política con Denegar para alcances de producción.

Publique la definición de política en Azure.

$PolicyDefinition = New-AzPolicyDefinition `
  -Name 'soc2-require-evidence-tags' `
  -DisplayName 'SOC 2 - Require evidence tags' `
  -Policy '.\soc2-policy\definitions\require-soc2-tags.json' `
  -Mode Indexed

Asigne la política a la suscripción actual.

$Scope = "/subscriptions/$SubscriptionId"

New-AzPolicyAssignment `
  -Name 'soc2-require-evidence-tags' `
  -DisplayName 'SOC 2 - Require evidence tags' `
  -Scope $Scope `
  -PolicyDefinition $PolicyDefinition

Asignación de Azure Policy para etiquetas SOC 2 requeridas

Recopilación de pruebas de cumplimiento de políticas de Azure

Ahora viene la parte más fácil de auditar: recopilar evidencia con PowerShell. El Get-AzPolicyState El cmdlet devuelve estados de cumplimiento de políticas para los recursos. Puede consultar el estado más reciente, filtrar recursos no conformes, seleccionar campos y exportar los resultados.

Crea un script llamado Exportar-Soc2PolicyEvidence.ps1.

param(
    [Parameter(Mandatory)]
    [string]$SubscriptionId,

    [string]$OutputFolder=".\soc2-evidence"
)

$ErrorActionPreference="Stop"

Set-AzContext -SubscriptionId $SubscriptionId | Out-Null
New-Item -ItemType Directory -Path $OutputFolder -Force | Out-Null

$Timestamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$PolicyCsv = Join-Path $OutputFolder "policy-compliance-$Timestamp.csv"

Get-AzPolicyState `
    -SubscriptionId $SubscriptionId `
    -Filter "ComplianceState eq 'NonCompliant'" `
    -Select 'Timestamp,ResourceId,PolicyAssignmentName,PolicyDefinitionName,ComplianceState' |
    Export-Csv -Path $PolicyCsv -NoTypeInformation

Write-Output "Policy evidence exported to $PolicyCsv"

Ejecute el script.

.\Export-Soc2PolicyEvidence.ps1 -SubscriptionId $SubscriptionId

Abra el CSV y tendrá una lista repetible de recursos que no cumplen con los requisitos en un momento dado. Ese resultado es mucho más útil que una captura de pantalla porque puede diferenciarlo a lo largo de semanas, enviarlo a los propietarios de recursos y probar las tendencias de corrección.

Exportación CSV que muestra recursos de Azure Policy no compatibles

Agregar evidencia de puntuación segura de Defender for Cloud

Azure Policy le indica si los recursos cumplen con las reglas de gobernanza asignadas. Microsoft Defender para la nube agrega contexto de postura de seguridad, incluida información de puntuación segura y vistas de cumplimiento normativo.

Utilice el cmdlet Az.Security Get-AzSecuritySecureScore para exportar datos de puntuación seguros para la suscripción. JSON es un buen formato aquí porque los objetos de puntuación seguros pueden incluir datos de resultados anidados.

$Timestamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$SecureScoreJson = ".\soc2-evidence\secure-score-$Timestamp.json"

Get-AzSecuritySecureScore |
    ConvertTo-Json -Depth 10 |
    Out-File -FilePath $SecureScoreJson -Encoding utf8

La puntuación segura no es un control SOC 2 en sí misma. Trátelo como evidencia de respaldo para su postura de seguridad de Azure, especialmente en lo que respecta a la gestión de vulnerabilidades, el monitoreo de la configuración y la mejora continua.

Resumen de puntuación segura de Microsoft Defender para la nube

Creación de un script de exportación de pruebas únicas

Una vez que las piezas individuales funcionen, combínelas en un guión programado. El siguiente ejemplo exporta evidencia de incumplimiento de políticas y puntuación segura a una carpeta con fecha.

param(
    [Parameter(Mandatory)]
    [string]$SubscriptionId,

    [string]$EvidenceRoot=".\soc2-evidence"
)

$ErrorActionPreference="Stop"

Set-AzContext -SubscriptionId $SubscriptionId | Out-Null

$RunStamp = Get-Date -Format 'yyyyMMdd-HHmmss'
$RunFolder = Join-Path $EvidenceRoot $RunStamp
New-Item -ItemType Directory -Path $RunFolder -Force | Out-Null

$PolicyPath = Join-Path $RunFolder 'azure-policy-noncompliance.csv'
$SecureScorePath = Join-Path $RunFolder 'defender-secure-score.json'

Get-AzPolicyState `
    -SubscriptionId $SubscriptionId `
    -Filter "ComplianceState eq 'NonCompliant'" `
    -Select 'Timestamp,ResourceId,PolicyAssignmentName,PolicyDefinitionName,ComplianceState' |
    Export-Csv -Path $PolicyPath -NoTypeInformation

Get-AzSecuritySecureScore |
    ConvertTo-Json -Depth 10 |
    Out-File -FilePath $SecureScorePath -Encoding utf8

[pscustomobject]@{
    SubscriptionId = $SubscriptionId
    EvidenceRun    = $RunStamp
    PolicyEvidence = $PolicyPath
    SecureScore    = $SecureScorePath
} | ConvertTo-Json | Out-File -FilePath (Join-Path $RunFolder 'manifest.json') -Encoding utf8

Write-Output "SOC 2 evidence exported to $RunFolder"

Un archivo de manifiesto es una adición pequeña pero útil. Proporciona a los auditores y revisores internos un punto de partida predecible para cada ejecución de evidencia.

Programación de la recopilación de pruebas

Puede ejecutar el script manualmente durante la preparación de la auditoría, pero el valor real proviene de programarlo. En producción, ejecute la exportación desde un host de automatización seguro, una cuenta de Azure Automation, un flujo de trabajo de GitHub Actions o un ejecutor de CI/CD mediante una identidad administrada o una entidad de servicio con los permisos mínimos necesarios.

Un cronograma práctico es semanal para el monitoreo normal y diario durante los períodos de remediación de auditoría. Almacene las exportaciones en una ubicación protegida, como una cuenta de almacenamiento privada, una biblioteca de SharePoint restringida o un repositorio de evidencia. Mantenga la retención alineada con su período de auditoría y la política de su empresa.

No otorgue a la identidad de automatización amplios derechos de propietario sólo porque sea conveniente. Para la recopilación de pruebas, normalmente son suficientes los permisos de lectura y el acceso a información sobre políticas. Para la implementación de políticas, utilice una identidad de implementación independiente con aprobaciones estrictamente controladas.

Hacer que los resultados sean fáciles de entender para los auditores

La automatización puede producir demasiados datos. Su trabajo es hacer que la evidencia sea fácil de revisar.

Para cada análisis de evidencia, incluya:

  • La versión del script o confirmación de Git que produjo la exportación.

  • El ámbito de la suscripción de Azure o del grupo de administración.

  • La fecha y hora de recogida.

  • Exportaciones CSV para los datos sin procesar.

  • Un breve resumen de excepciones abiertas y propietarios asignados.

Si su política de etiquetas requerida encuentra 200 recursos que no cumplen, no entierre el resultado en una carpeta y dé por terminado. Cree un flujo de trabajo de corrección. Asigne cada recurso al propietario etiquetado cuando sea posible, realice un seguimiento de la excepción y vuelva a ejecutar el informe después de la corrección.

Errores comunes

Evite estos errores al automatizar la evidencia de cumplimiento de SOC 2:

  • Tratar a la automatización como propietaria del control. Un guión recopila pruebas. La gente todavía es dueña del diseño, la revisión y la corrección del control.

  • Saltarse el control de fuente. Si las políticas se editan solo en el portal, se pierde el historial de revisión y se modifican las pruebas.

  • Exportando secretos. Revise cada exportación antes de almacenarla en un depósito de evidencia de auditoría.

  • Utilizando una gigantesca iniciativa política desde el primer día. Comience con controles de alta confianza y luego amplíelos.

  • Ignorando excepciones. Una excepción sin propietario, motivo, aprobación y fecha de vencimiento es la deuda de auditoría.

Conclusión

La automatización del cumplimiento de SOC 2 no se trata de reemplazar a los auditores o convertir un marco en un script de casilla de verificación. Se trata de hacer que su entorno Azure sea continuamente mensurable. PowerShell le brinda una forma repetible de recopilar evidencia, Azure Policy as Code le brinda gobernanza versionada y Defender for Cloud lo ayuda a monitorear la postura de seguridad de Azure.

Comience con un control, como las etiquetas de evidencia requeridas. Almacene la política en Git, asígnela en modo auditoría, exporte el incumplimiento de Get-AzPolicyStatey revise el CSV según un cronograma. Una vez que se confíe en ese flujo de trabajo, agregue más políticas, proteja las exportaciones de puntajes y genere informes de remediación.

Las listas de verificación de auditoría manuales siempre tendrán un lugar, pero no deberían ser su primera fuente de información. Deje que Azure y PowerShell hagan el trabajo repetitivo para que su equipo pueda concentrarse en corregir los hallazgos.

Fuentes

  • https://learn.microsoft.com/en-us/azure/governance/policy/overview

  • https://learn.microsoft.com/en-us/azure/governance/policy/concepts/policy-as-code

  • https://learn.microsoft.com/en-us/powershell/module/az.policyinsights/get-azpolicystate

  • https://learn.microsoft.com/en-us/powershell/module/az.security/get-azsecuritysecurescore

  • https://learn.microsoft.com/en-us/azure/defender-for-cloud/regulatory-compliance-dashboard

  • https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/tag-resources

  • https://learn.microsoft.com/en-us/powershell/azure/install-azure-powershell

  • https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services

Written by

Leave a comment