Recomendações para gestão de identidades e acessos

Aplica-se a esta recomendação da lista de verificação de Segurança do Power Platform Well-Architected:

Este guia descreve as recomendações para autenticar e autorizar identidades que estão a tentar aceder aos seus recursos de carga de trabalho.

Do ponto de vista do controlo técnico, a identidade é sempre o perímetro primário. Este âmbito não inclui apenas a periferia da sua carga de trabalho. Também inclui os componentes individuais que estão dentro da sua carga de trabalho.

As identidades típicas incluem:

• Seres humanos. Utilizadores, administradores, operadores, auditores e agentes mal-intencionados da aplicação.
• Sistemas. Identidades de carga de trabalho, identidades geridas, chaves de API, principais de serviço e recursos do Azure.
• Anónimos. Entidades que não forneceram qualquer prova sobre quem são.

Definições

OI Microsoft Entra ID como o fornecedor de identidade para o Power Platform

Todos os produtos do Power Platform utilizam o Microsoft Entra ID (anteriormente Azure Active Directory ou Azure AD) para gestão de identidades e acessos. O Entra ID permite que as organizações protejam e giram a identidade para os seus ambientes híbridos e multicloud. O Entra ID também é essencial para gerir convidados da empresa que necessitam de acesso a recursos do Power Platform. O Power Platform também utiliza o Entra ID para gerir outras aplicações que necessitam de integração com APIs do Power Platform utilizando as capacidades do principal de serviço. Ao utilizar o Entra ID, o Power Platform pode tirar partido de funcionalidades de segurança mais avançadas do Entra ID, como o Acesso Condicional e a Avaliação Contínua de Acesso.

Autenticação

A autenticação é um processo que verifica identidades. A identidade do requerente é obrigada a fornecer alguma forma de identificação verificável. Por exemplo:

• Um nome de utilizador e uma palavra-passe.
• Um segredo pré-partilhado, como uma chave de API que concede acesso.
• Um token de assinatura de acesso partilhado (SAS).
• Um certificado usado na autenticação mútua TLS (Transport Layer Security).

A autenticação do Power Platform envolve uma sequência de pedidos, respostas e redirecionamentos entre o browser do utilizador e os serviços do Power Platform ou do Azure. A sequência segue o fluxo de concessão do código de autorização do Microsoft Entra ID.

Ligar e autenticar a uma origem de dados é feito em separado da autenticação num serviço do Power Platform. Para obter mais informações, consulte Ligar e autenticar a origens de dados.

Autorização

O Power Platform utiliza a Plataforma de Identidade da Microsoft do Microsoft Entra ID para autorização de todas as chamadas à API com o protocolo OAuth 2.0 padrão do setor.

Principais estratégias de design

Para entender as necessidades de identidade para uma carga de trabalho, precisa de listar o utilizador e os fluxos do sistema, os ativos de carga de trabalho e as personas, bem como as ações que irão tomar.

Cada caso de utilização provavelmente terá o seu próprio conjunto de controlos que precisa de estruturar com uma mentalidade que presume falhas de segurança. Com base nos requisitos de identidade do caso de utilização ou das personas, identifique as escolhas condicionais. Evite utilizar uma solução para todos os casos de utilização. Por outro lado, os controlos não devem ser tão granulares a ponto de introduzir despesas gerais de gestão desnecessárias.

Tem de registar o registo de acessos de identidade. Ao fazê-lo, ajuda a validar os controlos e pode utilizar os registos 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 pedidos, respostas e redirecionamentos entre o browser do utilizador e os serviços do Power Platform ou do Azure. A sequência segue o fluxo de concessão do código de autorização do Microsoft Entra ID. O Power Platform autentica automaticamente todos os utilizadores que acedem à carga de trabalho para diversas finalidades.

Acesso de dentro para fora. A sua carga de trabalho terá de aceder a outros recursos. Por exemplo, ler ou escrever para a plataforma de dados, obter segredos do arquivo de segredos e registar telemetria para serviços de monitorização. Pode até precisar de aceder a serviços de terceiros. Estes são todos os requisitos de identidade da carga de trabalho. No entanto, também tem de considerar os requisitos de identidade do recurso; por exemplo, como os pipelines de implementação serão executados e autenticados.

