Definindo uma estratégia de ambiente

Os ambientes do Power Platform são contêineres que os administradores podem usar para gerenciar aplicativos, fluxos, conexões e outros ativos e, em conjunto com permissões, possibilitam que os membros da organização usem os recursos. Este artigo apresenta detalhes importantes sobre os ambientes em Microsoft Power Platform e discute como aproveitar um gerenciamento proativo. Mais informações: Visão geral de ambientes do Microsoft Power Platform

Desenvolver uma estratégia de ambiente significa configurar ambientes e outras camadas de segurança de dados de forma a permitir o desenvolvimento produtivo na sua organização, enquanto protege e organiza os recursos. Uma estratégia para gerenciar o provisionamento e acesso de ambientes e controlar os recursos dentro deles é importante para:

• Proteger os dados e o acesso.
• Entender como usar o ambiente padrão corretamente.
• Gerenciar o número correto de ambientes para evitar a proliferação e conservar a capacidade.
• Facilitar o gerenciamento do ALM (ciclo de vida do aplicativo).
• Organizar recursos em partições lógicas.
• Oferecer suporte a operações (e helpdesk) de identificação de aplicativos em produção, colocando-os em ambientes dedicados.
• Garantir que os dados estão sendo armazenados e transmitidos em regiões geográficas aceitáveis (por motivos de desempenho e conformidade).
• Garantir o isolamento dos aplicativos em desenvolvimento.

Noções básicas sobre os ambientes

Antes de começarmos, vamos ver alguns fatos importantes sobre ambiente e segurança:

• Os ambientes são vinculados a uma localização geográfica, que é configurada no momento da criação deles.
• Os ambientes podem ser usados para atingir públicos diferentes ou para outras finalidades, como desenvolvimento, teste e produção.
• Políticas de prevenção contra perdas de dados (DLP) podem ser aplicadas a ambientes individuais ou ao locatário.
• Cada locatário tem um ambiente padrão.
• Ambientes não padrão podem ser criados por usuários licenciados do Power Apps, do Power Automate e do Dynamics 365. A criação pode ser restrita apenas aos administradores globais e de serviço por meio de uma configuração de locatário.
• Os ambientes não padrão oferecem mais controle sobre as permissões.
• Um ambiente pode ter uma ou nenhuma instância do Microsoft Dataverse.
• Os ambientes incluem direitos de acesso predefinidos que refletem tarefas comuns do usuário com os níveis de acesso definidos de acordo com as práticas recomendadas de segurança, a fim de fornecer acesso ao mínimo de dados corporativos necessários para o uso do aplicativo.
• O roteamento de ambiente padrão é um recurso premium de governança. Esse recurso permite que os administradores do Power Platform direcionem automaticamente novos criadores para seus próprios ambientes de desenvolvimento pessoais quando visitarem make.powerapps.com pela primeira vez.

Tipos de ambiente

Antes de começar a desenvolver uma estratégia de ambiente, você precisa entender os diferentes tipos de ambiente.

Desenvolvendo uma estratégia

Veja a seguir um ponto de partida para começar sua estratégia de ambiente.

• Atribua aos seus administradores a função de administrador de serviço do Microsoft Power Platform ou do Dynamics 365.
  Essas funções fornecem acesso administrativo a aplicativos de tela do Power Apps, fluxos, aplicativos baseados em modelo, ambientes, conectores personalizados, conexões, gateways, portais do Power Apps, modelos do AI Builder e todas as instâncias do Dataverse. Essa função deve ser atribuída a administradores que não precisam de acesso administrativo global do locatário e são dedicados ao gerenciamento do Microsoft Power Platform.

• Restrinja a criação de novos ambientes de produção de rede aos administradores.
  Limitar a criação de ambientes ajuda a manter o controle, evitando o consumo de capacidade não contabilizada e reduzindo o número de ambientes a serem gerenciados. Se os usuários tiverem que solicitar ambientes a partir da TI central, será mais fácil visualizar em que as pessoas estão trabalhando se os administradores forem os gatekeepers.

