Compartir a través de

Recomendaciones para la administración de identidad y acceso

  • Artículo

Se aplica a esta recomendación de lista de comprobación de seguridad de buena arquitectura de Power Platform:

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

En esta guía se describen las recomendaciones para autenticar y autorizar identidades que pueden estar intentando tener acceso a sus recursos de carga de trabajo.

Desde una perspectiva de control técnico, la identidad es siempre el perímetro principal. Este ámbito no incluye solo los límites de su carga de trabajo. También incluye componentes individuales que se encuentran dentro de su carga de trabajo.

Las identidades típicas incluyen:

  • Personas. Usuarios de aplicaciones, administradores, operadores, auditores y malos actores.
  • Sistemas Identidades de carga de trabajo, identidades administradas, claves API, principales de servicio y recursos Azure.
  • Anónimas. Entidades que no han aportado ninguna evidencia sobre quiénes son.

Definiciones

Términos Definición
Autenticación (AuthN) Un proceso que verifica que una identidad es quien o lo que dice ser.
Autorización (AuthZ) Un proceso que verifica si una identidad tiene permiso para realizar una acción solicitada.
Acceso condicional Un conjunto de reglas que permite acciones basadas en criterios específicos.
IdP Un proveedor de identidades, como Microsoft Entra ID.
Rol Una función laboral o un título que tiene un conjunto de responsabilidades y acciones.
Claves previamente compartidas Un tipo de secreto que se comparte entre un proveedor y un consumidor y se utiliza a través de un mecanismo seguro y acordado.
Identidad de recurso Una identidad definida para los recursos de la nube administrada por la plataforma.
Role Un conjunto de permisos que definen lo que puede hacer un usuario o grupo.
Scope Diferentes niveles de la jerarquía organizativa en los que un rol está autorizado a operar. 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. Todos los miembros del grupo obtienen el mismo nivel de acceso.
Identidad de 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 utiliza para autenticarse en otros servicios y recursos.

Nota

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

Microsoft Entra ID como proveedor de identidad para Power Platform

Todos los productos de Power Platform usan Microsoft Entra ID (anteriormente Azure Active Directory o Azure AD) para la administración de la identidad y el acceso. Entra ID permite a las organizaciones proteger y administrar la identidad de sus entornos híbridos y multinube. Entra ID también es esencial para administrar los invitados de la empresa que requieren acceso a los recursos de Power Platform. Power Platform también usa Entra ID para administrar otras aplicaciones que necesitan integrarse con las API de Power Platform que usan las capacidades de la entidad de servicio. Al usar Entra ID, Power Platform puede aprovechar las características de seguridad más avanzadas de Entra ID, como el acceso condicional y la evaluación de acceso continuo.

Autenticación

La autenticación es un proceso que verifica las identidades. Se requiere que la identidad solicitante proporcione alguna forma de identificación verificable. Por ejemplo:

  • Un nombre de usuario y una contraseña.
  • Un secreto previamente compartido, como una clave API que otorga acceso.
  • Un token de Firma de acceso compartido (SAS).
  • Un certificado utilizado en la autenticación mutua de Seguridad de la Capa de Transporte (TLS).

La autenticación de Power Platform implica una secuencia de solicitudes, respuestas y redireccionamientos entre el navegador del usuario y servicios de Azure o Power Platform. La secuencia sigue el flujo de concesión de código de autenticación de Microsoft Entra ID.

Conectarse y autenticarse a un origen de datos es un paso independiente de la autenticación en un servicio de Power Platform. Para más información, vea Conexión y autenticación a orígenes de datos.

Autorización

Power Platform utiliza Plataforma de identidad de Microsoft de ID de Microsoft Entra para la autorización de todas las llamadas a la API con el protocolo estándar del sector OAuth 2.0.

Estrategias clave de diseño

Para comprender las necesidades de identidad de una carga de trabajo, debe enumerar los flujos de usuarios y sistemas, los activos de la carga de trabajo y las personas, y las acciones que realizarán.

Cada caso de uso probablemente tendrá su propio conjunto de controles que deberá diseñar con una mentalidad de asumir incumplimiento. Según los requisitos de identidad del caso de uso o de las personas, identifique las opciones condicionales. Evite utilizar una solución para todos los casos de uso. A la inversa, los controles no deben ser tan granulares que introduzcan una sobrecarga de administración innecesaria.

Debe registrar la traza de acceso a la identidad. Hacerlo ayuda a validar los controles y puede utilizar los registros para auditorías de cumplimiento.