Determinar ações para autorização

Em seguida, tem de saber o que cada identidade autenticada está a tentar fazer para que estas ações possam ser autorizadas. As ações podem ser divididas pelo tipo de acesso que requerem:

• Acesso ao plano de dados. As ações que ocorrem no plano de dados causam a transferência de dados. Por exemplo, uma aplicação a ler ou escrever dados do Microsoft Dataverse ou a escrever registos no Application Insights.

• Acesso ao plano de controlo. As ações que ocorrem no plano de controlo fazem com que um Power Platform recurso seja criado, modificado ou eliminado. Por exemplo, modificar propriedades de ambiente ou criar uma Política de dados.

As aplicações normalmente visam operações do plano de dados, enquanto as operações geralmente acedem a planos de controlo e de dados.

Fornecer autorização baseada em funções

Com base na responsabilidade de cada identidade, autorize as ações que devam ser permitidas. Não se deve permitir que uma identidade faça mais do que aquilo de que necessita. Antes de definir regras de autorização, precisa de ter uma compreensão clara de quem ou o que está a fazer pedidos, o que esta função pode fazer e até que ponto ela pode fazê-lo. Estes fatores levam a escolhas que combinam identidade, função e âmbito.

Considere o seguinte:

• A carga de trabalho precisa de ter acesso ao plano de dados do Dataverse para acesso de leitura e de escrita?
• A carga de trabalho também precisa de acesso às propriedades do ambiente?
• Se a identidade for comprometida por um agente mal-intencionado, qual seria o impacto para o sistema em termos de confidencialidade, integridade e disponibilidade?
• A carga de trabalho necessita de acesso permanente ou o acesso condicional pode ser considerado?
• A carga de trabalho executa ações que requerem permissões administrativas/elevadas?
• Como é que a carga de trabalho irá interagir com serviços de terceiros?
• Para cargas de trabalho de aplicações inteligentes, como agentes, tem requisitos de início de sessão único (SSO)?
• O agente está a operar em modo não autenticado, em modo autenticado ou em ambos?

Atribuição de funções

Uma função é um conjunto de permissões atribuído a uma identidade. Atribua funções que só permitam que a identidade conclua a tarefa e não mais do que isso. Quando as permissões do utilizador estão restringidas aos requisitos do seu trabalho, é mais fácil identificar comportamentos suspeitos ou não autorizados no sistema.

Faça as seguintes perguntas:

• O acesso só de leitura é suficiente?
• A identidade precisa de permissões para eliminar recursos?
• A função só precisa de ter acesso aos registos que criou?
• O acesso hierárquico baseado na unidade de negócio em que o utilizador está é necessário?
• A função precisa de permissões administrativas ou elevadas?
• A função precisa de acesso permanente a estas permissões?
• O que acontece se o utilizador mudar de emprego?

Limitar o nível de acesso que utilizadores, aplicações ou serviços têm reduz a superfície de ataque potencial. Se conceder apenas as permissões mínimas necessárias para executar tarefas específicas, o risco de um ataque bem-sucedido ou de acesso não autorizado é significativamente reduzido. Por exemplo, os programadores só necessitam de acesso de criador ao ambiente de desenvolvimento, mas não ao ambiente de produção; só necessitam de acesso para criar recursos, mas não para alterar as propriedades do ambiente; e podem só precisar de acesso para ler/escrever dados do Dataverse, mas não alterar o modelo de dados ou atributos da tabela do Dataverse.

Evite permissões que visam utilizadores individuais. As permissões granulares e personalizadas criam complexidade e confusão e podem tornar-se difíceis de manter à medida que os utilizadores mudam de funções e se movem pela empresa, ou à medida que novos utilizadores com requisitos de autenticação semelhantes se juntam à equipa. Esta situação pode criar uma configuração legada complexa que é difícil de manter e que afeta negativamente a segurança e a fiabilidade.