• Trate o ambiente padrão como um ambiente de produtividade de usuários e equipes para seus grupos de negócios.
  É recomendável renomear o ambiente no centro de administração para explicitar a finalidade desse ambiente. Deixe claro que o Padrão é usado para cenários de produtividade de usuários e equipes, mas não para aplicativos importantes ou críticos para os negócios. Esse ambiente não pode ser desabilitado ou excluído porque é integrado com produtos, como SharePoint e o Project. Recomendamos uma abordagem em camadas para ambientes de produtividade de usuários e equipes.

• Estabeleça um processo de solicitação de acesso ou criação de ambientes.
  Com a criação de ambientes limitada e o padrão reservado para aplicativos de integração primários, informe os membros da sua organização que um projeto de desenvolvimento adequado deve ser iniciado solicitando um novo ambiente dedicado que tenha uma comunicação clara de intenção e suporte entre desenvolvedores e administradores. A próxima seção mostra mais detalhes sobre a criação automatizada de ambientes, que é apenas uma maneira de implementar um processo de solicitação formal de uso fácil.

• Ambientes de desenvolvimento/teste /produção para grupos de negócios ou aplicativos específicos.
  Usar ambientes de teste garante que as mudanças feitas durante o desenvolvimento não interrompam os usuários na produção e os dados não sejam corrompidos. Quando os recursos são limitados, concentre-se neste padrão para aplicativos críticos e importantes ou nas unidades de negócios que têm mais necessidade de um espaço dedicado.

• Ambientes de uso individual para provas de conceito e workshops de treinamento.
  Ao hospedar workshops, hackathons e eventos de treinamento interno, como App in a Day ou Flow in a Day, crie um ambiente novo e separado para o evento a fim de manter cada um deles organizados. Peça que os usuários economizem os recursos de que precisam em um curto período após o evento e limpem o ambiente ou o redefinam para outros eventos. Use ambientes de teste que não consumam capacidade para esses tipos de atividade.

• Defina políticas de prevenção contra perda de dados (DLP) no nível do locatário e do ambiente
  As políticas de prevenção contra perda de dados (DLP) atuam como proteções para ajudar a evitar que os usuários exponham dados organizacionais acidentalmente e manter a segurança das informações no locatário. Uma parte essencial da função do administrador do Power Platform será definir e manter políticas de DLP no nível do locatário e do ambiente.

Abordagem em camadas para ambientes de produtividade de usuários e equipes

Para oferecer suporte a integrações, reduzir o número de ambientes necessários e acelerar a integração, recomendamos criar vários ambientes compartilhados que possam ser usados por indivíduos e equipes.

Ambiente padrão

Todos os membros no seu locatário têm permissão para criar aplicativos e fluxos nesse ambiente. Atualmente, não é possível bloquear a atribuição da função Criador de Ambiente. Este também é o ambiente usado para integrações primárias, como criar um aplicativo a partir de uma lista do SharePoint. Saiba mais: Ambiente padrão

Para diminuir o risco relacionado aos dados, os tipos de conectores usados nos seus aplicativos e fluxos devem ser limitados a uma política de prevenção contra perda de dados (DLP) mais rígida. Essa política deve incluir casos de uso de produtividade individual e de pequenas equipes, como trabalhar com dados do SharePoint, enviar e-mails e ter um fluxo de trabalho de aprovação.

Ambiente de usuário avançado

Embora o ambiente padrão abranja muitos casos de uso, alguns usuários avançados terão necessidades mais específicas para seus aplicativos e fluxos, como integração com Microsoft Teams, Microsoft Entra ID ou Azure DevOps.

Para isso, recomendamos criar um ambiente de usuário avançado. Esse ambiente compartilhado deve usar políticas de DLP mais permissivas e os administradores devem controlar a lista de criadores deste ambiente.

Veja a seguir algumas considerações para o ambiente de usuário avançado:

• Revise os conectores disponíveis nesse ambiente para garantir que são adequados para seus usuários.
• Documente a finalidade e os conectores disponíveis nesse ambiente de forma clara, por exemplo, em um site ou wiki do SharePoint.
• Crie um processo automatizado para que os criadores solicitem acesso ao ambiente de usuário avançado, por exemplo, usando o Microsoft Forms, um site do SharePoint ou um aplicativo. Se necessário, este processo pode incluir a aprovação do gerente de linha ou da TI.

