Recomendaciones para la administración de identidades y acceso

  • Artículo

Se aplica a esta recomendación de lista de comprobación de seguridad de Azure Well-Architected Framework:

SE:05 Implemente la administración estricta, condicional y auditable de identidades y acceso (IAM) en todos los usuarios de carga de trabajo, miembros del equipo y componentes del sistema. Limite el acceso exclusivamente a según sea necesario. Use estándares modernos del sector para todas las implementaciones de autenticación y autorización. Restrinja y audite rigurosamente el acceso que no se basa en la identidad.

En esta guía se describen las recomendaciones para autenticar y autorizar identidades que intentan acceder a los recursos de la carga de trabajo.

Desde una perspectiva de control técnico, la identidad siempre es el perímetro principal. Este ámbito no solo incluye los bordes de la carga de trabajo. También incluye componentes individuales que están dentro de la carga de trabajo. Las identidades típicas incluyen:

  • Humanos. Usuarios de aplicaciones, administradores, operadores, auditores y actores incorrectos.

  • Sistemas. Identidades de carga de trabajo, identidades administradas, claves de API, entidades de servicio y recursos de Azure.

  • Anónimo. Entidades que no han proporcionado ninguna evidencia sobre quiénes son.

Definiciones 

Términos Definición
Autenticación (AuthN) Proceso que comprueba que una identidad es quién o lo que dice que es.
Autorización (AuthZ) Proceso que comprueba si una identidad tiene permiso para realizar una acción solicitada.
Acceso condicional Conjunto de reglas que permite acciones basadas en criterios especificados.
IdP Un proveedor de identidades, como Microsoft Entra id.
Persona Función de trabajo o título que tiene un conjunto de responsabilidades y acciones.
Claves previamente compartidas Tipo de secreto que se comparte entre un proveedor y un consumidor y se usa a través de un mecanismo seguro y acordado.
Identidad del recurso Una identidad definida para los recursos en la nube administrados por la plataforma.
Rol Conjunto de permisos que definen lo que un usuario o grupo puede hacer.
Ámbito Diferentes niveles de jerarquía organizativa en los que un rol puede funcionar. También un grupo de características en un sistema.
Entidad de seguridad Una identidad que proporciona permisos. Puede ser un usuario, un grupo o una entidad de servicio. Los miembros del grupo obtienen el mismo nivel de acceso.
Identidad del usuario Una identidad para una persona, como un empleado o un usuario externo.
Identidad de carga de trabajo Una identidad del sistema para una aplicación, servicio, script, contenedor u otro componente de una carga de trabajo que se usa para autenticarse en otros servicios y recursos.

Nota

Una identidad se puede agrupar con otras identidades similares en un elemento primario denominado entidad de seguridad. Un grupo de seguridad es un ejemplo de una entidad de seguridad. Esta relación jerárquica simplifica el mantenimiento y mejora la coherencia. Dado que los atributos de identidad no se controlan en el nivel individual, también se reducen las posibilidades de errores. En este artículo, el término identidad es inclusiva de las entidades de seguridad.

El rol de un proveedor de identidades

Un proveedor de identidades (IdP) es un servicio hospedado en la nube que almacena y administra a los usuarios como identidades digitales.

Aproveche las funcionalidades proporcionadas por un IdP de confianza para la administración de identidades y acceso. No implemente sistemas personalizados para reemplazar un IdP. Los sistemas IdP se mejoran con frecuencia en función de los vectores de ataque más recientes mediante la captura de miles de millones de señales en varios inquilinos cada día. Microsoft Entra id. es el IdP para la plataforma en la nube de Azure.

Autenticación

La autenticación es un proceso que comprueba las identidades. La identidad solicitante es necesaria para proporcionar alguna forma de identificación verificable. Por ejemplo:

  • Un nombre de usuario y una contraseña.

  • Un secreto previamente compartido, como una clave de API que concede acceso.

  • Un token de firma de acceso compartido (SAS).

  • Certificado que se usa en la autenticación mutua tls.