Troca: uma abordagem de controlo de acesso granular permite melhor auditoria e monitorização das atividades dos utilizadores.

Conceda funções que comecem com o menor privilégio e adicione mais com base nas suas necessidades operacionais ou de acesso a dados. As suas equipas técnicas têm de ter orientações claras para implementar permissões.

Efetuar seleções de acesso condicional

Não dê a todas as identidades o mesmo nível de acesso. Baseie as suas decisões em dois fatores principais:

• Hora. Durante quanto tempo a identidade pode aceder ao seu ambiente.
• Privilégio. O nível de permissões.

Estes fatores não se excluem mutuamente. Uma identidade comprometida que tenha mais privilégios e duração ilimitada de acesso pode obter mais controlo sobre o sistema e os dados ou utilizar este acesso para continuar a alterar o ambiente. Restrinja estes fatores de acesso como uma medida preventiva e para controlar o raio de impacto.

As abordagens Just in Time (JIT) fornecem os privilégios necessários apenas quando são necessárias.

O acesso suficiente (JEA) fornece apenas os privilégios necessários.

Embora o tempo e o privilégio sejam os fatores principais, existem outras condições que se aplicam. Por exemplo, também pode utilizar o dispositivo, a rede e a localização de onde originou o acesso para definir políticas.

Utilize controlos avançados que filtrem, detetem e bloqueiem acesso não autorizado, incluindo parâmetros como a identidade e a localização do utilizador, o estado de funcionamento do dispositivo, o contexto da carga de trabalho, a classificação de dados e as anomalias.

Por exemplo, a sua carga de trabalho poderá ter de ser acedida por identidades de terceiros, como fornecedores, parceiros e clientes. Estes precisam do nível de acesso adequado, em vez das permissões predefinidas que fornece aos colaboradores a tempo inteiro. A diferenciação clara das contas externas facilita a prevenção e a deteção de ataques provenientes destes 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 destes sistemas e aplicações. O compromisso ou a utilização indevida podem ter um efeito prejudicial na sua empresa e nos 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 determinados adversários requer que adote uma abordagem completa e ponderada para isolar estes sistemas dos riscos. Seguem-se algumas estratégias:

• Minimize o número de contas de impacto crítico.

• Utilize funções separadas em vez de elevar os privilégios para identidades existentes.

• Evite o acesso permanente ou corrente utilizando os recursos JIT do seu IdP. Para situações de emergência, siga um processo de acesso de emergência.

• Utilize protocolos de acesso modernos, como a autenticação sem palavra-passe ou a autenticação multifator. Externalize estes mecanismos para o seu IdP.

• Imponha atributos chave de segurança utilizando políticas de acesso condicional.

• Desative contas administrativas que não estão a ser utilizadas.

Estabelecer processos para gerir o ciclo de vida da identidade

O acesso às identidades não deve durar mais do que os recursos aos quais as identidades acedem. Certifique-se de que tem um processo para desativar ou eliminar identidades quando houver alterações na estrutura da equipa ou nos componentes de software.

Esta orientação aplica-se ao controlo de origem, dados, planos de controlo, utilizadores de carga de trabalho, infraestrutura, ferramentas, monitorização de dados, registos, métricas e outras entidades.

Estabeleça um processo de governação de identidades para gerir o ciclo de vida de identidades digitais, utilizadores com privilégios elevados, utilizadores externos/convidados e utilizadores de carga de trabalho. Implemente revisões de acesso para garantir que quando as identidades deixarem a organização ou a equipa, as respetivas permissões de carga de trabalho serão removidas.

Proteger segredos não baseados em identidade

Os segredos da aplicação, como as chaves pré-partilhadas, devem ser considerados pontos vulneráveis do sistema. Na comunicação bidirecional, se o fornecedor ou o consumidor forem comprometidos, podem ser introduzidos riscos de segurança significativos. Estas chaves também podem ser pesadas porque introduzem processos operacionais.