Ambientes personalizados

Embora os ambientes compartilhados abranjam muitos casos de uso para aplicativos, as equipes e os projetos podem usar um ambiente personalizado para oferecer suporte aos casos de uso específicos da unidade de negócios ou cenários de gerenciamento de ciclo de vida de aplicativos.

Veja a seguir algumas considerações para ambientes personalizados:

• Trabalhe com as equipes de projeto ou unidades de negócios para definir se elas precisam de ambientes de desenvolvimento, teste e produção dedicados ou se é mais conveniente criar um ambiente de desenvolvimento dedicado e ambientes de teste e produção compartilhados.
• Considere usar ambientes dedicados para projetos e cargas de trabalho críticos. Os desenvolvedores têm acesso de Criador de Ambiente no ambiente de desenvolvimento, mas apenas acesso de usuário nos ambientes de teste e produção. Os usuários finais só têm acesso de usuário final à solução de produção. Portanto, ninguém conseguirá modificar os aplicativos de produção.
• Considere compartilhar os ambientes de teste e produção entre aplicativos importantes e de complexidade média. Projetos individuais e unidades de negócios têm seu próprio ambiente de desenvolvimento para proteger os dados, mas as soluções são implantadas em ambientes de teste e produção compartilhados. Os desenvolvedores são usuários finais no ambiente de teste e só têm acesso de usuário básico a soluções e dados no ambiente de produção.
• Trabalhe com a unidade de negócios para definir quais conectores são necessários e criar uma política de exceção.
• Trabalhe com a unidade de negócios para definir quem será o criador nesse ambiente e quem será o administrador.
• Cada ambiente consome 1 GB de capacidade de dados. Portanto, gerencie os ambientes personalizados de forma eficiente.

Além das recomendações acima, criar uma estratégia de ambiente também é importante para moldar e direcionar sua estratégia de DLP.

• Todos os membros são criadores. Informe a todos que o ambiente Padrão não deve ser usado para o desenvolvimento de aplicativos críticos.
• Apenas um usuário tem acesso. Os ambientes de desenvolvedor são completamente bloqueados para qualquer outro usuário, exceto aquele inscrito no plano da comunidade. Os aplicativos podem ser removidos do ambiente, se necessário.
• Somente os usuários aprovados têm acesso. Ambientes compartilhados para cenários de produtividade de usuários e equipes, com lista de criadores aprovados.
• Ambientes dedicados para projetos e cargas de trabalho críticos. Os desenvolvedores têm acesso de criador no ambiente de desenvolvimento, mas apenas de usuário nos ambientes de teste e produção. Os usuários finais só têm acesso de usuário final à solução de produção. Portanto, ninguém conseguirá modificar os aplicativos de produção.
• Ambientes de teste e produção compartilhados para aplicativos importantes e de complexidade média. Projetos individuais e unidades de negócios têm seu próprio ambiente de desenvolvimento para proteger os dados, mas as soluções são implantadas em ambientes de teste e produção compartilhados. Os desenvolvedores são usuários finais no ambiente de teste e só têm acesso de usuário básico a soluções e dados no ambiente de produção.

Recomendações adicionais para gerenciar ambientes

Com base na experiência bem-sucedida de envolvimento do cliente, veja a seguir uma lista de recomendações adicionais que podem facilitar o gerenciamento de ambientes.

