Domínio de segurança: segurança e privacidade do processamento de dados

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.

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 verificar se 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 a Base de Dados SQL, o SQL Managed Instance e o Azure Synapse Analytics 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 um instantâneo 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, ou seja, bases de dados, partilhas de ficheiros, arquivos, etc.) não excedem a política de retenção de dados definida. Os exemplos podem ser capturas de ecrã de:

• registos de bases de dados com um campo de data, pesquisados por ordem de registo mais antiga e/ou

• localizações de armazenamento de ficheiros que mostram carimbos de data/hora dentro do período de retenção Nota: todos os dados pessoais/confidenciais do cliente devem ser redigidos na captura de ecrã.

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 um instantâneo 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 à Base 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 instantâneos em que a primeira cópia de segurança de instantâneo é agendada imediatamente após a criação de um servidor e são feitas cópias de segurança de instantâneos adicionais uma vez por dia.

A captura de ecrã seguinte mostra um instantâneo da 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 Base de Dados do Azure para MySQL a partir de um instantâneo. 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 o instantâneo a partir do qual a base de dados será restaurada estiverem selecionados, 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 instantâneo de cópia de segurança, como mostra o seguinte.

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:

As cópias de segurança automatizadas da Base de Dados SQL do Azure e do Azure SQL Managed Instances são geridas pelo Azure e a respetiva integridade é da responsabilidade da plataforma do Azure; nenhum utilizador tem acesso aos mesmos e é encriptado inativo 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

A sua organização tem um sistema de Gestão de Informações de Privacidade (PIM) estabelecido, implementado e mantido:

• Mantém o compromisso de liderança através de uma política ou outra forma de documentação/sistema informatizado para a forma como os seus esforços de gestão de informações de privacidade são mantidos para confidencialidade e integridade do sistema.

• Determina funções, responsabilidades e autoridades de cada pessoa que mantém o sistema, incluindo Processadores e Controladores PII.

Intenção:

A intenção deste ponto é garantir que existe uma "cultura de privacidade" e é suportada pela liderança da organização através de um programa de governação de privacidade eficaz. A gestão da organização tem de demonstrar, através da respetiva documentação e processos estabelecidos, que existe um sistema de gestão de privacidade eficaz, disse que os processos estão alinhados com os objetivos estratégicos da organização e são estabelecidos no contexto e nas circunstâncias da organização, bem como garantir que o sistema de gestão de privacidade está incorporado nos processos empresariais.

Diretrizes:

Tal seria evidenciado ao fornecer a documentação estabelecida da organização que descreve a política e o procedimento da Gestão de Informações de Privacidade (PIM). 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ã seguintes mostram instantâneos de uma política PIM.

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ã.

Intent

A responsabilidade é um dos principais princípios da lei de proteção de dados, uma vez que permite que uma organização minimize os riscos associados ao tratamento dos seus dados pessoais ao implementar políticas, procedimentos e processos adequados e eficazes. Estas medidas têm de ser proporcionais aos riscos, que podem variar consoante a quantidade de dados a serem processados ou transferidos, a sua sensibilidade e a tecnologia em utilização. Para tal, cada colaborador tem de saber quem é o responsável pelos vários elementos do sistema de gestão de privacidade para garantir uma implementação bem-sucedida. Ao ter uma documentação estabelecida que descreve as funções, responsabilidades e autoridades de uma forma claramente definida e ter essas funções atribuídas adequadamente, uma organização pode garantir que o respetivo sistema de gestão de privacidade é eficaz.

Diretrizes:

Tal seria evidenciado ao fornecer a documentação estabelecida da organização que descreve as funções, responsabilidades e autoridades de cada pessoa relevante. 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ã seguintes mostram instantâneos de uma política PIM que mostra uma secção da política que contém a lista de funcionários aprovados.

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ã.

Controlo N.º 11

Forneça provas dos processos para mostrar que:

• A minimização do PII está a ocorrer.

• A eliminação e eliminação do PII está a ser feita no final do período de processamento.

• Estão em vigor controlos para a transmissão pii, incluindo qualquer confidencialidade.

• O registo de transferência do PII de um país/região para outro existe com o consentimento expresso para o fazer.

Intenção: PII