Trate estes segredos como entidades que podem ser retiradas dinamicamente de um arquivo de segredos. Não devem estar codificados nas suas aplicações, fluxos, pipelines de implementação ou em qualquer outro artefacto.

Certifique-se de que tem a capacidade de revogar segredos.

Aplique práticas operacionais que processem tarefas como rotação e expiração de chaves.

Para obter informações sobre as políticas de rotação, consulte Automatizar a rotação de um segredo para recursos que tenham dois conjuntos de credenciais de autenticação e Tutorial: Atualizar a frequência de rotação automática de certificados no Key Vault.

Manter os ambientes de desenvolvimento seguros

O acesso de escrita aos ambientes de programação deve ser fechado e o acesso de leitura ao código de origem deve estar limitado a funções com base na necessidade de conhecimento. Deve ter implementado um processo que analise recursos regularmente e identifique as vulnerabilidades mais recentes.

Manter um registo de auditoria

Um aspeto da gestão de identidade é garantir que o sistema é auditável. As auditorias validam se as estratégias que presumem falhas de segurança são eficazes. Manter um registo de auditoria ajuda-o a:

• Verificar se a identidade tem uma autenticação forte. Qualquer ação deve ser rastreável para evitar ataques de rejeição.

• Detetar protocolos de autenticação fracos ou em falta e obter visibilidade e informações sobre os inícios de sessão de utilizadores e aplicações.

• Avaliar o acesso das identidades à carga de trabalho com base nos requisitos de conformidade e segurança e considerar o risco da conta de utilizador, o estado do dispositivo e outros critérios e políticas que definiu.

• Monitorizar o progresso ou o desvio em relação aos requisitos de conformidade.

A maioria dos recursos tem acesso ao plano de dados. Precisa de conhecer as identidades que acedem aos recursos e as ações que executam. Pode utilizar estas informações para diagnósticos de segurança.

Facilitação do Power Platform

O controlo de acesso do Power Platform é uma parte essencial da sua arquitetura de segurança geral. Os pontos de controlo de acesso podem garantir que os utilizadores certos estão a obter acesso aos recursos do Power Platform. Nesta secção, vamos explorar os diferentes pontos de acesso que pode configurar e a sua função na estratégia de segurança geral.

Microsoft Entra ID

Todos os produtos do Power Platform utilizam o Microsoft Entra ID (anteriormente Azure Active Directory ou Azure AD) para gestão de identidades e acessos. O Entra ID permite que as organizações protejam e giram a identidade para os seus ambientes híbridos e multicloud. O Entra ID também é essencial para gerir convidados da empresa que precisam de acesso a recursos do Power Platform. O Power Platform também utiliza o Entra ID para gerir outras aplicações que necessitam de integração com APIs do Power Platform utilizando as capacidades do principal de serviço. Ao utilizar o Entra ID, o Power Platform pode tirar partido de funcionalidades de segurança mais avançadas do Entra ID, como o Acesso Condicional e a Avaliação Contínua de Acesso.

Atribuição de licenças

O acesso ao Power Apps e ao Power Automate começa com possuir uma licença. Os ativos e os dados a que um utilizador pode aceder são determinados pelo tipo de licença que têm. A tabela seguinte descreve, a um alto nível, as diferenças nos recursos disponíveis para um utilizador com base no tipo de plano. É possível encontrar detalhes de licenciamento granulares na Descrição geral de licenciamento.

Políticas de acesso condicional

O acesso condicional descreve a sua política para decisões de acesso. Para utilizar o acesso condicional, tem de compreender as restrições necessárias para o caso de utilização. Configure o Acesso Condicional do Microsoft Entra configurando uma política de acesso baseada nas suas necessidades operacionais.

Saber mais:

• Configurar o Acesso Condicional do Microsoft Entra
• Acesso condicional e autenticação multifator no Power Automate

Acesso contínuo

