Permitir que un pod en un clúster de AKS acceda de forma segura a Azure Key Vault sin usar credenciales almacenadas como secretos de cliente o certificados.
→Usar Azure AD Workload Identity. Crear una identidad administrada asignada por el usuario, establecer una credencial de identidad federada entre la cuenta de servicio de K8s y la identidad administrada, y otorgar a la identidad administrada acceso a Key Vault.
Por qué: Workload Identity utiliza la federación OIDC para intercambiar un token de Kubernetes por un token de Azure AD, eliminando completamente la necesidad de almacenar, gestionar o rotar secretos en el clúster.
Referencia↗
Proteger un Azure Key Vault para permitir solo el acceso desde VNets específicas, registrar todas las operaciones y proteger contra la eliminación accidental de claves críticas.
→Configurar el firewall de Key Vault para permitir el acceso desde "Punto de conexión privado y redes seleccionadas". Habilitar el registro de diagnóstico a un espacio de trabajo de Log Analytics. Habilitar tanto Soft Delete como Purge Protection.
Por qué: Soft Delete permite la recuperación de eliminaciones accidentales, pero Purge Protection impide que incluso un usuario privilegiado elimine permanentemente el almacén o su contenido durante el período de retención. Esta combinación es crítica para proteger las claves TDE.
Un Azure App Service necesita autenticarse en Azure SQL Database para recuperar datos, sin almacenar contraseñas de cadenas de conexión en la configuración.
→Habilitar una identidad administrada asignada por el sistema en el App Service. En Azure SQL, crear un usuario contenido mapeado al nombre de la identidad administrada del App Service y otorgarle los roles de base de datos necesarios (por ejemplo, db_datareader).
Por qué: Managed Identity proporciona una identidad para el propio recurso de Azure en Azure AD. Azure gestiona la creación y rotación de credenciales automáticamente, eliminando los secretos almacenados, lo cual es una práctica de seguridad fundamental.
Cifrar discos administrados de máquinas virtuales de Azure en reposo utilizando una clave que su organización controla en Azure Key Vault.
→Crear un recurso de Disk Encryption Set. Configurarlo para usar una clave administrada por el cliente (CMK) de su Azure Key Vault. Asignar el Disk Encryption Set a los discos administrados de la máquina virtual.
Por qué: Esto es Server-Side Encryption (SSE) con CMK, que cifra los datos en la infraestructura de almacenamiento. Es más simple que Azure Disk Encryption (ADE), que utiliza BitLocker/dm-crypt para cifrar datos dentro del sistema operativo invitado y generalmente se usa para discos de sistema operativo y datos juntos.
Asegurar que las imágenes de contenedor almacenadas en Azure Container Registry (ACR) sean escaneadas en busca de vulnerabilidades antes de ser desplegadas.
→Habilitar Microsoft Defender for Containers. Esto escaneará automáticamente las imágenes en ACR cuando se suban, cuando se extraigan y de forma continua en busca de vulnerabilidades recién descubiertas.
Por qué: Esta práctica de seguridad de "shift-left" identifica vulnerabilidades temprano en el pipeline de CI/CD. Defender for Containers proporciona esta capacidad de escaneo de forma nativa dentro del ecosistema de Azure.
Detectar y recibir alertas por posibles ataques de inyección SQL y patrones de acceso anómalos en una Azure SQL Database.
→Habilitar Microsoft Defender for SQL en el servidor SQL lógico. Esto proporciona protección avanzada contra amenazas y evaluación de vulnerabilidades.
Por qué: Defender for SQL es el plan de protección de cargas de trabajo dedicado que utiliza análisis de comportamiento y aprendizaje automático para detectar amenazas como inyección SQL, ataques de fuerza bruta y acceso inusual a datos, que no son visibles para las herramientas a nivel de red.
Restringir una cuenta de almacenamiento a una VNet específica, pero seguir permitiendo que servicios de Microsoft de confianza como Azure Backup accedan a ella.
→En la configuración de red de la cuenta de almacenamiento, seleccionar "Habilitado desde redes virtuales y direcciones IP seleccionadas". Añadir la VNet/subred requerida. Luego, marcar la casilla "Permitir que los servicios de Microsoft de confianza accedan a esta cuenta de almacenamiento".
Por qué: La excepción de servicios de confianza crea una ruta segura para que servicios específicos de Microsoft omitan las reglas del firewall de VNet. Sin ella, los servicios que operan en nombre del usuario (como Backup o Portal) serían bloqueados.
Proteger columnas de datos sensibles específicas (por ejemplo, números de tarjetas de crédito) en una base de datos de Azure SQL, incluso de administradores de bases de datos (DBAs) privilegiados.
→Usar Always Encrypted. El controlador de la aplicación cliente cifra transparentemente los datos antes de enviarlos a la base de datos, y las claves de cifrado nunca se revelan al motor de la base de datos.
Por qué: Transparent Data Encryption (TDE) cifra toda la base de datos en reposo (en disco), pero un DBA con acceso aún puede ver los datos. Always Encrypted proporciona cifrado del lado del cliente, separando a quienes gestionan los datos (DBAs) de quienes pueden verlos.
Procesar datos altamente sensibles en una VM de Azure, asegurando que permanezcan cifrados y protegidos incluso en memoria del hipervisor y los operadores de la nube.
→Desplegar una Azure Confidential VM. Estas VMs utilizan Entornos de Ejecución Confiables (TEEs) basados en hardware como AMD SEV-SNP para crear un espacio de memoria aislado y cifrado.
Por qué: El cifrado estándar de VM (como ADE o SSE) protege los datos en reposo. Confidential Computing es la única tecnología que protege los datos *mientras están en uso* en memoria, proporcionando el más alto nivel de privacidad y aislamiento de datos en la nube.
Un App Service necesita usar un secreto de Key Vault como configuración de aplicación, sin cambiar el código de la aplicación para usar el SDK de Key Vault.
→Habilitar la identidad administrada en el App Service y otorgarle permisos "Get" sobre los secretos en Key Vault. En la configuración del App Service, crear una configuración de aplicación con el valor formateado como una referencia de Key Vault: `@Microsoft.KeyVault(SecretUri=...)`.
Por qué: Esta característica permite que la plataforma de App Service resuelva el valor del secreto en tiempo de ejecución utilizando la identidad administrada. El código de la aplicación simplemente lee una variable de entorno estándar, abstraendo la interacción con Key Vault.
Almacenar datos relacionados con el cumplimiento en Azure Blob Storage en un estado WORM (Write-Once, Read-Many) durante un período de retención de 7 años.
→En el contenedor de almacenamiento, configurar una política de inmutabilidad. Usar una política de retención basada en el tiempo establecida en 7 años y bloquear la política. Una vez bloqueada, los datos no pueden ser modificados o eliminados por nadie hasta que expire el período de retención.
Por qué: Esta característica está específicamente diseñada para cumplir con los requisitos de cumplimiento normativo (por ejemplo, SEC 17a-4). Bloquear la política es el paso crítico que la hace verdaderamente inmutable.
En una aplicación multi-inquilino que utiliza una única base de datos Azure SQL, asegurar que los usuarios de un inquilino solo puedan ver los datos pertenecientes a su propio inquilino.
→Implementar Row-Level Security (RLS). Crear una política de seguridad con una función de predicado que filtre filas basándose en el ID de inquilino del usuario, que se almacena en el contexto de la sesión o en una tabla de búsqueda de usuarios.
Por qué: RLS aplica la lógica de acceso directamente dentro del motor de la base de datos. Esto es más seguro y fiable que implementar el filtrado en la capa de aplicación, ya que no se puede eludir y es transparente para el código de la aplicación.
Proteger máquinas virtuales de Generación 2 contra boot kits y rootkits asegurando la integridad de toda la cadena de arranque desde UEFI hasta el kernel del sistema operativo.
→Aprovisionar la VM con Trusted Launch habilitado. Esto activa Secure Boot, que valida la firma de todos los componentes de arranque, y un Módulo de Plataforma Confiable virtual (vTPM) para arranque medido y atestación.
Por qué: Trusted Launch aborda malware sofisticado de bajo nivel que puede subvertir los controles de seguridad tradicionales a nivel del sistema operativo. Establece una raíz de confianza de hardware para la VM.