O objetivo da minimização do PII (Informações Pessoais) é garantir que uma organização recolhe, utiliza e retém apenas a quantidade mínima de dados pessoais necessários para alcançar um objetivo específico no contexto da organização e na justificação comercial. Ao processar dados pessoais, uma organização tem de identificar qual é a menor quantidade de dados necessária para atingir esse objetivo/tarefa e garantir que não estão a ser armazenados mais do que os dados mínimos necessários. Ao minimizar o processamento e o armazenamento de dados pessoais desnecessários, uma organização garante que o nível de risco associado à utilização indevida de dados, acesso não autorizado e violações de dados é reduzido.

Diretrizes: PII

As provas podem ser fornecidas através das definições de configuração da solução utilizada para minimizar a utilização de informações pessoais se tal for feito através de uma plataforma automatizada ou, se for um processo administrativo manual, a prova do processo de minimização e a evidência dos registos do processo que está a ocorrer devem ser fornecidas ao analista para revisão.

Exemplo de evidência: PII

A seguinte captura de ecrã mostra que está agendada uma reunião mensal recorrente onde todos os novos dados recebidos na organização dentro desse período são revistos e, quando aplicável, todas as informações pessoais consideradas desnecessárias são removidas.

Na captura de ecrã seguinte encontra-se um exemplo de um formulário de registo de utilizador preenchido utilizado para integrar novos clientes na plataforma.

A captura de ecrã subsequente demonstra que, com base na reunião e revisão da minimização do PII, foi considerado que algumas das informações confidenciais recolhidas no formulário já não são necessárias para fornecer o serviço de volta ao utilizador. Na imagem seguinte, o PII dos árbitros foi removido, bem como o endereço de e-mail (a expectativa é que cada organização tenha uma justificação comercial para manter ou remover essas informações).

Nota: o anterior é um exemplo de um cenário potencial. Não é de forma alguma abrangente e, ao fornecer provas, o processo de minimização do PII deve ser claramente demonstrado e deve aplicar-se ao contexto específico da organização.

Intenção: privacidade dos dados

A intenção deste subponto é multifacetada e abrange várias técnicas e conceitos diferentes, mas o objetivo geral é que uma organização esteja em conformidade com os regulamentos de proteção de dados ao garantir que a privacidade dos dados em toda a organização é melhorada.

A partir da eliminação da identificação, que é o processo de remoção de informações específicas que podem ser utilizadas para identificar um indivíduo a partir de dados, a intenção é garantir que todas as informações consideradas confidenciais, como o endereço de e-mail, a data de nascimento, etc., são alteradas/convertidas (através de várias técnicas, como pseudonimização ou máscara) num formato que a torna inutilizável para ligá-la diretamente a um indivíduo. O objetivo deste processo não é apenas preservar a utilidade dos dados, mas também garantir que o nível de risco associado a utilização indevida de dados, acesso não autorizado e violações de dados é reduzido.

As organizações devem definir a retenção de dados e eliminar dados desnecessários no final do período de processamento. Depois de os dados excederem o período de retenção de dados definidos, têm de ser eliminados de forma segura para garantir que não podem ser reconstruídos ou recuperados. Manter os dados necessários e durante o tempo necessário ajuda 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— legais, operacionais ou relacionados com segurança.

Diretrizes: privacidade dos dados

As provas podem ser fornecidas através das definições de configuração do mecanismo e/ou técnica utilizadas para garantir que os dados PII são anonimizados e eliminados de acordo com o requisito de controlo.

Exemplo de evidência: privacidade dos dados

O exemplo apresentado nas capturas de ecrã seguintes utiliza o modelo incorporado de anonimização de dados do Azure Data Factory, que faz parte da Galeria de Modelos e permite-nos mover um conjunto de ficheiros de texto de uma localização para outra enquanto anonimizamos os respetivos conteúdos. Mostra que existe uma fábrica de dados no Azure para anonimização do PII.

A captura de ecrã seguinte mostra a configuração do pipeline de anonimização do PII. Tira partido do código para utilizar o Presidio no Serviço de Aplicações do Azure para chamar o Presidio como um ponto final REST HTTP no pipeline do Azure Data Factory enquanto analisa e armazena cada ficheiro como um Armazenamento de Blobs do Azure.

