Partilhar via

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

  • Artigo

Aplica-se a esta Power Platform recomendação de lista de verificação de segurança bem arquitetada:

SE:05 Implemente uma gestão de identidades e acessos (IAM) rigorosa, condicional e auditável em todos os utilizadores da carga de trabalho, membros da equipa e componentes do sistema. Limite o acesso exclusivamente ao necessário. Utilize padrões modernos da indústria para todas as implementações de autenticação e autorização. Restrinja e audite rigorosamente o acesso que não se baseia na identidade.

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:

  • 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ónimo. Entidades que não forneceram qualquer prova sobre quem são.

Definições

Termos Definição
Autenticação (AuthN) Um processo que verifica se uma identidade é quem é ou diz ser.
Autorização (AuthZ) Um processo que verifica se uma identidade tem permissão para executar uma ação pedida.
Acesso condicional Um conjunto de regras que permite ações com base em critérios especificados.
IdP Um fornecedores de identidade, como o Microsoft Entra ID.
Persona Uma função ou um título que tenha um conjunto de responsabilidades e ações.
Chaves pré-partilhadas Um tipo de segredo que é partilhado entre um fornecedor e um consumidor e utilizado através de um mecanismo seguro e acordado.
Identidade de recurso Uma identidade definida para recursos de cloud que é gerida pela plataforma.
Função Um conjunto de permissões que definem o que um utilizador ou grupo pode fazer.
Scope Diferentes níveis de hierarquia organizacional onde uma função tem permissão para operar. Além disso, um grupo de recursos num sistema.
Principal de segurança Uma identidade que fornece permissões. Pode ser um utilizador, um grupo ou um principal de serviço. Qualquer membro do grupo obtém o mesmo nível de acesso.
Identidade do utilizador Uma identidade para uma pessoa, como um funcionário ou um utilizador externo.
Identidade da carga de trabalho Uma identidade de sistema para uma aplicação, serviço, script, contentor ou outro componente de uma carga de trabalho que é utilizada para se autenticar a outros serviços e recursos.

Nota

Uma identidade pode ser agrupada com outras identidades semelhantes sob um elemento principal chamado principal de segurança. Um grupo de segurança é um exemplo de um principal de segurança. Esta relação hierárquica simplifica a manutenção e melhora a consistência. Como os atributos de identidade não são tratados a nível individual, as hipóteses de erros também são reduzidas. Neste artigo, o termo identidade inclui as entidades de segurança.

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

Power Platform usa Microsoft Entra a ID Microsoft Identity Platform para autorização de todas as chamadas de API com o protocolo 2.0 padrão OAuth 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 exterior-in. 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.

  • Controle o acesso ao plano. 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 a que tem de fazer. 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 copilotos, você tem requisitos de logon único (SSO)?
  • O copiloto está a operar no modo não autenticado, no 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.

Compensação: Uma abordagem granular de controle de acesso permite uma melhor auditoria e monitoramento das atividades do utente.

Conceda funções que comecem com privilégios mínimos 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ários.

Just Enough Access (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.

Use controles fortes que filtrem, detetem e bloqueiem o acesso não autorizado, incluindo parâmetros como identidade e localização do utente, integridade do dispositivo, contexto da carga de trabalho, classificação de dados e 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.

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

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

  • Use protocolos de acesso modernos, como autenticação sem senha ou autenticação multifator. Externalize estes mecanismos para o seu IdP.

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

  • Descomissionar contas administrativas que não estão a ser usadas.

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 governança de identidade para gerenciar o ciclo de vida de identidades digitais, usuários com privilégios elevados, usuários externos/convidados e usuários 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 repúdio.

  • Detete protocolos de autenticação fracos ou ausentes e obtenha visibilidade e informações sobre entradas de usuários e aplicativos.

  • 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.

  • Acompanhe o progresso ou desvio dos 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.

Diagrama de um sistema de computação na cloud.

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 uma decisão 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.

Para mais informações, consulte:

Acesso contínuo

O acesso contínuo acelera quando determinados eventos são avaliados para determinar se o acesso deve ser revogado. Tradicionalmente, com OAuth a autenticação 2.0, token de acesso expiração 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. Microsoft está a trabalhar para adicionar suporte a outros Power Platform serviços e clientes. 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 de Comportamento de Usuários 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 o UEBA no Microsoft Sentinel.

Registo de identidades

Power Apps, Power Automate, Copilot Studio, Conectores e registro de atividades de Prevenção de Perda de Dados são rastreados e visualizados no Microsoft portal de conformidade Purview. Para obter mais informações, consulte Saiba mais sobre Microsoft o 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 do utente em Copilot Studio

Copilot Studio suporta várias opções de autenticação. Escolha o que atende às suas necessidades. A autenticação permite que os usuários façam login, concedendo assim ao seu copiloto acesso a recursos ou informações restritas. Os usuários podem fazer login usando o Microsoft Entra ID ou qualquer OAuth provedor de identidade 2.0, como o Google ou Facebook. Saiba mais em Configurar autenticação de utente em Copilot Studio.

Com Direct Line segurança baseada, você pode restringir o acesso a locais que você controla habilitando o acesso seguro com Direct Line segredos ou tokens.

Copilot Studio suporta logon único (SSO), o que significa que copilots podem entrar no utente. O SSO deve ser implementado em suas páginas da Web e aplicativos móveis. Pois Microsoft Teams, o SSO é perfeito se você selecionar a opção de autenticação "Somente no Teams". Ele também pode ser configurado manualmente com Azure AD a v2, no entanto, neste caso, o aplicativo Teams deve ser implantado como um arquivo zip, não através da implantação do Teams com Copilot Studio 1 clique.

Saber mais:

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

A maioria das operações, suporte e solução de problemas realizados pelo Microsoft pessoal (incluindo subprocessadores) não requer acesso aos dados do cliente. 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, ele é usado quando um Microsoft engenheiro precisa acessar dados do cliente, seja em resposta a um tíquete de suporte iniciado pelo cliente ou a um problema identificado por 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.

Lista de verificação de segurança

Consulte o conjunto completo de recomendações.

Lista de verificação de segurança