• Use uma conta de serviço para implantar soluções de produção: Crie uma conta de serviço que a TI central gerencie para implantar em ambientes de teste e produção. Veja algumas das vantagens dessa abordagem:

  • Permite que todos os membros de TI gerenciem recursos administrativos (como ambientes de teste e produção).
  • Apenas a conta de serviço tem permissões de administrador no ambiente.
  • Todos os outros usuários têm permissões de usuário final e não podem criar novos recursos. Isso é importante porque, se os usuários receberem acesso a uma conexão de dados, eles poderão criar uma nova interface para interagir com os dados não permitidos pelo desenvolvedor.
  • A TI controla quais aplicativos de nível de produção estão em implantação, pois ela participa do processo.
  • As contas de serviço precisarão de permissão de administrador de serviço do Microsoft Power Platform ou do Dynamics 365 no PIM. Atribua licenças adicionais conforme necessário, dependendo de quais conectores precisam ser usados no processo de solicitação (por exemplo, se o Dataverse e o Outlook forem utilizados, atribua o Premium Power Apps e o Office Enterprise).
  • Ao exibir os detalhes de um aplicativo, você verá a conta de serviço como autora e não criadora. Isso ajudará os usuários finais a saber com quem entrar em contato em caso de problemas com o aplicativo.

  Considere se os riscos de ter uma conta de serviço são importantes para você. Algumas organizações não se sentem confortáveis com uma conta de serviço porque, por exemplo, um recurso compartilhado com privilégios de administrador não pode ser rastreado a um único indivíduo. Isso é válido, mas pode ser atenuado com etapas como aplicação de acesso condicional com base em localização, rastreamento de logs de auditoria para um IP ou métodos mais abrangentes, por exemplo, manutenção de uma estação de trabalho de acesso seguro que requer a identificação do usuário durante o uso e restrição do acesso à conta de serviço para esse dispositivo.

• Reduza o número de ambientes de desenvolvimento compartilhados

  Tenha ambientes específicos para o desenvolvimento de projetos separados, especialmente ao lidar com dados seguros. Ambientes são contêineres de recursos como conexões de dados, e pode haver várias pessoas com acesso de criador em ambientes de desenvolvimento. Se os criadores tiverem acesso a uma conexão de dados compartilhada e puderem desenvolver aplicativos e fluxos, alguém poderá criar uma nova interface para ler, atualizar e excluir dados disponíveis a ele. Isso é especialmente importante para o ambiente padrão – você deve sempre ter conexões de dados importantes, conectores personalizados e outros ativos que precisam ser adicionados a ambientes isolados para maior proteção.

• Compartilhe recursos com grupos de segurança do Microsoft Entra

  Os grupos de segurança podem ser usados para gerenciar o acesso a Power Apps, fluxos, direitos de acesso do Dataverse e outros serviços do Office 365, como SharePoint Online. Isso evita que o administrador precise atualizar o acesso a usuários finais individuais para cada componente (especialmente se houver vários), pois os proprietários do aplicativo podem modificar essa configuração no nível do grupo de segurança sem ajuda da TI (a menos que ela restrinja acesso ao gerenciamento do grupo de segurança).

• Automatize a criação de ambientes

  Os conectores de administrador (Microsoft Power Platform for Admins) possibilitam a criação de um fluxo de aprovação em que os usuários solicitam ambientes quando a TI restringiu a criação de ambientes aos administradores. A TI central pode revisar a solicitação e aprovar ou rejeitar a criação do ambiente, sem precisar acessar manualmente o centro de administração e criar o ambiente para o usuário. Ela só precisará validar os detalhes da solicitação, a justificativa comercial, os requisitos de DLP e se a capacidade suficiente está disponível.

• Crie ambientes de desenvolvimento temporários

  Conforme mencionado, é recomendável separar os ambientes de desenvolvimento o máximo possível e evitar, especificamente, o desenvolvimento simultâneo de aplicativos para soluções críticas no ambiente padrão. Se os ambientes forem criados para fins de desenvolvimento, defina um prazo de tempo no qual o ambiente estará disponível para os desenvolvedores e tenha um processo em vigor para fazer backup desse ambiente e removê-lo.

• Menos é mais

  Embora seja importante garantir que os recursos sejam particionados de forma adequada entre projetos e unidades de negócios usando ambientes, também é essencial encontrar um bom equilíbrio entre segurança e viabilidade. Gerenciar ambientes de teste e produção compartilhados é uma boa maneira de criar um maior número de soluções importante, preservando a capacidade e seguindo as práticas recomendadas. Isso mantém as permissões restritas, porque ambientes de teste e produção têm permissões limitadas. Portanto, os usuários finais não podem modificar os aplicativos.