O acesso contínuo acelera quando determinados eventos são avaliados para determinar se o acesso deve ser revogado. Tradicionalmente, com a autenticação OAuth 2.0, a expiração do token de acesso ocorre quando uma verificação é feita durante a renovação do token. Com o acesso contínuo, os eventos críticos e as alterações de localização de rede de um utilizador são continuamente avaliados para determinar se o utilizador ainda deve manter o acesso. Estas avaliações podem resultar no encerramento antecipado de sessões ativas ou requerer uma nova autenticação. Por exemplo, se uma conta de utilizador estiver desativada, deverá perder o acesso à aplicação. A localização também é importante; por exemplo, o token pode ter sido autorizado a partir de um local fiável, mas o utilizador alterou a sua ligação para uma rede não fiável. O acesso contínuo invocaria a avaliação da política de acesso condicional e o utilizador perderia o acesso porque já não está a ligar a partir de uma localização aprovada.

Atualmente, com o Power Platform, apenas o Dataverse suporta a Avaliação Contínua de Acesso. A Microsoft está a trabalhar 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 a utilização de aplicações na cloud, o Entra ID tornou-se um perímetro de segurança primário crucial para proteger os utilizadores e os recursos. O acesso condicional estende este perímetro para além de um perímetro de rede para incluir a identidade do utilizador e do dispositivo. O acesso contínuo garante que, à medida que os eventos ou as localizações dos utilizadores mudam, o acesso é reavaliado. A utilização do Entra ID do Power Platform permite que implemente uma governação de segurança ao nível da organização que pode aplicar de forma consistente em todo seu portfólio de aplicações. Reveja estas melhores práticas de gestão de identidades para obter mais orientação na criação do seu próprio plano de utilização do Entra ID com o Power Platform.

Gestão de acesso a grupos

Em vez de conceder permissões a utilizadores específicos, atribua acesso a grupos no Microsoft Entra ID. Se não existir um grupo, trabalhe com a sua equipa de identidade para criar um. Em seguida, pode adicionar e remover membros do grupo fora do Azure e certificar-se de que as permissões estão atualizadas. Também pode utilizar o grupo para outras finalidades, como listas de correio.

Para obter mais informações, consulte Controlo de acesso seguro utilizando grupos no Microsoft Entra ID.

Deteção de ameaças

A Proteção do Microsoft Entra ID pode ajudá-lo a detetar, investigar e remediar riscos baseados na identidade. Para obter mais informações, consulte O que é o Identity Protection?.

A deteção de ameaças pode assumir a forma de reação a um alerta de atividade suspeita ou de procura proativa de eventos anómalos nos registos de atividades. A Análise Comportamental de Utilizadores e Entidades (UEBA) no Microsoft Sentinel facilita a deteção de atividades suspeitas. Para obter mais informações, consulte Identificar ameaças avançadas com a UEBA no Microsoft Sentinel.

Registo de identidades

O registo de atividades do Power Apps, do Power Automate, do Copilot Studio, de Conectores e da Prevenção de Perda de Dados é monitorizado e visto a partir do portal de conformidade do Microsoft Purview. Saiba mais sobre o Microsoft Purview.

Regista as alterações que são feitas em registos de clientes num ambiente com uma base de dados do Dataverse. A auditoria do Dataverse também regista o acesso de utilizador através de uma aplicação ou através do SDK num ambiente. Esta auditoria está ativada ao nível do ambiente e é necessária uma configuração adicional para as tabelas e colunas individuais.

Funções de administrador do serviço

O Entra ID contém um conjunto de funções pré-estabelecidas que podem ser atribuídas aos administradores para lhes dar permissão para executar tarefas administrativas. Pode rever a matriz de permissões para obter uma discriminação granular dos privilégios de cada função.

Utilize o Microsoft Entra Privileged Identity Management (PIM) para gerir funções de administrador com privilégios elevados no centro de administração do Power Platform.

Proteger dados do Dataverse

