Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este domínio de segurança foi concebido para garantir que todos os dados consumidos do Microsoft 365 estão devidamente protegidos em trânsito e inativos. Este domínio também garante que as preocupações de privacidade dos consumidores (titulares dos dados) estão a ser satisfeitas pelo ISV, em conformidade com o RGPD (Regulamento Geral sobre a Proteção de Dados) e a HIPAA (Health Insurance Portability and Accountability Act de 1996).
Dados em Trânsito
Os requisitos de conectividade das aplicações/suplementos desenvolvidos do Microsoft 365 exigem comunicação através de redes públicas, especificamente a Internet. Por conseguinte, os dados em trânsito têm de ser devidamente protegidos. Esta secção abrange a proteção das comunicações de dados através da Internet.
Controlo N.º 1
Forneça provas para todos os seguintes procedimentos:
Confirme que a Configuração do TLS é TLS1.2 ou superior.
É mantido e mantido um inventário de chaves e certificados fidedignos.
Intenção: TLS
A intenção deste subponto é garantir que os dados do Microsoft 365 que estão a ser consumidos pela sua organização sejam transmitidos de forma segura. A Configuração do Perfil TLS é utilizada para definir requisitos específicos do TLS que ajudam a garantir que o tráfego está seguro contra ataques man-in-the-middle.
Diretrizes: TLS
A forma mais fácil de evidenciar isto é executar a ferramenta qualys SSL Server Test em TODOS os serviços de escuta web, incluindo qualquer que seja executado em portas não padrão.
Lembre-se de marcar a opção "Não mostrar os resultados nos quadros", o que impede que o URL seja adicionado ao site.
Os Requisitos de Configuração do Perfil TLS podem ser demonstrados ao fornecer provas de verificações individuais. Para fornecer provas de definições específicas, como desativar a Compressão TLS, podem ser utilizadas definições de configuração, scripts e ferramentas de software.
Exemplo de evidência: TLS
A captura de ecrã seguinte mostra os resultados da análise SSL da Qualys para a webappfrontdoor- byendbagh6a0fcav.z01.azurefd.net.
A secção Protocolos mostra que o TLS1.2 é o único protocolo suportado/ativado.
Nota: os analistas de certificação irão rever a saída completa da análise para confirmar que todos os requisitos dos requisitos de configuração do perfil TLS são cumpridos. A expectativa será que sejam fornecidas análises para todos os pontos finais que estão expostos publicamente (Endereços IP e URLs) ao ambiente de back-end que está no âmbito. Dependendo das provas fornecidas, os analistas podem executar a sua própria análise qualys.
Exemplo de evidência: TLS
A captura de ecrã seguinte mostra as definições de configuração do TLS no serviço de aplicações do Azure, seguidas da enumeração TLS através do PowerShell.
Intenção: chaves e certificados
A intenção deste subponto é garantir a manutenção de um inventário abrangente de chaves e certificados fidedignos, que envolve a identificação de vários sistemas, serviços e aplicações que dependem destes elementos criptográficos.
Diretrizes: chaves e certificados
As provas têm de demonstrar que existe e mantém um inventário de chaves e certificados fidedignos. Além disso, as provas aplicáveis das ferramentas utilizadas para armazenar as chaves e certificados reais podem ser fornecidas, como o cofre de chaves do Azure, os Segredos do Cofre da HashiCorp, a Cloud de Confluence, etc.
Exemplo de provas: chaves e certificados
A captura de ecrã seguinte mostra que uma chave e um inventário de certificados são mantidos na Confluence Cloud.
A seguinte captura de ecrã mostra a lista aprovada de chaves e certificados fidedignos. Inclui detalhes como o certificado, chaves, cifras e os sistemas nos quais estão instalados.
A seguinte captura de ecrã é do HashiCorp Vault. Os certificados descritos e registados na lista de inventário estão a ser armazenados neste cofre online. O HashiCorp Vault é uma ferramenta open source para gestão de segredos, encriptação como serviço e gestão de acesso privilegiado.
A seguinte captura de ecrã é uma extração do certificado real e as chaves armazenadas no cofre online.
Página 
Nota: a expectativa será que a localização de armazenamento das chaves tenha controlos de acesso adequados. Se a chave privada estiver comprometida, alguém pode falsificar o servidor com um certificado legítimo.
Exemplo de provas: chaves e certificados
Um inventário de chaves e certificados fidedignos também pode ser mantido com o Microsoft 365 Defender, que fornece uma funcionalidade de Inventário, conforme mostrado na captura de ecrã seguinte.
A captura de ecrã seguinte mostra os detalhes do certificado.
Nota: estes exemplos não são capturas de ecrã inteiro. Terá de submeter capturas de ecrã inteiro com qualquer URL, utilizador com sessão iniciada e carimbo de data e hora para revisão de provas. Se for um utilizador do Linux, isto pode ser feito através da linha de comandos.
Controlo N.º 2
Forneça provas para todos os seguintes procedimentos:
Mostra que a compressão TLS está desativada para todos os serviços destinados ao público que lidam com pedidos Web para prevenir a CRIMINALIDADE (Compressão Ratio Info-leak Made Easy).
Valida que o TLS HSTS está ativado e configurado para 180 dias em todos os sites.
Intenção: TLS
O ataque CRIME (Compression Ratio Info-leak Made Easy (CVE-2012-4929)) é uma vulnerabilidade na compressão dos protocolos SSL (Secure Sockets Layer)/Transport Layer Security (TLS). Por este motivo, as recomendações do setor são desativar a compressão SSL.
O HTTP Strict Transport Security (HSTS) é um mecanismo de segurança concebido para proteger os sites contra ataques man-in-the-middle ao forçar ligações TLS através de um campo de cabeçalho de resposta HTTPS denominado "Strict-Transport-Security".
Diretrizes: TLS
Isto pode ser evidenciado através da ferramenta Qualys SSL Labs. Exemplo de evidência: TLS
A seguinte captura de ecrã mostra que a compressão SSL/TLS está desativada.
A captura de ecrã seguinte mostra que o HSTS está ativado.
Nota: o analista de certificação irá rever a saída completa para confirmar que todos os requisitos dos Requisitos de Configuração do Perfil TLS são cumpridos (forneça capturas de ecrã da saída completa da análise). Dependendo das provas fornecidas, os analistas podem executar a sua própria análise qualys.
Outras ferramentas que podem ser utilizadas para marcar que o HSTS está ativado são "Espião de Cabeçalho HTTP" e
securityheaders.com conforme mostrado nos exemplos seguintes. Provas Adicionais
Capturas de ecrã, como as definições de configuração dos cabeçalhos de segurança, especificamente O HSTS pode ser fornecido para demonstrar ainda mais a postura de segurança da pegada pública.
As capturas de ecrã seguintes mostram a configuração do Azure Front Door e o conjunto de regras implementado para reescrever os cabeçalhos.
A captura de ecrã seguinte mostra a análise de cabeçalhos de segurança efetuada e que todos os cabeçalhos de segurança são implementados e não apenas HSTS.
Nota: se forem utilizados o Scanner SSL da Qualys ou os Cabeçalhos de Segurança, a expectativa será que o relatório completo seja fornecido para uma revisão.
Dados em repouso
Quando os dados consumidos a partir da plataforma do Microsoft 365 são armazenados por ISVs, os dados têm de ser devidamente protegidos. Esta secção abrange os requisitos de proteção dos dados armazenados em bases de dados e arquivos de ficheiros.
Controlo N.º 3
Forneça provas de que os dados inativos são encriptados de acordo com os requisitos do perfil de encriptação, utilizando algoritmos de encriptação como AES, Blowfish, TDES e tamanhos de chave de encriptação de 128 bits e 256 bits.
Intenção:
Alguns algoritmos de encriptação mais antigos são conhecidos por conterem algumas fraquezas criptográficas, o que aumenta as hipóteses de um ator de ameaças conseguir desencriptar os dados sem o conhecimento da chave. Por este motivo, a intenção deste controlo é garantir que apenas os algoritmos de encriptação aceites pela indústria são utilizados para proteger dados M365 armazenados.
Diretrizes:
As provas podem ser fornecidas através de capturas de ecrã, que mostram a encriptação que está a ser utilizada para proteger os dados do M365 em bases de dados e noutras localizações de armazenamento. As provas devem demonstrar que a configuração de encriptação está em conformidade com os Requisitos de Configuração do Perfil de Encriptação da Certificação do Microsoft 365.
Exemplo de provas:
A captura de ecrã seguinte mostra que a Encriptação de Dados Transparente (Encriptação de Dados Transparente) está ativada na base de dados da Contoso. A segunda captura de ecrã mostra a página de documentação da Microsoft Encriptação de dados transparente para Banco de Dados SQL, Instância Gerenciada de SQL e Análise de Azure Synapse a mostrar que a encriptação AES 256 é utilizada para a Encriptação de Dados Transparente do Azure.
Nota: nos exemplos anteriores, não foram utilizadas capturas de ecrã completas. No entanto, todas as capturas de ecrã submetidas pelo ISV têm de ser capturas de ecrã completas a mostrar o URL, qualquer data e hora do utilizador e do sistema com sessão iniciada.
Exemplo de provas:
A captura de ecrã seguinte mostra o Armazenamento do Azure configurado com encriptação para blobs e ficheiros. A captura de ecrã seguinte mostra a página Documentação da Microsoft Encriptação do Armazenamento do Azure para dados inativos que mostra que o Armazenamento do Microsoft Azure utiliza a AES-256 para encriptação.
Retenção, cópia de segurança e eliminação de dados
Quando os ISVs consomem e armazenam dados do Microsoft 365, existe o risco de um compromisso de dados caso um ator de ameaças comprometa o ambiente ISV. Para minimizar este risco, as organizações só devem manter os dados de que precisam para fornecer serviços e não dados que "possam" ser utilizados no futuro. Além disso, os dados só devem ser mantidos durante o tempo necessário para fornecer os serviços para os que os dados foram capturados. A retenção de dados deve ser definida e comunicada com os utilizadores. Depois de os dados excederem o período de retenção definido, estes têm de ser eliminados de forma segura para que os dados não possam ser reconstruídos ou recuperados.
Controlo N.º 4
Indique a prova de que um período de retenção de dados aprovado é formalmente estabelecido e documentado.
Intenção:
Uma política de retenção documentada e seguida é importante não só para cumprir algumas obrigações legais, como, por exemplo, legislação sobre privacidade de dados, como, mas não se limitando a, o Regulamento Geral sobre a Proteção de Dados (RGPD da UE) e a Lei de Proteção de Dados (DPA do Reino Unido 2018), mas também para limitar o risco de uma organização. Ao compreender os requisitos de dados das organizações e durante quanto tempo os dados são necessários para a empresa desempenhar as suas funções, as organizações podem garantir que os dados são eliminados corretamente assim que a sua utilidade expirar. Ao reduzir os volumes de dados armazenados, as organizações estão a reduzir a quantidade de dados que seriam expostos caso ocorra um comprometimento de dados. Isto irá limitar o impacto geral.
Muitas vezes, as organizações armazenam dados porque é bom ter apenas por via das dúvidas. No entanto, se a organização não precisar dos dados para efetuar o serviço ou a função empresarial, os dados não devem ser armazenados, uma vez que isto está a aumentar desnecessariamente o risco da organização.
O objetivo deste controlo é confirmar que a organização estabeleceu formalmente e documentou um período de retenção de dados aprovado para todos os tipos de dados relevantes. Isto envolve não só especificar a duração para a qual serão armazenados diferentes tipos de dados, mas também delinear os procedimentos para eliminação de dados ou arquivamento após a expiração.
Diretrizes:
Forneça a política de retenção de dados completa que detalha claramente durante quanto tempo os dados (têm de abranger todos os tipos de dados) devem ser mantidos para que a empresa possa desempenhar as suas funções empresariais.
Exemplo de provas:
A captura de ecrã seguinte mostra a política de retenção de dados da Contoso.
Nota: estas capturas de ecrã mostram uma snapshot de um documento de política/processo. A expectativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.
Controlo N.º 5
Demonstre que os dados são retidos apenas para o período de retenção definido, conforme discutido no controlo 4.
Intenção:
A intenção deste controlo é simplesmente validar que os períodos de retenção de dados definidos estão a ser cumpridos. Tal como já foi discutido, as organizações podem ter a obrigação legal de cumprir esta situação, mas também ao manter os dados que são necessários e durante o tempo que for necessário ajudam a reduzir o risco para a organização caso ocorra uma falha de segurança de dados. Isto garante que os dados não são retidos durante uma duração excessivamente longa nem eliminados prematuramente, sendo que ambos podem representar riscos de natureza variável— relacionadas com a segurança, legal, operacional ou de segurança.
Diretrizes:
Forneça provas de captura de ecrã (ou através de screenshare) que mostram que os dados armazenados (em todas as várias localizações de dados, incluindo bases de dados, partilhas de ficheiros, arquivos e cópias de segurança) não excedem a política de retenção de dados definida. Exemplos de capturas de ecrã aceitáveis incluem:
- Registos de Base de Dados com um campo de data, pesquisado na ordem de registo mais antiga e/ou
- Localizações de Armazenamento de Ficheiros a mostrar carimbos de data/hora dentro do período de retenção. Nota: todos os dados pessoais ou confidenciais do cliente devem ser redigidos na captura de ecrã.
- Registos de cópia de segurança que mostram que os dados de cópia de segurança são mantidos dentro do período de retenção definido e eliminados corretamente após este período.
Exemplo de provas:
A seguinte prova mostra uma consulta SQL que mostra o conteúdo da tabela da base de dados ordenada por ordem ascendente no campo "DATE_TRANSACTION" para mostrar os registos mais antigos na base de dados. Isto mostra que os dados têm menos de dois meses, o que não excede o período de retenção definido.
Nota: esta é uma base de dados de teste, pelo que não existem muitos dados históricos na mesma.
Nota: nos exemplos anteriores, não foram utilizadas capturas de ecrã completas. No entanto, todas as capturas de ecrã submetidas pelo ISV têm de ser capturas de ecrã completas que mostrem o URL, qualquer data e hora do sistema e utilizador com sessão iniciada.
Controlo N.º 6
Demonstre que os processos estão implementados para eliminar dados de forma segura após o respetivo período de retenção.
Intenção:
A intenção deste controlo é garantir que o mecanismo utilizado para eliminar dados que excedam o período de retenção está a fazê-lo de forma segura. Por vezes, os dados eliminados podem ser recuperados; Por conseguinte, o processo de eliminação tem de ser suficientemente robusto para garantir que os dados não podem ser recuperados depois de eliminados.
Diretrizes:
Se o processo de eliminação for feito através de programação, forneça uma captura de ecrã do script utilizado para efetuar esta ação. Se for executado com base numa agenda, forneça uma captura de ecrã a mostrar a agenda. Por exemplo, um script para eliminar ficheiros numa partilha de ficheiros pode ser configurado como uma tarefa CRON, captura de ecrã da tarefa CRON que mostra a agenda e o script que é executado; e forneça o script que mostra o comando utilizado.
Exemplo de provas:
Este é um script simples que pode ser utilizado para eliminar todos os registos de dados retidos com base na data -WHERE DateAdd é -30 dias, o que removerá todos os registos retidos com mais de 30 dias após a data de retenção de dados selecionada. Tenha em atenção que vamos precisar do script; prova de que o trabalho está a ser executado e os resultados.
Nota: nos exemplos anteriores, não foram utilizadas capturas de ecrã completas. No entanto, todas as capturas de ecrã submetidas pelo ISV têm de ser capturas de ecrã completas a mostrar o URL, qualquer data e hora do utilizador e do sistema com sessão iniciada.
Exemplo de provas:
A captura de ecrã seguinte foi obtida a partir da Política de Retenção de Dados da Contoso (do Controlo 4) – mostra os procedimentos utilizados para a destruição de dados.
Nota: esta captura de ecrã mostra uma snapshot de um documento de política/processo. A expectativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.
Exemplo de provas:
Neste exemplo, foi criado um Runbook e uma agenda correspondente no Azure para eliminar de forma segura registos que tenham uma data de fim criada a partir dos 30 dias após a expiração da política de retenção de registos de dados. Esta tarefa está definida para ser executada todos os meses no último dia do mês.
A captura de ecrã seguinte mostra que o Runbook foi editado para localizar registos e tem comandos de eliminação que não estão visíveis como o script.
Nota: o URL completo e o nome de utilizador têm de estar visíveis para estas capturas de ecrã e serão necessários ISVs para mostrar uma captura de ecrã de antes da contagem de registos de eliminação e uma captura de ecrã de após a contagem de registos de eliminação.
Estas capturas de ecrã são apenas exemplos das diferentes formas de abordagem.
Controlo N.º 7
Forneça provas que demonstrem que:
Um sistema de cópia de segurança automatizado está implementado e configurado para efetuar cópias de segurança em horas agendadas.
As informações de cópia de segurança são testadas em conformidade com o procedimento de agendamento de cópias de segurança e restauradas periodicamente para confirmar a fiabilidade e integridade dos dados.
São implementados controlos de acesso e mecanismos de proteção adequados (ou seja, cópias de segurança imutáveis) para garantir que as cópias de segurança/instantâneos do sistema estão protegidos contra o acesso não autorizado e para garantir a confidencialidade, integridade e disponibilidade dos dados de cópia de segurança.
Intenção:
O objetivo deste controlo é confirmar que a organização tem um sistema de cópia de segurança automatizado implementado, que está configurado para executar cópias de segurança em horas predeterminadas.
Diretrizes:
Forneça capturas de ecrã das definições de configuração da solução de cópia de segurança que mostram que as cópias de segurança estão a ser executadas em períodos/intervalos de tempo agendados. Se o agendamento de cópias de segurança for feito automaticamente pela solução, pode ser suportado ao fornecer documentação do fornecedor.
Exemplo de provas:
A captura de ecrã seguinte aplica-se ao Banco de Dados do Azure para MySQL, que é uma instância gerida. Indica que foi concluída uma primeira cópia de segurança automatizada.
A captura de ecrã seguinte é efetuada após a passagem de um período e mostra que foram feitas mais cópias de segurança completas. As cópias de segurança em servidores flexíveis são baseadas em snapshot em que a primeira cópia de segurança snapshot é agendada imediatamente após a criação de um servidor e snapshot cópias de segurança adicionais são efetuadas uma vez por dia.
A captura de ecrã seguinte mostra uma snapshot de documentação online que descreve a frequência da cópia de segurança e a capacidade de cópia de segurança automatizada.
Intenção:
O objetivo deste controlo é confirmar que as informações de cópia de segurança não só são geradas de acordo com o agendamento, como também são fiáveis e mantêm a sua integridade ao longo do tempo. Para cumprir este objetivo, serão realizados testes periódicos nos dados de cópia de segurança.
Diretrizes:
As provas para cumprir este controlo dependerão do processo e do procedimento da organização para testar os dados de cópia de segurança. Podem ser fornecidas provas que mostram que as cópias de segurança estão a ser testadas com êxito juntamente com registos de conclusão de testes históricos.
Exemplo de provas:
A captura de ecrã seguinte mostra que existe um procedimento de agendamento e restauro de cópias de segurança e é mantido e que é definida uma configuração de cópia de segurança para todos os sistemas aplicáveis, incluindo a frequência de cópias de segurança em execução na plataforma Confluence.
A captura de ecrã seguinte mostra uma página de registos históricos de testes de cópias de segurança para cada um dos sistemas aplicáveis. Observe que, no lado direito da tabela, as permissões JIRA são referenciadas para cada um dos testes.
As quatro capturas de ecrã seguintes mostram o processo ponto a ponto de restaurar a Banco de Dados do Azure para MySQL a partir de um snapshot. Com a opção "Restauro Rápido", podemos iniciar o processo de restauro da base de dados SQL.
A seguinte captura de ecrã mostra a página de configuração onde podemos personalizar o restauro.
Assim que a localização de destino, a rede e a snapshot a partir das quais a base de dados será restaurada estiverem selecionadas, podemos iniciar a implementação. Observe que a nossa instância de base de dados é agora denominada "teste".
Após um total de cinco minutos, a base de dados SQL foi restaurada com êxito e totalmente restaurada a partir do snapshot de cópia de segurança, conforme mostrado a seguir.
Uma vez concluído o teste, em linha com o processo, foi criado um pedido JIRA para registar os testes de cópia de segurança e os detalhes do restauro realizado. Isto garante que os dados históricos estão disponíveis para fins de conformidade, bem como existem registos completos para revisão na eventualidade de um incidente ou desastre, de modo a permitir que a organização efetue uma análise da causa raiz.
Intenção:
A partir do controlo anterior, os controlos de acesso devem ser implementados para limitar o acesso apenas a utilizadores individuais responsáveis pelos dados de cópia de segurança. Ao limitar o acesso, está a limitar o risco de efetuar alterações não autorizadas e, assim, introduzir alterações inseguras. Deve ser tomada uma abordagem com menos privilégios para proteger as cópias de segurança.
Para proteger corretamente os dados, as organizações têm de estar cientes dos dados que o seu ambiente/sistema está a consumir e onde os dados estão a ser armazenados. Assim que isto estiver totalmente compreendido e documentado.
Em seguida, as organizações podem não só implementar uma proteção de dados adequada, mas também consolidar onde os dados estão localizados para implementar a proteção de forma mais eficaz. Além disso, quando os dados são consolidados para o menor número possível de locais, é muito mais fácil implementar UM RBAC adequado (controlo de acesso baseado em funções) para limitar o acesso ao número de funcionários que for necessário.
Diretrizes:
Devem ser fornecidas provas do sistema/tecnologia utilizadas para demonstrar as permissões de acesso às cópias de segurança e soluções de cópia de segurança com documentação de suporte da lista de acesso aprovada.
Exemplo de provas:
Podemos ver nas capturas de ecrã seguintes apresentadas que os controlos de acesso são implementados na instância da base de dados para restringir o acesso apenas a indivíduos autorizados com base na função da tarefa.
Exemplo de provas:
SQL do Azure As cópias de segurança automatizadas da Base de Dados e do SQL do Azure Managed Instances são geridas pelo Azure e a sua integridade é da responsabilidade da plataforma do Azure; nenhum utilizador tem acesso às mesmas e é encriptada em inatividade sem possibilidade de ataques de ransomware. Também são replicadas para outras regiões para proteção.
Gestão de acesso a dados
O acesso a dados tem de ser limitado a tão poucas pessoas quanto necessário para reduzir as hipóteses de os dados serem comprometidos maliciosamente ou acidentalmente. O acesso a chaves de dados e encriptação deve ser limitado a utilizadores com uma necessidade comercial legítima de acesso para desempenhar a função de trabalho. Deve ser implementado um processo bem documentado e bem estabelecido para pedir acesso. O acesso a chaves de dados e encriptação deve seguir o princípio de menor privilégio.
Controlo N.º 8
Forneça provas que demonstrem que uma lista de indivíduos com acesso a dados e/ou chaves de encriptação:
é mantida, incluindo a justificação comercial para cada indivíduo.
foram formalmente aprovados com base nos privilégios de acesso necessários para a função de trabalho.
são configurados com os privilégios descritos na aprovação.
Intenção:
As organizações devem limitar o acesso a chaves de dados e encriptação ao menor número possível de funcionários. A intenção deste controlo é garantir que o acesso dos funcionários aos dados e/ou às chaves de encriptação seja restringido aos funcionários com uma necessidade de negócio clara para esse acesso.
Diretrizes:
Documentação ou capturas de ecrã de sistemas internos que documentam todos os funcionários com acesso a dados e/ou chaves de encriptação, juntamente com a justificação comercial do motivo pelo qual estas pessoas têm acesso devem ser fornecidas. Esta lista será utilizada pelo analista de certificação para exemplo de utilizadores para os próximos controlos.
Exemplo de provas:
O documento seguinte mostra a lista documentada de utilizadores com acesso aos dados e a justificação comercial.
Nota: esta captura de ecrã mostra um documento de política/processo. A expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real.
Intenção:
O processo de concessão de acesso a dados e/ou chaves de encriptação tem de incluir aprovação, garantindo que o acesso de um indivíduo é necessário para a função de trabalho. Isto garante que os funcionários sem um motivo genuíno de acesso não obtenham acesso desnecessário.
Diretrizes:
Normalmente, as provas fornecidas para o controlo anterior podem ajudar a suportar este controlo. Se não existir uma aprovação formal na documentação fornecida, os elementos de prova poderão consistir num pedido de alteração a ser gerado e aprovado para o acesso numa ferramenta como o Azure DevOps ou jira.
Exemplo de provas:
Este conjunto de imagens mostra permissões Jira criadas e aprovadas para o controlo (i) para conceder ou negar o acesso a dados confidenciais e/ou chaves de encriptação. Esta imagem demonstra que foi criado um pedido em Jira para obter a aprovação de Sam Daily para Chaves de Encriptação no ambiente de back-end dos sistemas. Isto é feito como o próximo passo em que a autorização escrita foi obtida.
Isto mostra que o pedido para dar acesso diário a Sam Foi aprovado por Jon Smith uma pessoa da administração. (Tenha em atenção que a aprovação tem de ser proveniente de alguém com autoridade suficiente para permitir o pedido de alteração, não pode ser outro programador).
O anterior mostra um fluxo de trabalho em Jira para este processo. Tenha em atenção que nada pode ser adicionado como Concluído, a menos que tenha passado pelo processo de aprovação que é automatizado e, portanto, não pode ser ignorado.
O quadro do Project está agora a mostrar que foi dada aprovação para o acesso do Sam Daily às chaves de encriptação. O seguinte registo de tarefas pendentes mostra a aprovação do pedido de Sam Daily e a pessoa atribuída para fazer o trabalho.
Para cumprir os requisitos deste controlo, tem de mostrar todas estas capturas de ecrã ou provas semelhantes/equivalentes aplicáveis com uma explicação para demonstrar que cumpriu o requisito de controlo.
Nota: nos exemplos anteriores, não foram utilizadas capturas de ecrã completas. No entanto, todas as capturas de ecrã submetidas pelo ISV têm de ser capturas de ecrã completas a mostrar o URL, qualquer data e hora do utilizador e do sistema com sessão iniciada.
Exemplo de provas:
No exemplo seguinte, foram pedidas permissões de acesso de administrador e controlo total para um utilizador para a base de dados de produção. O pedido foi enviado para aprovação, tal como pode ser visto à direita da imagem, e este foi aprovado conforme mostrado à esquerda.
A imagem seguinte indica que o acesso foi aprovado e assinado como concluído.
Nota: nos exemplos anteriores, não foram utilizadas capturas de ecrã completas. No entanto, todas as capturas de ecrã submetidas pelo ISV têm de ser capturas de ecrã completas a mostrar o URL, qualquer data e hora do utilizador e do sistema com sessão iniciada.
Intent
A intenção deste subponto é confirmar que o acesso a dados e/ou chave de encriptação está configurado de acordo com o documentado.
Diretrizes:
As provas podem ser fornecidas através de uma captura de ecrã que mostra os dados e/ou os privilégios de acesso da chave de encriptação concedidos aos indivíduos de amostra. As provas têm de abranger todas as localizações de dados.
Exemplo de provas:
Esta captura de ecrã mostra as permissões concedidas ao utilizador "John Smith" que seriam cruzadas
referenciado relativamente ao pedido de aprovação para este mesmo utilizador de acordo com as provas do controlo anterior.
Nota: o exemplo seguinte não é uma captura de ecrã inteiro. Terá de submeter capturas de ecrã inteiro com qualquer URL, utilizador com sessão iniciada e carimbo de data e hora para revisão de provas. Se for um utilizador do Linux, isto pode ser feito através da linha de comandos.
Controlo N.º 9
Forneça provas de que:
É mantida uma lista de todos os terceiros com os quais os dados são partilhados.
Os contratos de partilha de dados estão em vigor com todos os terceiros que consomem dados.
Intenção:
Quando são utilizados terceiros para armazenamento ou processamento de dados do Microsoft 365, estas entidades podem representar um risco significativo. As organizações devem desenvolver um bom processo de gestão e diligência de terceiros para garantir que estes terceiros estão a armazenar/processar dados de forma segura e garantir que respeitarão quaisquer obrigações legais que possam ter, por exemplo, como processador de dados ao abrigo do RGPD.
As organizações devem manter uma lista de todos os terceiros com os quais partilham dados com alguns ou todos os seguintes:
que serviço(s) é(estão) a ser fornecidos
que dados são partilhados
por que motivo os dados são partilhados
informações de contacto chave (ou seja, contacto principal, contacto de notificação de violação, DPO, etc.)
renovação/expiração do contrato
obrigações legais/de conformidade (ou seja, RGPD, HIPAA, PCI DSS, FedRAMP, etc.)
Diretrizes:
Forneça documentação que detalha todos os terceiros com os quais os dados do Microsoft 365 são partilhados.
Nota: se terceiros não estiverem a ser utilizados, isto terá de ser confirmado por escrito (e-mail) por um membro da equipa de liderança sénior.
Exemplo de provas:
Nota: nos exemplos anteriores, não foram utilizadas capturas de ecrã completas. No entanto, todas as capturas de ecrã de provas submetidas pelo ISV têm de ser capturas de ecrã completas que mostrem o URL, qualquer data e hora do sistema e utilizador com sessão iniciada.
Exemplo de provas:
A seguinte captura de ecrã mostra um exemplo de e-mail de um membro da equipa de liderança sénior a confirmar que não são utilizados terceiros para processar dados do Microsoft 365.
Nota: nestes exemplos, não foram utilizadas capturas de ecrã completas. No entanto, todas as capturas de ecrã de provas submetidas pelo ISV têm de ser capturas de ecrã completas a mostrar o URL, qualquer data e hora do utilizador e do sistema com sessão iniciada.
Intenção:
Quando os dados do M365 são partilhados com terceiros, é importante que os dados estejam a ser processados de forma adequada e segura. Os contratos de partilha de dados têm de estar em vigor para garantir que terceiros processam os dados apenas conforme necessário e que compreendem as suas obrigações de segurança. A segurança de uma organização é tão forte quanto a ligação mais fraca. A intenção deste controlo é garantir que terceiros não se tornem um elo fraco das organizações.
Diretrizes:
Indique os contratos de partilha de dados que estão em vigor com terceiros.
Exemplo de provas:
A captura de ecrã seguinte mostra um exemplo simplista de um contrato de partilha de dados.
Nota: o contrato completo deve ser partilhado e não uma captura de ecrã.
Privacidade
A conformidade de privacidade e a gestão de informações são essenciais para proteger os direitos das pessoas e garantir o processamento de dados responsável. Para que uma organização estabeleça um sistema de informações de privacidade eficaz, tem de estar ciente dos dados pessoais que detém e da finalidade do processamento e armazenamento desses dados. Uma organização deve mapear o fluxo de informações e como isto é processado, reconhecendo que podem estar a ocorrer vários tipos diferentes de processamento.
Controlo N.º 10 – Dados Pessoais
Forneça provas de que a sua organização:
A) Mantém um inventário atualizado de todos os dados pessoais recolhidos, processados e armazenados, incluindo a finalidade de cada elemento de dados.
B) Estrutura formulários de recolha de dados para incluir apenas campos necessários para fins empresariais e implementa campos obrigatórios e opcionais adequadamente.
C) Desenvolve e impõe políticas que especificam os tipos de dados pessoais que podem ser recolhidos e os fins para os quais podem ser utilizados.
D) Permite que os utilizadores optem ativamente por não processar ou analisar de forma abrangente os seus dados essenciais pessoais e não empresariais.
Intenção:
A intenção deste controlo é garantir que está a aderir à privacidade dos dados relacionada com a recolha de dados, garantindo que existe uma justificação para os dados que estão a ser capturados e para ser transparente com o que e por que motivo os dados são recolhidos. Também é importante que os utilizadores (titulares dos dados) tenham a capacidade de optar ativamente por não processar.
Diretrizes:
Este controlo pode ser evidenciado da seguinte forma:
A) Forneça uma versão atual do Registo de Atividades de Processamento (RoPA) da organização (Consulte o Artigo 30.º do RGPD) ou documento semelhante que detalha os elementos de dados e a finalidade(s) do processamento (Consulte o artigo 5.1.b do RGPD).
Na maioria dos casos, esta seria uma folha de cálculo do Excel (que poderia ser extraída de ferramentas, como o OneTrust).
Se o ficheiro for demasiado grande ou contiver dados confidenciais, poderá ser fornecido um excerto que mostra todos os campos de dados de uma determinada amostra de dados, que podem ser parcialmente redigidos, desde que as provas possam garantir que o RoPA está em vigor.
Não conforme: os registos não existem, são muito antigos/desatualizados ou faltam campos de chave.
B) Para efeitos de "Minimização de Dados" (consulte o artigo 5.1.c do RGPD), forneça todos os formulários utilizados para obter dados, quer sejam online, através de tablets ou dispositivos semelhantes (por exemplo, numa conferência) ou documento. Estes podem estar em branco/modelos.
Não conforme: os formulários têm campos obrigatórios que não são necessários para o objetivo de processamento pretendido. Por exemplo, pedir números de telefone, idade ou género para enviar uma brochura por e-mail ou para um endereço postal.
C) Para efeitos de "legalidade, equidade e transparência" (Consulte o artigo 5.1.a do RGPD) a Política de Privacidade (destinado aos funcionários), o Aviso de Privacidade (destinado a utilizadores/clientes) tem de estar em vigor. Normalmente, o Aviso de Privacidade deve estar disponível publicamente no site da organização.
Não conforme: as políticas não existem ou faltam elementos-chave.
Elementos-chave:
Política de Privacidade/Aviso: recolha e utilização de informações, elementos de dados processados, objetivos do processamento, legalidade do processamento, transferências de dados para outros países, direitos do titular dos dados, armazenamento e retenção de dados.
D) Relativamente ao mecanismo de opt-out (Consulte o artigo 4.11.º do RGPD, artigo 6.º do RGPD e o artigo 7.º do RGPD), normalmente numa página Web. Verifique a navegação que o utilizador teria de seguir para aceder a essa página (por exemplo, é fácil de encontrar?).
Não conforme: nenhuma funcionalidade clara de opt-out ou opt-out "genérico", sem granularidade.
Exemplo de provas:
Para A):
Para B):
Para C):
Para D):
Controlo N.º 11 – Deteção do Utilizador
Forneça provas de que os utilizadores estão cientes de:
A) quem tem acesso aos respetivos dados
B) quem tem acesso aos espaços em que está a trabalhar
C) quem poderia obter acesso aos respetivos dados através da partilha ou dos fluxos de dados para que possam tomar decisões informadas.
Intenção:
O objetivo deste controlo é demonstrar o princípio "Transparência" da proteção de dados (consulte o artigo 5.1.a do RGPD) é cumprido.
Diretrizes:
Para demonstrar isto, idealmente, deve existir alguma forma de reconhecimento do utilizador (por exemplo, ter lido a Política de Privacidade) em vigor e ser registada.
Na prática, apenas a Política de Privacidade (para funcionários), o Aviso de Privacidade (para utilizadores e clientes), fornece detalhes suficientes sobre o seguinte:
- Com quem os dados pessoais estão a ser partilhados (processadores, subcontratantes, terceiros, contratantes, etc.).
Não conforme: não existem confirmações ou a Política de Privacidade/Aviso de Privacidade não existe.
Exemplo de provas:
OU
N.º de Controlo 12 – Contratos de Processamento de Dados (DPAs)
Forneça provas do Contrato de Processamento de Dados, que deve ter uma lista de todos os terceiros/subcontratantes aprovados.
Intenção:
Para garantir que está a ser transparente com os titulares dos dados, garantindo que são informados sobre que terceiros/subcontratantes podem ter acesso aos respetivos dados, a função que desempenham no processamento (controlador de dados, processador de dados), as respetivas responsabilidades e mecanismos de segurança em vigor.
Além disso, quando a partilha de dados implicaria transferências de dados para territórios fora da UE (ao abrigo do RGPD), os detalhes do mecanismo para garantir as transferências são legais. (Consulte o artigo 5.º do RGPD e o artigo 44-50.o do RGPD)
Para o RGPD, os territórios de processamento têm de cumprir uma das seguintes condições:
- Ser um Estado-Membro da União Europeia.
- Ser considerado pela Comissão Europeia para fornecer "salvaguardas adequadas". A lista atual pode ser encontrada aqui: Adequação da proteção de dados para países terceiros
A partir de13 de junho de 2025:
- Faça parte do Data Privacy Framework (DPF) e listado aqui: Estrutura de Privacidade de Dados
- Ter regras empresariais de enlace (BCRs) implementadas.
- Ter Standard Cláusulas Contratuais (SCCs) implementadas.
Diretrizes:
A prova pode ser através da amostragem de um par de Contratos de Processamento de Dados (DPA) com subcontratantes existentes. Em determinados casos, as organizações podem não ter DPAs, mas teriam adendas a contratos ou "Cláusulas de Privacidade".
Não conforme:
- Falta a lista de 3entidades/ subprotetores rd.
- Não são fornecidos detalhes sobre os países destinatários.
- Os países não estão listados como "países adequados" e não existem BCRs ou SCCs.
Exemplo de provas:
Este exemplo mostra um DPA de exemplo do IAPP ou uma prova pode ser um documento relacionado que lista as partes com quem os dados são partilhados.
Além disso, marcar os mecanismos de transferência de dados fora da UE.
Controlo N.º 13 – Avaliações de Impacto da Proteção de Dados (DPIAs)
Fornecer provas de que a sua organização realiza a Avaliação de Impacto da Proteção de Dados (DPIA)
OU
Indique o nome da avaliação relacionada com a privacidade e proteção de dados a que esta revisão de privacidade está ligada.
Intenção:
O objetivo deste controlo é garantir que está a realizar avaliações sobre os riscos potenciais para os direitos e liberdades das pessoas, especialmente relacionadas com a introdução de novas tecnologias, ou novas utilizações de tecnologias existentes. (Consulte o artigo 35.º do RGPD)
Diretrizes:
Este controlo seria avaliado através da revisão de uma DPIA recente ou de uma documentação de avaliação relacionada.
Não conforme:
Um DPIA deve ter os seguintes elementos:
- Identificação da necessidade de um DPIA.
- Descrição do processamento previsto, incluindo âmbito, contexto e finalidade(s).
- Avaliação da necessidade e proporcionalidade.
- Identificação e avaliação de riscos.
- Identificação de medidas para reduzir o risco.
- Resultados registados.
Se alguma das opções acima estiver em falta ou apenas for executada a um nível perfunctório, este controlo pode ser marcado como não conforme.
Exemplo de provas:
O modelo completo de um DPIA pode ser encontrado no site da ICO aqui dpia-template.docx
Controlo N.º 14 – Dados Biométricos
A aplicação interage com dados biométricos? Se sim,
Forneça provas de que os dados biométricos passaram pela revisão legal, estão protegidos e os utilizadores são informados e têm a opção de optar ativamente por participar/não participar na recolha de dados biométricos.
Intenção:
Este controlo está interessado em assegurar proteções adequadas dos dados biométricos, que, nos termos do artigo 9.º do RGPD , são classificados como uma categoria especial de dados. A utilização de dados biométricos foi submetida a uma análise legal.
Diretrizes:
A utilização de dados biométricos tem de passar por uma revisão legal, pelo que tem de ser fornecida como parte da recolha de provas. Se não existir nenhum, peça o modelo que seria utilizado (para marcar a preparação).
Não conforme:
A revisão legal sobre o processamento de dados biométricos deve conter o seguinte:
- Base jurídica do processamento (uma ou mais das seguintes:
| Consentimento | Desempenho de um contrato | Outra obrigação legal |
|---|---|---|
| Consentimento | Desempenho de um contrato | Outra obrigação legal |
| Interesses vitais | Interesse público | Interesse legítimo |
- Liste uma condição válida para o processamento de dados biométricos (uma ou mais das seguintes:
| Consentimento explícito do utilizador | Emprego ou segurança social |
|---|---|
| Consentimento explícito do utilizador | Emprego ou segurança social |
| Proteção de interesses vitais | Atividades legítimas |
| Dados pessoais manifestamente tornados públicos pelo titular dos dados | Estabelecimento, exercício ou defesa de reclamações legais |
| Interesse público substancial | Medicina preventiva ou ocupacional |
| Interesse público na área da saúde pública | Arquivamento para fins de interesse público, investigação científica ou histórica |
- Consideração dada à utilização de alternativas, em vez de dados biométricos.
Se alguma das opções acima estiver em falta ou apenas for executada a um nível perfunctório, este controlo pode ser marcado como não conforme.
Exemplo de provas:
Fontes:
- RGPD artigo 9.º – Processamento de Categorias Especiais de Dados: Arte. 9 RGPD – Processamento de categorias especiais de dados pessoais – Regulamento Geral sobre a Proteção de Dados (RGPD)
- ICO "Como processamos os dados biométricos legalmente?": Como processamos legalmente os dados biométricos? | ICO
Controlo N.º 15 – Informações de Dados
Forneça provas de que as métricas apenas mostram dados agregados e anonimizados sem dados identificáveis individualmente. O inquilino deve ser capaz de configurar o limite inferior do nível de agregação preferencial, com um mínimo absoluto de 5 permitido pelo produto.
Intenção:
A intenção deste controlo é garantir que implementou e mantém a status de dados anónimos e pseudonimizados ao longo do ciclo de vida dos dados. (Consulte
Diretrizes:
Para ajudar a demonstrar que este controlo está em vigor, devem ser fornecidas provas através da GUI ou da CLI para demonstrar:
- Configuração ao nível do utilizador para os limites mais baixos dos níveis de agregação.
- Uma amostra de métricas.
Avalie se o utilizador pode configurar um limiar para os níveis de agregação preferenciais para um mínimo de 5. As provas devem demonstrar que apenas o anonimizado está presente na amostra de métricas.
Não conforme:
- Os utilizadores não conseguem personalizar os respetivos níveis de agregação para um mínimo de 5 ou a competência técnica necessária para o fazer não pode ser esperada pelo utilizador típico.
- Os dados pessoais estão presentes no exemplo de métrica; por exemplo: nome, apelido, ID, número de cliente, número de telefone, endereço de e-mail, endereço postal, detalhes bancários, parente mais próximo, etc.
Exemplo de provas:
Capturas de ecrã das definições de configuração, que mostram os detalhes específicos.
Exemplo de métricas recolhidas. Talvez perguntar sobre o processo para alcançar o anonimato.
RGPD
A maioria das organizações irá processar dados que são potencialmente dados do Cidadão Europeu (titulares dos dados). Quando os dados de QUALQUER titular dos dados forem processados, as organizações terão de cumprir o Regulamento Geral sobre a Proteção de Dados (RGPD). Isto aplica-se aos Controladores de Dados (está a capturar diretamente esses dados) ou aos Processadores de Dados (está a processar estes dados em nome de um Controlador de Dados). Embora esta secção não aborde todo o regulamento, aborda alguns dos elementos-chave do RGPD para ajudar a obter alguma garantia de que a organização está a levar o RGPD a sério.
Controlo N.º 16
Forneça provas que demonstrem a adesão aos direitos dos titulares dos dados ao mostrar:
A) Facilitação do Pedido de Acesso do Requerente (SAR):
Documentação que confirma que os titulares dos dados são informados sobre o direito de aceder aos respetivos dados pessoais e podem submeter Pedidos de Acesso de Requerentes (SARs) à sua organização.
B) Deteção de Dados e cumprimento da SAR:
Prova da capacidade da sua organização de localizar e obter todos os dados pessoais relativos a um titular de dados individual em todos os sistemas e repositórios em resposta a uma SAR.
Intenção:
O objetivo deste controlo é garantir que existem mecanismos adequados para que os titulares dos dados façam pedidos sobre os seus dados pessoais detidos pela organização e que o cumprimento de pedidos legítimos seja minucioso. (Consulte o artigo 15.º do RGPD).
Diretrizes:
A) O Aviso de Privacidade deve conter detalhes sobre como criar uma SAR, que pode estar a utilizar os seguintes métodos:
- Utilizar um formulário Web fornecido pela organização
- Utilizar um endereço de e-mail fornecido pela organização
- Utilizar um número de telefone/webchat fornecido pela organização
- Utilizar uma Autoridade de Supervisão (por exemplo, a ICO no Reino Unido)
Pedir provas do método em vigor; as capturas de ecrã devem ser suficientes.
B) Um Documento RoPA ou semelhante pode ser utilizado para identificar as localizações onde residem os dados pessoais relativos ao titular dos dados, quer sejam digitais ou como parte de sistemas de arquivamento (físicos).
Em alternativa, os exercícios de deteção de e-discovery podem alcançar o mesmo resultado.
Peça provas do processo/fluxo de trabalho que seriam utilizados para cumprir uma SAR e uma explicação sobre como foi determinado que o processo é minucioso e não perderia quaisquer dados pessoais relacionados com o titular dos dados.
Não conforme:
A) Não são fornecidas informações no site da organização (normalmente no Aviso de Privacidade).
B) As provas indicam que o processo de recolha dos dados pessoais não é minucioso ou pode não ter detalhes técnicos (por exemplo, não são fornecidos nomes/localizações para bases de dados).
Exemplo de provas:
A) Seguem-se exemplos das provas que podem ser fornecidas para cobrir o ponto A).
– Formulário Web:
Fonte: Pedido de Acesso a Requerentes - Police Care UK
- Email endereço/número de telefone:
Origem: Qual? Política de Privacidade - Qual?
- Webchat:
Origem: Fazer um pedido de acesso ao requerente à HMRC - GOV.UK
- Através de uma Autoridade de Supervisão (por exemplo, a ICO):
Origem: Fazer o pedido de acesso do requerente | ICO
B) Foram fornecidos artefactos de provas detalhando fluxos de trabalho ou descrições de processos com detalhes técnicos suficientes, que poderiam ser utilizados plausivelmente para cumprir a SAR.
Controlo N.º 17
Indique o Aviso de Privacidade que deve conter todos os elementos necessários da seguinte forma:
A) A identidade e os detalhes de contacto da organização e do Data Protection Officer (DPO), se aplicável.
B) Os tipos de dados pessoais que a sua organização processa (nome, apelido, número de cliente, endereço de e-mail, número de telefone, etc.). Além disso, as origens de dados pessoais (por exemplo, de onde provêm os dados pessoais), caso a organização não os tenha obtido diretamente a partir dos titulares dos dados.
C) A finalidade(s) do processamento de dados pessoais.
D) A base legal do processamento de dados pessoais (incluindo interesses legítimos, sempre que relevante).
E) As partes com as quais a sua organização partilha dados pessoais.
F) Detalhes de quanto tempo os dados pessoais serão mantidos.
G) Detalhes dos direitos dos titulares dos dados:
Direito de ser informado
Direito de acesso
Direito à retificação
Direito de eliminação
Direito à restrição do processamento
Direito à portabilidade dos dados
Da direita para o objeto
Direitos relacionados com a tomada de decisões automatizada, incluindo a criação de perfis
H) Os detalhes relativos a qualquer transferência de dados pessoais para um país terceiro e as salvaguardas tomadas.
I) O direito de apresentar uma queixa junto de uma autoridade de supervisão, fornecendo detalhes de contacto da autoridade de supervisão (por exemplo, a ICO no Reino Unido).
Intenção:
A intenção é garantir que o Aviso de Privacidade publicado contém detalhes suficientes ao incluir os elementos e princípios acima referidos, nos termos do Capítulo 3 do RGPD.
Diretrizes:
De acordo com o Controlo 10.c, tem de publicar um Aviso de Privacidade que abranja o serviço incluído na Certificação do Microsoft 365. Este Aviso de Privacidade tem de conter os elementos e princípios realçados acima.
Não conforme:
Consulte Controlo 10.c.
Exemplo de provas:
Consulte Controlo 10.c.
HIPAA (Health Insurance Portability and Accountability Act)
O Health Insurance Portability and Accountability Act de 1996 (HIPAA) é uma legislação federal aplicável a cidadãos americanos e organizações de cuidados de saúde. É importante notar que esta legislação abrange também todas as organizações fora dos EUA que processam dados de cuidados de saúde de cidadãos americanos. A introdução da legislação ordenou ao Secretário do Departamento de Saúde e Serviços Humanos dos EUA (HHS) desenvolver regulamentos que protejam a privacidade e a segurança de determinadas informações de saúde. Algumas organizações podem processar dados que são informações de saúde potencialmente protegidas (ePHI), o que significa informações de saúde individualmente identificáveis transmitidas por suportes de dados eletrónicos, mantidas em suportes eletrónicos ou transmitidas ou mantidas de qualquer outra forma ou meio. Quando os dados de saúde de QUALQUER titular de dados são processados, as organizações terão de cumprir a HIPAA.
A HIPAA tem duas leis que têm de ser consideradas: "A Regra de Privacidade", ou Normas de Privacidade das Informações de Saúde Individualmente Identificáveis, que descreve as normas nacionais para a proteção de determinadas informações de saúde, e "As Normas de Segurança" para a Proteção das Informações de Saúde Protegidas Eletrónicas também referidas como "Regra de Segurança". Este último estabelece um conjunto nacional de normas de segurança para proteger determinadas informações de saúde que são mantidas ou transferidas de forma electrónica.
A partir de uma descrição geral de alto nível, "A Regra de Segurança" é uma implementação prática das proteções oferecidas pela "Regra de Privacidade". Descreve as medidas técnicas e não técnicas que as "entidades abrangidas" devem implementar para garantir a segurança das "informações de saúde eletrónicas protegidas" (e-PHI). Apesar de esta secção não abranger todo o regulamento, aborda alguns dos principais elementos da HIPAA para ajudar a obter alguma garantia de que a organização está a cumprir o requisito e que a organização está a salvaguardar as informações de saúde que processa.
Controlo N.º 18
Forneça provas de que:
Existe uma política para o tratamento hipAA e HIPAA na sua organização para funcionários, empreiteiros, etc.
O ISV está a garantir a confidencialidade, integridade e disponibilidade do ePHI que cria, recebe, mantém ou transmite.
Proteja-se contra quaisquer ameaças e perigos razoavelmente previstos para a segurança ou integridade do ePHI.
Intenção:
O objetivo deste subponto é garantir que as organizações estabeleceram protocolos que servem como procedimentos padrão para gerir informações de saúde, lidar com emergências e interrupções de serviço e acesso de pessoal a informações e formação de saúde. Além disso, espera-se que as organizações mantenham e delineiem estas salvaguardas administrativas como parte do programa de segurança HIPAA. Este é um aspecto crucial do cumprimento dos regulamentos da HIPAA.
Diretrizes:
Tal seria evidenciado ao fornecer a documentação estabelecida da organização que descreve a política e o procedimento da HIPAA. Os analistas de certificação irão analisá-lo para garantir que todas as informações fornecidas no controlo são abordadas.
Exemplo de provas:
As capturas de ecrã mostram instantâneos de uma política HIPAA. Nota: a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte real e não apenas forneçam uma captura de ecrã.
Nota: a expetativa é que um ISV partilhe a documentação de política/procedimento de suporte abrangente real e não apenas forneça uma captura de ecrã.
Intenção:
Para compreender a intenção deste subponto e garantir a conformidade com a Regra de Segurança, as "entidades abrangidas" têm primeiro de saber como os termos de confidencialidade, integridade e disponibilidade são definidos em } 164.304:
Confidencialidade: "a propriedade que os dados ou informações não são disponibilizados ou divulgados a pessoas ou processos não autorizados."
Integridade: "a propriedade que os dados ou informações não foram alterados ou destruídos de forma não autorizada."
Disponibilidade: "a propriedade que os dados ou informações são acessíveis e utilizáveis a pedido de uma pessoa autorizada."
A intenção deste requisito é que as organizações implementem medidas/salvaguardas técnicas, tais como controlos de acesso, auditoria, integridade e transmissão na infraestrutura de TI, para garantir a confidencialidade do ePHI, mantendo a sua integridade e disponibilidade para os utilizadores autorizados.
Diretrizes:
As provas podem ser fornecidas através das definições de configuração dos mecanismos de proteção utilizados para garantir que os dados ePHI estão protegidos de acordo com o requisito de controlo. Estes mecanismos podem incluir controlos de acesso, procedimentos de acesso de emergência, RBAC, encriptação, etc.
Exemplo de evidência: controlos de acesso e integridade
A captura de ecrã seguinte mostra que existe uma lista de acesso autorizado de indivíduos que têm permissões para processar localizações de armazenamento ePHI e que é mantida no documento de política HIPAA. Além disso, nas capturas de ecrã que seguem a lista de inventário aprovado, pode observar-se que existe um acesso de escrita limitado no cluster, com apenas o administrador e o analista de manutenção da base de dados a conseguirem ler e escrever no cluster.
A captura de ecrã seguinte tirada de uma das bases de dados de armazenamento ePHI no Atlas Mongo demonstra que apenas os utilizadores autorizados têm o acesso documentado e que todas as contas têm IDs de utilizador exclusivos para garantir a responsabilidade.
A primeira captura de ecrã mostra a main localização de armazenamento/cluster de bases de dados do ePHI.
A segunda captura de ecrã demonstra que os utilizadores aprovados têm apenas as funções e o acesso documentados.
As duas capturas de ecrã seguintes mostram uma vista mais granular de cada uma das funções atribuídas e todas as permissões associadas que estão em conformidade com a aprovação de acesso acima.
Cada função personalizada tem um conjunto de permissões e âmbito de acesso.
Por fim, a captura de ecrã seguinte demonstra, numa perspetiva de rede, que apenas o intervalo de IP autorizado que é a rede empresarial segura tem permissão para aceder ao cluster.
Exemplo de evidência: controlos de auditoria
Estas capturas de ecrã mostram que o registo e os alertas estão implementados para o cluster de bases de dados. A primeira captura de ecrã mostra que os alertas estão ativados. Tenha em atenção que a expectativa é que as provas fornecidas também mostram as regras de alerta que foram definidas com base na necessidade/implementação da organização. A segunda captura de ecrã mostra que a auditoria da base de dados está a ser ativada.
A captura de ecrã seguinte mostra o histórico de acesso ao cluster de bases de dados que está a ser gravado. A expectativa é que os alertas sejam definidos e baseados nos registos de auditoria e que qualquer acesso não autorizado que não cumpra as condições predefinidas acione um alerta.
As duas últimas capturas de ecrã mostram que os registos de auditoria são gerados para o cluster de bases de dados e que os registos podem ser exportados para análise.
Tenha em atenção que a expetativa é que exista um processo em vigor para que os registos de auditoria gerados sejam analisados. Também é necessário fornecer provas do processo de revisão. Se tal for alcançado programaticamente, as capturas de ecrã das definições de configuração da ingestão de registos na plataforma/solução de registo utilizada, bem como capturas de ecrã das regras, têm de ser fornecidas para revisão.
Exemplo de evidência: encriptação e controlos de transmissão
As capturas de ecrã seguintes demonstram que a localização de armazenamento tem dados inativos encriptados por predefinição. Tenha em atenção que, se a encriptação não for efetuada pela plataforma utilizada por predefinição e as suas próprias chaves de encriptação estiverem a ser utilizadas, a expectativa é que essas chaves estejam devidamente protegidas e sejam fornecidas provas para o demonstrar.
As duas capturas de ecrã seguintes demonstram que a localização de armazenamento tem dados em trânsito encriptados por predefinição. A primeira captura de ecrã demonstra que uma API de dados está ativada com permissões de "leitura e escrita".
Uma análise SSL do ponto final demonstra que os dados em trânsito são encriptados através do TLS 1.2.
Exemplo de evidência: controlos de disponibilidade e recuperação
A captura de ecrã seguinte demonstra que o cluster de bases de dados é replicado em três regiões para garantir a disponibilidade. Isto é feito por predefinição pelo Mongo Atlas. Além disso, a cópia de segurança está ativada e está ativa.
A captura de ecrã seguinte mostra o dashboard de cópia de segurança do cluster, que também demonstra que já foi criada uma snapshot.
As duas capturas de ecrã seguintes demonstram que está em vigor uma política de cópia de segurança para executar cópias de segurança agendadas em diferentes pontos no tempo (PIT).
O seguinte indica que existe uma política de retenção para instantâneos e restauro para um ponto anterior no tempo (PIT).
Intenção:
A intenção deste subponto alinha-se com a regra de segurança desenvolvida para garantir flexibilidade e escalabilidade para que uma "entidade abrangida" possa implementar políticas, procedimentos e soluções tecnológicas adequadas para fins para o tamanho da entidade, a sua estrutura organizacional e os seus riscos específicos, bem como o seu apetite pelo risco. De uma perspetiva prática, isto significa que as medidas de segurança adequadas implementadas dependerão da natureza do negócio da "entidade abrangida", bem como do seu tamanho e recursos.
É vital que todas as organizações realizem uma análise de risco abrangente para descobrir potenciais riscos e vulnerabilidades à confidencialidade, integridade e disponibilidade de e-PHI. Através desta análise de risco, as organizações podem implementar controlos de segurança adequados para mitigar estes riscos identificados.
Diretrizes:
As provas podem ser fornecidas através da saída da análise de risco. Quando a análise de risco é efetuada e mantida através de uma plataforma online, devem ser fornecidas capturas de ecrã de toda a saída.
Exemplo de provas:
As capturas de ecrã seguintes mostram instantâneos do processo de avaliação de riscos, seguidos da análise de risco que foi efetuada para determinar até que ponto os controlos são implementados corretamente e funcionam como se destinassem a proteger o ePHI. A segunda captura de ecrã mostra uma análise de risco para os riscos identificados na avaliação de riscos e os controlos de compensação e mitigações implementados para diminuir o nível de risco.
Exemplo 1 – Instantâneo do processo de avaliação de riscos na política HIPAA e análise de risco realizada
Nota: esta captura de ecrã mostra uma snapshot de um documento de análise de riscos, isto é apenas um exemplo e a expetativa é que os ISVs partilhem a documentação real e não forneçam simplesmente uma captura de ecrã.
Exemplo 2 – Capturas de ecrã do processo de avaliação de riscos na política HIPAA e análise de risco realizada (Mantida na Plataforma confluence cloud)
A segunda captura de ecrã mostra uma análise de risco para os riscos identificados na avaliação de riscos e os controlos de compensação e mitigações implementados para diminuir o nível de risco. Podemos ver que isto existe e é mantido na plataforma de cloud Confluence.
Controlo N.º 19
Forneça provas de que o utilizador (ISV):
Protege contra utilizações razoavelmente previstas ou divulgações de tais informações que não são permitidas pela Regra de Privacidade; e
Garanta a conformidade com a Regra de Segurança pela respetiva força de trabalho.
Plano de cópia de segurança de dados e Recuperação após desastre em 164..308 (a)(7)(ii)(A) e 164.308 (a)(7)(ii)(B).
Intent
A Regra de Privacidade define que partes das Informações de Saúde Protegidas (PHI) são abrangidas pela lei e proíbe utilizações impróprias e divulgações de PHI. A intenção deste subponto é que uma organização tem de limitar o acesso e a utilização de e-PHI apenas àqueles que precisam dele para fins autorizados e que têm de cumprir a regra mínima necessária, o que exige que utilizem ou divulguem apenas o montante mínimo de e-PHI necessário para cumprir a finalidade pretendida.
Tem de existir uma combinação de salvaguardas técnicas e administrativas para restringir a utilização da ePHI e para garantir que o risco de divulgação do ePHI seja diminuído.
Diretrizes:
As provas fornecidas têm de mostrar as salvaguardas técnicas em vigor, tais como tecnologias e mecanismos que estão a ser utilizados para proteger o e-PHI e como a organização controla marcar o acesso e a movimentação desses dados.
Exemplo de provas:
As capturas de ecrã seguintes mostram Prevenção Contra Perda de Dados do Microsoft Purview (DLP), que é uma plataforma integrada que permite às organizações gerir as políticas DLP a partir de uma única localização centralizada.
Pode observar abaixo que uma política "Avançada da HIPAA dos E.U.A. está ativada", o que permite impedir que os utilizadores colem dados confidenciais em sites específicos, incluindo e-mail pessoal, pedidos de IA geradoras, sites de redes sociais e muito mais quando acedidos através de um browser suportado.
A captura de ecrã seguinte fornece uma descrição geral mais abrangente da política, incluindo o âmbito ao qual é aplicada. A política está definida para todas as contas em localizações como o SharePoint, Dispositivos, OneDrive, etc.
Ao selecionar a opção para "Editar Política", é apresentada uma vista mais granular nas configurações específicas disponíveis.
As duas capturas de ecrã seguintes mostram a definição de conteúdo e as condições que têm de ser cumpridas para que a política seja aplicada.
A política abrange vários tipos de dados confidenciais, bem como um conjunto de classificadores.
A secção seguinte mostra as ações configuradas para serem executadas quando as condições apresentadas nas capturas de ecrã anteriores forem cumpridas.
A captura de ecrã seguinte mostra que a política DLP está definida para impedir que os seus utilizadores copiem e colem informações confidenciais, como informações pessoais (PII) das bases de dados internas da organização nas suas contas de e-mail pessoais, chatbots e sites de redes sociais em browsers suportados.
Por fim, as notificações do utilizador são configuradas para notificar e fornecer orientações aos utilizadores à medida que estão a processar dados ePHI.
A captura de ecrã seguinte mostra o painel de configuração para gerar alertas quando ocorre um incidente.
Intenção:
A intenção deste subponto é que uma organização tenha de formar o seu pessoal sobre como lidar com o e-PHI de forma segura e adequada e que tem de impor políticas e procedimentos para garantir a conformidade com a Regra de Segurança.
Diretrizes:
As provas fornecidas têm de demonstrar que a preparação hipAA é realizada sobre como lidar com a ePHI e que existem registos de presença e conclusão da formação. Quando aplicável, isto pode ser suportado pela documentação da política e pelos materiais de preparação utilizados.
Exemplo de provas:
Os exemplos seguintes mostram as potenciais provas que podem ser submetidas para demonstrar que a preparação adequada da HIPAA ocorre em conformidade com a política.
A captura de ecrã seguinte mostra uma snapshot da política HIPAA com uma secção específica que descreve o requisito de preparação. Tenha em atenção que este é apenas um exemplo e não um documento/implementação abrangente. A expetativa é que o ISV tenha um processo estabelecido que é aplicável à respetiva organização.
Exemplo 1 – Formação de Utilizadores da HIPAA através do Processo Administrativo
Na captura de ecrã seguinte, o diapositivo de descrição geral do curso mostra um resumo dos objetivos do curso. Se a preparação for construída em casa, os materiais de preparação têm de ser fornecidos para revisão, tenha em atenção que o material completo tem de ser submetido e não apenas uma captura de ecrã do resumo.
A seguinte captura de ecrã mostra o registo de participação dos funcionários que participaram na formação. O registo também mostra a classificação do passe, bem como a data agendada da próxima preparação.
O segundo exemplo demonstra como o Microsoft 365 Defender pode ser utilizado para definir e iniciar campanhas de formação.
Exemplo 2 – formação de utilizadores HIPAA através da Plataforma de Simulação de Ataques do Microsoft 365 Defender (Todos os utilizadores)
A captura de ecrã anterior mostra a campanha de formação de Segurança HIPAA, a duração total em minutos, bem como a conclusão status. A captura de ecrã seguinte fornece uma descrição geral dos utilizadores aos quais a formação foi atribuída e a status de preparação que demonstra a conclusão com êxito.
Exemplo 3 – Formação de Utilizadores HIPAA através da Plataforma de Simulação de Ataques do Microsoft 365 Defender (utilizador individual)
Embora o exemplo anterior se tenha focado em demonstrar que todos os utilizadores concluíram a campanha de formação anual, o exemplo final mostra provas direcionadas que demonstram a conclusão de um funcionário.
Pode observar nas duas capturas de ecrã anteriores que, assim que a campanha de formação foi iniciada, todos os funcionários receberam um e-mail a confirmar a tarefa de formação e a data para conclusão, bem como os módulos atribuídos, a duração, etc.
Com a ligação disponível na notificação por e-mail, a seguinte captura de ecrã mostra a página Tarefas de Formação do utilizador e os dois módulos que foram agora concluídos.
Intenção:
De acordo com a Regra de Segurança hipAA, um plano de cópia de segurança de dados e um plano de recuperação após desastre são obrigatórios para qualquer "entidade abrangida" que processe informações eletrónicas de estado de funcionamento protegido (ePHI). Estes planos fazem parte da estratégia de contingência que visa garantir a disponibilidade e a segurança da ePHI em caso de emergência ou outra ocorrência que prefire os sistemas que contêm ePHI.
O objetivo do plano de cópia de segurança de dados é criar e manter cópias idênticas recuperáveis do ePHI. Isto também deve incluir testes periódicos das cópias de segurança para garantir que a recuperação de dados é possível. O objetivo do plano de recuperação após desastre é restaurar quaisquer potenciais dados perdidos em caso de desastre, o que deve especificar os passos que têm de ser seguidos para restaurar o acesso aos dados, incluindo a forma como os ficheiros devem ser restaurados a partir de cópias de segurança.
Diretrizes:
Indique a versão completa do plano/procedimento de recuperação após desastre que deve abranger o plano de cópia de segurança e o plano de recuperação. Forneça o documento pdf/Word real se estiver numa versão digital, em alternativa, se o processo for mantido através de uma plataforma online fornecer uma exportação de PDF ou se não for possível exportar devido a limitações da plataforma, forneça capturas de ecrã que abranjam toda a política.
Exemplo de provas:
A captura de ecrã seguinte mostra instantâneos da Política de Segurança HIPAA que contêm uma descrição geral do procedimento de cópia de segurança geral e de alto nível e do plano de Recuperação Após Desastre.
Nota: esta captura de ecrã mostra uma snapshot do documento de política/processo, este é apenas um exemplo e a expetativa é que os ISVs partilhem a documentação de política/procedimento de suporte abrangente real e não apenas forneçam uma captura de ecrã.
Manuais
Murdoch D. (2018) Blue Team Handbook: Incident Response Edition: A condensed field guide for the Cyber Security Incident Responding Responder. 2ª Edição, Publicador: CreateSpace Independent Publishing Platform.
Referências
Relatório de Crime Cibernético de Fraude de Ação Disponível em: https://www.actionfraud.police.uk/ (Acedido: 10/12/2023).
A UE. (2021) Lista de Verificação do RGPD para controladores de dados Disponíveis em: https://gdpr.eu/checklist/ (Acedido: 10/12/2023).
Microsoft. (2018) Registo de Eventos (Windows Installer) Disponível em: Registo de Eventos (Acedido: 05/03/2024).
Tecnologias Positivas. (2020) How to approach secure software development Available at: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Accessed:12/10/2023).
Regulamento (UE) 2016/679 do Parlamento Europeu e do Conselho de 27 de abril de 2016 sobre a proteção de pessoas singulares no que diz respeito ao processamento de dados pessoais e à livre circulação desses dados, e revogação da Diretiva 95/46/CE (Regulamento Geral sobre a Proteção de Dados) (Texto com relevância do EEE) (2016) Disponível em: https://www.legislation.gov.uk/eur/2016/679/contents (Acedido: 10/12/2023).
Métricas de Segurança. (2020) Guia de Métricas de Segurança para Conformidade do PCI DSS. Disponível em: https://info.securitymetrics.com/pci-guide-2020(Acedido: 10/12/2023).
Williams J. OWASP Risk Ranking Disponível em: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (Accessed: 10/12/2023).
Qualys. (2014) SSL Labs: New Grades for Trust (T) and Mismatch (M) Issues Available at: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (Accessed: 12/10/2023).
NIST SP800-61r2: Guia de Processamento de Incidentes de Segurança Informática Disponível em: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (Acedido: 10/12/2023).
Criar um pipeline CI/CD com o Azure Pipelines e o Google Kubernetes Engine | .NET
Google Cloud (Acedido: 10/10/2023).
O Plano de Recuperação Após Desastre em: https://www.sans.org/white-papers/1164/ (Acedido: 10/10/2023).
https://github.com/ (Acedido: 10/10/23).
Modelos de Política de Segurança em: https://www.sans.org/information-security-policy/ (Acedido: 10/10/23).
https://www.openedr.com/ (Acedido: 10/02/23).
https://www.atlassian.com/software/confluence (Acedido: 10/10/23).
https://www.atlassian.com/software/jira (Acedido a 28/09/23).
Business Continuity Plan (BCP) Table Top Exercise Template at: https://www.pivotpointsecurity.com/services/business-continuity-management/table-top-exercise-template/ (Accessed: 10/10/23).
Resumo da Regra de Segurança HIPAA | HHS.gov (Acedido: 10/18/2023).
Leis de Privacidade das Informações de Saúde na Era Digital: HIPAA Não Se Aplica - PMC (nih.gov) (Acedido: 10/18/2023).
Qual é o Objetivo da HIPAA? Atualização 2023 (hipaajournal.com) (Acedido: 10/18/2023).
O que é Considerado PHI na HIPAA? Atualização de 2023 (hipaajournal.com) (Acedido: 10/18/2023).
Políticas e Procedimentos HIPAA (hipaajournal.com) (Acedido: 10/18/2023).
Conceber Políticas HIPAA & Políticas Administrativas | Dash Solutions (dashsdk.com) (Acedido: 10/18/2023).
/Instituto de Informação Legal (cornell.edu) (Acedido: 10/18/2023).
O que é a conformidade com a HIPAA? Leis hipaa & regras | Proofpoint UK (Acedido: 10/18/2023).
Regras de Segurança, Regulamentos e Normas da HIPAA (training-hipaa.net) (Acedido: 10/18/2023).
Resumo da Regra de Segurança HIPAA | HHS.gov (Acedido: 10/18/2023).
SP 800-66 Rev. 1, Um Guia de Recursos Introdutórios para Implementar aRegra de Segurança da HipAA (Health Insurance Portability and Accountability Act) | CSRC (nist.gov) (Acedido: 10/18/2023).
A Regra de Segurança | HHS.gov (Acedido: 10/18/2023).
https://www.hipaajournal.com/hipaa-encryption-requirements (Acedido: 10/19/2023).
https://www.hipaajournal.com/hipaa-privacy-rule/ (Acedido: 10/19/2023).
https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (Acedido: 10/19/2023).
https://www.tausight.com/the-ultimate-guide-to-electronic-protected-health-information- ephi/ (Acedido: 10/19/2023).
Configurar Encriptação — Manual do MongoDB (Acedido: 10/19/2023).
https://its.ucsc.edu/policies/docs/hipaa-risk-analysis.doc (Acedido: 10/19/2023).
Microsoft Community Hub (Acedido: 10/24/2023).
| Lei dos E.U.A. | LII/Instituto> de Informação Legal (cornell.edu) (Acedido: 10/24/2023).
Quando devemos fornecer informações de privacidade? | ICO (Acedido: 11/08/2023).
Como devemos redigir as nossas informações de privacidade? | ICO (Acedido: 11/08/2023).
Estrutura de Responsabilidade | ICO (Acedido: 11/08/2023).
ISO 27001 Requirement 5.1 - Leadership & Commitment | ISMS.online (Accessed: 08/11/2023).
Plataforma de Navegação Online (OBP) (iso.org) (Acedido: 11/08/2023).
Cláusula 5.3 Funções Organizacionais, Responsabilidades e Autoridades – Formação ISO (Acedido: 11/08/2023).
5.3 Funções, Responsabilidade e Autoridade (iso9001help.co.uk) (Acedido: 11/08/2023).
Eliminação da identificação e reidentificação do PII em conjuntos de dados em grande escala com a Proteção de Dados Confidenciais| Centro de Arquitetura da Cloud | Google Cloud (Acedido: 11/08/2023).
Desidentificador dados confidenciais | Documentação da Proteção de Dados Confidenciais | Google Cloud (Acedido: 11/08/2023).
Um guia para a segurança de dados | ICO (Acedido: 11/08/2023).
Transferências de dados internacionais | ICO (Acedido: 11/08/2023).
Gestão e segurança de registos | ICO (Acedido: 11/08/2023).
ISO 27701 - Gestão de Informações de Privacidade (Acedido: 11/08/2023).
ISO 27701 Sistema de Gestão de Informações de Privacidade (PIMS) | ISMS.Online (Acedido: 11/08/2023).
Imagens/texto retirados de Documentos da Microsoft
https://www.sans.org/information-security-policy/ (Acedido: 02/18/21).
Obter análise comportamental e deteção de anomalias (Acedido:03/05/24).
O que são alertas do Azure Monitor? (Acedido:03/05/24).
(Acedido:03/05/24).
Gerir e responder a alertas de segurança no Microsoft Defender para a Cloud (Acedido:03/05/24).
Gerir e responder a alertas de segurança no Microsoft Defender para a Cloud (Acedido:03/05/24).
https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (Acedido: 10/09/23).
Encriptação de dados transparente para Banco de Dados SQL, Instância Gerenciada de SQL e Análise de Azure Synapse (Acedido:03/05/24).
Início Rápido: criar uma atribuição de política para identificar recursos não conformes (Acedido:03/05/24).
Configurar o Advanced Threat Protection para a Base de Dados SQL do Azure (Acedido:03/05/24).
Cópia de segurança e restauro no Banco de Dados do Azure para MySQL – Servidor Flexível (Acedido:03/05/24).
Inventário de certificados (Acedido:03/05/24).
Cópia de segurança e restauro no Banco de Dados do Azure para MySQL (Acedido:03/05/24).
https://github.com/microsoft/presidio/blob/main/docs/samples/deployments/data- factory/presidio-data-factory-template-gallery-http.md (Acedido: 11/08/2023).