Proteger o ambiente padrão

  • Artigo

Cada funcionário em sua organização tem acesso ao ambiente padrão do Power Platform. Como administrador do Power Platform, você precisa levar em consideração maneiras de proteger esse ambiente e, ao mesmo tempo, mantê-lo acessível para uso pessoal de produtividade dos criadores. Este artigo fornece sugestões.

Atribuir funções de administrador criteriosamente

Considere se os usuários administradores precisam ter a função Administrador do Power Platform. A função Administrador de ambiente ou Administrador do sistema seria mais apropriada? De qualquer forma, limite a função Administrador do Power Platform mais avançada a somente alguns usuários. Saiba mais sobre como administrar os ambientes do Power Platform.

Comunicar a intenção

Um dos principais desafios da equipe do centro de excelência (CoE) do Power Platform é comunicar os usos pretendidos do ambiente padrão. Veja algumas recomendações.

Renomear o ambiente padrão

O ambiente padrão é criado com o nome TenantName (padrão). Você pode alterar o nome do ambiente para algo mais descritivo, como Ambiente de produtividade pessoal, para destacar claramente a intenção.

Usar o hub do Power Platform

O hub do Microsoft Power Platform é um modelo de site de comunicação do SharePoint. Ele fornece um ponto de partida para uma fonte central de informações para criadores sobre o uso do Power Platform em sua organização. O conteúdo inicial e os modelos de página facilitam a oferta de informações aos criadores, como:

  • Casos de uso de produtividade pessoal
  • Como criar aplicativos e fluxos
  • Onde criar aplicativos e fluxos
  • Como entrar em contato com a equipe de suporte do CoE
  • Regras sobre integração com serviços externos

Adicione links para outros recursos internos que podem ser úteis para os criadores.

Limite o compartilhamento com todos

Os criadores podem compartilhar os aplicativos com outros usuários individuais, grupos de segurança e, por padrão, todos na organização. Seria uma boa ideia usar um processo restrito em aplicativos amplamente usados para impor políticas e requisitos como estes:

  • Política de revisão de segurança
  • Política de revisão de negócios
  • Requisitos de gerenciamento do ciclo de vida do aplicativo (ALM)
  • Experiência do usuário e requisitos de identidade visual

Considere também desativar o recurso Compartilhar com todos no Power Platform. Com essa restrição em vigor, apenas um pequeno grupo de administradores pode compartilhar um aplicativo com "Todos" no ambiente. Veja como.

  1. Execute o cmdlet Get-TenantSettings para ver a lista de configurações de locatário da sua organização como um objeto.

    O objeto powerPlatform.PowerApps inclui três sinalizadores:

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

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

    $settings=Get-TenantSettings 
$settings.powerPlatform.powerApps.disableShareWithEveryone=$true

  3. Execute o cmdlet Set-TenantSettings com o objeto de configurações para impedir que criadores compartilhem aplicativos com todos no locatário.

      Set-TenantSettings $settings

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

Outra forma de proteger o ambiente padrão é criar uma política de prevenção contra perda de dados (DLP) para ele. Ter uma política DLP em vigor é especialmente essencial para o ambiente padrão, pois todos os funcionários em sua organização têm acesso a ele. Veja algumas recomendações para ajudar a aplicar a política.

Personalizar a mensagem de governança da DLP

Personalize a mensagem de erro exibida se um criador desenvolver um aplicativo que viole a política DLP da sua organização. Direcione o criador para o Hub Power Platform da sua organização e forneça o endereço de e-mail da sua equipe CoE.

À medida que a equipe CoE refina a política DLP ao longo do tempo, você pode interromper inadvertidamente alguns aplicativos. Verifique se a mensagem de violação da política DLP contém informações de contato ou um link para mais informações para fornecer um caminho a seguir para os criadores.

Use os seguintes cmdlets do PowerShell para personalizar a mensagem da política de governança:

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

Bloquear novos conectores no ambiente padrão

Por padrão, todos os novos conectores são colocados no grupo não comercial de sua política DLP. Você sempre pode alterar o grupo padrão para Comercial ou Bloqueado. Para uma política DLP aplicada ao ambiente padrão, recomendamos que você configure o grupo Bloqueado como padrão para garantir que os novos conectores permaneçam inutilizáveis ​​até que sejam revisados ​​por um de seus administradores.

Limitar os criadores a conectores predefinidos

Restrinja os criadores a apenas conectores básicos e não bloqueáveis para impedir o acesso ao restante.

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

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

Limitar os conectores personalizados

Os conectores personalizados integram um aplicativo ou fluxo com um serviço desenvolvido internamente. Esses serviços destinam-se a usuários técnicos, como desenvolvedores. É uma boa ideia reduzir a pegada de APIs criadas pela organização que podem ser chamadas de aplicativos ou fluxos no ambiente padrão. Para evitar que os criadores criem e usem conectores personalizados para APIs no ambiente padrão, crie uma regra para bloquear todos os padrões de URL.