Determinar todas las identidades para la autenticación

Acceso exterior-interior. La autenticación de Power Platform implica una secuencia de solicitudes, respuestas y redireccionamientos entre el navegador del usuario y servicios de Azure o Power Platform. La secuencia sigue el flujo de concesión de código de autenticación de Microsoft Entra ID. Power Platform autentica automáticamente a todos los usuarios que tienen acceso a la carga de trabajo para diversos fines.

Acceso interior-exterior. Su carga de trabajo necesitará tener acceso 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 servicios de supervisión. Es posible que incluso necesite tener acceso a servicios de terceros. Todos estos son requisitos de identidad de la carga de trabajo. Sin embargo, también es necesario considerar los requisitos de identidad de los recursos; por ejemplo, cómo se ejecutarán y autenticarán las canalizaciones de implementación.

Determinar acciones para la autorización

A continuación, necesita saber qué intenta hacer cada identidad autenticada para que esas acciones puedan autorizarse. 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. Por ejemplo, una aplicación que lee o escribe datos desde Microsoft Dataverse o escribe registros en Application Insights.

  • Acceso al plano de control. Las acciones que tienen lugar en el plano de control provocan la creación, modificación o eliminación de un recurso de Power Platform. Por ejemplo, modificar las propiedades del entorno o crear una política de datos.

Las aplicaciones normalmente tienen como objetivo operaciones en el plano de datos, mientras que las operaciones a menudo tienen acceso tanto al plano de control como al de datos.

Proporcionar autorización basada en roles

Basándose en la responsabilidad de cada identidad, autorice las acciones que deben permitirse. No se debe permitir que una identidad haga más de lo que necesita. Antes de establecer reglas de autorización, debe tener una comprensión clara de quién o qué realiza las solicitudes, qué puede hacer ese rol y en qué medida puede hacerlo. Esos factores conducen a elecciones que combinan identidad, rol y ámbito.

Tenga en cuenta lo siguiente:

  • ¿La carga de trabajo necesita tener acceso al plano de datos de Dataverse para acceso de lectura y escritura?
  • ¿La carga de trabajo también necesita acceso a las propiedades del entorno?
  • Si la identidad se ve comprometida por un mal actor, ¿cuál sería el impacto en el sistema en términos de confidencialidad, integridad y disponibilidad?
  • ¿La carga de trabajo necesita acceso permanente o se puede considerar el acceso condicional?
  • ¿La carga de trabajo realiza acciones que requieren permisos administrativos/elevados?
  • ¿Cómo interactuará la carga de trabajo con los servicios de terceros?
  • Para las cargas de trabajo de aplicaciones inteligentes, como los agentes, ¿tiene requisitos de inicio de sesión único (SSO)?
  • ¿El agente funciona en modo no autenticado, en modo autenticado o en ambos?

Asignación de roles

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

Haga preguntas como estas:

  • ¿Es suficiente el acceso de solo lectura?
  • ¿La identidad necesita permisos para eliminar recursos?
  • ¿El rol solo necesita acceso a los registros que creó?
  • ¿Se requiere acceso jerárquico basado en la unidad de negocio en la que se encuentra el usuario?
  • ¿El rol necesita permisos administrativos o elevados?
  • ¿El rol necesita acceso permanente a estos permisos?
  • ¿Qué pasa si el usuario cambia de trabajo?

Limitar el nivel de acceso que tienen los usuarios, aplicaciones o servicios reduce la superficie de ataque potencial. Si otorga solo los permisos mínimos necesarios para realizar tareas específicas, el riesgo de un ataque exitoso o de acceso no autorizado se reduce significativamente. Por ejemplo, los desarrolladores solo necesitan acceso de creador al entorno de desarrollo, pero no al entorno de producción; solo necesitan acceso para crear recursos pero no cambiar las propiedades del entorno; y es posible que solo necesiten acceso para leer/escribir datos desde Dataverse pero no cambiar el modelo de datos o los atributos de la tabla de Dataverse.

Evite permisos dirigidos a usuarios individuales. Los permisos granulares y personalizados crean complejidad y confusión y pueden resultar difíciles de mantener a medida que los usuarios cambian de roles y se mueven por la empresa, o cuando nuevos usuarios con requisitos de autenticación similares se unen al equipo. Esta situación puede crear una configuración heredada compleja que es difícil de mantener y afecta negativamente tanto a la seguridad como a la fiabilidad.

