Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Esta recomendação da lista de verificação de Segurança do Power Platform Well-Architected se aplica a:
| SE:05 | Implemente o gerenciamento de identidade e acesso (IAM) rigoroso, condicional e auditável em todos os usuários da carga de trabalho, membros da equipe e componentes do sistema. Limite o acesso exclusivamente quando necessário. Use padrões do setor modernos para todas as implementações de autenticação e autorização. Restrinja e audite rigorosamente o acesso que não se baseie em identidade. |
|---|
Este guia descreve as recomendações para autenticar e autorizar identidades que estão tentando acessar seus recursos de carga de trabalho.
Do ponto de vista do controle técnico, a identidade é sempre o perímetro principal. Este escopo não inclui apenas os limites da sua carga de trabalho. Ele também inclui componentes individuais que estão dentro de sua carga de trabalho.
Entre as identidades típicas estão:
- Humanos. Usuários de aplicativos, administradores, operadores, auditores e agentes mal-intencionados.
- Sistemas. Identidades de carga de trabalho, identidades gerenciadas, chaves de API, entidades de serviço e recursos de Azure.
- Anônimo. Entidades que não deram nenhuma evidência sobre quem são.
Definições
| Condições | Definição |
|---|---|
| Autenticação (AuthN) | Um processo que verifica se uma identidade é de fato quem ou o que afirma ser. |
| Autorização (AuthZ) | Um processo que verifica se uma identidade tem permissão para executar uma ação solicitada. |
| Acesso condicional | Um conjunto de regras que permite ações com base em critérios especificados. |
| IdP | Um provedor de identidade, como o Microsoft Entra ID. |
| Persona | Uma função de trabalho ou um título que tem um conjunto de responsabilidades e ações. |
| Chaves pré-compartilhadas | Um tipo de segredo compartilhado entre um provedor e um consumidor e usado por meio de um mecanismo seguro e acordado. |
| Identidade do recurso | Uma identidade definida para recursos de nuvem gerenciados pela plataforma. |
| Função | Um conjunto de permissões que definem o que um usuário ou um grupo pode fazer. |
| Scope | Níveis diferentes de hierarquia organizacional em que uma função tem permissão para operar. Também é um grupo de recursos em um sistema. |
| Principal de segurança | Uma identidade que dá permissões. Pode ser um usuário, um grupo ou uma entidade de serviço. Todos os membros do grupo obtêm o mesmo nível de acesso. |
| Identidade do utilizador | Uma identidade para uma pessoa, como um funcionário ou um usuário externo. |
| Identidade da carga de trabalho | Uma identidade do sistema para um aplicativo, serviço, script, contêiner ou outro componente de uma carga de trabalho usada para se autenticar em outros serviços e recursos. |
Note
Uma identidade pode ser agrupada com outras identidades semelhantes sob um principal chamado 'entidade de segurança'. Um grupo de segurança é um exemplo de entidade de segurança. Esse relacionamento hierárquico simplifica a manutenção e aumenta a consistência. Como os atributos de identidade não são tratados no nível individual, as chances de erros também são reduzidas. Neste artigo, o termo identidade é inclusivo dos princípios de segurança.
Microsoft Entra ID como provedor de identidades do Power Platform
Todos os produtos do Power Platform usam Microsoft Entra ID (anteriormente Azure Active Directory ou Azure AD) para gerenciamento de identidade e acesso. O Entra ID permite que as organizações protejam e gerenciem a identidade para os ambientes híbridos e multinuvem. A ID do Entra também é essencial para gerenciar convidados de negócios que precisem de acesso a recursos do Power Platform. O Power Platform também usa a ID do Entra para gerenciar outros aplicativos que precisem de integração com APIs do Power Platform usando as capacidades da entidade de serviço. Usando a ID do Entra, o Power Platform pode aproveitar os recursos de segurança mais avançados da ID do Entra, como Acesso Condicional e avaliação contínua de acesso.
Authentication
Autenticação é um processo que verifica identidades. A identidade solicitante é necessária para oferecer alguma forma de identificação verificável. Por exemplo:
- Um nome de usuário e senha.
- Um segredo pré-compartilhado, como uma chave de API que concede acesso.
- Um token de assinatura de acesso compartilhado (SAS).
- Um certificado usado na autenticação mútua no TLS (Transport Layer Security).
A autenticação do Power Platform envolve uma sequência de solicitações, respostas e redirecionamentos entre o navegador do usuário e o Power Platform ou Azure serviços. A sequência segue o Microsoft Entra ID fluxo de concessão de código de autenticação.
Conectar e autenticar em uma fonte de dados externa é feita separadamente da autenticação em um serviço do Power Platform. Para obter mais informações, consulte Conexão e autenticação com fontes de dados.
Authorization
O Power Platform usa Microsoft Entra ID Microsoft Identity Platform para autorização de todas as chamadas à API com o protocolo OAuth 2.0 padrão do setor.
Estratégias-chave de design
Para compreender as necessidades de identidade de uma carga de trabalho, você precisa listar os fluxos de usuário e sistema, os ativos de carga de trabalho e as personas, além das ações que eles vão tomar.
Cada caso de uso provavelmente terá o próprio conjunto de controles que você precisa projetar com uma mentalidade de presunção de violação. Com base nos requisitos de identidade do caso de uso ou das personas, identifique as opções condicionais. Evite usar uma solução para todos os casos de uso. Por outro lado, os controles não devem ser tão granulares a ponto de introduzir sobrecarga desnecessária no gerenciamento.
Você precisa registrar a trilha de acesso da identidade. Isso ajuda a validar os controles e você pode usar os logs para auditorias de conformidade.
Determinar todas as identidades para autenticação
Acesso de fora para dentro. A autenticação do Power Platform envolve uma sequência de solicitações, respostas e redirecionamentos entre o navegador do usuário e o Power Platform ou Azure serviços. A sequência segue o Microsoft Entra ID fluxo de concessão de código de autenticação. O Power Platform autentica automaticamente todos os usuários que acessam a carga de trabalho para finalidades variadas.
Acesso de dentro para fora. A carga de trabalho necessitará acessar outros recursos. Por exemplo, a leitura ou a gravação na plataforma de dados, a recuperação de segredos do repositório de segredos e o registro da telemetria em serviços de monitoramento. Talvez seja necessário até mesmo acessar serviços de terceiros. Todos esses são requisitos de identidade da carga de trabalho. No entanto, você também precisa levar em consideração os requisitos de identidade dos recursos; por exemplo, como os pipelines de implantação serão executados e autenticados.
Determinar ações para autorização
Em seguida, você precisa saber o que cada identidade autenticada está tentando fazer para que essas ações possam ser autorizadas. As ações podem ser divididas pelo tipo de acesso que elas exigem:
Acesso ao plano de dados. Ações ocorridas no plano de dados causam transferência de dados. Por exemplo, um aplicativo que lê ou grava dados no Microsoft Dataverse, ou que grava logs no Application Insights.
Acesso ao plano de controle. Ações ocorridas no plano de controle fazem com que um recurso do Power Platform seja criado, modificado ou excluído. Por exemplo, modificação das propriedades do ambiente ou criação de uma política de dados.
Os aplicativos tipicamente visam operações do plano de dados, enquanto as operações frequentemente acessam tanto o plano de controle quanto o de dados.
Fornecer autorização baseada em função
De acordo com a responsabilidade atribuída a cada identidade, autorize as ações que podem ser permitidas. Uma identidade não deve ter permissão para fazer mais do que precisa fazer. Antes de definir regras de autorização, você precisa ter uma compreensão clara de quem ou o que está fazendo solicitações, o que essa função tem permissão para fazer e até que ponto ela pode fazê-lo. Esses fatores levam a escolhas que combinam identidade, função e escopo.
Considere o seguinte:
- A carga de trabalho precisa ter acesso ao plano de dados do Dataverse para leitura e gravação?
- A carga de trabalho precisa também de acesso às propriedades do ambiente?
- Se a identidade fosse comprometida por um ator mal-intencionado, qual seria o impacto para o sistema em termos de confidencialidade, integridade e disponibilidade?
- A carga de trabalho precisa de acesso permanente ou o acesso condicional pode ser levado em consideração?
- A carga de trabalho realiza ações que exigem permissões administrativas/elevadas?
- Como a carga de trabalho vai interagir com serviços de terceiros?
- Para agentes, você tem requisitos de SSO (logon único)?
- O agente está operando no modo não autenticado, no modo autenticado ou em ambos?
Atribuição de função
Uma função é um conjunto de permissões atribuídas a uma identidade. Atribua funções que permitam apenas que a identidade conclua a tarefa e nada mais. Quando as permissões do usuário são restritas aos requisitos do trabalho, é mais fácil identificar comportamentos suspeitos ou não autorizados no sistema.
Faça perguntas como estas:
- O acesso somente leitura é suficiente?
- A identidade precisa de permissões para excluir recursos?
- A função só precisa de acesso aos registros que ela mesma criou?
- O acesso hierárquico é baseado na unidade de negócios em que o usuário está?
- A função precisa de permissões administrativas ou elevadas?
- A função precisa de acesso permanente a essas permissões?
- O que acontecerá se o usuário mudar de trabalho?
A limitação do nível de acesso que usuários, aplicativos ou serviços têm reduz a superfície de ataque em potencial. Se você conceder apenas as permissões mínimas necessárias para executar tarefas específicas, o risco de um ataque bem-sucedido ou acesso não autorizado será significativamente reduzido. Por exemplo, os desenvolvedores só precisam de acesso de criador ao ambiente de desenvolvimento, mas não ao ambiente de produção; eles só precisam de acesso para criar recursos, mas não alterar propriedades de ambiente; e eles talvez só precisem de acesso para ler/gravar dados do Dataverse, mas não alterar o modelo de dados ou os atributos da tabela do Dataverse.
Evite permissões direcionadas para usuários individuais. As permissões granulares e personalizadas geram complexidade e confusão e podem ser difíceis de manter à medida que os usuários mudam de função e se movem pela empresa, ou à medida que novos usuários com requisitos de autenticação semelhantes ingressam na equipe. Essa situação pode criar uma configuração herdada complexa que é difícil de manter, além de afetar negativamente a segurança e a confiabilidade.
Vantagens e desvantagens: Uma abordagem granular de controle de acesso permite melhor auditoria e monitoramento das atividades do usuário.
Conceda funções que comecem com menos privilégios e adicione mais com base nas necessidades operacionais ou de acesso a dados. Suas equipes técnicas devem ter diretrizes claras para implementar permissões.
Fazer opções de acesso condicional
Não dê a todas as identidades o mesmo nível de acesso. Baseie suas decisões em dois fatores principais:
- Hora. Por quanto tempo a identidade pode acessar seu ambiente.
- Privilégio. O nível de permissões.
Esses fatores não são mutuamente excludentes. Uma identidade comprometida que tem mais privilégios e duração ilimitada de acesso pode obter mais controle sobre o sistema e os dados ou usar esse acesso para continuar a alterar o ambiente. Restrinja esses fatores de acesso tanto como medida preventiva quanto para controlar o raio de explosão.
As abordagens JIT (Just in Time) fornecem os privilégios necessários somente quando são necessários.
Just Enough Access (JEA) só oferece os privilégios necessários.
Embora o tempo e o privilégio sejam os fatores principais, existem outras condições aplicáveis. Por exemplo, você também pode usar o dispositivo, a rede e o local de origem do acesso para definir políticas.
Use controles fortes que filtrem, detectem e bloqueiem acesso não autorizado, inclusive parâmetros como identidade do usuário e localização, integridade do dispositivo, contexto da carga de trabalho, classificação de dados e anomalias.
Por exemplo, sua carga de trabalho pode precisar ser acessada por identidades de terceiros, como fornecedores, parceiros e clientes. Eles precisam do nível apropriado de acesso, em vez das permissões padrão que você fornece aos funcionários em tempo integral. A diferenciação clara de contas externas facilita a prevenção e a detecção de ataques vindos desses vetores.
Contas de impacto crítico
As identidades administrativas apresentam alguns dos riscos de segurança de maior impacto porque as tarefas que executam exigem acesso privilegiado a um amplo conjunto desses sistemas e aplicativos. O comprometimento ou o uso indevido podem ter um efeito prejudicial em seus negócios e seus sistemas de informação. A segurança da administração é uma das áreas de segurança mais críticas.
A proteção do acesso privilegiado contra adversários determinados exige que você adote uma abordagem completa e cuidadosa para isolar esses sistemas de riscos. Aqui estão algumas estratégias:
Minimize o número de contas de impacto crítico.
Use funções à parte em vez de elevar privilégios para identidades existentes.
Evite o acesso permanente ou constante usando os recursos JIT do seu IdP. Para situações de quebra de vidro, siga um processo de acesso de emergência.
Use protocolos de acesso modernos, como autenticação sem senha ou autenticação multifator. Externalize esses mecanismos para o seu IdP.
Reforce os atributos-chave de segurança usando políticas de acesso condicional.
Desative contas administrativas que não estejam sendo usadas.
Estabelecer processos para gerenciar o ciclo de vida da identidade
O acesso a identidades não deve durar mais do que os recursos que as identidades acessam. Certifique-se de ter um processo para desabilitar ou excluir identidades quando houver alterações na estrutura da equipe ou nos componentes do software.
Esta diretriz se aplica ao controle de origem, aos dados, aos planos de controle, aos usuários da carga de trabalho, à infraestrutura, às ferramentas, ao monitoramento de dados, aos logs, às métricas e a outras entidades.
Estabeleça um processo de governança de identidade para gerenciar o ciclo de vida de identidades digitais, usuários com altos privilégios, usuários externos/convidados e usuários de carga de trabalho. Implemente revisões de acesso para garantir que, quando as identidades saírem da organização ou da equipe, suas permissões de carga de trabalho sejam removidas.
Proteger segredos não baseados em identidade
Segredos de aplicativos, como chaves pré-compartilhadas, devem ser considerados pontos vulneráveis no sistema. Na comunicação bidirecional, se o provedor ou consumidor for comprometido, riscos de segurança significativos podem ser introduzidos. Essas chaves também podem ser onerosas porque introduzem processos operacionais.
Trate esses segredos como entidades que podem ser extraídas dinamicamente de um repositório secreto. Eles não devem ser codificados nos aplicativos, nos fluxos, nos pipelines de implantação ou em qualquer outro artefato.
Verifique se você tem a capacidade de revogar segredos.
Aplique práticas operacionais que lidam com tarefas como rotação e expiração de chaves.
Para obter informações sobre políticas de rotação, consulte Automatizar a rotação de um segredo para recursos que têm dois conjuntos de credenciais de autenticação e Tutorial: Atualizando a frequência de rotação automática de certificados no Key Vault.
Manter ambientes de desenvolvimento seguros
O acesso de gravação em ambientes de desenvolvedor deve ser fechado, e o acesso de leitura ao código-fonte deve ser limitado a funções com base na necessidade de conhecimento. Você deve ter um processo em vigor que verifique regularmente os recursos e identifique as vulnerabilidades mais recentes.
Manter uma trilha de auditoria
Um aspecto do gerenciamento de identidades é a garantia de que o sistema seja auditável. As auditorias validam se as estratégias de pressuposto de violação são eficazes. A manutenção de uma trilha de auditoria ajuda você a:
Verifique se a identidade está autenticada com autenticação forte. Qualquer ação deve ser rastreável para evitar ataques de repúdio.
Detectar protocolos de autenticação fracos ou ausentes e obter visibilidade e insights sobre autenticações de usuários e aplicativos.
Avalie o acesso das identidades à carga de trabalho com base em requisitos de segurança e de conformidade, considerando o risco da conta de usuário, o status do dispositivo e outros critérios e políticas definidos por você.
Acompanhe o progresso ou o desvio dos requisitos de conformidade.
A maioria dos recursos possui acesso ao plano de dados. Você precisa conhecer as identidades que acessam os recursos e as ações que eles executam. Você pode usar essas informações para diagnósticos de segurança.
Capacitação do Power Platform
O controle de acesso do Power Platform é uma parte vital da arquitetura de segurança geral. Os pontos de controle de acesso podem garantir que os usuários certos tenham acesso aos recursos do Power Platform. Nesta seção, vamos explorar os diferentes pontos de acesso que você pode configurar e a função na estratégia de segurança geral.
Microsoft Entra ID
Todos os produtos do Power Platform usam Microsoft Entra ID (anteriormente Azure Active Directory ou Azure AD) para gerenciamento de identidade e acesso. O Entra ID permite que as organizações protejam e gerenciem a identidade para os ambientes híbridos e multinuvem. A ID do Entra também é essencial para gerenciar convidados de negócios que precisem de acesso a recursos do Power Platform. O Power Platform também usa a ID do Entra para gerenciar outros aplicativos que precisem de integração com APIs do Power Platform usando as capacidades da entidade de serviço. Usando a ID do Entra, o Power Platform pode aproveitar os recursos de segurança mais avançados da ID do Entra, como Acesso Condicional e avaliação contínua de acesso.
Atribuição de licença
O acesso a Power Apps e Power Automate começa com ter uma licença. Os ativos e os dados que um usuário pode acessar são determinados pelo tipo de licença que eles têm. A tabela a seguir descreve, em alto nível, diferenças entre recursos disponíveis para um usuário com base no tipo de plano. Os detalhes granulares de licenciamento podem ser encontrados em Visão geral de licenciamento.
Políticas de acesso condicional
O acesso condicional descreve sua política para uma decisão de acesso. Para usar o acesso condicional, você precisa entender as restrições necessárias para o caso de uso. Configure o Acesso Condicional do Microsoft Entra definindo uma política de acesso com base nas suas necessidades operacionais.
Saiba mais:
- Set up Microsoft Entra Conditional Access
- Acesso condicional e autenticação multifatorial no Power Automate
Acesso contínuo
O acesso contínuo é agilizado quando determinados eventos são avaliados para determinar se o acesso deve ser revogado. Tradicionalmente, com a autenticação do OAuth 2.0, a expiração do token de acesso ocorre quando uma verificação é feita durante a renovação do token. Com acesso contínuo, os eventos críticos de um usuário e as alterações feitas no local de rede são avaliados continuamente para determinar se o usuário ainda deve manter o acesso. Essas avaliações podem acarretar o encerramento antecipado de sessões ativas ou exigir uma reautenticação. Por exemplo, se uma conta de usuário for desabilitada, ela deverá perder o acesso ao aplicativo. A localização também é importante; por exemplo, o token pode ter sido autorizado em um local confiável, mas o usuário alterou a conexão com uma rede não confiável. O acesso contínuo invocaria a avaliação da política de acesso condicional, e o usuário perderia o acesso porque não está mais se conectando de um local aprovado.
Atualmente, com o Power Platform, só o Dataverse dá suporte à avaliação contínua de acesso. A Microsoft está trabalhando para adicionar suporte a outros serviços e clientes do Power Platform. Para obter mais informações, consulte Avaliação Contínua de Acesso.
Com a adoção contínua de modelos de trabalho híbridos e o uso de aplicativos em nuvem, a ID do Entra e tornou um perímetro de segurança primário crucial para proteger usuários e recursos. O acesso condicional estende esse perímetro além de um perímetro de rede para incluir o usuário e a identidade do dispositivo. O acesso contínuo garante que, à medida que os eventos ou os locais de usuário sejam alterados, o acesso seja reavaliado. O uso do Entra ID pelo Power Platform permite implementar governança de segurança organizacional que pode ser aplicada de maneira consistente em todo o portfólio de aplicativos. Revise estas melhores práticas de gerenciamento de identidades para obter mais diretrizes sobre como compilar o próprio plano de uso da ID do Entra com o Power Platform.
Gerenciamento de acesso ao grupo
Em vez de conceder permissões a usuários específicos, atribua acesso a grupos no Microsoft Entra ID. Se um grupo não existir, trabalhe com sua equipe de identidade para criar um. Em seguida, você pode adicionar e remover membros do grupo fora do Azure e verificar se as permissões estão atualizadas. Você também pode usar o grupo para outros fins, como listas de distribuição.
Para obter mais informações, consulte o controle de acesso seguro usando grupos no Microsoft Entra ID.
Detecção de ameaça
Microsoft Entra ID Protection pode ajudá-lo a detectar, investigar e corrigir riscos baseados em identidade. Para obter mais informações, consulte O que é o Identity Protection?.
A detecção de ameaças pode assumir a forma de reação a um alerta de atividade suspeita ou pesquisa proativa de eventos anômalos em logs de atividades. A UEBA (Análise de Comportamento de Usuário e Entidade) no Microsoft Sentinel facilita a detecção de atividades suspeitas. Para obter mais informações, consulte Identifique ameaças avançadas com UEBA no Microsoft Sentinel.
Log de identidade
Power Apps, Power Automate, Copilot Studio, Conectores e log de atividades de Prevenção contra Perda de Dados são acompanhados e exibidos no portal de conformidade do Microsoft Purview. Saiba mais sobre Microsoft Purview.
Registra alterações feitas nos registros de clientes em um ambiente com um banco de dados do Dataverse. A auditoria do Dataverse também registra o acesso do usuário por meio de um aplicativo ou do SDK em um ambiente. Essa auditoria é habilitada no nível do ambiente, e a configuração adicional é necessária para tabelas e colunas individuais.
Funções de administrador do serviço
A ID do Entra contém um conjunto de funções preestabelecidas que podem ser atribuídas a administradores para dar a eles permissão para realizar tarefas administrativas. Você pode revisar a matriz de permissões para obter um detalhamento granular dos privilégios de cada função.
Use Microsoft Entra Privileged Identity Management (PIM) para gerenciar funções de administrador com privilégios elevados no centro de administração do Power Platform.
Proteção dos dados do Dataverse
Um dos principais recursos do Dataverse é o modelo de segurança avançado que pode se adaptar a vários cenários de uso comercial. Este modelo de segurança só permanece disponível quando um banco de dados do Dataverse está no ambiente. Como um profissional de segurança, é provável que você não compile todo o modelo de segurança por conta própria, embora possa ter envolvimento na garantia de que o uso dos recursos de segurança seja consistente com os requisitos de segurança dos dados da organização. O Dataverse usa a segurança baseada em função para agrupar uma coleção de privilégios. Essas funções de segurança podem estar associadas diretamente a usuários, ou podem ser associadas a equipes e unidades de negócios do Dataverse. Para obter mais informações, consulte conceitos de segurança no Microsoft Dataverse.
Configurar a autenticação de usuário no Copilot Studio
Microsoft Copilot Studio dá suporte a várias opções de autenticação. Escolha aquela que atenda às suas necessidades. A autenticação permite que os usuários entrem, concedendo assim ao seu agente acesso a recursos ou informações restritas. Os usuários podem entrar usando Microsoft Entra ID ou qualquer provedor de identidade OAuth 2.0, como Google ou Facebook. Saiba mais em Configurar a autenticação de usuário no Copilot Studio.
Com a segurança baseada em Direct Line, você pode restringir o acesso aos locais que controla habilitando o acesso seguro com chaves secretas ou tokens do Direct Line.
Copilot Studio dá suporte ao SSO (logon único), o que significa que os agentes podem conectar o usuário. O SSO deve ser implementado em suas páginas da Web e aplicativos móveis. Para Microsoft Teams, o SSO será contínuo se você selecionar a opção de autenticação "Somente no Teams". Ele também pode ser configurado manualmente com Azure AD v2; no entanto, nesse caso, o aplicativo Teams deve ser implantado como um arquivo zip, não por meio da implantação do Teams de 1 clique do Copilot Studio.
Saiba mais:
- Configure o logon único com o Microsoft Entra ID
- Configure autenticação única com Microsoft Entra ID para os agentes no Microsoft Teams
- Configurar logon único com um provedor OAuth genérico
Acesse os dados com segurança usando o Customer Lockbox
A maioria das operações, suporte e solução de problemas realizados pelo pessoal da Microsoft (incluindo subprocessadores) não exigem acesso a dados do cliente. Com o Power Platform Customer Lockbox, fornecemos uma interface para que os clientes revisem e aprovem (ou rejeitem) solicitações de acesso a dados nas raras ocasiões em que o acesso a dados do cliente é necessário. Por exemplo, ele é usado quando um engenheiro da Microsoft precisa ter acesso aos dados do cliente, seja em resposta a um tíquete de suporte iniciado pelo cliente ou a um problema identificado pela Microsoft. Para obter mais informações, consulte como acessar com segurança dados do cliente usando o Customer Lockbox no Power Platform e Dynamics 365.
Gerenciar usuários convidados
Talvez seja necessário permitir que usuários convidados acessem ambientes e Power Platform recursos. Assim como os usuários internos, você pode usar o acesso condicional da ID do Microsoft Entra e a avaliação contínua de acesso para garantir que os usuários convidados atendam a um nível elevado de segurança.
Para aprimorar ainda mais a segurança e reduzir o risco de compartilhamento excessivo incidental, bloqueie ou habilite o acesso dos convidados do Microsoft Entra aos seus ambientes com suporte do Dataverse, conforme necessário.
Informações relacionadas
- Configurar o gerenciamento de identidade e acesso
- Como conectar e autenticar em fontes de dados
- Autenticação em serviços do Power Platform
- Conceitos de segurança no Microsoft Dataverse
- Perguntas frequentes sobre segurança na Power Platform
- Matriz de permissão do administrador de serviço
- Avaliação contínua de acesso
- Set up Microsoft Entra Conditional Access
- Recomandos para acesso condicional e autenticação multifator no Microsoft Power Automate
- Plataforma de identidade da Microsoft e fluxo de código de autorização do OAuth 2.0
- O que há de novo no Microsoft Entra ID?
- Funções integradas do Microsoft Entra
- Visão geral do controle de acesso baseado em função no Microsoft Entra ID
Lista de verificação de segurança
Consulte o conjunto completo de recomendações.