Procedimientos recomendados para Azure RBAC
En este artículo se describen algunos procedimientos recomendados para usar el control de acceso basado en roles de Azure (Azure RBAC). Estos procedimientos recomendados proceden de nuestra experiencia con Azure RBAC y las experiencias de clientes como usted.
Solo concede el acceso que los usuarios necesitan
Con Azure RBAC, puede repartir las tareas entre el equipo y conceder a los usuarios únicamente el nivel de acceso que necesitan para realizar su trabajo. En lugar de proporcionar a todos los empleados permisos no restringidos en los recursos o la suscripción de Azure, puede permitir solo determinadas acciones en un ámbito concreto.
Al planear la estrategia de control de acceso, es recomendable conceder a los usuarios el privilegio mínimo para que realicen su trabajo. Evite la asignación de roles más amplios en ámbitos más amplios, aunque inicialmente parezca más práctico hacerlo. Al crear roles personalizados, incluya solo los permisos que necesitan los usuarios. Al limitar los roles y los ámbitos, se limitan los recursos en peligro si la entidad de seguridad llegara a verse comprometida.
El siguiente diagrama muestra un patrón sugerido para la asignación de RBAC de Azure.
Para más información sobre la asignación de roles, consulte Asignaciones de roles de Azure mediante Azure Portal.
Limitación del número de propietarios de suscripciones
Debe tener un máximo de 3 propietarios de suscripción para reducir el riesgo de vulneración por parte de un propietario en peligro. Esta recomendación se puede supervisar en Microsoft Defender for Cloud. En el caso de otras recomendaciones de identidad y acceso en Defender for Cloud, consulte Guía de referencia sobre las recomendaciones de seguridad.
Limitar las asignaciones de roles de administrador con privilegios
Algunos roles se identifican como roles de administrador con privilegios. Considere la posibilidad de realizar las siguientes acciones para mejorar la posición de seguridad:
- Quite las asignaciones de roles con privilegios innecesarias.
- Evite asignar un rol de administrador con privilegios cuando se pueda usar en su lugar un rol de función de trabajo.
- Si debe asignar un rol de administrador con privilegios, use un ámbito estrecho, como el grupo de recursos o el recurso, en lugar de un ámbito más amplio, como el grupo de administración o la suscripción.
- Si va a asignar un rol con permiso para crear asignaciones de roles, considere la posibilidad de agregar una condición para restringir la asignación de roles. Para más información, consulte Delegación de la administración de asignaciones de roles de Azure a otros usuarios con condiciones.
Para obtener más información, consulte Enumerar o administrar asignaciones de roles de administrador con privilegios.
Uso de Microsoft Entra Privileged Identity Management
Para proteger las cuentas con privilegios frente a ataques cibernéticos malintencionados, puede usar Microsoft Entra Privileged Identity Management (PIM) para reducir el tiempo de exposición de los privilegios y aumentar la visibilidad de su uso a través de informes y alertas. PIM ayuda a proteger las cuentas con privilegios al proporcionar acceso con privilegios Just-In-Time al identificador de Microsoft Entra y a los recursos de Azure. El acceso puede estar limitado por el tiempo, después del cual los privilegios se revocan automáticamente.
Para obtener más información, consulte ¿Qué es Microsoft Entra Privileged Identity Management?.
Asignación de roles a grupos, no a usuarios
Para que las asignaciones de roles sean más fáciles de administrar, evite la asignación directa de roles a los usuarios. En su lugar, asigne roles a grupos. La asignación de roles a grupos en lugar de a usuarios también ayuda a minimizar el número de asignaciones de roles, que tiene un límite de asignaciones de roles por suscripción.
Asignación de roles con el identificador de rol único en lugar del nombre del rol
Hay un par de veces en las que el nombre de un rol puede cambiar, por ejemplo:
- Utiliza su propio rol personalizado y decide cambiar el nombre.
- Utiliza una rol de versión preliminar que tiene (Versión preliminar) en el nombre. Cuando se libera el rol, se cambia su nombre.
Incluso si se cambia el nombre de un rol, su identificador no cambia. Si utiliza scripts o automatización para crear las asignaciones de roles, se recomienda utilizar el identificador de rol único en lugar del nombre del rol. Por tanto, si se cambia el nombre de un rol, es más probable que los scripts funcionen.
Para obtener más información, vea Asignación de un rol con el identificador de rol único y Azure PowerShell y Asignación de un rol con el identificador de rol único y la CLI de Azure.
Evitar el uso de un carácter comodín al crear roles personalizados
Al crear roles personalizados, puede usar el carácter comodín (*) para definir permisos. Se recomienda especificar Actions y DataActions explícitamente en lugar de usar el carácter comodín (*). El acceso adicional y los permisos concedidos a través del futuro Actions o DataActions podrían ser comportamientos no deseados mediante el carácter comodín. Para más información, consulte Roles personalizados de Azure.