Tanto como sea posible, el idP debe controlar el proceso de verificación.

Authorization

La autorización es un proceso que permite o deniega las acciones solicitadas por la identidad comprobada. La acción puede estar operativa o relacionada con la administración de recursos.

La autorización requiere que asigne permisos a las identidades, que debe hacer mediante la funcionalidad proporcionada por el IdP.

Estrategias de diseño principales

Para obtener una vista holística de las necesidades de identidad de una carga de trabajo, debe catalogar los flujos, los recursos de carga de trabajo y los roles, y las acciones que realizarán los recursos y los roles. La estrategia debe cubrir todos los casos de uso que controlan los flujos que llegan a la carga de trabajo o a sus componentes (acceso externo) y los flujos que llegan desde la carga de trabajo a otros orígenes (acceso dentro del exterior).

Cada caso de uso probablemente tendrá su propio conjunto de controles que necesita para diseñar con una mentalidad de supuesto incumplimiento. En función de los requisitos de identidad del caso de uso o de los roles, identifique las opciones condicionales. Evite usar una solución para todos los casos de uso. Por el contrario, los controles no deben ser tan granulares que introduzca una sobrecarga de administración innecesaria.

Debe registrar la ruta de acceso a la identidad. Esto ayuda a validar los controles y puede usar los registros para las auditorías de cumplimiento.

Determinación de todas las identidades para la autenticación

  • Acceso de fuera hacia dentro. El diseño de identidad debe autenticar a todos los usuarios que accedan a la carga de trabajo con diversos fines. Por ejemplo, un usuario final que accede a la aplicación mediante una llamada a las API.

    En un nivel pormenorizados, es posible que los componentes de la carga de trabajo también necesiten acceso desde fuera. Por ejemplo, un operador que necesita acceso a través del portal o acceso al proceso para ejecutar comandos.

    Ambos son ejemplos de identidades de usuario que tienen diferentes roles.

  • Acceso de dentro hacia fuera. La aplicación tendrá que acceder a otros recursos. Por ejemplo, leer o escribir en la plataforma de datos, recuperar secretos del almacén de secretos y registrar telemetría en los servicios de supervisión. Incluso podría necesitar acceder a servicios de terceros. Estas necesidades de acceso requieren identidad de carga de trabajo, lo que permite que la aplicación se autentique en los demás recursos.

    El concepto se aplica en el nivel de componente. En el ejemplo siguiente, el contenedor podría necesitar acceso a las canalizaciones de implementación para obtener su configuración. Estas necesidades de acceso requieren identidad de recursos.

El IdP debe autenticar todas estas identidades.

Este es un ejemplo de cómo se puede implementar la identidad en una arquitectura:

Diagrama que muestra cómo se puede implementar la identidad en una arquitectura.

Determinación de acciones para la autorización

A continuación, debe saber qué está intentando hacer cada identidad autenticada para que esas acciones se puedan autorizar. Las acciones se pueden dividir por el tipo de acceso que requieren:

  • Acceso al plano de datos. Las acciones que tienen lugar en el plano de datos provocan la transferencia de datos para el acceso dentro o fuera. Por ejemplo, una aplicación que lee datos de una base de datos y escribe datos en una base de datos, captura secretos o escribe registros en un receptor de supervisión. En el nivel de componente, el proceso que extrae o inserta imágenes hacia o desde un registro se considera operaciones del plano de datos.

  • Acceso al plano de control. Las acciones que tienen lugar en el plano de control hacen que se cree, modifique o elimine un recurso de Azure. Por ejemplo, los cambios en las propiedades de los recursos.

Las aplicaciones suelen tener como destino las operaciones del plano de datos, mientras que las operaciones suelen tener acceso tanto al control como a los planos de datos. Para identificar las necesidades de autorización, tenga en cuenta las acciones operativas que se pueden realizar en el recurso. Para obtener información sobre las acciones permitidas para cada recurso, consulte Operaciones del proveedor de recursos de Azure.