Para permitir que os criadores acessem algumas APIs (por exemplo, um serviço que gera uma lista de feriados da empresa), configure várias regras que classificam diferentes padrões de URL nos grupos de dados comerciais e não comerciais. As conexões devem sempre usar o protocolo HTTPS. Saiba mais 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. Com ele, os criadores podem enviar, excluir e responder a mensagens de email nas caixas de correio às quais têm acesso. O risco desse conector também é um de recursos mais poderosos: a capacidade de enviar um email. 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 Exchange Server para impedir o envio de emails de aplicativos. Também é possível excluir fluxos ou aplicativos específicos das regras definidas para bloquear emails de saída. Você pode associar essas regras a uma "lista permitida" de endereços de email para garantir que emails de aplicativos e fluxos só possam ser enviados de um pequeno grupo de caixas de correio.

Sempre que um aplicativo ou fluxo envia um email por meio do conector do Office 365, ele insere cabeçalhos SMTP específicos na mensagem. Você pode usar frases reservadas nos cabeçalhos para identificar se a origem do email foi um fluxo ou um aplicativo.

O cabeçalho SMTP inserido em um email enviado de um fluxo tem a aparência deste exemplo:

 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 a seguir descreve os valores que podem aparecer no cabeçalho x-ms-mail-application dependendo do serviço usado:

Service Valor
Power Automate Microsoft Power Automate; User-Agent: azure-logic-apps/1.0 (workflow <GUID>; version <version number>) microsoft-flow/1.0
Power Apps Microsoft Power Apps; User-Agent: PowerApps/ (; AppName= <app name>)

A tabela a seguir descreve os valores que podem aparecer no cabeçalho x-ms-mail-operation-type dependendo da ação que está sendo executada:

Valor Descrição
Responder Para operações de email de resposta
Encaminhar Para operações de email encaminhado
Enviar Para enviar operações de email, 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 você está usando:

  • No Power Apps, ele sempre está presente.
  • No Power Automate, ele está presente apenas em conexões criadas após julho de 2020.
  • Em Aplicativos Lógicos, ele nunca está presente.

Possíveis regras do Exchange para o ambiente padrão

Veja algumas ações de email que talvez você deseje bloquear usando regras do Exchange.

  • Bloqueie emails de saída para destinatários externos: bloqueie todos os emails de saída enviados para destinatários externos do Power Automate e do Power Apps. Essa regra impede que os criadores enviem e-mails para parceiros, fornecedores ou clientes usando os respectivos aplicativos ou fluxos.

  • Bloqueie encaminhamentos de saída: bloqueie todos os emails de saída encaminhados para destinatários externos do Power Automate e do Power Apps em que o remetente não seja de uma lista permitida de caixas de correio. Essa regra impede que os criadores criem um fluxo que encaminhe automaticamente emails de entrada para um destinatário externo.

Exceções a serem consideradas com regras de bloqueio de email

Estas são possíveis exceções às regras do Exchange para bloquear email para adicionar flexibilidade:

  • Isente aplicativos e fluxos específicos: adicione uma lista de isenções às regras sugeridas anteriormente para que aplicativos ou fluxos aprovados possam enviar emails para destinatários externos.

  • Lista de permissões em nível da organização: nesse cenário, faz sentido migrar a solução para um ambiente dedicado. Se vários fluxos no ambiente precisarem enviar emails de saída, você poderá criar uma regra de exceção geral para permitir emails de saída desse ambiente. A permissão do criador e do administrador nesse ambiente deve ser rigidamente controlada e limitada.

Aplicar isolamento entre locatários

O Power Platform tem um sistema de conectores baseado no Microsoft Entra que permite aos usuários autorizados do Microsoft Entra conectar aplicativos e fluxos a armazenamentos de dados. O isolamento do locatário controla a movimentação de dados de fontes de dados autorizadas do Microsoft Entra de e para seu locatário.

O isolamento do locatário é aplicado no nível do locatário e afeta todos os ambientes do locatário, incluindo o ambiente padrão. Como todos os funcionários são criadores no ambiente padrão, configurar uma política de isolamento de locatário robusta é essencial para proteger o ambiente. Como prática recomendada, configure explicitamente os locatários aos quais os funcionários possam se conectar. Todos os outros locatários devem ser cobertos por regras padrão que bloqueiam o fluxo de entrada e saída de dados.

O isolamento do locatário do Power Platform é diferente da restrição de locatário do Microsoft Entra ID. Isso não afeta o acesso baseado no Microsoft Entra fora do Power Platform. Funciona apenas para conectores que usam autenticação baseada no Microsoft Entra ID, como conectores do Office 365 Outlook e SharePoint.

Confira também

Restringir o acesso entre locatários de entrada e saída (versão preliminar)

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