Proteger o ambiente predefinido

Todos os colaboradores na organização têm acesso ao ambiente predefinido do Power Platform. Enquanto admin do Power Platform, precisa de considerar formas de proteger esse ambiente, mantendo-o acessível para as utilizações de produtividade pessoal dos criadores. Este artigo fornece sugestões.

Atribuir funções de administrador de forma criteriosa

Considere se os utilizadores administradores necessitam de ter a função de administrador do Power Platform. A função de administrador do ambiente ou administrador de sistema seria mais apropriada? Em qualquer caso, limite a função de admin do Power Platform mais poderosa apenas a alguns utilizadores. Obter informações sobre a administração de ambientes do Power Platform.

Comunicar intenção

Um dos principais desafios para a equipa do Centro de Excelência (CoE) do Power Platform é comunicar as utilizações pretendidas do ambiente predefinido. Eis algumas recomendações.

Mudar o nome do ambiente predefinido

O ambiente predefinido é criado com o nome TenantName (predefinido). Pode alterar o nome do ambiente para algo mais descritivo, como Ambiente de Produtividade Pessoal, para chamar claramente a atenção para a intenção.

Utilizar o hub do Power Platform

O hub do Microsoft Power Platform é um modelo de site de comunicação do SharePoint. Fornece um ponto de partida para uma origem central de informações para criadores acerca da utilização do Power Platform pela sua organização. O conteúdo inicial e os modelos de página facilitam a oferta de informações dos criadores como:

  • Casos de utilização de produtividade pessoal
  • Como construir aplicações e fluxos
  • Onde construir aplicações e fluxos
  • Como contactar a equipa de suporte do CoE
  • Regras sobre a integração com serviços externos

Adicione ligações a quaisquer outros recursos internos que os criadores possam considerar úteis.

Limitar a partilha com todos

Os criadores podem partilhar as respetivas aplicações com outros utilizadores individuais, grupos de segurança e, por predefinição, todas as pessoas na organização. Deverá considerar a utilização de um processo controlado por porta em torno de aplicações amplamente utilizadas para impor políticas e requisitos como estes:

  • Política de revisão da segurança
  • Política de revisão do negócio
  • Requisitos da Gestão do Ciclo de Vida das Aplicações (ALM)
  • Requisitos de experiência de utilizador e de imagem corporativa

Considere também desativar a caraterística Partilhar com Todos no Power Platform. Com essa restrição em vigor, apenas um pequeno grupo de administradores poderá partilhar uma aplicação com todos no ambiente. Eis como.

  1. Execute o cmdlet Get-TenantSettings para obter a lista das definições de inquilino da sua organização como um objeto.

    O objeto powerPlatform.PowerApps inclui três sinalizadores:

    Captura de ecrã de três sinalizadores no objeto $settings.powerPlatform.PowerApps.

  2. Execute os seguintes comandos do PowerShell para obter o objeto de definições e definir a variável a partilhar com todos como false.

    $settings=Get-TenantSettings 
    $settings.powerPlatform.powerApps.disableShareWithEveryone=$true 
    
  3. Execute o cmdlet Set-TenantSettings com o objeto de definições para impedir que os criadores partilhem as suas aplicações com todas as pessoas no inquilino.

      Set-TenantSettings $settings
    

Estabelecer uma política de prevenção de perda de dados

Outra forma de proteger o ambiente predefinido é criar uma política de prevenção de perda de dados (DLP) para ele. Ter uma política DLP em vigor é especialmente crítico para o ambiente predefinido porque todos os colaboradores na sua organização têm acesso a ele. Eis algumas recomendações para o ajudar a impor a política.

Personalizar a mensagem de governação de DLP

Personalize a mensagem de erro que é apresentada se um criador criar uma aplicação que viole a política DLP da sua organização. Direcione o criador para o Hub do Power Platform da sua organização e forneça o endereço de e-mail da sua equipa do CoE.