Proporcionar autorización basada en roles

En función de la responsabilidad de cada identidad, autorice las acciones que se deben permitir. No se debe permitir que una identidad haga más de lo que necesita. Antes de establecer reglas de autorización, debe tener un conocimiento claro de quién o qué está realizando solicitudes, qué rol puede hacer y en qué medida puede hacerlo. Esos factores conducen a opciones que combinan identidad, rol y ámbito.

Considere una identidad de carga de trabajo como ejemplo. La aplicación debe tener acceso al plano de datos a la base de datos, por lo que se deben permitir acciones de lectura y escritura en el recurso de datos. Sin embargo, ¿la aplicación necesita acceso del plano de control al almacén de secretos? Si la identidad de la carga de trabajo se ve comprometida por un actor incorrecto, ¿cuál sería el impacto en el sistema, en términos de confidencialidad, integridad y disponibilidad?

Asignación de roles

Un rol es un conjunto de permisos asignados a una identidad. Asigne roles que solo permitan que la identidad complete la tarea y no más. Cuando los permisos del usuario están restringidos a sus requisitos de trabajo, es más fácil identificar comportamientos sospechosos o no autorizados en el sistema.

Formule preguntas como estas:

  • ¿El acceso de solo lectura es suficiente?
  • ¿La identidad necesita permisos para eliminar recursos?

Limitar el nivel de acceso que los usuarios, las aplicaciones o los servicios tienen a los recursos de Azure reducen la posible superficie expuesta a ataques. Si concede solo los permisos mínimos necesarios para realizar tareas específicas, se reduce significativamente el riesgo de un ataque correcto o acceso no autorizado. Por ejemplo, los equipos de seguridad solo necesitan acceso de solo lectura a los atributos de seguridad para todos los entornos técnicos. Ese nivel es suficiente para evaluar los factores de riesgo, identificar posibles mitigaciones e informar sobre los riesgos.

Hay escenarios en los que los usuarios necesitan más acceso debido a la estructura organizativa y a la organización del equipo. Es posible que haya una superposición entre varios roles o que los usuarios individuales puedan realizar varios roles estándar. En este caso, use varias asignaciones de roles basadas en la función empresarial en lugar de crear un rol personalizado para cada uno de estos usuarios. Al hacerlo, los roles son más fáciles de administrar.

Evite permisos que hagan referencia específicamente a usuarios o recursos individuales. Los permisos granulares y personalizados crean complejidad y confusión porque no pasan la intención a los nuevos recursos similares. Esto puede crear una configuración heredada compleja que sea difícil de mantener y afectar negativamente tanto a la seguridad como a la confiabilidad.

Compensación: un enfoque de control de acceso granular permite una mejor auditoría y supervisión de las actividades del usuario.

Un rol también tiene un ámbito asociado. El rol puede funcionar en el grupo de administración, la suscripción, el grupo de recursos o el ámbito de recursos permitidos, o en otro ámbito personalizado. Incluso si la identidad tiene un conjunto limitado de permisos, ampliar el ámbito para incluir recursos que están fuera de la función de trabajo de la identidad es arriesgado. Por ejemplo, el acceso de lectura a todo el código fuente y los datos puede ser peligroso y debe controlarse.

Puede asignar roles a identidades mediante el control de acceso basado en rol (RBAC). Use siempre RBAC proporcionado por IdP para aprovechar las características que le permiten aplicar el control de acceso de forma coherente y revocarlo rigurosamente.

Use roles integrados. Están diseñados para cubrir la mayoría de los casos de uso. Los roles personalizados son eficaces y a veces útiles, pero debe reservarlos para escenarios en los que los roles integrados no funcionarán. La personalización conduce a la complejidad que aumenta la confusión y hace que la automatización sea más compleja, desafiante y frágil. Todos estos factores afectan negativamente a la seguridad.

