Autorización con Azure AD

  • Artículo
  • Tiempo de lectura: 7 minutos

No proporcione acceso permanente para las cuentas críticas y reduzca los permisos cuando ya no se necesite el acceso. Entre las estrategias se incluyen:

  • Acceso con privilegios Just-In-Time a Azure AD y a los recursos de Azure.
  • Acceso limitado en el tiempo.
  • Acceso basado en la aprobación.
  • "Rompa el cristal" para que el proceso de acceso de emergencia obtenga acceso.

Limite el acceso de escritura a los sistemas de producción a las entidades de servicio. Ninguna cuenta de usuario debería tener acceso de escritura normal.

Asegúrese de que hay un proceso para deshabilitar o eliminar las cuentas administrativas que no se usen.

Puede utilizar opciones nativas y de terceros para elevar los permisos de acceso al menos a las actividades con privilegios elevados, si no a todas las actividades. Azure AD Privileged Identity Management (Azure AD PIM) es la solución nativa recomendada en Azure.

Para más información sobre Privileged Identity Management, consulte ¿Qué es Azure AD Privileged Identity Management?

Saber más

Establecer la administración del ciclo de vida de las cuentas de impacto crítico

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

La autorización es un proceso que concede o deniega el acceso a un sistema al comprobar si el descriptor de acceso tiene los permisos necesarios para realizar la acción solicitada. El descriptor de acceso en este contexto es la carga de trabajo (aplicación en la nube) o el usuario de la carga de trabajo. La acción puede estar operativa o relacionada con la administración de recursos. Hay dos enfoques principales para la autorización: basada en roles y basada en recursos. Ambas se pueden configurar con Azure AD.

Puntos clave

  • Uso de una combinación de autorización basada en roles y basada en recursos Comience por el principio con privilegios mínimos y agregue más acciones en función de sus necesidades.
  • Defina unas líneas de responsabilidad claras y una separación de las tareas para los roles de aplicación y los recursos que puede administrar. Tenga en cuenta los niveles de acceso de cada función operativa, como los permisos necesarios para publicar la versión de producción, acceder a los datos de cliente y manipular los registros de base de datos.
  • No proporcione acceso permanente para las cuentas críticas. Eleve los permisos de acceso que se basan en la aprobación y están limitados en el tiempo mediante Azure AD Privileged Identity Management (Azure AD PIM).|

Autorización basada en roles

Este enfoque autoriza una acción basada en el rol asignado a un usuario. Por ejemplo, algunas acciones requieren un rol de administrador.

Un rol es un conjunto de permisos. Por ejemplo, el rol de administrador tiene permisos para realizar todas las operaciones de lectura, escritura y eliminación. Además, el rol tiene un ámbito. El ámbito especifica los grupos de administración, las suscripciones o los grupos de recursos en los que el rol puede funcionar.

La aplicación de permisos coherentes a los recursos a través de los grupos de administración o grupos de recursos reduce la proliferación de permisos personalizados y específicos por recurso. Los permisos basados en recursos personalizados a menudo son innecesarios y pueden causar confusión, ya que no llevan su intención a nuevos recursos similares. Este proceso se puede agregar a una configuración heredada compleja que es difícil de mantener o cambiar sin temor a romper algo, lo que afecta negativamente tanto a la seguridad como a la agilidad de la solución.