Desventajas: un enfoque de control de acceso granular permite una mejor auditoría y supervisión de las actividades de los usuarios.

Otorgue roles que comiencen con privilegios mínimos y agregue más según sus necesidades operativas o de acceso a datos. Sus equipos técnicos deben tener una guía clara para implementar permisos.

Hacer elecciones de acceso condicional

No dé a todas las identidades el mismo nivel de acceso. Base sus decisiones en dos factores principales:

  • Hora. Cuánto tiempo puede acceder la identidad a su entorno.
  • Privilegio. El nivel de permisos.

Esos factores no son mutuamente excluyentes. Una identidad comprometida que tiene más privilegios y una duración ilimitada de acceso puede obtener más control sobre el sistema y los datos o utilizar ese acceso para continuar cambiando el entorno. Restrinja esos factores de acceso tanto como medida preventiva como para controlar el radio afectado.

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 utilizar el dispositivo, la red y la ubicación desde donde se originó el acceso para establecer políticas.

Utilice controles sólidos que filtren, detecten y bloqueen el acceso no autorizado, incluidos parámetros como la identidad y 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 identidades de terceros, como proveedores, socios y clientes, deban tener acceso a su carga de trabajo. Necesitan el nivel de acceso adecuado en lugar de los permisos por defecto que usted proporciona a los empleados a tiempo completo. La clara diferenciación de cuentas externas facilita la prevención y detección de ataques que provienen de estos vectores.

Cuentas de impacto crítico

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

Proteger el acceso privilegiado contra determinados adversarios requiere que usted adopte un enfoque completo y reflexivo para aislar estos sistemas de los riesgos. Estas son algunas estrategias:

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

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

  • Evite el acceso permanente o fijo usando las funciones JIT de su IdP. En situaciones de emergencia, siga un proceso de acceso de emergencia.

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

  • Haga cumplir los atributos de seguridad clave mediante el uso de políticas de acceso condicional.

  • Retire las cuentas administrativas que no se estén usando.

Establezca 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 tener un proceso para deshabilitar o eliminar identidades cuando haya cambios en la estructura del equipo o los componentes del software.

Esta guía se aplica al control de fuentes, datos, planos de control, usuarios de cargas de trabajo, infraestructura, herramientas, supervisión de datos, registros, métricas y otras entidades.

Establezca un proceso de gobernanza de identidad para administrar el ciclo de vida de identidades digitales, usuarios con altos privilegios, usuarios externos/invitados y usuarios de cargas de trabajo. Implemente revisiones de acceso para garantizar que cuando las identidades abandonen la organización o el equipo, se eliminen sus permisos de carga de trabajo.

Proteger secretos no basados en identidad

Los secretos de aplicaciones, como las claves previamente compartidas, deben considerarse puntos vulnerables del sistema. En la comunicación bidireccional, si el proveedor o el consumidor se ve comprometido, se pueden introducir importantes riesgos de seguridad. Esas claves también pueden resultar engorrosas porque introducen procesos operativos.

Trate estos secretos como entidades que pueden extraerse dinámicamente de un almacén de secretos. No deben estar codificados en sus aplicaciones, flujos, canalizaciones de implementación ni en ningún otro artefacto.

Asegúrese de tener la capacidad de revocar secretos.

Aplique prácticas operativas que manejen tareas como rotación y caducidad de claves.

Para obtener información sobre las políticas de rotación, consulte Automatizar la rotación de un secreto para 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

El acceso de escritura a los entornos de desarrollador debe estar cerrado y el acceso de lectura al código fuente debe limitarse a los roles según sea necesario. Debe contar con un proceso que analice los recursos con regularidad e identifique las vulnerabilidades más recientes.

Mantener una pista de auditoría

Un aspecto de la administración de identidades es garantizar que el sistema sea auditable. Las auditorías validan si las estrategias de asumir incumplimientos son efectivas. Mantener un registro de auditoría le ayuda a:

  • Verifique que la identidad esté autenticada con autenticación sólida. Cualquier acción debe ser rastreable para prevenir ataques de rechazo.

  • Detecte protocolos de autenticación débiles o que faltan y obtenga visibilidad e información sobre los inicios de sesión de usuarios y aplicaciones.

  • Evalúe el acceso de las identidades a la carga de trabajo según los requisitos de seguridad y cumplimiento y considere el riesgo de la cuenta de usuario, el estado del dispositivo y otros criterios y políticas 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. Necesita conocer las identidades que acceden a los recursos y las acciones que realizan. Puede usar esa información para diagnósticos de seguridad.