Conceda roles que comiencen con privilegios mínimos y agreguen más en función de sus necesidades operativas o de acceso a datos. Los equipos técnicos deben tener instrucciones claras para implementar permisos.

Si desea un control específico sobre RBAC, agregue condiciones en la asignación de roles en función del contexto, como acciones y atributos.

Tomar decisiones de acceso condicional

No asigne a todas las identidades el mismo nivel de acceso. Base sus decisiones sobre dos factores principales:

  • Hora. Cuánto tiempo puede acceder la identidad a su entorno.

  • Privilegio. Nivel de permisos.

Esos factores no son mutuamente excluyentes. Una identidad comprometida que tiene más privilegios y una duración ilimitada del acceso puede obtener más control sobre el sistema y los datos o usar ese acceso para seguir modificando el entorno. Restrinja esos factores de acceso como medida preventiva y controle el radio de explosión.

  • Los enfoques Just-In-Time (JIT) proporcionan los privilegios necesarios solo cuando son necesarios.

  • Just Enough Access (JEA) proporciona solo los privilegios necesarios.

Aunque el tiempo y los privilegios son los factores principales, existen otras condiciones que se aplican. Por ejemplo, también puede usar el dispositivo, la red y la ubicación desde los que se originó el acceso para establecer directivas.

Use controles seguros que filtren, detecten y bloqueen el acceso no autorizado, incluidos parámetros como la identidad y la ubicación del usuario, el estado del dispositivo, el contexto de la carga de trabajo, la clasificación de datos y las anomalías.

Por ejemplo, es posible que sea necesario tener acceso a la carga de trabajo mediante identidades de terceros, como proveedores, asociados y clientes. Necesitan el nivel de acceso adecuado en lugar de los permisos predeterminados que proporcione a los empleados a tiempo completo. La diferenciación clara de las cuentas externas facilita la prevención y detección de ataques procedentes de estos vectores.

Su elección de IdP debe ser capaz de proporcionar esa diferenciación, proporcionar características integradas que concedan permisos basados en el privilegio mínimo y proporcionar inteligencia sobre amenazas integrada. Esto incluye la supervisión de las solicitudes de acceso y los inicios de sesión. El IdP de Azure es Microsoft Entra id. Para más información, consulte la sección facilitación de Azure de este artículo.

Cuentas de impacto crítico

Las identidades administrativas presentan algunos de los riesgos de seguridad de mayor impacto porque las tareas que realizan requieren acceso con privilegios a un amplio conjunto de estos sistemas y aplicaciones. El riesgo o el uso indebido pueden tener un efecto perjudicial en su negocio y en sus sistemas de información. La seguridad de la administración es una de las áreas de seguridad más críticas.

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. Estas son algunas estrategias:

  • Minimice el número de cuentas de impacto crítico.

  • Use roles independientes en lugar de elevar privilegios para las identidades existentes.

  • Evite el acceso permanente o permanente mediante las características JIT del IdP. Para situaciones de emergencia, siga un proceso de acceso de emergencia.

  • Use protocolos de acceso modernos , como la autenticación sin contraseña o la autenticación multifactor. Externalice esos mecanismos al IdP.

  • Aplicar atributos de seguridad clave mediante directivas de acceso condicional.

  • Retirar cuentas administrativas que no se usan.

Use una única identidad entre entornos y asocie una única identidad con el usuario o la entidad de seguridad. La coherencia de las identidades en entornos locales y en la nube reduce los errores humanos y los riesgos de seguridad resultantes. Los equipos de ambos entornos que administran recursos necesitan un origen coherente y autoritativo para satisfacer las garantías de seguridad. Trabaje con el equipo de identidad central para asegurarse de que las identidades de entornos híbridos estén sincronizadas.

