Compartilhar via

Recomendações para gerenciamento de identidades e acesso

  • Artigo

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

SE:05 Implemente o Gerenciamento de Identidades e Acesso (IAM) rígido, condicional e auditável em todos os usuários da carga de trabalho, membros da equipe e componentes do sistema. Limite o acesso exclusivamente a conforme 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 estejam tentando acessar recursos da carga de trabalho.

De uma perspectiva de controle técnico, a identidade é sempre o perímetro primário. Este escopo não inclui apenas as bordas da carga de trabalho. Ele também inclui componentes individuais que estejam dentro da 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 do Azure.
  • Anônimo. Entidades que não deram nenhuma evidência sobre quem são.

Definições

Terms Definição
Autenticação (AuthN) Um processo que verifica se uma identidade é quem ou o que ela diz que é.
Autorização (AuthZ) Um processo que verifica se uma identidade tem permissão para realizar uma ação solicitada.
Acesso condicional Um conjunto de regras que permite ações baseadas em critérios especificados.
IdP Um provedor de Identidade, como a ID do Microsoft Entra.
Persona Uma função ou um cargo que tenha 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.
Entidade de segurança Uma identidade que dá permissões. Ela 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 usuário 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.

Observação

Uma identidade pode ser agrupada com outras identidades semelhantes sob um pai 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 inclui entidades de segurança.

ID do Microsoft Entra como o provedor de identidade para Power Platform