Uma das principais funcionalidades do Dataverse é o seu modelo de segurança avançado que pode adaptar-se a muitos cenários de utilização de negócio. Este modelo de segurança só está disponível quando existe uma base de dados do Dataverse no ambiente. Como profissional de segurança, provavelmente não estará a criar todo o modelo de segurança, mas poderá estar envolvido em garantir que a utilização das funcionalidades de segurança é consistente com os requisitos de segurança de dados da organização. O Dataverse utiliza a segurança baseada em funções para agrupar uma coleção de privilégios. Estes direitos de acesso podem ser associados diretamente a utilizadores ou podem ser associados a equipas ou unidades de negócio do Dataverse. Para obrer mais informações, consulte Conceitos de segurança no Microsoft Dataverse.

Configurar a autenticação de utilizador no Copilot Studio

O Microsoft Copilot Studio suporta várias opções de autenticação. Escolha a que se adequa às suas necessidades. A autenticação permite que os utilizadores iniciem sessão, concedendo assim acesso ao seu agente a recursos ou a informações restritas. Os utilizadores podem iniciar sessão com o Microsoft Entra ID ou com qualquer fornecedor de identidade OAuth 2.0, como a Google ou o Facebook. Obtenha mais informações em Configurar a autenticação de utilizador no Copilot Studio.

Com a segurança baseada no Direct Line, pode restringir o acesso apenas a localizações que controla, permitindo acesso seguro com segredos ou tokens do Direct Line.

O Copilot Studio suporta início de sessão único (SSO), o que significa que os agentes podem iniciar sessão pelo utilizador. O SSO tem de ser implementado nas suas páginas da Web e aplicações móveis. Para o Microsoft Teams, o SSO está totalmente integrado se selecionar a opção de autenticação "Só no Teams". Também pode ser configurado manualmente com o Azure AD v2; no entanto, neste caso, a aplicação Teams tem de ser implementada como um ficheiro zip, não através da implementação com 1 clique do Teams a partir do Copilot Studio.

Saber mais:

• Configurar início de sessão único com o Microsoft Entra ID
• Configurar início de sessão único com o Microsoft Entra ID para agentes no Microsoft Teams
• Configurar o início de sessão único com um fornecedor OAuth genérico

Aceder aos dados com segurança utilizando o Sistema de Proteção de Dados do Cliente

A maioria das operações, suporte e resolução de problemas efetuados por colaboradores da Microsoft (incluindo subprocessadores) não necessita de acesso a dados de clientes. Com o Sistema de Proteção de Dados do Cliente do Power Platform, fornecemos uma interface para que os clientes revejam e aprovem (ou rejeitem) pedidos de acesso a dados na rara ocasião em que é necessário o acesso a dados dos clientes. Por exemplo, é utilizado quando um engenheiro da Microsoft necessita de aceder a dados de clientes, seja em resposta a um pedido de suporte iniciado pelo cliente ou um problema identificado pela Microsoft. Para obter mais informações, consulte Aceder com segurança aos dados de clientes utilizando o Sistema de Proteção de Dados do Cliente no Power Platform e no Dynamics 365.

Gerenciar usuários convidados

Talvez seja necessário permitir que usuários convidados acessem ambientes e Power Platform recursos. Como os usuários internos, você pode usar o acesso condicional do Microsoft Entra ID 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 melhorar ainda mais a segurança e reduzir o risco de compartilhamento excessivo incidental, bloqueie ou habilite o acesso de convidados do Microsoft Entra aos seus ambientes apoiados pelo Dataverse, conforme necessário.

Informações relacionadas

• Configurar o gerenciamento de identidade e acesso
• Ligar a e autenticar origens de dados
• Autenticar para serviços do Power Platform
• Conceitos de segurança no Microsoft Dataverse
• FAQs de segurança do Power Platform
• Matriz de permissão do administrador de serviços
• Avaliação contínua de acesso
• Configurar o Acesso Condicional do Microsoft Entra
• Recomendações de acesso condicional e autenticação multifator no Microsoft Power Automate
• Fluxo de código de autorização da plataforma de identidade da Microsoft e OAuth 2.0
• Novidades do Microsoft Entra ID?
• Funções incorporadas do Microsoft Entra
• Descrição geral do controlo de acesso baseado em funções no Microsoft Entra ID

Lista de verificação de segurança

Consulte o conjunto completo de recomendações.