Riesgo: existe un riesgo asociado a la sincronización de identidades con privilegios elevados. Un atacante puede obtener el control total de los recursos locales y esto puede dar lugar a un compromiso correcto de una cuenta en la nube. Evalúe la estrategia de sincronización filtrando las cuentas que pueden agregar a la superficie expuesta a ataques.

Establecimiento de procesos para administrar el ciclo de vida de la identidad

El acceso a las identidades no debe durar más que los recursos a los que acceden las identidades. Asegúrese de que tiene un proceso para deshabilitar o eliminar identidades cuando haya cambios en la estructura del equipo o en los componentes de software.

Esta guía se aplica al control de código fuente, los datos, los planos de control, los usuarios de carga de trabajo, la infraestructura, las herramientas, la supervisión de datos, registros, métricas y otras entidades.

Establezca un proceso de gobernanza de identidades para administrar el ciclo de vida de las identidades digitales, los usuarios con privilegios elevados, los usuarios externos o invitados y los usuarios de carga de trabajo. Implemente revisiones de acceso para asegurarse de que, cuando las identidades abandonan la organización o el equipo, se quitan sus permisos de carga de trabajo.

Protección de secretos no basados en identidad

Los secretos de aplicación, como las claves previamente compartidas, deben considerarse puntos vulnerables en el sistema. En la comunicación bidireccional, si el proveedor o el consumidor están en peligro, se pueden introducir riesgos de seguridad significativos. Esas claves también pueden ser pesadas porque introducen procesos operativos.

Cuando pueda, evite usar secretos y considere la posibilidad de usar la autenticación basada en identidades para el acceso de usuario a la propia aplicación, no solo a sus recursos.

En la lista siguiente se proporciona un resumen de las instrucciones. Para más información, consulte Recomendaciones para secretos de aplicación.

  • Trate estos secretos como entidades que se pueden extraer dinámicamente de un almacén de secretos. No deben codificarse de forma rígida en el código de la aplicación, los scripts de IaC, las canalizaciones de implementación ni en ningún otro artefacto.

  • Asegúrese de que tiene la capacidad de revocar secretos.

  • Aplique prácticas operativas que controle tareas como la rotación de claves y la expiración.

Para obtener información sobre las directivas de rotación, consulte Automatización de la rotación de un secreto para los recursos que tienen dos conjuntos de credenciales de autenticación y Tutorial: Actualización de la frecuencia de rotación automática de certificados en Key Vault.

Mantener seguros los entornos de desarrollo

Todos los scripts y código, las herramientas de canalización y los sistemas de control de código fuente deben considerarse activos de carga de trabajo. El acceso a las escrituras debe estar privado con la automatización y la revisión del mismo nivel. El acceso de lectura al código fuente debe limitarse a los roles de forma necesaria. Los repositorios de código deben tener control de versiones y las revisiones de código de seguridad de los elementos del mismo nivel deben ser una práctica normal integrada con el ciclo de vida de desarrollo. Debe tener un proceso en vigor que examine los recursos periódicamente e identifique las vulnerabilidades más recientes.

Use identidades de carga de trabajo para conceder acceso a los recursos desde entornos de implementación, como GitHub.

Mantenimiento de una pista de auditoría

Un aspecto de la administración de identidades es asegurarse de que el sistema es auditable. Las auditorías validan si las estrategias de vulneración de seguridad son eficaces. Mantener una pista de auditoría le ayuda a:

  • Compruebe que la identidad está autenticada con autenticación segura. Cualquier acción debe ser rastreable para evitar ataques de rechazo.

  • Detecte protocolos de autenticación débiles o que falten y obtenga visibilidad sobre los inicios de sesión de usuario y aplicación.

  • Evalúe el acceso de las identidades a la carga de trabajo en función de los requisitos de seguridad y cumplimiento, y considere el riesgo de la cuenta de usuario, el estado del dispositivo y otros criterios y directivas que establezca.

  • Realice un seguimiento del progreso o la desviación de los requisitos de cumplimiento.