A seguinte captura de ecrã mostra os passos e a lógica do pipeline.

A captura de ecrã final demonstra uma execução bem-sucedida do pipeline para anonimizar o PII.

Nota: o anterior é um exemplo de um cenário potencial. Não é de forma alguma abrangente e, ao fornecer provas, o processo de anonimização do PII deve ser claramente demonstrado e deve aplicar-se ao contexto específico da organização.

Exemplo de evidência: privacidade dos dados

A captura de ecrã seguinte demonstrou um exemplo de como abordar a eliminação de PII no final do período de processamento ao ativar uma política de gestão do Ciclo de Vida para a conta de armazenamento no Azure onde o PII é mantido.

A captura de ecrã seguinte demonstra que a retenção está definida para um período predefinido após o qual os dados são eliminados automaticamente.

Nota: o anterior é um exemplo de um cenário potencial. Não é de forma alguma abrangente e, ao fornecer provas, o processo de eliminação de dados PII e o período de retenção específico aplicável devem ser claramente demonstrados e devem aplicar-se ao contexto específico da organização.

Exemplo de evidência: privacidade dos dados

A captura de ecrã final demonstra que está implementada uma política de retenção de gestão do ciclo de vida de dados para transferência e armazenamento de dados PII em várias localizações na organização, como o SharePoint, OneDrive, dispositivos, caixa de correio, etc. Esta política está ativada com o Microsoft Purview. A política de retenção é configurada para eliminar automaticamente qualquer PII assim que o período de retenção predefinido tiver decorrido.

Nota: o anterior é um exemplo de um cenário potencial. Não é de forma alguma abrangente e, ao fornecer provas, o processo de eliminação de dados PII e o período de retenção específico aplicável devem ser claramente demonstrados e devem aplicar-se ao contexto específico da organização.

Intenção: controlos

O objetivo deste subponto é garantir que as organizações têm salvaguardas técnicas e administrativas/operacionais adequadas para proteger o PII durante o processamento e a transmissão. A ênfase na confidencialidade refere-se à proteção de dados de acesso não autorizado e divulgações através de controlos técnicos e administrativos, tais como a encriptação dos dados inativos e em trânsito, listas documentadas de controlo de acesso e auditoria regular.

Diretrizes: controlos

As provas podem ser fornecidas através das definições de configuração dos mecanismos de proteção utilizados para garantir que os dados PII estão protegidos de acordo com o requisito de controlo. Estes mecanismos podem incluir controlos de acesso, RBAC, encriptação, prevenção de perda de dados, etc.

Exclusão de responsabilidade: os exemplos apresentados mostram alguns cenários potenciais em que os controlos são aplicados para garantir que o PII está protegido. Tenha em atenção que o tipo de mecanismos de proteção implementados depende do contexto da sua organização e da forma como o PII é utilizado, armazenado, etc.

Exemplo de evidência: Encriptação

Os exemplos seguintes mostram a encriptação do PII na localização de armazenamento onde o PII está a ser mantido e a encriptação durante o trânsito através da aplicação/plataforma Web onde os utilizadores introduzem informações pessoais armazenadas no back-end da aplicação.

As capturas de ecrã 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 pela sua própria encriptação

as chaves estão em utilização e, em seguida, a expectativa é que essas chaves estejam adequadamente protegidas, e são fornecidas provas para demonstrar isso.

A segunda captura de ecrã mostra que o TLS1.2 é imposto em trânsito para a aplicação onde o PII é recolhido.

Exemplo de evidência: controlos de acesso

A captura de ecrã seguinte demonstra, do ponto de vista da rede, que apenas o intervalo de IP autorizado/aprovado, que é a rede empresarial segura, tem permissão para aceder à localização de armazenamento PII.

A captura de ecrã seguinte mostra um exemplo do PIM do Azure e a lista de utilizadores com as atribuições elegíveis. Ao utilizar o acesso just-in-time (JIT), permite que os utilizadores obtenham acesso temporário a uma função ou recurso com privilégios durante um período limitado de tempo, o que diminui o risco de um utilizador com privilégios ser comprometido ou introduzir alterações no ambiente, localizações de dados, etc.

