Escalabilidade, desempenho e facilidade de manutenção

Concluído

Nesta seção do modelo, você examina as perguntas que identificam se possíveis problemas ocorrerão quando o aplicativo for expandido para usuários adicionais e o volume de dados aumentar.

Responda as seguintes perguntas de manutenção no modelo.

  • Você identificou situações nas quais o registro não precisa pertencer a um usuário ou a uma equipe? - Ao criar novas tabelas que representam dados referenciais entre empresas e nunca precisarão de detalhamento para cada unidade de negócios, equipe ou usuário, considere criá-los como tabelas pertencentes à organização.

    A propriedade do registro é importante quando a permissão de visibilidade ou de edição variável precisa ser concedida a usuários diferentes. No entanto, se houver registros gerais que devem ser visíveis a todos os usuários, e todos os usuários compartilharem o mesmo nível de permissões de edição (como registros gerados usando uma integração), uma estratégia como atribuir registros à equipe da unidade de negócios deve ser considerada para que esses registros não precisem ser reatribuídos quando alguém sair da empresa.

  • Você identificou possíveis desafios de escalabilidade em seu projeto de segurança em volumes maiores? - Estratégias como o compartilhamento de registros podem funcionar adequadamente em implantações menores, mas podem rapidamente se tornar ineficientes quando são dimensionados para um grande número de usuários.

    Além disso, ter usuários como membros de milhares de equipes em milhares de unidades de negócios pode ser um desafio em termos de desempenho e escalabilidade.

  • Você considerou o impacto de seus modelos de dados e de segurança na tabela POA? - O compartilhamento excessivo leva a uma tabela POA grande e pode degradar o desempenho do sistema.

  • Você atualiza regularmente registros de usuário, de equipe ou de unidade de negócios? - Como regra geral, as atualizações regulares de usuários, equipes ou tabelas de unidades de negócios devem ser evitadas. Por exemplo, a atualização de um atributo em uma tabela de usuário pode liberar o cache de segurança e impactar o desempenho.

  • Você considerou o impacto de uma grande organização para os usuários, equipes, unidades de negócios e registros? - Estruturas de negócios mudam. Novas empresas são adquiridas, divisões são alienadas e as pessoas saem ou mudam para outros departamentos. A estrutura deve ser flexível o suficiente para que você possa adicionar ou remover facilmente os usuários, as equipes ou as unidades de negócios sem exigir um novo projeto completo do modelo de segurança.

  • Para os usuários que já têm acesso a uma grande porcentagem de registros, você já considerou oferecer acesso global para obter um melhor desempenho? - Fornecer acesso de leitura organizacional/global aos registros pode otimizar o desempenho da implementação de uma exibição porque o sistema não precisa considerar os princípios de segurança que se aplicam a um usuário (funções individuais, funções de equipe, registros compartilhados, hierarquia) ao recuperar registros.

    Embora um usuário possa ter acesso a todos os registros de um ponto de vista de segurança, você deve personalizar as exibições do sistema que filtrarão o número de registros para apresentar somente o que é relevante ao seu trabalho.

  • Você reatribui registros em massa quando um usuário sai? Você considerou o impacto de um relacionamento em cascata? - As configurações de relacionamento em cascata para atividades e outros registros comuns podem causar resultados inesperados ao se reatribuir registros. Esse comportamento deve ser modificado se você não deseja que as atividades fechadas sejam reatribuídas ao reatribuir a conta do cliente e os registros de contato.

Teste de segurança

O modelo de segurança é composto de várias partes que trabalham juntas, com várias áreas em que pode falhar. Nesta seção do modelo, você revisará a abordagem que será usada para testar a segurança, identificar o plano em andamento para monitorar o acesso ao Dynamics 365 e garantir que o projeto dos direitos de acesso seja bem documentado e simples de manter em longo prazo.

Perguntas sobre segurança e por que elas são importantes

Na seção teste de segurança do Modelo de segurança, responda às perguntas a seguir.

  • Você tem ambientes de teste para validar os dados no contexto dos requisitos de segurança? - Para testar adequadamente os direitos de acesso, seu cliente precisará de um ambiente de não produção com a mesma configuração que a produção e uma boa aproximação do conjunto de dados de produção. Embora não sejam necessários 100% dos dados da produção, os dados devem ser semelhantes o suficiente para testar com precisão o comportamento de direitos de acesso. Também é importante ter usuários de teste distintos e não reatribuir funções aos mesmos usuários de teste. O motivo é que os usuários que originalmente têm permissão mais alta podem reter acesso a certos registros quando essa função é removida usando a propriedade ou o compartilhamento de registros.

    Você tem a planilha do Excel em matriz de segurança com níveis de acesso e privilégios definidos por sua empresa ou cliente? É importante ter alguma documentação do projeto de segurança fora do direito de acesso Dynamics 365 caso alguém o altere e você deseje se lembrar como ele foi projetado. Este documento pode ser uma planilha do Excel que indica o nível de permissão apropriado por tabela.

  • Você tem casos de teste ao redor da matriz de segurança para todos os direitos de acesso? - Os requisitos de segurança do cliente provavelmente vieram dos requisitos coletados nos workshops anteriores do projeto e criam a base dos casos de teste de segurança. Cada restrição de segurança deve ter um caso de teste e ser testada completamente antes da ativação. Em seguida, as restrições devem ser testadas no contexto de cada direito de acesso ou persona.

  • Você considerou um teste negativo em equipes e campos de segurança em nível de campo? - É importante testar se alguém com uma função pode ver campos protegidos e acessar registros atribuídos a sua equipe. Além disso, você deve verificar se os usuários sem essas funções ou as atribuições de equipe não podem acessar esses itens.

  • Você executará testes de penetração na plataforma? - O teste de penetração é uma opção para ambientes altamente seguros. Lembre-se de que o teste de penetração deve seguir as regras de contratação da Microsoft Cloud para o teste de penetração. Para obter mais informações, confira Regras de contratação para teste de penetração.