La mayoría de los recursos tienen acceso al plano de datos. Debe conocer las identidades que acceden a los recursos y las acciones que realizan. Puede usar esa información para el diagnóstico de seguridad.

Para obtener más información, consulte Recomendaciones sobre la supervisión de la seguridad y el análisis de amenazas.

Facilitación de Azure

Se recomienda usar siempre protocolos de autenticación modernos que tengan en cuenta todos los puntos de datos disponibles y usen el acceso condicional. Microsoft Entra id. proporciona administración de identidades y acceso en Azure. Abarca el plano de administración de Azure y se integra con los planos de datos de la mayoría de los servicios de Azure. Microsoft Entra identificador es el inquilino asociado a la suscripción de carga de trabajo. Realiza un seguimiento y administra las identidades y sus permisos permitidos y simplifica la administración general para minimizar el riesgo de supervisión o error humano.

Estas funcionalidades se integran de forma nativa en el mismo modelo de identidad y permisos de Microsoft Entra para segmentos de usuario:

Puede usar Microsoft Entra identificador para la autenticación y autorización de aplicaciones personalizadas a través de la Biblioteca de autenticación de Microsoft (MSAL) o características de plataforma, como la autenticación para aplicaciones web. Abarca el plano de administración de Azure, los planos de datos de la mayoría de los servicios de Azure y las funcionalidades de integración de las aplicaciones.

Para mantenerse al día, visite Novedades en Microsoft Entra ID.

Compensación: el identificador de Microsoft Entra de Microsof es un único punto de error igual que cualquier otro servicio fundamental. No hay ninguna solución alternativa hasta que Microsoft corrija la interrupción. Sin embargo, el amplio conjunto de características de Microsoft Entra supera el riesgo de usar soluciones personalizadas.

Azure admite protocolos abiertos como OAuth2 y OpenID Connect. Se recomienda usar estos mecanismos de autenticación y autorización estándar en lugar de diseñar sus propios flujos.

Azure RBAC

RBAC de Azure representa entidades de seguridad en Microsoft Entra id. Todas las asignaciones de roles se realizan a través de RBAC de Azure. Aproveche las ventajas de los roles integrados que proporcionan la mayoría de los permisos que necesita. Para obtener más información, consulte Roles integrados de Microsoft Entra.

Estos son algunos casos de uso:

Para más información sobre RBAC, consulte Procedimientos recomendados para RBAC de Azure.

Para obtener información sobre los controles basados en atributos, consulte ¿Qué es Azure ABAC?.

Identidad de carga de trabajo

Microsoft Entra identificador puede controlar la identidad de la aplicación. La entidad de servicio asociada a la aplicación puede dictar su ámbito de acceso.

Para más información, consulte ¿Qué son las identidades de carga de trabajo?.

La entidad de servicio también se abstrae cuando se usa una identidad administrada. La ventaja es que Azure administra todas las credenciales de la aplicación.

No todos los servicios admiten identidades administradas. Si no puede usar identidades administradas, puede usar entidades de servicio. Sin embargo, el uso de entidades de servicio aumenta la sobrecarga de administración. Para más información, consulte ¿Qué es Managed Identities for Azure Resources?

Identidad del recurso

El concepto de identidades administradas se puede ampliar a los recursos de Azure. Los recursos de Azure pueden usar identidades administradas para autenticarse en otros servicios que admiten la autenticación Microsoft Entra. Para más información, consulte Servicios de Azure que pueden usar identidades administradas para acceder a otros servicios.

Directivas de acceso condicional

El acceso condicional describe la directiva para una decisión de acceso. Para usar el acceso condicional, debe comprender las restricciones necesarias para el caso de uso. Configure Microsoft Entra acceso condicional mediante la configuración de una directiva de acceso para que se base en sus necesidades operativas.

Para más información, consulte Acceso condicional: Usuarios, grupos e identidades de carga de trabajo.

Administración de acceso a grupos