Exemplo de evidência: prevenção de transmissão e divulgação do PII

Estas capturas de ecrã mostram a Prevenção de Perda de Dados (DLP) do Microsoft Purview, 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 de "Dados PII do Reino Unido" está ativada. Isto permite impedir que os utilizadores forneçam dados confidenciais a 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. Isto garante que o risco de potenciais violações de confidencialidade ou divulgações não autorizadas do PII por funcionário é diminuído, uma vez que todos os dispositivos/utilizadores do local de trabalho têm a política organizacional aplicada.

As capturas de ecrã seguintes fornecem uma descrição geral 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.

A captura de ecrã anterior e seguinte mostra que a política DLP está definida para impedir que os utilizadores copiem e colem informações confidenciais, como informações pessoais (PII)

das bases de dados internas da organização às respetivas contas de e-mail pessoais, chatbots e sites de redes sociais em browsers suportados.

Intenção: registos

A intenção deste subponto é dupla; garante que existe uma gestão eficaz dos registos para facilitar a governação de dados e a proteção de dados, ao mesmo tempo que garante a conformidade legal e a responsabilidade, uma vez que a transferência de informações pessoais identificáveis em diferentes países envolve a navegação em diferentes requisitos legais. Antes de iniciar uma transferência PII, uma organização tem de garantir que tem o consentimento explícito do(s) titular(s) dos dados a quem pertence, os referidos indivíduos devem ser informados sobre a transferência, o objetivo da transferência e o risco associado. O registo do consentimento que está a ser obtido validará a autorização da transferência. O registo das transferências também deve conter detalhes adicionais sobre a transferência, a avaliação de riscos, o impacto da proteção de dados e o período de retenção.

Diretrizes: registos

As provas que podem ser fornecidas para registos de transferências PII e registos de consentimento expresso dependerão da forma como o processo de transferência e a gestão de registos são implementados ao nível da organização. Isto pode incluir se o consentimento é obtido através de uma plataforma, termos e condições do serviço ou através de formulários de consentimento preenchidos por cada utilizador. As provas fornecidas têm de mostrar que existem registos históricos das transferências concluídas ao longo de um período e como tal é controlado, bem como registos de consentimento explícito obtidos.

Exemplo de evidência: registos

A captura de ecrã seguinte mostra um exemplo de um formulário de consentimento preenchido por um dos utilizadores dos serviços da organização. Podemos ver que o consentimento explícito, a confirmação e a compreensão das condições foram fornecidos pelo utilizador.

A captura de ecrã seguinte mostra que existe um registo histórico de transferências PII e inclui detalhes dos dados pii específicos que estão a ser trocados, o objetivo da transferência, o país de origem, o país de destino, a proteção dos dados em trânsito, aprovação, etc.

Nota: o anterior é um exemplo de um cenário potencial, não é de forma alguma abrangente e, ao fornecer provas, o processo de transferência de dados PII, gestão de registos, etc. deve ser claramente demonstrado e deve aplicar-se ao contexto específico da organização.

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.º 12

Forneça provas que demonstrem que:

• Os titulares dos dados podem criar SARs.

• Confirme que o utilizador (o ISV) consegue identificar todas as localizações dos dados dos titulares dos dados ao responder a um pedido de SARs.

• Existe um período de retenção para as cópias de segurança que permite que os clientes que pedem a remoção de dados através de SARs sejam removidos, uma vez que as cópias de segurança sem interrupção durante um período são removidas (ciclo de vida das eliminações/reescritas de cópias de segurança mais antigas).

Intenção:

O RGPD inclui obrigações específicas que têm de ser cumpridas pelas organizações que processam os dados dos titulares dos dados. A obrigação de as organizações gerirem pedidos de acesso a requerentes (SARs) está incluída no artigo 12.º que, nos termos do artigo 12.3.º, concede um mês a um responsável pelo tratamento de dados da receção da SAR para responder ao pedido. Uma extensão é permitida por mais dois meses, se necessário e apenas se houver justificação para o fazer. Mesmo que a sua organização esteja a agir como Um Processador de Dados, isto continuará a ser necessário para ajudar os seus clientes (o Controlador de Dados) a cumprirem as suas obrigações de SARs.