Todos os produtos do Power Platform usam a ID do Microsoft Entra (anteriormente conhecido como 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.

Autenticação

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 de protocolo TLS mútua.

A autenticação do Power Platform envolve uma sequência de solicitações, respostas e redirecionamentos entre o navegador do usuário e os serviços do Azure ou Power Platform. A sequência segue o fluxo de concessão de código de autenticação do Microsoft Entra ID.

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.

Autorização

Power Platform usa Microsoft Entra ID Microsoft Identity Platform para autorização de todas as chamadas de API com o protocolo padrão da indústria OAuth 2.0.

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 pressuposição da violação. Com base nos requisitos de identidade do caso de uso ou das personas, identifique as escolhas 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 em 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 os serviços do Azure ou Power Platform. A sequência segue o fluxo de concessão de código de autenticação do Microsoft Entra ID. 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 vai precisar ter acesso a 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 da identidade do recurso; por exemplo, como os pipelines de implantação vão ser executados e autenticados.

Determinar ações de 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 leia ou grave dados no Microsoft Dataverse, ou ainda que grave 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 normalmente visam operações do plano de dados, e as operações normalmente têm acesso a planos de dados e controle.

Oferecer autorização baseada em função

Com base na responsabilidade de cada identidade, autorize ações que devam ser permitidas. Não se deve permitir que uma identidade faça mais do que o necessário. Para definir regras de autorização, você precisa ter um reconhecimento claro de quem ou o que está fazendo solicitações, o que essa função pode fazer e até que ponto ela pode fazer isso. Esses fatores acarretam escolhas que integram identidade, função e escopo.

Considere estes fatores:

  • A carga de trabalho precisa ter acesso ao plano de dados ao Dataverse ter acesso de leitura e gravação?
  • A carga de trabalho também precisa de acesso a propriedades de 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 copilotos, vocês têm requisitos de logon único (SSO)?
  • O copiloto 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 só permitam que a identidade conclua a tarefa, e nada mais. Quando as permissões do usuário permanecem restritas aos requisitos do trabalho, fica mais fácil identificar um comportamento suspeito ou não autorizado 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 criados por ela?
  • O acesso hierárquico se baseia na unidade de negócios na qual o usuário é necessário?
  • 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ê só conceder as permissões mínimas necessárias para realizar tarefas específicas, o risco de um ataque bem-sucedido ou acesso não autorizado vai ser reduzido significativamente. 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.

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

Conceda funções que começam com o menor privilégio e adicionam mais com base em suas necessidades operacionais ou de acesso a dados. As equipes técnicas devem ter diretrizes claras para implementar permissões.

Fazer escolhas de acesso condicional

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

  • Hora. Por quanto tempo a identidade pode ter acesso ao ambiente.
  • Privilégio. O nível de permissões.

Esses fatores não são mutuamente excludentes. Uma identidade comprometida com 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 alterando o ambiente. Restrinja esses fatores de acesso tanto como medida preventiva quanto para controlar o raio de explosão.

Abordagens Just in Time (JIT) fornecem os privilégios necessários somente quando eles 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 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, incluindo parâmetros como identidade e localização do usuário, integridade do dispositivo, contexto da carga de trabalho, classificação de dados e anomalias.

Por exemplo, a carga de trabalho pode precisar ser acessada por identidades de terceiros, como fornecedores, parceiros e clientes. Eles precisam do nível indicado de acesso, em vez das permissões padrão dadas por você para 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 à segurança de maior impacto porque as tarefas realizadas por eles exigem acesso privilegiado a um amplo conjunto desses sistemas e aplicativos. O comprometimento ou o uso indevido podem ter um efeito prejudicial sobre os negócios e os 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 separadas em vez de elevar privilégios para identidades existentes.

  • Evite acesso permanente ou em pé 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 esses mecanismos para o IdP.

  • Reforce os atributos-chave de segurança usando políticas de acesso condicional.

  • Desative contas administrativas que não estejam sendo utilizadas.

Estabelecer processos para gerenciar o ciclo de vida da identidade

O acesso a identidades não deve durar mais do que os recursos acessados pelas identidades. Verifique se você tem um processo para desabilitar ou excluir identidades quando houver alterações na estrutura da equipe ou nos componentes de 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 deixarem a organização ou a equipe, as permissões da carga de trabalho sejam removidas.

Proteger segredos não baseados em identidade

Os segredos de aplicativo, como chaves pré-compartilhadas, devem ser considerados pontos vulneráveis no sistema. Na comunicação bidirecional, se o provedor ou o consumidor está comprometido, riscos à segurança significativos podem ser introduzidos. Essas chaves também podem ser onerosas porque introduzem processos operacionais.

Trate esses segredos como entidades que possam ser extraídas dinamicamente de um repositório de segredos. 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 lidem 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 tenham dois conjuntos de credenciais de autenticação e Tutorial: atualização da frequência de autorrotação 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 pressuposição da violação são eficazes. A manutenção de uma trilha de auditoria ajuda você a:

  • Verificar se a identidade está autenticada com autenticação forte. Qualquer ação deve ser rastreável para evitar ataques de repúdio.

  • Detecte protocolos de autenticação fracos ou ausentes e obtenha visibilidade e insights sobre logins de usuários e aplicativos.

  • Avaliar o acesso por identidades à carga de trabalho com base em requisitos de conformidade e segurança, além de levar em consideração 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 desvio dos requisitos de conformidade.

A maioria dos recursos tem acesso ao plano de dados. Você precisa conhecer as identidades com acesso a recursos e as ações realizadas por eles. Você pode usar essas informações no diagnóstico de segurança.

Facilitaçã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 a ID do Microsoft Entra (anteriormente conhecido como 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.

Diagrama de um sistema de computação em nuvem.

Atribuição de licença

O acesso a Power Apps e Power Automate começa com 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 compreender as restrições necessárias do caso de uso. Configure o acesso condicional do Microsoft Entra definindo uma política de acesso baseada nas necessidades operacionais.

Para obter mais informações, consulte:

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 2.0, a expiração do token de acesso ocorre quando uma verificação é feita durante a renovação do token. OAuth 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 for desabilitada, uma conta de usuário deverá perder 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. Microsoft está trabalhando para adicionar suporte a outros Power Platform serviços e clientes. Para obter 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 Power Platform da ID do Entra permite a você implementar governança de segurança no nível da organização 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 na ID do Microsoft Entra. Se um grupo não existir, trabalhe com a equipe de identidade para criar um. 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 Controle de acesso seguro usando grupos na ID do Microsoft Entra.

Detecção de ameaça

O Microsoft Entra ID Protection pode ajudar 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ça pode assumir a forma de reação a um alerta de atividade suspeita ou procura proativa de eventos anômalos em logs de atividade. O User and Entity Behavior Analytics (UEBA) no Sentinel facilita a detecção de atividades suspeitas. Microsoft Para obter mais informações, consulte Identificar ameaças avançadas com UEBA no Microsoft Sentinel.

Registro em log da atividade

Power Apps, Power Automate, Copilot Studio, Conectores e registros de atividades de dados prevenção contra perdas são rastreados e visualizados no Microsoft portal de conformidade do Purview. Para obter mais informações, consulte Saiba mais sobre Microsoft o Purview.

As alterações de log feitas nos registros do cliente 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.

Usar o Privileged Identity Management (PIM) do Microsoft Entra para gerenciar funções de administrador de alto privilégio no centro de administrador 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 associados diretamente a outros usuários, ou podem ser associadas com equipes e unidades de negócios do Dataverse. Para obter mais informações, consulte Conceitos de segurança do Microsoft Dataverse.

Configurar autenticação de usuário no Copilot Studio

O 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 façam login, concedendo assim ao seu copiloto acesso a recursos ou informações restritos. Os usuários podem efetuar login usando Microsoft Entra ID ou qualquer OAuth provedor de identidade 2.0, como Google ou Facebook. Saiba mais em Configurar autenticação de usuário em Copilot Studio.

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

Copilot Studio suporta login único (SSO), o que significa que os copilotos podem fazer login do usuário. O SSO deve ser implementado em suas páginas da web e aplicativos móveis. Para Microsoft Teams, o SSO é perfeito se você Select a opção de autenticação "Somente no Teams". Ele também pode ser configurado manualmente com a v2; no entanto, neste caso, o aplicativo Teams deve ser implantado como um arquivo zip, não por meio da implantação do Teams com 1 clique em Azure AD . Copilot Studio

Saiba mais:

Acessar com segurança os dados usando o Sistema de Proteção de Dados do Cliente

A maioria das operações, suporte e solução de problemas realizados por pessoal (incluindo subprocessadores) não exigem acesso aos dados do cliente. Microsoft Com o Sistema de Proteção de Dados do Cliente do Power Platform, fornecemos uma interface para os clientes para revisar e aprovar (ou rejeitar) 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 Microsoft engenheiro precisa acessar dados do cliente, seja em resposta para um tíquete de suporte iniciado pelo cliente ou um problema identificado por Microsoft. Para obter mais informações, consulte Acessar com segurança os dados do cliente usando 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