En lugar de conceder permisos a usuarios específicos, asigne acceso a grupos en Microsoft Entra id. Si no existe un grupo, trabaje con el equipo de identidad para crear uno. Después, puede agregar y quitar miembros del grupo fuera de Azure y asegurarse de que los permisos están actualizados. También puede usar el grupo para otros fines, como las listas de distribución de correo.

Para obtener más información, consulte Protección del control de acceso mediante grupos en Microsoft Entra id.

Detección de amenazas

Protección de Microsoft Entra ID puede ayudarle a detectar, investigar y corregir los riesgos basados en identidades. Para más información, consulte ¿Qué es Identity Protection?.

La detección de amenazas puede adoptar la forma de reaccionar a una alerta de actividad sospechosa o buscar de forma proactiva eventos anómalos en los registros de actividad. Análisis de comportamiento de usuarios y entidades (UEBA) en Microsoft Sentinel facilita la detección de actividades sospechosas. Para obtener más información, consulte Identificación de amenazas avanzadas con UEBA.

Sistemas híbridos

En Azure, no sincronice las cuentas con Microsoft Entra identificador que tengan privilegios elevados en la instancia de Active Directory existente. Esta sincronización se bloquea en la configuración predeterminada de Microsoft Entra Connect Sync, por lo que solo tiene que confirmar que no ha personalizado esta configuración.

Para obtener información sobre el filtrado en Microsoft Entra identificador, consulte Microsoft Entra Connect Sync: Configurar el filtrado.

Registro de identidades

Habilite la configuración de diagnóstico en los recursos de Azure para emitir información que puede usar como pista de auditoría. La información de diagnóstico muestra qué identidades intentan acceder a qué recursos y el resultado de esos intentos. Los registros recopilados se envían a Azure Monitor.

Compensación: el registro conlleva costos debido al almacenamiento de datos que se usa para almacenar los registros. También puede provocar un impacto en el rendimiento, especialmente en el código y en las soluciones de registro que agregue a la aplicación.

Ejemplo

En el ejemplo siguiente se muestra una implementación de identidad. Los distintos tipos de identidades se usan juntos para proporcionar los niveles de acceso necesarios.

Diagrama que muestra una implementación de identidad.

Componentes de identidad

  • Identidades administradas por el sistema. Microsoft Entra id. proporciona acceso a los planos de datos de servicio que no se enfrentan a los usuarios, como Azure Key Vault y almacenes de datos. Estas identidades también controlan el acceso, a través de RBAC, al plano de administración de Azure para los componentes de carga de trabajo, los agentes de implementación y los miembros del equipo.

  • Identidades de la carga de trabajo. Los servicios de aplicación del clúster de Azure Kubernetes Service (AKS) usan identidades de carga de trabajo para autenticarse en otros componentes de la solución.

  • Identidades administradas. Los componentes del sistema del rol de cliente usan identidades administradas por el sistema, incluidos los agentes de compilación.

  • Identidades humanas. La autenticación de usuario y operador se delega en Microsoft Entra id. o identificador de Microsoft Entra (nativo, B2B o B2C).

La seguridad de los secretos previamente compartidos es fundamental para cualquier aplicación. Azure Key Vault proporciona un mecanismo de almacenamiento seguro para estos secretos, incluidos Redis y secretos de terceros.

Se usa un mecanismo de rotación para ayudar a garantizar que los secretos no estén en peligro. Los tokens para la implementación de Plataforma de identidad de Microsoft de OAuth 2 y OpenID Connect se usan para autenticar a los usuarios.

Azure Policy se usa para asegurarse de que los componentes de identidad como Key Vault usar RBAC en lugar de directivas de acceso. JIT y JEA proporcionan permisos permanentes tradicionales para los operadores humanos.

Los registros de acceso se habilitan en todos los componentes a través de Azure Diagnostics o a través del código para los componentes de código.

Lista de comprobación de seguridad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de seguridad