Diretrizes:

Forneça o processo documentado para processar SARs. Exemplo de provas:

O exemplo seguinte mostra um processo documentado para o processamento de SARs.

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 objetivo deste controlo é garantir que a organização tem um mecanismo robusto para identificar todos os dados dos titulares dos dados. Este pode ser um processo manual porque todo o armazenamento de dados está bem documentado ou outras ferramentas podem ser utilizadas para garantir que todos os dados estão localizados como parte do processo de SARs.

Diretrizes:

As provas podem ser fornecidas através de uma lista de todas as localizações de dados e de um processo documentado para procurar dados em todas as localizações de dados. Isto incluiria quaisquer comandos necessários para procurar dados, ou seja, se as localizações SQL estiverem incluídas, as instruções SQL específicas seriam detalhadas para garantir que os dados são encontrados corretamente.

Exemplo de provas:

A captura de ecrã seguinte é um fragmento do procedimento da SAR anterior que mostra como os dados serão encontrados.

As quatro imagens seguintes mostram como as localizações de dados ISV foram consultadas e o Explorador de Armazenamento foi utilizado para desagregar os ficheiros ou blobs que precisavam de ser removidos do armazenamento para cumprir o pedido de SARs.

Nota: se estes exemplos não forem 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.

Esta consulta confirma as contas de armazenamento em utilização. Pode consultar e remover armazenamento, blobs e/ou ficheiros com o Explorador do Resource Graph (Kusto) ou o PowerShell (ver seguinte).

Nota: - Para os exemplos nesta secção, as capturas de ecrã completas não foram utilizadas, no entanto, todas as capturas de ecrã de provas submetidas pelo ISV têm de ser capturas de ecrã inteiro a mostrar o URL, qualquer data e hora do sistema e utilizador com sessão iniciada.

A imagem seguinte mostra os dados que foram encontrados no contentor de blobs para o cliente que precisa de ser removido e o seguinte mostra a ação para eliminar ou eliminar de forma recuperável as informações no blob.

Tenha em atenção que os 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.

Intenção:

O objetivo deste controlo é demonstrar que existe um período de retenção formal para cópias de segurança, concebido de forma a acomodar a remoção de dados nos termos das SARs. A arquitetura de retenção deve permitir a eliminação progressiva de cópias de segurança mais antigas durante um período definido, garantindo que todos os dados removidos devido a uma SAR são, em última análise, apagados de todas as cópias de segurança. Isto é fundamental para alinhar as práticas de cópia de segurança e retenção de dados da organização com obrigações decorrentes de SARs, cumprindo assim os requisitos regulamentares relativos ao direito de eliminação.

Diretrizes:

As provas podem ser fornecidas através de uma captura de ecrã que mostra as definições de configuração da cópia de segurança que demonstram o período e a metodologia com que as cópias de segurança são efetuadas. A ênfase deve estar no período de frequência da cópia de segurança.

Exemplo de provas:

A captura de ecrã seguinte é um fragmento das definições de configuração da base de dados do Azure para MySQL, que é uma instância gerida.

Podemos ver na captura de ecrã que o período de retenção da cópia de segurança está definido para 28 dias.

Com base na secção de cópia de segurança, sabemos que as cópias de segurança em servidores flexíveis são baseadas em instantâneos com a primeira cópia de segurança de instantâneos agendada imediatamente após a criação de um servidor e que são criadas cópias de segurança de instantâneos adicionais diariamente uma vez.

A retenção da cópia de segurança de 28 dias combinada com a frequência da cópia de segurança significa que, quando uma SAR é cumprida, a cópia de segurança sem interrupção continuará durante um máximo de 27 dias sem interrupções e diminuindo conforme imposto pelo período de retenção até que todos os dados desse utilizador sejam removidos.

Controlo N.º 13

Indique o aviso de privacidade que deve conter todos os elementos necessários da seguinte forma:

• Detalhes das entidades (Nome, Endereço, etc.)

• Detalhes do tipo de dados pessoais que estão a ser processados.

• Detalhes durante quanto tempo os dados pessoais serão mantidos.

• Detalhes da legalidade do processamento de dados pessoais.

