Protección del entorno de Azure
Ahora que ya sabe cómo controlar los entornos y proteger las canalizaciones de implementación, puede considerar deshabilitar el acceso humano a sus entornos controlados. En esta unidad, aprenderá a estructurar los permisos de los usuarios en entornos de Azure. Esto incluye cómo permitir el acceso en situaciones de emergencia y cómo auditar los cambios que se producen en su propiedad de Azure.
Bloqueo de acceso humano
Al bloquear el acceso humano a los entornos controlados, se asegura de que los cambios accidentales o malintencionados no se puedan omitir en los procesos de revisión e implementación automatizada de su equipo. Si no bloquea el acceso humano, alguien podría eludir sin darse cuenta los controles que ha dedicado tanto tiempo a planear e implementar en todo el repositorio y las canalizaciones.
Sin controles de bloqueo, también es fácil que alguien dañe algo accidentalmente. Por ejemplo, supongamos que un usuario tiene dos copias de Azure Portal abiertas. Una es para un entorno de prueba y la otra para el entorno de producción. Cuando el usuario cambia de una pestaña a otra en el explorador, es fácil que realice cambios accidentalmente en un entorno de producción que en realidad estaban pensados para un entorno de prueba.
Para bloquear el acceso humano, puede usar el control de acceso basado en roles (RBAC) de Azure. En RBAC, se crean asignaciones de roles para definir:
- Qué usuarios, grupos o entidades de servicio pueden tener acceso a un conjunto definido de recursos de Azure (el ámbito).
- Qué pueden hacer esos usuarios, grupos o entidades de servicio cuando acceden a los recursos (el rol).
Azure RBAC proporciona muchos tipos de roles integrados, entre los que se incluyen:
- Lector, que tiene acceso de solo lectura al entorno.
- Colaborador, que puede modificar los recursos.
- Propietario, que puede modificar los recursos y conceder acceso a otros usuarios.
Es importante conceder acceso según el ámbito adecuado. Si su organización sigue la práctica recomendada de usar suscripciones de Azure dedicadas para cada entorno, considere la posibilidad de usar los grupos de administración de Azure para simplificar el ámbito de las asignaciones de roles. Si su organización usa una sola suscripción de Azure para todos los entornos, evite conceder a los usuarios acceso a toda la suscripción, ya que todos los recursos, incluidos los entornos controlados, heredarían ese permiso.
Sugerencia
Las asignaciones de roles son recursos de Azure Resource Manager (ARM). Esto significa que puede configurar las asignaciones de roles RBAC de Azure en código, por ejemplo, mediante Bicep.
Al planear las asignaciones de roles, necesita decidir qué tiene sentido para su organización. Por ejemplo, supongamos que su organización crea suscripciones independientes para cada uno de los entornos. Puede optar por conceder a los administradores y desarrolladores acceso de lector a los entornos controlados. Con ese rol, pueden acceder al entorno de producción dentro de Azure Portal para revisar la configuración de los recursos, ver métricas y registros e investigar problemas o errores sin realizar cambios en el entorno.
Esta es la manera de configurar las asignaciones de roles para los entornos de su empresa de juguetes, tanto para los administradores de Azure como para los desarrolladores que escriben el código y los scripts:
| Nombre del entorno | Nivel de control | Permiso de administrador | Permiso de desarrollador |
|---|---|---|---|
| Desarrollo | Controlado | Lector | Lector |
| Prueba | Controlado | Lector | Lector |
| Ensayo | Controlado | Lector | Lector |
| Producción | Controlado | Lector | Lector |
| Demostración | No controlado | Propietario | Colaborador |
| Pruebas de rendimiento | No controlado | Propietario | None |
| Pruebas de penetración | No controlado | Propietario | None |
| Revisiones de PR | No controlado | Propietario | Propietario |
| Espacios aislados de desarrollo | No controlado | Propietario | Propietario |
Cuando planee las asignaciones de roles, asegúrese de probarlas exhaustivamente. A veces, las operaciones de administración pueden requerir permisos que no son obvios. Dé a los miembros del equipo la oportunidad de probar todo su trabajo diario con los permisos que planea usar. Revise los problemas que experimenten.
Audite las asignaciones de roles periódicamente. Asegúrese de no haber concedido acceso accidentalmente a personas equivocadas o un acceso demasiado amplio.
Acceso al plano de datos
En Azure hay dos tipos de operaciones:
- Las operaciones de plano de control se usan para administrar los recursos de la suscripción.
- Las operaciones de plano de datos se usan para obtener acceso a las características que expone un recurso.
Por ejemplo, se usa una operación de plano de control para crear una cuenta de almacenamiento. Use una operación de plano de datos para conectarse a la cuenta de almacenamiento y acceder a los datos que contiene.
Al bloquear el acceso directo de los usuarios a los recursos de Azure, tenga en cuenta también cómo se aplica esta restricción a las operaciones de plano de datos. Por ejemplo, el proceso de implementación podría almacenar la clave de una cuenta de almacenamiento en un lugar al que pueda acceder un administrador. Dicho administrador podría usar la clave para eludir los controles y acceder directamente al plano de datos de la cuenta de almacenamiento.
Un número creciente de recursos de Azure admite la configuración del control de acceso del plano de datos mediante Microsoft Entra ID. Esta compatibilidad reduce la probabilidad de que filtre claves o conceda acceso al plano de datos sin darse cuenta. Se recomienda usar Microsoft Entra ID para el acceso al plano de datos siempre que sea posible.
Acceso de emergencia
A veces, se producen emergencias y alguien necesita obtener acceso rápidamente a un entorno de producción para investigar o resolver un problema. Es importante planear y ensayar cómo desea responder a estas situaciones de emergencia mucho antes de que se produzcan. No es buena idea ponerse a codificar para solucionar algo en medio de una interrupción.
Un enfoque que puede tener en cuenta es una cuenta de rotura de cristal, que es una cuenta de usuario especial que tiene mayores niveles de permisos que los usuarios normales. Se denomina cuenta de rotura de cristal porque requiere algo inusual para obtener acceso a las credenciales, algo similar a romper el cristal de un panel de alarma de incendios. Puede proporcionar una forma segura para que sus operadores obtengan acceso a las credenciales de la cuenta de rotura de cristal. A continuación, estos operadores podrán iniciar sesión en esa cuenta para realizar cambios de emergencia.
La secuencia de pasos para usar una cuenta de rotura de cristal es la siguiente:
- El usuario intenta realizar un cambio de emergencia con su cuenta normal, pero la operación se bloquea porque la cuenta de usuario normal no tiene permiso suficiente.
- El usuario obtiene acceso a las credenciales de la cuenta de rotura de cristal e inicia sesión como ese usuario.
- El usuario (que actúa como la cuenta de rotura de cristal) tiene permiso para realizar la operación.
El uso de cuentas de rotura de cristal requiere un alto nivel de disciplina. Su uso debe reservarse para situaciones reales de emergencia. Administre y proteja sus credenciales con cuidado, porque que la cuenta tiene muchos privilegios. Es recomendable cambiar las credenciales de las cuentas de rotura de cristal con frecuencia, para minimizar la posibilidad de que se hayan visto expuestas o comprometidas.
Las cuentas de rotura de cristal se comparten a menudo dentro de un equipo, por lo que es difícil localizar quién las ha usado y qué han hecho esos usuarios. Un enfoque alternativo para las cuentas de emergencia es adoptar la característica Microsoft Entra Privileged Identity Management (PIM). Permite conceder temporalmente a la cuenta de un usuario un nivel de permiso más alto.
La secuencia de pasos para usar Privileged Identity Management es la siguiente:
El usuario intenta realizar un cambio de emergencia con su cuenta normal, pero la operación se bloquea porque la cuenta de usuario normal no tiene permisos suficientes.
El usuario se pone en contacto con Privileged Identity Management y solicita una elevación temporal de permisos.
PIM puede realizar una validación adicional de la identidad del usuario o pedir la aprobación de alguien, dependiendo de cómo se configure en la organización.
Si la solicitud está autorizada, Privileged Identity Management actualiza temporalmente los permisos del usuario.
El usuario puede realizar la operación.
Una vez transcurrido el período de tiempo definido, PIM revoca los permisos elevados que ha concedido al usuario.
Tanto PIM como Azure escriben registros de auditoría completos para ayudarlo a comprender quién ha solicitado permisos elevados y por qué. Los registros también hacen un seguimiento de qué hicieron en su entorno cuando se otorgaron esos permisos.
Nota:
PIM requiere una licencia premium para Microsoft Entra ID.
Cuando finalice la emergencia
Una vez finalizada una emergencia, es importante que haya un proceso para volver a las operaciones normales. Debe seguir este proceso antes de que transcurra demasiado tiempo o corre el riesgo de olvidar información importante o dejar la configuración en un estado no seguro.
Revise cuidadosamente los registros de auditoría de Azure y Privileged Identity Management para comprender los cambios realizados en los entornos controlados y, especialmente, en el entorno de producción.
Importante
Alguien que use Privileged Identity Management o una cuenta de rotura de cristal podría tener la oportunidad de conceder a su cuenta de usuario normal un acceso más amplio de lo que debería tener. También puede usar los permisos temporales para obtener acceso a las claves de plano de datos que podrá seguir usando después de revocar los permisos.
Audite cuidadosamente todo el uso de sus cuentas de rotura de cristal o Privileged Identity Management. Revoque o renueve las claves que se hayan visto expuestas durante la emergencia.
Poco después de la emergencia, vuelva a sincronizar los activos de infraestructura como código con los cambios realizados durante la emergencia. Por ejemplo, supongamos que, como parte de la resolución de un problema urgente, un administrador aumentó manualmente la SKU de un plan de Azure App Service. Actualice las plantillas de implementación para incluir la nueva SKU en la configuración de recursos. En caso contrario, durante la siguiente implementación normal de la canalización, la SKU podría restablecerse al valor anterior y provocar otra interrupción.
Auditoría de cambios en el entorno de Azure
También se recomienda configurar la auditoría y el registro en todo el entorno de Azure, así como supervisar eventos o amenazas específicos.
Considere la posibilidad de usar una herramienta de administración de eventos e información de seguridad (SIEM), como Microsoft Sentinel. Puede usar esta herramienta para recopilar y analizar registros de su propiedad de Azure e incluso de Azure DevOps, GitHub y otros sistemas. Puede usar Sentinel para supervisar los cambios inesperados o no autorizados en los recursos de Azure. También puede importar los registros de auditoría de la canalización y activar alertas cuando se produzcan eventos, por ejemplo, cuando un administrador cambia una directiva de protección de ramas en su repositorio.