Outras perguntas de segurança do Dynamics 365

Nesta seção do Modelo de segurança, você examina a segurança quanto às funções relacionadas no Dynamics 365.

Responda às perguntas a seguir.

  • Você já considerou o privilégio Exportar para o Excel? - Exportar para o Excel é um recurso de grande conveniência e geração de relatórios, mas também pode ser um risco porque alguns clientes fazem com que funcionários levem dados de clientes ao sair da empresa.

    É importante estar ciente e cauteloso de que, embora o privilégio Exportar para o Excel possa impedir que alguns usuários baixem dados facilmente do Dynamics 365 com o botão Exportar para o Excel, qualquer pessoa que tenha acesso de leitura a um registro pode acessar esses dados por meio de APIs e, por fim, exportá-los.

  • Se aplicável, como você planeja controlar a segurança no Serviço de Exportação de Dados, no Azure SQL ou Exportar para Data Lake e no Power BI? - Quando os dados saem do Microsoft Dataverse para geração de relatórios ou integração, eles não são mais protegidos pela segurança do Dynamics 365. As organizações devem estar cientes desse parâmetro e planejar a segurança quando os dados saírem do sistema.

  • Se aplicável, qual é a sua estratégia de modelo de segurança para portais do Power Pages e Unified Service Desk? - O Power Pages ajuda a expor dados externamente e permitem que as partes externas atualizem dados do Dynamics 365. No entanto, é importante considerar as implicações de segurança desse recurso e garantir que os dados seguros e confidenciais não sejam expostos a pessoas erradas.

    Se seus usuários herdam seus direitos de acesso exclusivamente de equipes, você considerou usar a configuração Herança para direcionar o usuário nos direitos de acesso? Quando você está atribuindo um direito de acesso a uma equipe proprietária (incluindo equipes de grupo de segurança do Microsoft Entra ID ou equipes de grupo de escritório do Azure AD), a configuração Herança de privilégios do membro deve ser verificada para garantir que esteja definida corretamente. Essa configuração pode permitir que os usuários membros da equipe herdem os privilégios de nível de usuário (e não de unidade de negócios ou superior) como se o direito de acesso tivesse sido atribuído diretamente a eles.

    Esse recurso é útil para permitir que os usuários tenham registros em seus nomes mesmo que não tenham um direito de acesso atribuído diretamente a eles. Por exemplo, com essa configuração, os usuários podem ter exibições pessoais. Com as equipes proprietárias, os direitos de acesso não precisam ser concedidos diretamente a usuários individuais, o que ajuda a reduzir os esforços administrativos.

  • Se você planeja usar tabelas virtuais, já pensou em criar um modelo de segurança em torno delas? - As tabelas virtuais permitem a criação de tabelas que não armazenam dados no Dataverse, mas sim apontam para uma fonte de dados externos. Embora esse recurso seja conveniente e, em muitos casos, preferível a sobrecarregar o Dynamics 365 com dados, você deve entender que a conexão da tabela virtual usa uma única fonte de dados, o que significa que todos os usuários que têm acesso à tabela virtual verão os mesmos registros. Se você tem registros confidenciais que não devem ser visíveis para todos os usuários, a integração de dados é recomendável.

Monitoramento de segurança

Nesta seção do modelo, você revisará a estratégia do cliente para monitorar os direitos de acesso adequados e identificará o uso indevido do aplicativo. Se as auditorias de atividade estiverem habilitadas no Dynamics 365, várias atividades do usuário serão registradas no Centro de administração do Microsoft 365. Ao usar esses logs, é possível identificar atividades incomuns ou potencialmente mal-intencionadas no sistema, incluindo ações comuns como:

  • Quem publicou personalizações

  • Quem foi adicionado a uma equipe

  • Quem adicionou uma solução

  • Quem publicou personalizações

  • Quem exportou para o Excel

  • Quem visualizou um relatório

  • Quem exportou um relatório

Os logs de auditoria padrão são monitorados quando os usuários acessam o sistema. As ferramentas como Microsoft Power Automate podem alertar quando certas atividades acontecerem e o Microsoft Entra ID pode alertar quando pessoas fora da região acessarem o sistema.

Nesta seção do modelo de workshop do Modelo de segurança, você resumirá a estratégia para monitorar e alertar o comportamento anormal e os planos para verificar regularmente as permissões do usuário no Dynamics 365.

Regulamentos e conformidade

Nesta seção do modelo, você identificará se há regulamentos governamentais ou de conformidade que possam impactar o modelo de segurança do Dynamics 365. Isso inclui regulamentações de proteção de dados de consumo como a HIPAA e a SEC e as preocupações com o auditor, como a segmentação comercial. Preencha as informações no slide sobre regulamentos e conformidade.