• Detalhes dos direitos do titular dos dados:

  • Direito de ser informado

  • Direito de acesso pelo titular dos dados

  • 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

Intenção:

O artigo 13.º do RGPD inclui informações específicas que têm de ser fornecidas aos titulares dos dados no momento em que os dados pessoais são obtidos. O objetivo deste controlo é garantir que o aviso de privacidade dos dados da organização fornece aos titulares dos dados algumas das informações principais incluídas no artigo 13.º.

Diretrizes:

Normalmente, tal seria fornecido ao fornecer o aviso de privacidade dos dados. Os analistas de certificação irão analisá-lo para garantir que todas as informações fornecidas no controlo estão incluídas no aviso de privacidade dos dados.

Exemplo de provas:

As capturas de ecrã seguintes mostram instantâneos de uma política de privacidade.

Tenha em atenção que 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.

As imagens de um Aviso de Privacidade mostram um exemplo de uma política de privacidade online com o artigo 13.º do RGPD incluído.

Segue-se uma Política de Proteção de Dados que pode ser utilizada em conjunto com o aviso de privacidade apresentado anteriormente.

A imagem anterior do Azure mostra como o Azure foi configurado para cumprir os requisitos de conformidade do RGPD para dados armazenados num ambiente de back-end. A política (que pode ser personalizada ou criada a partir do Azure Blueprints) permite ao ISV garantir que os dados do cliente são armazenados corretamente e que só são acessíveis pelas métricas especificadas. Além disso, os alertas são definidos para garantir a conformidade e mostrarão dados não conformes ou acesso de utilizador no dashboard do gestor de conformidade.

Tenha em atenção que os exemplos anteriores 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.

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 protegidas eletrónicas" (e-PHI) das pessoas. 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.º 14

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 localização de armazenamento principal/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 criado um instantâneo.

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 da 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 um instantâneo de um documento de análise de risco, isto é apenas um exemplo e a expetativa é que os ISVs partilhem a documentação real e não apenas forneçam 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.º 15

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 da Informação de Saúde Protegida (PHI) são abrangidas pela lei e proíbe utilizações impróprias e divulgações da PHI. A intenção deste subponto é que uma organização tenha de limitar o acesso e a utilização da 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 a quantidade mínima de e-PHI necessária 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 a forma como a organização controla o acesso e a movimentação desses dados.

Exemplo de provas:

As capturas de ecrã seguintes mostram a Prevenção de Perda de Dados (DLP) do Microsoft Purview, 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 a 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 um instantâneo 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 incorporada, 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 o estado de conclusão. A captura de ecrã seguinte fornece uma descrição geral dos utilizadores aos quais a preparação foi atribuída e o estado 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 um instantâneo 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 em 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).

• 45 CFR - 164.304 - Definições. | Código Eletrónico de Regulamentos Federais (e-CFR) | Lei dos E.U.A. | LII

• /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.restore.co.uk/Records/Services/Magnetic-Tape-Storage (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).

• Prevenção de Perda de Dados do Microsoft Purview: Anúncio de disponibilidade geral de várias capacidades

• Microsoft Community Hub (Acedido: 10/24/2023).

• 45 CFR - 164.308 - Salvaguardas administrativas. | Código Eletrónico de Regulamentos Federais (e-CFR)

• | Lei dos E.U.A. | LII/Instituto> de Informação Legal (cornell.edu) (Acedido: 10/24/2023).

• https://www.iow.nhs.uk/Downloads/Policies/Business%20Continuity%20Policy.pdf (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).

• Princípio (c): Minimização de dados | ICO (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).

• Obter análise comportamental e deteção de anomalias

• (Acedido:03/05/24).

• Gerir e responder a alertas de segurança no Microsoft Defender para Cloud (Acedido:03/05/24).

• Gerir e responder a alertas de segurança no Microsoft Defender para Cloud (Acedido:03/05/24).

• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (Acedido: 10/09/23).

• O que é a Proteção de Informações do Azure?

• Encriptação de dados transparente para a Base de Dados SQL, o SQL Managed Instance e o Azure Synapse Analytics (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 na Base 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 na Base 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).

Saiba mais

• Guia de provas de exemplo - Descrição geral
• Guia de provas de exemplo - Operações