Facilitación de Power Platform

El control de acceso de Power Platform es una parte vital de su arquitectura de seguridad general. Los puntos de control de acceso pueden garantizar que los usuarios adecuados obtengan acceso a los recursos de Power Platform. En esta sección, exploraremos los diferentes puntos de acceso que puede configurar y su función en su estrategia de seguridad general.

Id. de Microsoft Entra

Todos los productos de Power Platform usan Microsoft Entra ID (anteriormente Azure Active Directory o Azure AD) para la administración de la identidad y el acceso. Entra ID permite a las organizaciones proteger y administrar la identidad de sus entornos híbridos y multinube. Entra ID también es esencial para administrar los invitados de la empresa que requieren acceso a los recursos de Power Platform. Power Platform también usa Entra ID para administrar otras aplicaciones que necesitan integrarse con las API de Power Platform que usan las capacidades de la entidad de servicio. Al usar Entra ID, Power Platform puede aprovechar las características de seguridad más avanzadas de Entra ID, como el acceso condicional y la evaluación de acceso continuo.

Diagrama de un sistema de informática en la nube.

Asignación de licencias

El acceso a Power Apps y Power Automate comienza con tener una licencia. Los activos y datos a los que puede tener acceso a un usuario vienen determinados por el tipo de licencia que tenga. La siguiente tabla describe, en un alto nivel, diferencias en los recursos disponibles para un usuario en función del tipo de plan. Los detalles granulares de la licencia se encuentran en la Información general de licencias.

Directivas de acceso condicional

El acceso condicional describe su política para una decisión de acceso. Para usar el acceso condicional, debe comprender las restricciones necesarias para el caso de uso. Configure el acceso condicional de Microsoft Entra configurando una política de acceso que se base en sus necesidades operativas.

Para obtener más información, consulte:

Acceso continuo

El acceso continuo se acelera cuando se evalúan ciertos eventos para determinar si se debe revocar el acceso. Tradicionalmente, con la autenticación 2.0 de OAuth, la caducidad del token de acceso se produce cuando se realiza una comprobación durante la renovación del token. Con el acceso continuo, los eventos críticos de un usuario y los cambios de ubicación de la red se evalúan continuamente para determinar si el usuario aún debe mantener el acceso. Estas evaluaciones pueden resultar en la terminación anticipada de sesiones activas o requerir una nueva autenticación. Por ejemplo, si una cuenta de usuario está deshabilitada, debería perder el acceso a la aplicación. La ubicación también es importante; por ejemplo, es posible que el símbolo (token) se haya autorizado desde una ubicación fiable, pero el usuario cambió su conexión a una red que no es fiable. El acceso continuo invocaría la evaluación de la política de acceso condicional y el usuario perdería el acceso porque ya no se conecta desde una ubicación aprobada.

Actualmente, con Power Platform, solo Dataverse admite la evaluación continua de acceso. Microsoft está trabajando para agregar soporte a otros servicios y clientes de Power Platform. Para obtener más información, consulte Evaluación continua de acceso.

Con la adopción continua de modelos de trabajo híbridos y el uso de aplicaciones en la nube, Entra ID se ha convertido en un perímetro de seguridad primario crucial para proteger a los usuarios y los recursos. El acceso condicional extiende ese perímetro más allá del perímetro de la red para incluir la identidad del usuario y del dispositivo. El acceso continuo garantiza que, a medida que cambian los eventos o las ubicaciones de los usuarios, se reevalúe el acceso. El uso que Power Platform realiza de Entra ID le permite implementar un control de seguridad en el nivel de organización que puede aplicar de manera consistente en toda su cartera de aplicaciones. Revise estos procedimientos recomendados de administración de identidad para obtener más orientación sobre cómo crear su propio plan para usar Entra ID con Power Platform.

Administración de acceso de grupo

En lugar de otorgar permisos a usuarios específicos, asigne acceso a grupos en Microsoft Entra ID. Si no existe un grupo, trabaje con su equipo de identidad para crear uno. Luego puede agregar y eliminar miembros del grupo fuera de Azure y asegurarse de que los permisos estén actualizados. También puedes usar el grupo para otros fines, como listas de correo.

Para obtener más información, consulte Control de acceso seguro mediante grupos en Microsoft Entra ID.

Detección de amenazas