À medida que a equipa de CoE ajusta a política DLP ao longo do tempo, poderá inadvertidamente quebrar algumas aplicações. Certifique-se de que a mensagem de violação da política DLP contém detalhes de contacto ou uma ligação para mais informações, para fornecer uma forma de prosseguir para os criadores.

Utilize os cmdlets do PowerShell seguintes para personalizar a mensagem da política de governação:

Command Descrição
Set-PowerAppDlpErrorSettings Definir mensagem de governação
Set-PowerAppDlpErrorSettings Atualizar mensagem de governação

Bloquear novos conectores no ambiente predefinido

Por predefinição, todos os novos conectores são colocados no grupo Não negócio da sua política DLP. Pode sempre alterar o grupo predefinido para Negócio ou Bloqueado. Para uma política DLP aplicada ao ambiente predefinido, recomendamos que configure o grupo Bloqueado como o predefinido para se certificar de que os novos conectores permanecem inutilizáveis até que tenham sido revistos por um dos administradores.

Limitar os criadores a conectores pré-criados

Restringir os criadores a apenas conectores básicos não bloqueáveis para impedir o acesso aos restantes.

  1. Mova todos os conectores que não podem ser bloqueados para o grupo de dados de negócio.

  2. Mova todos os conectores bloqueáveis para o grupo de dados bloqueado.

Limitar conectores personalizados

Os conectores personalizados integram uma aplicação ou um fluxo com um serviço interno. Estes serviços destinam-se a utilizadores técnicos, como programadores. É boa ideia reduzir a pegada de APIs, criadas pela sua organização, que podem ser invocadas a partir de aplicações ou fluxos no ambiente predefinido. Para impedir que os criadores criem e utilizem conectores personalizados para APIs no ambiente predefinido, crie uma regra para bloquear todos os padrões de URL.

Para permitir que os criadores acedam a algumas APIs (por exemplo, um serviço que devolve uma lista de feriados da empresa), configure várias regras que classifiquem padrões de URL diferentes para os grupos de dados de negócio e não negócio. Certifique-se de que as ligações utilizam sempre o protocolo HTTPS. Mais informações sobre a política DLP para conectores personalizados.

Proteger a integração com o Exchange

O conector do Office 365 Outlook é um dos conectores padrão que não podem ser bloqueados. Permite que os criadores enviem, eliminem e respondam a mensagens de e-mail a que têm acesso. O risco com este conector também é uma das capacidades mais poderosas — a capacidade de enviar um e-mail. Por exemplo, um criador pode criar um fluxo que envia e-mails em massa.

O administrador do Exchange da sua organização pode configurar regras no servidor Exchange para impedir que os e-mails sejam enviados a partir de aplicações. Também é possível excluir fluxos ou aplicações específicos das regras configuradas para bloquear e-mails de saída. Pode combinar estas regras com uma lista de permissões de endereços de e-mail para se certificar de que os e-mails de aplicações e fluxos só podem ser enviados a partir de um pequeno grupo de caixas de correio.

Quando uma aplicação ou um fluxo envia um e-mail utilizando o conector do Office 365 Outlook, insere os cabeçalhos SMTP específicos na mensagem. Pode usar frases reservadas nos cabeçalhos para identificar se um e-mail teve origem num fluxo ou numa aplicação.

O cabeçalho SMTP inserido num e-mail enviado a partir de um fluxo parece-se com o exemplo seguinte:

 x-ms-mail-application: Microsoft Power Automate; 
 User-Agent: azure-logic-apps/1.0 (workflow 2321aaccfeaf4d7a8fb792e29c056b03;version 08585414259577874539) microsoft-flow/1.0
 x-ms-mail-operation-type: Send
 x-ms-mail-environment-id: 0c5781e0-65ec-ecd7-b964-fd94b2c8e71b 

Detalhes do cabeçalho

A tabela que se segue descreve os valores que aparecem no cabeçalho x-ms-mail-application, dependendo do serviço utilizado:

Service valor
Power Automate Microsoft Power Automate; Agente Utilizador: azure-logic-apps/1.0 (<GUID> do fluxo de trabalho; versão <número da versão>) microsoft-flow/1.0
Power Apps Microsoft Power Apps; Agente Utilizador: PowerApps/ (; AppName= <nome da aplicação>)

A tabela que se segue descreve os valores que aparecem no cabeçalho x-ms-mail-operation-type, dependendo da ação a ser efetuada:

valor Descrição
Resposta Para operações de resposta de e-mail
Seguinte Para operações de encaminhamento de e-mail
Enviar Para operações de envio de e-mail, incluindo, SendEmailWithOptions e SendApprovalEmail

O cabeçalho x-ms-mail-environment-id contém o valor de ID do ambiente. A presença deste cabeçalho depende do produto que está a utilizar:

  • No Power Apps, está sempre presente.
  • No Power Automate, só está presente em ligações criadas após julho de 2020.
  • Em Logic Apps, nunca está presente.

Regras Potenciais do Exchange para o ambiente predefinido

Eis algumas ações de e-mail que poderá querer bloquear utilizando regras do Exchange.

  • Bloquear e-mails de saída para destinatários externos: bloqueie todos os e-mails de saída enviados para destinatários externos do Power Automate e do Power Apps. Esta regra impede que os criadores enviem e-mails para parceiros, fornecedores ou clientes a partir das respetivas aplicações ou fluxos.

  • Bloquear encaminhamento de saída: bloqueie todos os e-mails encaminhados para destinatários externos a partir do Power Automate e do Power Apps em que o remetente não provém de uma lista de caixas de correio permitidas. Esta regra impede que os criadores criem um fluxo que encaminha automaticamente e-mails de entrada para um destinatário externo.

Exceções a considerar com regras de bloqueio de e-mails

Eis algumas potenciais exceções às regras do Exchange para bloquear e-mail para adicionar flexibilidade:

  • Isentar aplicações e fluxos específicos: adicione uma lista de isenção às regras sugeridas anteriormente para que as aplicações ou os fluxos aprovados possam enviar e-mails para destinatários externos.

  • Lista de permissões ao nível da organização: neste cenário, faz sentido mover a solução para um ambiente dedicado. Se vários fluxos no ambiente tiverem de enviar e-mails de saída, pode criar uma regra de exceção de proteção para permitir e-mails de saída desse ambiente. A permissão de criador e de admin nesse ambiente tem de ser bem controlada e limitada.

Aplicar o isolamento entre inquilinos

O Power Platform tem um sistema de conectores baseado no Microsoft Entra que permite que os utilizadores autorizados do Microsoft Entra liguem aplicações e fluxos a arquivos de dados. O isolamento do inquilino governa a circulação de dados de origens de dados do Microsoft Entra autorizadas de e para o respetivo inquilino.

O isolamento de inquilinos é aplicado ao nível do inquilino e afeta todos os ambientes no inquilino, incluindo o ambiente predefinido. Uma vez que todos os colaboradores são criadores no ambiente predefinido, a configuração de uma política de isolamento de inquilinos robusta é essencial para proteger o ambiente. Recomendamos que configure explicitamente os inquilinos aos quais os seus colaboradores se podem ligar. Todos os outros inquilinos deverão estar abrangidos por regras predefinidas que bloqueiam o fluxo de dados de entrada e de saída.

O isolamento de inquilinos do Power Platform é diferente da restrição ao nível do inquilino do Microsoft Entra ID. Não afeta o acesso baseado no Microsoft Entra ID fora do Power Platform. Só funciona para conectores que usam a autenticação baseada no Microsoft Entra ID, como os conectores do Office 365 Outlook e do SharePoint.

Consulte também

Restringir o acesso entre inquilinos de entrada e saída (pré-visualização)

Get-PowerAppTenantIsolationPolicy (Microsoft.PowerApps.Administration.PowerShell)