• Ambientes de provisionamento com instâncias do Dataverse na região apropriada

  Em empresas com funcionários em vários países/regiões, pode haver preocupações de conformidade em termos de onde os dados são armazenados e enviados entre países/regiões. Se o ambiente tem uma instância do Dataverse , os dados são armazenados fisicamente na região. Revise a lista de regiões de ambiente suportadas.

Fatores que influenciam o provisionamento

Alguns fatores influenciam a escolha dos tipos de ambientes:

• Camadas definidas de suporte de aplicativo

  O nível de complexidade, quão crítico é o aplicativo e os usuários impactados por ele (por exemplo, usuários ativos mensais/total de usuários em uma organização) são fatores importantes para provisionar ambientes que ofereçam suporte a todos os cenários.

  Diferentes tipos de aplicativos devem ser separados em ambientes diferentes com base na importância de cada um.

  	Cenários de missão crítica e/ou alta complexidade e/ou uso em toda a organização. Suporte pela TI. Processo de ALM robusto (desenvolvimento/teste/produção). Ciclo de desenvolvimento mais longo, geralmente maior que 3 meses, para um produto mínimo viável.
  	Importante, mas não crítico e/ou de média complexidade e/ou com escopo para a unidade de negócios. Suporte pelo proprietário do aplicativo ou pela unidade de negócios com validação pela TI. Ambientes que usam ALM são recomendados, mas podem não ser necessários. Desenvolvimento normalmente em menos de 3 meses para um Produto Mínimo Viável.
  	Aplicativo de produtividade que não necessita de alto nível de governança. Suporte pelo desenvolvedor do aplicativo. Normalmente, o gerenciamento do ciclo de vida do aplicativo não é necessário. Menos de 2 semanas para um produto mínimo viável.

• Capacidade

  Cada ambiente (além dos ambientes de teste e de desenvolvedor) consumirá 1 GB para o provisionamento inicial. Isso pode ser uma restrição para o provisionamento de ambientes se sua organização não tiver licenças do Premium Power Apps ou do Dynamics 365. Além disso, a capacidade também é compartilhada entre o locatário e precisa ser alocada para aqueles que precisam dela.

  Conserve capacidade ao:

  • Gerenciar ambientes de teste e de produção compartilhados. Ao contrário dos ambientes de desenvolvimento compartilhados, as permissões em ambientes de teste e produção devem ser limitadas ao acesso do usuário final para teste.
  • Automatize a limpeza de ambientes de desenvolvimento temporários e incentive o uso de ambientes de teste para trabalhos de experimentação ou prova de conceito.

• Envolvimento do administrador

  Nem sempre é possível envolver a TI central em todos os projetos de desenvolvimento que acontecem em todo o locatário, especialmente se a equipe de TI for pequena ou se houver uma empresa maior para gerenciar.

  Reduza a carga do administrador ao:

  • Automatizar a criação de ambientes para que o administrador do locatário só precise aprovar a solicitação.
  • Automatizar a limpeza do ambiente de desenvolvimento com ambientes temporários.

Comunique claramente a estratégia de ambiente da sua organização para os criadores

Configure um site ou wiki do SharePoint que comunique claramente:

• O objetivo do seu ambiente padrão.
• A finalidade dos ambientes compartilhados de produtividade de equipes e usuários, além de outros ambientes compartilhados que os criadores possam ter acesso (por exemplo, ambientes de treinamento) e como solicitar acesso a esses ambientes.
• O objetivo dos ambientes de teste e como solicitá-los.
• O objetivo dos ambientes de desenvolvedor e como criá-los
• O processo de solicitação de ambientes personalizados para unidades de negócios específicas ou as finalidades do projeto.
• As responsabilidades de um criador:
  • Manter o locatário limpo. Excluir seus ambientes, aplicativos e fluxos se eles não forem mais necessários. Usar ambientes de teste durante a experimentação.
  • Compartilhar de forma eficiente. Atentar-se ao compartilhamento excessivo dos seus ambientes, aplicativos, fluxos e conexões compartilhadas.
  • Proteger os dados da organização. Evitar mover dados de fontes altamente confidenciais para um armazenamento externo ou não protegido.

Além disso, comunique claramente as políticas de DLP aos criadores.