Seguridad para el plano de control de Azure

El término plano de control hace referencia a la administración de los recursos de la suscripción. Estas actividades incluyen la creación, actualización y eliminación de recursos de Azure según lo requiera el equipo técnico.

Azure Resource Manager controla todas las solicitudes del plano de control y aplica las restricciones que especifica mediante el control de acceso basado en rol de Azure (Azure RBAC), Azure Policy y bloqueos. Aplique esas restricciones en función de los requisitos de la organización.

Se recomienda implementar la infraestructura como código e implementar la infraestructura de aplicaciones a través de automatización y de CI/CD con fines de coherencia y auditoría.

Puntos clave

Asignación de roles y permisos

¿La infraestructura de la carga de trabajo está protegida con el control de acceso basado en rol de Azure (RBAC de Azure)?

El control de acceso basado en rol de Azure (RBAC de Azure) proporciona las herramientas necesarias para mantener la separación de los problemas de administración y el acceso a la infraestructura de aplicaciones. Decida quién tiene acceso a los recursos en el nivel pormenorizado y qué pueden hacer con dichos recursos. Por ejemplo:

• Los desarrolladores no pueden tener acceso a la infraestructura de producción.
• Solo el equipo de SecOps puede leer y administrar los secretos de Key Vault.
• Si hay varios equipos, el equipo del proyecto A puede tener acceso y administrar el grupo de recursos A y todos los recursos dentro de él.

Conceda a los roles los permisos adecuados que comienzan con privilegios mínimos y agregue más según sus necesidades operativas. Proporcione instrucciones claras a los equipos técnicos que implementan los permisos. Esta claridad facilita la detección y corrección de los errores humanos, como la asignación de permisos excesivos.

Azure RBAC le ayuda a administrar esa separación. Puede asignar permisos a los usuarios, los grupos y las aplicaciones en un ámbito determinado. El ámbito de una asignación de roles puede ser una suscripción, un grupo de recursos o un único recurso. Para información más detallada, consulte ¿Qué es el control de acceso basado en rol de Azure (RBAC)?.

• Asigne permisos en el grupo de administración en lugar de en las suscripciones individuales para impulsar la coherencia y garantizar la aplicación a futuras suscripciones.
• Tenga en cuenta los roles integrados antes de crear roles personalizados para conceder los permisos adecuados a los recursos y otros objetos.

Por ejemplo, asigne a los equipos de seguridad el permiso Lectores de seguridad, que proporciona el acceso necesario para evaluar los factores de riesgo e identificar posibles mitigaciones sin proporcionar acceso a los datos.

Más información

Documentación de Azure RBAC

Bloqueos de administración

¿Hay bloqueos de recursos aplicados a partes críticas de la infraestructura?

A diferencia del control de acceso basado en rol de Azure, se usan bloqueos de administración para aplicar una restricción a todos los usuarios y roles.

Normalmente, la infraestructura crítica no cambia con frecuencia. Use bloqueos de administración para evitar la eliminación o modificación de un recurso, grupo de recursos o suscripción. Utilice el bloqueo en aquellos casos de uso en los que solo determinados roles y usuarios con permisos deberían poder eliminar o modificar recursos.

Como administrador, puede que tenga que bloquear una suscripción, un grupo de recursos o un recurso para impedir que otros usuarios de su organización eliminen o modifiquen accidentalmente recursos esenciales. Puede establecer el nivel de bloqueo en CanNotDelete o ReadOnly. En el portal, los bloqueos se denominan Delete y Read-only respectivamente:

• CanNotDelete significa que los usuarios autorizados pueden leer y modificar recursos, pero no eliminarlos.
• ReadOnly significa que los usuarios autorizados solo pueden leer recursos, pero no actualizarlos ni eliminarlos. Aplicar este bloqueo es similar a restringir todos los usuarios autorizados a los permisos concedidos por el rol Lector.

Cuando se aplica un bloqueo en un ámbito primario, todos los recursos heredan el mismo bloqueo. Incluso los recursos que agregue posteriormente heredan el bloqueo del elemento primario. El bloqueo más restrictivo de toda la herencia tiene prioridad.

Al diferencia del control de acceso basado en rol, los bloqueos de administración se usan para aplicar una restricción a todos los usuarios y roles. Para información sobre cómo establecer permisos para usuarios y roles, consulte Control de acceso basado en rol de Azure (RBAC de Azure).

Identifique la infraestructura crítica y evalúe la idoneidad del bloqueo de recursos.

Establezca los bloqueos en el proceso DevOps con cuidado, ya que los bloqueos de modificación a veces pueden bloquear la automatización. Para ver ejemplos de estos bloques y consideraciones, consulte Consideraciones antes de aplicar bloqueos.

Acciones sugeridas

• Restrinja el acceso a la infraestructura de la aplicación solo a CI/CD.
• Use directivas de acceso condicional para restringir el acceso a la administración de Microsoft Azure.

Más información

Administración del acceso a la administración de Azure con acceso condicional

Pasos siguientes

Conceda o deniegue el acceso a un sistema al comprobar si el descriptor de acceso tiene los permisos necesarios para realizar la acción solicitada.

Vínculos relacionados

Vuelva al artículo principal: Consideraciones sobre la administración de identidades y acceso de Azure