La protección de Microsoft Entra ID puede ayudarle a detectar, investigar y remediar riesgos basados en la identidad. Para obtener más información, consulte ¿Qué es la protección de identidad?.

La detección de amenazas puede consistir en reaccionar a una alerta de actividad sospechosa o buscar proactivamente eventos anómalos en los registros de actividad. User and Entity Behavior Analytics (UEBA) en Microsoft Sentinel facilita la detección de actividades sospechosas. Para obtener más información, consulte Identificar amenazas avanzadas con UEBA en Microsoft Sentinel.

Registro de identidad

Power Apps, Power Automate, Copilot Studio, los conectores y el registro de actividad de prevención de pérdidas de datos se rastrean y se ven desde el portal de cumplimiento de Microsoft Purview. Para obtener más información, consulte Información sobre Microsoft Purview.

Los cambios de registros que se realizan en los registros del cliente en un entorno con una base de datos de Dataverse. Las auditorías de Dataverse también registran el acceso de los usuarios a través de una aplicación o a través del SDK en un entorno. Esta auditoría está habilitada a nivel de entorno y se requiere configuración adicional para tablas y columnas individuales.

Roles de administrador de servicios

Entra ID contiene un conjunto de roles preestablecidos que se pueden asignar a los administradores para darles permiso para realizar tareas administrativas. Puede revisar la matriz de permisos para obtener un desglose granular de los privilegios de cada función.

Use Microsoft Entra Privileged Identity Management (PIM) para administrar funciones de administrador con altos privilegios en el centro de administración de Power Platform.

Seguridad de datos de Dataverse

Una de las características clave de Dataverse es su rico modelo de seguridad, que se puede adaptar a múltiples escenarios de uso empresarial. Este modelo de seguridad solo está disponible cuando hay una base de datos de Dataverse en el entorno. Como profesional de la seguridad, probablemente no tendrá que crear todo el modelo de seguridad usted mismo, pero puede participar en garantizar que el uso de las funciones de seguridad sea coherente con los requisitos de seguridad de los datos de la organización. Dataverse utiliza la seguridad basada en roles para agrupar una recopilación de privilegios. Estos roles de seguridad se pueden asociar directamente a los usuarios, o se pueden asociar con equipos y unidades de negocio de Dataverse. Para obtener más información, consulte Conceptos de seguridad en Microsoft Dataverse.

Configurar la autenticación de usuarios en Copilot Studio

Microsoft Copilot Studio admite varias opciones de autenticación. Elija la que se adapte a sus necesidades. La autenticación permite a los usuarios iniciar sesión, lo que le da a su agente acceso a un recurso o información restringidos. Los usuarios pueden iniciar sesión con un ID Microsoft Entra, o con cualquier proveedor de identidades de OAuth como Google o Facebook. Obtenga más información en Configurar la autenticación de usuario en Copilot Studio.

Con la seguridad basada en Direct Line puede restringir el acceso únicamente a las ubicaciones que controla habilitando el acceso protegido mediante secretos o símbolos de Direct Line.

Copilot Studio admite el inicio de sesión único (SSO), lo que significa que los agentes pueden iniciar sesión al usuario. El SSO debe implementarse en sus páginas web y aplicaciones móviles. Para Microsoft Teams, el inicio de sesión único es perfecto si selecciona la opción de autenticación «Solo en Teams». También se puede configurar manualmente con Azure AD v2; sin embargo, en este caso la aplicación de Teams debe implementarse como un archivo zip, no a través de la implementación de Teams con un solo clic desde Copilot Studio.

Más información:

Acceder de forma segura a los datos mediante Caja de seguridad del cliente

La mayoría de las operaciones, el soporte y la resolución de problemas a cargo del personal de Microsoft (lo que incluye los subprocesadores) no requieren acceso a los datos del cliente. Con la Caja de seguridad del cliente de Power Platform ofrecemos una interfaz para que los clientes puedan revisar y aprobar (o rechazar) solicitudes de acceso a datos en las raras ocasiones en que se necesita acceso a datos de clientes. Por ejemplo, se usa cuando un ingeniero de Microsoft necesita tener acceso a los datos del cliente, ya sea en respuesta a una incidencia de soporte técnico iniciada por el cliente o a un problema identificado por Microsoft. Para obtener más información, consulte Acceda de forma segura a los datos del cliente utilizando la Caja de seguridad del cliente en Power Platform y Dynamics 365.

Lista de verificación de seguridad

Consulte el conjunto completo de recomendaciones.

Lista de verificación de seguridad