Al asignar un rol a un usuario, considere qué acciones puede realizar el rol y cuál es el ámbito de esas operaciones. Estas son algunas consideraciones que se deben tener en cuenta para la asignación de roles:

  • Utilice roles integrados antes de crear roles personalizados para conceder los permisos adecuados a las máquinas virtuales y a otros objetos. Puede asignar roles integrados a usuarios, grupos, entidades de servicio e identidades administradas. Para más información, consulte Roles integrados en Azure.

  • Si necesita crear roles personalizados, conceda a los roles la acción adecuada. Las acciones se clasifican en acciones operativas y de datos. Para evitar la asignación de permisos excesivos, comience por las acciones que tienen privilegios mínimos y agregue más según sus necesidades operativas o de acceso a datos. Proporcione instrucciones claras a los equipos técnicos que implementan los permisos. Para más información, consulte Roles personalizados de Azure.

  • Si tiene una estrategia de segmentación, asigne permisos con un ámbito. Por ejemplo, si utiliza el grupo de administración para apoyar su estrategia, establezca el ámbito en el grupo en lugar de en las suscripciones individuales. Esto controlará la coherencia y garantizará su aplicación a suscripciones futuras. Al asignar permisos para un segmento, tenga en cuenta la coherencia y la flexibilidad para acomodar varios modelos organizativos. Estos modelos pueden ir desde un único grupo de TI centralizado hasta equipos de TI y DevOps bastante independientes. Para más información sobre cómo asignar el ámbito, consulte Ámbitos asignables.

  • Puede usar grupos de seguridad para asignar permisos. Sin embargo, existen inconvenientes. Se puede volver complejo porque la carga de trabajo requiere un seguimiento de qué grupos de seguridad corresponden a qué roles de aplicación para cada inquilino. Además, los tokens de acceso pueden crecer de forma significativa, y Azure AD incluye una demanda de "uso por encima del límite" para limitar el tamaño del token. Consulte Tokens de acceso de la Plataforma de identidad de Microsoft.

  • En lugar de conceder permisos a usuarios específicos, asigne acceso a los grupos de Azure AD. Además, cree un modelo de delegación completo que incluya RBAC en grupos de administración, suscripciones o grupos de recursos. Para más información, consulte Control de acceso basado en rol de Azure (Azure RBAC).

Para más información sobre la implementación de la autorización basada en roles en una aplicación ASP.NET, consulte Autorización basada en roles.

Más información

Autorización basada en recursos

Con la autorización basada en roles, un usuario obtiene el mismo nivel de control en un recurso basado en el rol del usuario. Sin embargo, puede haber situaciones en las que necesite definir derechos de acceso por recurso. Por ejemplo, en un grupo de recursos, desea permitir que algunos usuarios eliminen el recurso; otros usuarios no pueden. En tales situaciones, utilice la autorización basada en recursos que autoriza una acción basada en un recurso determinado. Cada recurso tiene un propietario. El propietario puede eliminar el recurso. Los colaboradores pueden leerlo y actualizarlo, pero no pueden eliminarlo.

Nota

Los roles de propietario y colaborador para un recurso no son lo mismo que los roles de aplicación.

Deberá implementar la lógica personalizada para la autorización basada en recursos. Esa lógica puede ser una asignación de recursos, un objeto de Azure AD (como rol, grupo, usuario) y permisos.

Para ver información y un ejemplo de código sobre la implementación de la autorización basada en recursos en una aplicación ASP.NET, consulte Autorización basada en recursos.

Autorización para cuentas críticas

Puede haber casos en los que necesite realizar actividades que requieran acceso a recursos importantes. Es posible que estos recursos ya estén accesibles para cuentas críticas, como una cuenta de administrador. O bien, puede que tenga que elevar los permisos de acceso hasta que se completen las actividades. Ambos enfoques pueden plantear riesgos significativos.

Las cuentas críticas son aquellas que pueden generar un salida crítica para la empresa, y pueden ser administradores en la nube o usuarios con privilegios específicos de la carga de trabajo. Poner en peligro o hacer un uso incorrecto de dicha cuenta puede tener un efecto perjudicial para el material en la empresa y sus sistemas de información. Es importante identificar esas cuentas y adoptar los procesos necesarios, entre los que se incluyen una supervisión estrecha y la administración del ciclo de vida, incluida la retirada.

La protección del acceso con privilegios es un primer paso crítico para establecer controles de seguridad para los recursos empresariales de una organización moderna. La seguridad de la mayoría, si no todos, los recursos empresariales de una organización de TI depende de la integridad de las cuentas con privilegios que realizan tareas de administración, gestión y desarrollo. A menudo, el objetivo de los ciberatacantes son estas cuentas y otros elementos de acceso con privilegios para obtener acceso a datos y sistemas mediante ataques de robo de credenciales como Pass-the-Hash y Pass-the-Ticket.

La protección del acceso con privilegios contra determinados adversarios requiere la adopción de un enfoque completo y meditado para aislar estos sistemas frente a los riesgos.

¿Se ha aprovechado los procesos y las herramientas para administrar las actividades con privilegios?