Domínio de segurança: tratamento de dados, segurança e privacidade

Esse domínio de segurança foi projetado para garantir que todos os dados consumidos do Microsoft 365 estejam adequadamente protegidos em trânsito e em repouso. Esse domínio também garante que as preocupações com a privacidade dos consumidores (titulares dos dados) sejam atendidas pelo ISV, de acordo com o GDPR (Regulamento Geral sobre a Proteção de Dados) e a HIPAA (Lei de Portabilidade e Responsabilidade de Seguros de Saúde de 1996).

Dados em trânsito

Os requisitos de conectividade dos aplicativos/suplementos desenvolvidos pelo Microsoft 365 exigem a comunicação por redes públicas, especificamente a Internet. Portanto, os dados em trânsito devem ser adequadamente protegidos. Esta seção aborda a proteção das comunicações de dados pela Internet. 

Controle nº 1

FALHA DIFÍCIL

Fornecer evidências de que:

• Todas as configurações de TLS são TLS1.2 ou superior, conforme destacado nos requisitos de configuração de perfil TLS. 

• Um inventário de chaves confiáveis e certificados é mantido e mantido.

Requisitos de configuração de perfil

Intenção: TLS

A intenção deste subponto é garantir que os dados do Microsoft 365 que estão sendo consumidos pela sua organização sejam transmitidos com segurança. A Configuração de Perfil TLS é usada para definir os requisitos específicos do TLS que ajudam a garantir que o tráfego seja seguro contra ataques man-in-the-middle. 

Diretrizes: TLS

A maneira mais fácil de evidenciar isso é executar a ferramenta de Teste do Servidor SSL Qualys em TODOS os ouvintes da Web, incluindo qualquer um que seja executado em portas não padrão. 

Lembre-se de marcar a opção "Não mostrar os resultados nos quadros", que impede que o URL seja adicionado ao site. 

Os requisitos de configuração de perfil TLS podem ser demonstrados fornecendo evidências de verificações individuais. Para fornecer evidências de configurações específicas, como desabilitar a compactação TLS, podem ser utilizadas definições de configuração, scripts e ferramentas de software. 

Exemplo de evidência: TLS

A captura de tela a seguir mostra os resultados da verificação SSL pela Qualys para o webappfrontdoor- byendbagh6a0fcav.z01.azurefd.net. 

A seção Protocolos mostra que o TLS1.2 é o único protocolo compatível/habilitado.

Observação: os analistas de certificação revisarão a saída completa da verificação para confirmar se todos os requisitos dos requisitos de configuração do perfil TLS foram atendidos. A expectativa é que as verificações sejam fornecidas para todos os pontos de extremidade expostos publicamente (endereços IP e URLs) para o ambiente de back-end que está no escopo. Dependendo das evidências fornecidas, os analistas podem executar sua própria varredura Qualys. 

Exemplo de evidência: TLS

A captura de tela a seguir mostra as definições de configuração para TLS no serviço de aplicativo do Azure seguido pela enumeração TLS via PowerShell. 

Intenção: chaves e certificados

A intenção deste subponto é garantir que um inventário abrangente de chaves e certificados confiáveis seja mantido, o que envolve a identificação de vários sistemas, serviços e aplicativos que dependem desses elementos criptográficos. 

Diretrizes: chaves e certificados

A evidência deve demonstrar que existe e é mantido um inventário de chaves e certificados confiáveis. Além disso, podem ser fornecidas evidências aplicáveis das ferramentas usadas para armazenar as chaves e certificados reais, como o cofre de chaves do Azure, os segredos do cofre da HashiCorp, o Confluence Cloud etc. 

Exemplo de evidência: chaves e certificados

A captura de tela a seguir mostra que uma chave e um inventário de certificados são mantidos no Confluence Cloud. 

A captura de tela a seguir mostra a lista aprovada de chaves e certificados confiáveis. Inclui detalhes como o certificado, chaves, cifras e os sistemas nos quais estão instalados. 

A captura de tela a seguir é do HashiCorp Vault. Os certificados descritos e registrados na lista de inventário estão sendo armazenados neste cofre online. O HashiCorp Vault é uma ferramenta de código aberto para gerenciamento de segredos, criptografia como serviço e gerenciamento de acesso privilegiado.

A captura de tela a seguir é um extrato do certificado real e das chaves armazenadas no cofre online.

Observação: a expectativa é que o local de armazenamento das chaves tenha controles de acesso apropriados. Se a chave privada estiver comprometida, alguém poderá falsificar o servidor com um certificado legítimo. 

Exemplo de evidência: chaves e certificados

A próxima captura de tela demonstra exemplos de evidências de certificados armazenados no Azure KeyVault.  

Exemplo de evidência: chaves e certificados

Um inventário de chaves e certificados confiáveis também pode ser mantido com o Microsoft 365 Defender, que fornece um recurso de inventário, conforme mostrado na próxima captura de tela.

A próxima captura de tela mostra os detalhes do certificado.

Observação: esses exemplos não são capturas de tela em tela cheia, você deverá enviar capturas de tela em tela cheia com qualquer URL, usuário conectado e carimbo de data e hora para revisão de evidências. Se você for um usuário do Linux, isso poderá ser feito por meio do prompt de comando. 

Controle nº 2

Fornecer evidências de que:

A compactação TLS está desabilitada para todos os serviços voltados para o público que lidam com solicitações da Web para evitar o vazamento de informações da taxa de compactação facilitado (CRIME). 

O TLS HTTP Strict Transport Security (HSTS) está habilitado e configurado para uma idade mínima de 180 dias em todos os sites. 

Intenção: TLS

O ataque CRIME (Compression Ratio Info-leak Made Easy (CVE-2012-4929)) é uma vulnerabilidade na compactação dos protocolos SSL (Secure Sockets Layer)/TLS (Transport Layer Security). Por esse motivo, as recomendações do setor são desabilitar a compactação SSL. 

O HTTP Strict Transport Security (HSTS) é um mecanismo de segurança projetado para proteger sites contra ataques man-in-the-middle, forçando conexões TLS por meio de um campo de cabeçalho de resposta HTTPS chamado "Strict-Transport-Security". 

Diretrizes: TLS

Isso pode ser evidenciado por meio da ferramenta Qualys SSL Labs. Exemplo de evidência: TLS

A captura de tela a seguir mostra que a compactação SSL/TLS está desabilitada. 

A próxima captura de tela mostra que o HSTS está habilitado.

Observação: o analista de certificação examinará a saída completa para confirmar se todos os requisitos dos requisitos de configuração de perfil TLS foram atendidos (forneça capturas de tela da saída de verificação completa). Dependendo das evidências fornecidas, os analistas podem executar sua própria varredura Qualys. 

Outras ferramentas que podem ser usadas para marcar se o HSTS está habilitado são 'HTTP Header Spy' e

securityheaders.com conforme mostrado nos exemplos a seguir. Evidência Adicional

Capturas de tela, como definições de configuração dos cabeçalhos de segurança, especificamente HSTS, podem ser fornecidas para demonstrar ainda mais a postura de segurança da pegada pública. 

As próximas capturas de tela mostram a configuração do Azure Front Door e o conjunto de regras implementado para reescrever os cabeçalhos. 

A próxima captura de tela mostra a verificação dos cabeçalhos de segurança realizada e que todos os cabeçalhos de segurança estão implementados, não apenas o HSTS.

Observação: se o Qualys SSL Scanner ou os cabeçalhos de segurança forem usados, a expectativa será que o relatório completo seja fornecido para revisão. 

Dados em repouso

Quando os dados consumidos da plataforma Microsoft 365 são armazenados por ISVs, os dados precisam ser protegidos adequadamente. Esta seção aborda os requisitos de proteção de dados armazenados em bancos de dados e armazenamentos de arquivos. 

Controle nº 3

FALHA DIFÍCIL

Fornecer evidências de que:

Os dados inativos são criptografados de acordo com os requisitos do perfil de criptografia, usando algoritmos de criptografia como; Advanced Encryption Standard (AES), Blowfish e XChaCha20. 

Tamanhos de chave de criptografia de no mínimo 128 bits. 

Requisitos de perfil de criptografia 

Intenção: alguns algoritmos de criptografia mais antigos são conhecidos por conter alguns pontos fracos criptográficos, o que aumenta as chances de um agente de ameaça conseguir descriptografar os dados sem o conhecimento da chave. Por esse motivo, a intenção desse controle é garantir que apenas algoritmos de criptografia aceitos pelo setor sejam usados para proteger os dados armazenados do M365. 

Diretrizes: as evidências podem ser fornecidas por meio de capturas de tela, mostrando a criptografia sendo empregada para proteger os dados do M365 em bancos de dados e outros locais de armazenamento. A evidência deve demonstrar que a configuração de criptografia está alinhada com os Requisitos de Configuração de Perfil de Criptografia da Certificação Microsoft 365. 

Exemplo de evidência: a próxima captura de tela mostra que a TDE (Transparent Data Encryption) está habilitada no banco de dados da Contoso. A segunda captura de tela mostra a página de documentação da Microsoft Transparent Data Encryption for Banco de Dados SQL, Instância Gerenciada de SQL e Análise do Azure Synapse, mostrando que a criptografia AES 256 é usada para o TDE do Azure. 

Observação: nos exemplos anteriores, capturas de tela completas não foram usadas, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema. 

Exemplo de evidência: a captura de tela a seguir mostra o Armazenamento do Azure configurado com criptografia para blobs e arquivos. A próxima captura de tela mostra a página de Documentação da Microsoft Criptografia do Armazenamento do Azure para dados em repouso, mostrando que o Armazenamento do Azure usa AES-256 para criptografia. 

Retenção, backup e descarte de dados

Onde os ISVs consomem e armazenam dados do Microsoft 365, há o risco de um comprometimento de dados caso um agente de ameaça comprometa o ambiente do ISV. Para minimizar esse risco, as organizações devem manter apenas os dados de que precisam para fornecer serviços e não os dados que "podem" ser úteis no futuro. Além disso, os dados só devem ser mantidos pelo tempo necessário para fornecer os serviços para os quais os dados foram capturados. A retenção de dados deve ser definida e comunicada aos usuários. Quando os dados excederem o período de retenção definido, eles deverão ser excluídos com segurança para que não possam ser reconstruídos ou recuperados. 

Controle nº 4

Fornecer evidências 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 apenas para atender a algumas obrigações legais, por exemplo, legislação de privacidade de dados, como, mas não se limitando a, o Regulamento Geral sobre a Proteção de Dados (GDPR da UE) e a Lei de Proteção de Dados (DPA 2018 do Reino Unido), mas também para limitar o risco de uma organização. Ao entender os requisitos de dados das organizações e por quanto tempo os dados são necessários para que a empresa desempenhe suas funções, as organizações podem garantir que os dados sejam descartados adequadamente quando sua utilidade expirar. Ao reduzir os volumes de dados armazenados, as organizações estão reduzindo a quantidade de dados que seriam expostos caso ocorresse um comprometimento de dados. Isso limitará o impacto geral. 

Muitas vezes, as organizações armazenam dados porque é bom tê-los apenas no caso. No entanto, se a organização não precisar dos dados para executar seu serviço ou função comercial, os dados não deverão ser armazenados, pois isso está aumentando o risco da organização desnecessariamente. 

O objetivo desse controle é confirmar se a organização estabeleceu e documentou formalmente um período de retenção de dados aprovado para todos os tipos de dados relevantes. Isso envolve não apenas especificar a duração pela qual os diferentes tipos de dados serão armazenados, mas também delinear os procedimentos para exclusão de dados ou arquivamento pós-expiração.  

Diretrizes: Forneça a política completa de retenção de dados que detalha claramente quanto tempo os dados (devem cobrir todos os tipos de dados) devem ser mantidos para que a empresa possa desempenhar suas funções de negócios. A política de retenção deve abranger claramente todos os dados do cliente armazenados no ambiente de back-end do aplicativo que está sendo certificado. 

Exemplo de evidência: a próxima captura de tela mostra a política de retenção de dados da Contoso. 

Observação: essas capturas de tela mostram um snapshot de um documento de política/processo. A expectativa é que os ISVs compartilhem a documentação real da política/procedimento de suporte e não simplesmente forneçam uma captura de tela. 

Controle nº 5

Fornecer evidências de que:

Os dados são retidos apenas pelo período de retenção definido, conforme discutido no controle 4. 

Intenção: a intenção desse controle é simplesmente validar se os períodos de retenção de dados definidos estão sendo atendidos. Como já discutido, as organizações podem ter a obrigação legal de cumprir isso, mas também manter os dados necessários e pelo tempo necessário ajuda a reduzir o risco para a organização caso ocorra uma violação de dados. Isso garante que os dados não sejam retidos por uma duração excessivamente longa nem excluídos prematuramente, o que pode representar riscos de natureza variada — legais, operacionais ou relacionados à segurança. 

Diretrizes: forneça evidências de captura de tela (ou por meio de compartilhamento de tela) mostrando que os dados armazenados (em todos os vários locais de dados, incluindo bancos de dados, compartilhamentos de arquivos, arquivos e backups) não excedem a política de retenção de dados definida. Exemplos de capturas de tela aceitáveis incluem:

Registros de Banco de Dados com um campo de data, pesquisados na ordem do registro mais antigo e/ou

Locais de armazenamento de arquivos mostrando carimbos de data/hora que estão dentro do período de retenção. Observação: todos os dados pessoais ou confidenciais do cliente devem ser redigidos na captura de tela. 

Registros de backup mostrando que os dados de backup são retidos dentro do período de retenção definido e excluídos corretamente após esse período. 

Exemplo de evidência: a evidência a seguir mostra uma consulta SQL mostrando o conteúdo da tabela do banco de dados ordenada em ordem crescente no campo 'DATE_TRANSACTION' para mostrar os registros mais antigos no banco de dados. Isso mostra que os dados têm menos de dois meses, o que não excede o período de retenção definido. 

Nota: Este é um banco de dados de teste, portanto, não há muitos dados históricos nele. 

Observação: nos exemplos anteriores, capturas de tela completas não foram usadas, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema.

Controle nº 6

Fornecer evidências de que:

Existem processos para excluir dados com segurança após o período de retenção. 

Intenção: a intenção desse controle é garantir que o mecanismo usado para excluir dados que excedem o período de retenção esteja fazendo isso com segurança. Os dados excluídos às vezes podem ser recuperados; Portanto, o processo de exclusão precisa ser robusto o suficiente para garantir que os dados não possam ser recuperados depois de excluídos. 

Diretrizes: Se o processo de exclusão for feito programaticamente, forneça uma captura de tela do script usado para fazer isso. Se for executado em um agendamento, forneça uma captura de tela mostrando o agendamento. Por exemplo, um script para excluir arquivos em um compartilhamento de arquivos pode ser configurado como um trabalho CRON, captura de tela do trabalho CRON mostrando o agendamento e o script que é executado; e forneça o script mostrando o comando usado. 

Exemplo de evidência: este é um script simples que pode ser usado para excluir todos os registros de dados retidos com base na data -WHERE DateAdd é -30 dias, o que limpará todos os registros retidos com mais de 30 dias após a data de retenção de dados selecionada. Observe que precisaremos do script; evidências do trabalho que está sendo executado e os resultados. 

Observação: nos exemplos anteriores, capturas de tela completas não foram usadas, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema. 

Exemplo de evidência: A captura de tela a seguir foi tirada da Política de Retenção de Dados da Contoso (do Controle 4) – Isso mostra os procedimentos usados para destruição de dados.

Observação: esta captura de tela mostra um snapshot de um documento de política/processo. A expectativa é que os ISVs compartilhem a documentação real da política/procedimento de suporte e não simplesmente forneçam uma captura de tela. 

Exemplo de evidência: neste exemplo, um Runbook foi criado e um agendamento correspondente no Azure para excluir com segurança registros que têm uma data de término criada a partir dos 30 dias após a expiração da política de retenção de registro de dados. Esse trabalho está definido para ser executado todos os meses no último dia do mês. 

A próxima captura de tela mostra que o Runbook foi editado para localizar registros e tem comandos de exclusão que não estão em exibição como o script.

Observação: a URL completa e o nome de usuário devem estar em exibição para essas capturas de tela e os ISVs serão obrigados a mostrar uma captura de tela da contagem de registros antes da exclusão e uma captura de tela da contagem de registros após a exclusão. 

Essas capturas de tela são apenas exemplos das diferentes maneiras pelas quais isso pode ser abordado.

Controle nº 7

Fornecer evidências de que:

Um sistema de backup automatizado está em vigor e configurado para executar backups em horários agendados de acordo com um procedimento de backup documentado. 

As informações de backup são restauradas periodicamente para confirmar a confiabilidade e integridade dos dados de acordo com o procedimento de backup documentado. 

Controles de acesso apropriados e mecanismos de proteção (ou seja, backups imutáveis) são implementados para garantir que os backups/instantâneos do sistema sejam protegidos contra acesso não autorizado e para garantir a confidencialidade, integridade e disponibilidade dos dados de backup. 

Intenção:

O objetivo desse controle é confirmar se a organização possui um sistema de backup automatizado, configurado para executar backups em horários predeterminados. 

Diretrizes:

Forneça capturas de tela das definições de configuração da sua solução de backup mostrando que os backups estão sendo executados em períodos/intervalos de tempo agendados. Se a programação de backup for feita pela solução automaticamente, isso poderá ser suportado fornecendo documentação do fornecedor. 

Exemplo de evidência:

A captura de tela a seguir se aplica ao Banco de Banco de Dados do Azure para MySQL, que é uma instância gerenciada. Isso indica que um primeiro backup automatizado foi concluído.

A próxima captura de tela tirada após um período mostra que outros backups completos foram feitos. Os backups em servidores flexíveis são baseados em snapshots, onde o primeiro backup de snapshot é agendado imediatamente após a criação de um servidor e outros backups de snapshot são feitos uma vez por dia. 

A próxima captura de tela mostra um snapshot da documentação online que descreve a frequência de backup e a funcionalidade de backup automatizado. 

Intenção: o objetivo desse controle é comprovar que as informações de backup não são apenas geradas de acordo com o cronograma, mas também são confiáveis e mantêm sua integridade ao longo do tempo. Para atender a esse objetivo, testes periódicos serão realizados nos dados de backup. 

Diretrizes: As evidências para atender a esse controle dependerão do processo e procedimento da organização para testar os dados de backup. Evidências podem ser fornecidas mostrando backups sendo testados com sucesso ao lado de registros de conclusão de testes históricos. 

Exemplo de evidência: A captura de tela a seguir mostra que existe e é mantido um procedimento de agendamento e restauração de backup e que uma configuração de backup é definida para todos os sistemas aplicáveis, incluindo a frequência de backups realizados na plataforma Confluence.

A próxima captura de tela mostra uma página de registros históricos de testes de backup para cada um dos sistemas aplicáveis. Observe que no lado direito da tabela os tíquetes JIRA são referenciados para cada um dos testes. 

As próximas quatro capturas de tela mostram o processo de restauração de ponta a ponta do Banco de Dados do Azure para MySQL de um snapshot. Usando a opção 'Restauração rápida', podemos iniciar o processo de restauração do banco de dados SQL. 

A captura de tela a seguir mostra a página de configuração onde podemos personalizar a restauração.

Depois que o local de destino, a rede e o snapshot do qual o banco de dados será restaurado forem selecionados, poderemos iniciar a implantação. Observe que nossa instância de banco de dados agora é chamada de 'teste'.

Após um total de cinco minutos, o banco de dados SQL foi restaurado com êxito e totalmente do snapshot de backup, como mostra a seguir.

Depois que o teste foi concluído, de acordo com o processo, um tíquete JIRA foi criado para registrar o teste de backup e os detalhes da restauração realizada. Isso garante que os dados históricos estejam disponíveis para fins de conformidade, bem como a existência de registros completos para revisão na eventualidade de um incidente ou desastre para permitir que a organização realize uma análise de causa raiz. 

Intenção: a partir do controle anterior, os controles de acesso devem ser implementados para limitar o acesso apenas a usuários individuais responsáveis pelos dados de backup. Ao limitar o acesso, você está limitando o risco de alterações não autorizadas serem realizadas e, assim, introduzir alterações não seguras. Uma abordagem menos privilegiada deve ser adotada para proteger os backups. 

Para proteger adequadamente os dados, as organizações precisam estar cientes de quais dados seu ambiente/sistemas estão consumindo e onde os dados estão sendo armazenados. Uma vez que isso seja totalmente compreendido e documentado. 

As organizações podem não apenas implementar a 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 no menor número possível de lugares, é muito mais fácil implementar o RBAC (controle de acesso baseado em função) adequado para limitar o acesso ao menor número possível de funcionários. 

Diretrizes: Devem ser fornecidas evidências do sistema/tecnologia utilizada demonstrando as permissões de acesso aos backups e soluções de backup com documentação de suporte da lista de acesso aprovada. 

Exemplo de evidência: podemos ver nas capturas de tela a seguir apresentadas que os controles de acesso são implementados na instância do banco de dados para restringir o acesso apenas a indivíduos autorizados com base na função de trabalho. 

Exemplo de evidência:

Os backups automatizados do Banco de Dados SQL do Azure do Azure e das Instâncias Gerenciadas de SQL do Azure são gerenciados pelo Azure e sua integridade é de responsabilidade da plataforma do Azure; nenhum usuário tem acesso a eles e são criptografados em repouso sem possibilidade de ataques de ransomware. Eles também são replicados para outras regiões para proteção. 

Gerenciamento de acesso a dados

O acesso a dados precisa ser limitado ao menor número de pessoas necessário para reduzir as chances de comprometimento dos dados de forma maliciosa ou acidental. O acesso aos dados e às chaves de cifragem deve ser limitado aos utilizadores com uma necessidade comercial legítima de acesso para desempenhar as suas funções. Um processo bem documentado e bem estabelecido para solicitar acesso deve ser implementado. O acesso aos dados e às chaves de criptografia deve seguir o princípio de privilégios mínimos. 

Controle nº 8

Fornecer evidências de que:

É mantida uma lista de usuários com acesso a dados e/ou chaves de criptografia, incluindo a justificativa comercial para cada pessoa. 

Esta lista de usuários foi formalmente aprovada com base nos privilégios de acesso necessários para sua função de trabalho. 

Os usuários são configurados com os privilégios descritos nas aprovações. 

Observação: Uma amostra de usuários será selecionada para demonstrar os pontos B e C.

Intenção:

As organizações devem limitar o acesso aos dados e às chaves de criptografia ao menor número possível de funcionários. A intenção desse controle é garantir que o acesso dos funcionários aos dados e/ou chaves de criptografia seja restrito aos funcionários com uma necessidade comercial clara de acesso. 

Diretrizes:

Documentação ou capturas de tela de sistemas internos que documentam todos os funcionários com acesso a dados e/ou chaves de criptografia, juntamente com a justificativa comercial de por que esses indivíduos têm acesso, devem ser fornecidas. Essa lista será usada pelo analista de certificação para usuários de exemplo para os próximos controles. 

Exemplo de evidência:

O documento a seguir mostra a lista documentada de usuários com acesso aos dados e a justificativa comercial.

Observação: esta captura de tela mostra um documento de política/processo, a expectativa é que os ISVs compartilhem a documentação real de política/procedimento de suporte. 

Intenção: o processo para conceder acesso a dados e/ou chaves de criptografia precisa incluir aprovação, garantindo que o acesso de um indivíduo seja necessário para sua função de trabalho. Isso garante que os funcionários sem um motivo genuíno para o acesso não tenham acesso desnecessário. 

Diretrizes: Normalmente, as evidências fornecidas para o controle anterior podem ajudar a apoiar esse controle. Se não houver uma aprovação formal na documentação fornecida, a evidência poderá consistir em uma solicitação de alteração sendo levantada e aprovada para o acesso em uma ferramenta como o Azure DevOps ou o Jira. 

Exemplo de evidência: este conjunto de imagens mostra tíquetes do Jira criados e aprovados para o controle (i) para conceder ou negar acesso a dados confidenciais e/ou chaves de criptografia. Esta imagem demonstra que uma solicitação foi criada no Jira para obter a aprovação diária de Sam para chaves de criptografia no ambiente de back-end do sistema. Isso é feito como a próxima etapa em que a autorização por escrito foi obtida. 

Isso mostra que o pedido para dar acesso ao Sam Daily foi aprovado por Jon Smith, uma pessoa da gerência. (Observe que a aprovação deve vir de alguém com autoridade suficiente para permitir a solicitação de alteração, não pode ser outro desenvolvedor).

O anterior mostra um fluxo de trabalho no Jira para esse processo. Observe 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 conselho do projeto agora está mostrando que a aprovação foi dada para o acesso de Sam Daily às chaves de criptografia. A lista de pendências a seguir mostra a aprovação da solicitação de Sam Daily e a pessoa designada para fazer o trabalho.

Para atender aos requisitos desse controle, você deve mostrar todas essas capturas de tela ou evidências semelhantes/equivalentes aplicáveis com uma explicação para demonstrar que você atendeu ao requisito de controle. 

Observação: nos exemplos anteriores, capturas de tela completas não foram usadas, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema. 

Exemplo de evidência: no próximo exemplo, o acesso de administrador e as permissões de controle total foram solicitados para um usuário para o banco de dados de produção. A solicitação foi enviada para aprovação, como pode ser visto à direita da imagem, e foi aprovada conforme mostrado à esquerda. 

A próxima imagem indica que o acesso foi aprovado e assinado como concluído.

Observação: nos exemplos anteriores, capturas de tela completas não foram usadas, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema. 

Intenção A intenção deste subponto é confirmar se o acesso aos dados e/ou à chave de criptografia está configurado conforme documentado. 

Diretrizes: As evidências podem ser fornecidas por meio de captura de tela que mostra os dados e/ou privilégios de acesso à chave de criptografia concedidos aos indivíduos amostrados. As evidências devem cobrir todos os locais de dados. 

Exemplo de evidência: esta captura de tela mostra as permissões concedidas ao usuário "John Smith" que seriam cruzadas

referenciado na solicitação de aprovação para esse mesmo usuário de acordo com a evidência do controle anterior. 

Observação: o exemplo a seguir não é uma captura de tela em tela cheia, você deverá enviar capturas de tela em tela inteira com qualquer URL, usuário conectado e carimbo de data e hora para revisão de evidências. Se você for um usuário do Linux, isso poderá ser feito por meio do prompt de comando. 

Controle nº 9

Fornecer evidências de que:

É mantida uma lista de todos os terceiros com os quais os dados são compartilhados. 

Os contratos de compartilhamento de dados estão em vigor com todos os terceiros que consomem dados. 

Intenção: quando terceiros são usados para armazenamento ou processamento de dados do Microsoft 365, essas entidades podem representar um risco significativo. As organizações devem desenvolver um bom processo de due diligence e gerenciamento de terceiros para garantir que esses terceiros estejam armazenando/processando dados com segurança e para garantir que honrarão quaisquer obrigações legais que possam ter, por exemplo, como processador de dados sob o GDPR. 

As organizações devem manter uma lista de todos os terceiros com os quais compartilham dados com alguns ou todos os seguintes:

Quais serviços estão sendo fornecidos

Quais dados são compartilhados

Por que os dados são compartilhados

Principais informações de contato (ou seja, contato principal, contato de notificação de violação, DPO, etc.)

Renovação/expiração de contrato

Obrigações legais/de conformidade (ou seja, GDPR, HIPAA, PCI DSS, FedRAMP etc.)

Diretrizes: forneça documentação detalhando TODOS os terceiros com os quais os dados do Microsoft 365 são compartilhados. 

Nota: Se terceiros não estiverem em uso, isso precisará ser confirmado por escrito (e-mail) por um membro da equipe de liderança sênior. 

Exemplo de evidência:

Observação: - Nos exemplos anteriores, capturas de tela completas não foram usadas, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema. 

Exemplo de evidência:

A captura de tela a seguir mostra um exemplo de email de um membro da equipe de liderança sênior confirmando que nenhum terceiro é usado para processar dados do Microsoft 365. 

Observação: - Nestes exemplos, capturas de tela completas não foram usadas, no entanto, TODAS as capturas de tela de evidências enviadas pelo ISV devem ser capturas de tela completas mostrando o URL, qualquer usuário conectado e hora e data do sistema. 

Intenção: Quando os dados do M365 são compartilhados com terceiros, é importante que os dados sejam tratados de forma adequada e segura. Acordos de compartilhamento de dados devem estar em vigor para garantir que terceiros estejam processando dados apenas conforme necessário e que entendam suas obrigações de segurança. A segurança de uma organização é tão forte quanto o elo mais fraco. A intenção desse controle é garantir que terceiros não se tornem o elo fraco da organização. 

Diretrizes: Forneça os acordos de compartilhamento de dados em vigor com terceiros. 

Exemplo de evidência: a próxima captura de tela mostra um exemplo simplista de um contrato de compartilhamento de dados. 

Observação: o contrato completo deve ser compartilhado e não uma captura de tela.

Privacidade

A privacidade, a conformidade e o gerenciamento de informações são essenciais para proteger os direitos dos indivíduos e garantir o tratamento responsável dos dados. Para que uma organização estabeleça um sistema de informações de privacidade eficaz, ela precisa estar ciente de quais dados pessoais possui e a finalidade para processar e armazenar esses dados. Uma organização deve mapear o fluxo de informações e como isso é processado, reconhecendo que vários tipos diferentes de processamento podem estar ocorrendo. 

Controle nº 10 – Dados Pessoais

Forneça evidências de que sua organização:

Mantém um inventário atualizado de todos os dados pessoais coletados, processados e armazenados, incluindo a finalidade de cada elemento de dados.  

Projeta formulários de coleta de dados para incluir apenas campos necessários para a finalidade comercial e implementa campos obrigatórios e opcionais adequadamente.  

Desenvolve e aplica políticas que especificam os tipos de dados pessoais que podem ser coletados e as finalidades para as quais eles podem ser usados.  

Permite que os usuários recusem o processamento ou a exibição ampla de seus dados pessoais essenciais não comerciais.  

Intenção: a intenção desse controle é garantir que você esteja aderindo à privacidade de dados relacionada à coleta de dados, garantindo que haja uma justificativa para os dados que estão sendo capturados e ser transparente com quais e por que os dados são coletados. Também é importante que os usuários (titulares de dados) tenham a capacidade de recusar o processamento.   

Diretrizes: Esse controle pôde ser evidenciado da seguinte forma:

A) Fornecer uma versão atual do Registro de Atividades de Processamento (RoPA) da organização (consulte o Artigo 30 do GDPR) ou documento semelhante detalhando os elementos de dados e a finalidade (s) do processamento (consulte o Artigo 5.1.b do GDPR).  

Na maioria dos casos, seria uma planilha do Excel (que pode ser extraída de ferramentas, como o OneTrust).  

Se o arquivo for muito grande ou contiver dados confidenciais, um trecho poderá ser fornecido, mostrando todos os campos de dados para uma determinada amostra de dados, que pode ser parcialmente redigida, desde que a evidência possa fornecer garantia de que o RoPA está em vigor.  

Não compatível: os registros não existem, são muito antigos/desatualizados ou estão faltando campos-chave.  

B) Para fins de 'Minimização de Dados' (Consulte o Artigo 5.1.c do GDPR), forneça todos os formulários usados para obter dados, seja online, usando tablets ou dispositivos semelhantes (por exemplo, em uma conferência) ou em papel. Podem estar em branco/modelos.  

Não compatível: os formulários possuem campos obrigatórios que não são necessários para a finalidade pretendida do processamento. Por exemplo, solicitar números de telefone, idade ou sexo, para enviar um folheto por e-mail ou para um endereço postal.   

C) Para fins de 'legalidade, justiça e transparência' (Consulte o Artigo 5.1.a do GDPR), a Política de Privacidade (destinada a funcionários), o Aviso de Privacidade (destinado a usuários/clientes) deve estar em vigor. Normalmente, o Aviso de Privacidade deve estar disponível publicamente no site da organização.   

Não compatível: as políticas não existem ou estão faltando elementos-chave.  

Principais elementos:

Política/Aviso de Privacidade: coleta e uso de informações, elementos de dados processados, finalidade(s) 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) Para o mecanismo de recusa (consulte o Artigo 4.11 do GDPR, o Artigo 6 do GDPR e o Artigo 7 do GDPR), normalmente em uma página da Web. Verifique a navegação que o usuário precisaria seguir para chegar a essa página (por exemplo, é fácil de encontrar?).  

Não compatível: nenhuma funcionalidade de recusa clara ou recusa "genérica", sem granularidade.  

Exemplo de evidência:

Para A):

Para B):

Para C):

Para D):

Controle nº 11 – Conscientização do usuário

Forneça evidências de que os usuários estejam cientes:

Quem tem acesso aos dados. 

Quem tem acesso aos espaços em que estão trabalhando. 

Quem pode obter acesso aos seus dados por meio de compartilhamento ou fluxos de dados para que possam tomar decisões informadas. 

Intenção: a intenção desse controle é demonstrar que o princípio da "transparência" de proteção de dados (consulte o artigo 5.1.a do GDPR) foi atendido. 

Diretrizes: Para demonstrar que isso está em vigor, idealmente, alguma forma de reconhecimento do usuário (por exemplo, ter lido a Política de Privacidade) deve estar em vigor e registrada. 

Na prática, apenas que a Política de Privacidade (para funcionários), o Aviso de Privacidade (para usuários e clientes), forneça detalhes suficientes sobre o seguinte:

- Com quem os dados pessoais estão sendo compartilhados (processadores, subprocessadores, terceiros, contratados, etc.). 

Não compatível: não existem reconhecimentos ou a Política de Privacidade/Aviso de Privacidade não existe. 

Exemplo de evidência:

OU

Controle nº 12 – Contratos de Processamento de Dados (DPAs)

Forneça evidências do Contrato de Processamento de Dados, que deve ter uma lista de todos os terceiros/subprocessadores aprovados. 

Intenção: Garantir que você esteja sendo transparente com os titulares dos dados, garantindo que eles sejam informados sobre quais terceiros / subprocessadores podem ter acesso aos seus dados, o papel que desempenham no processamento (controlador de dados, processador de dados), suas respectivas responsabilidades e mecanismos de segurança em vigor. 

Além disso, quando o compartilhamento de dados envolver transferências de dados para territórios fora da UE (sob o GDPR), detalhes do mecanismo para garantir que as transferências sejam legais. (Consulte o Artigo 5 do GDPR e o Artigo 44-50 do GDPR)

Para GDPR, os territórios para processamento devem atender a uma das seguintes condições:

- Ser um Estado-Membro da União Europeia. 

- Ser considerado pela Comissão Europeia como fornecendo 'salvaguardas adequadas'. A lista atual pode ser encontrada aqui: Adequação da proteção de dados para países não pertencentes à UE 

A partir de 13 de junho de 2025:

• Faça parte da DPF (Estrutura de Privacidade de Dados) e esteja listado aqui: Estrutura de Privacidade de Dados 

• Ter regras corporativas vinculativas (BCRs) em vigor. 

• Ter cláusulas contratuais Standard (SCCs) em vigor. 

Diretrizes: A evidência pode ser por meio da amostragem de alguns Acordos de Processamento de Dados (DPA) com subprocessadores existentes. Em certos casos, as organizações podem não ter DPAs, mas teriam adendos aos contratos ou "Cláusulas de Privacidade". 

Não compatível:

• A lista de terceiros/subprocessadores está ausente. 

• Nenhum detalhe é fornecido sobre os países beneficiários. 

• Os países não estão listados como 'países adequados' e não há BCRs ou SCCs em vigor. 

Exemplo de evidência: este exemplo mostra um exemplo de DPA do IAPP, ou a evidência pode ser um documento relacionado listando as partes com as quais os dados são compartilhados. 

Além disso, marque os mecanismos para transferências de dados fora da UE.

Controle nº 13 – Avaliações de Impacto sobre Proteção de Dados (DPIAs)

Forneça evidências de que sua organização realiza a Avaliação de Impacto sobre a Proteção de Dados (DPIA)

     OU

Forneça o nome da avaliação relacionada à privacidade e proteção de dados à qual essa revisão de privacidade está conectada. 

Intenção: A intenção desse controle é garantir que você esteja realizando avaliações sobre os riscos potenciais aos direitos e liberdades dos indivíduos, especialmente relacionados à introdução de novas tecnologias ou novos usos de tecnologias existentes. (Consulte o artigo 35 do GDPR)

Diretrizes: Esse controle seria avaliado por meio da revisão de um DPIA recente ou documentação de avaliação relacionada. 

Não compatível:

Um AIPD deve ter os seguintes elementos:

• Identificação da necessidade de um DPIA. 

• Descrição do processamento previsto, incluindo escopo, 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 registrados. 

Se alguma das opções acima estiver ausente ou apenas executada em um nível superficial, esse controle poderá ser marcado como não compatível. 

Exemplo de evidência:

O modelo completo de um DPIA pode ser encontrado no site da ICO aqui dpia-template.docx

Controle nº 14 – Dados biométricos

O aplicativo interage com dados biométricos? Em caso afirmativo,

Fornecer evidências de que os dados biométricos passaram pela revisão legal, estão protegidos e os usuários são informados e têm a opção de ativar/desativar a coleta de dados biométricos. 

Intenção: esse controle está interessado em garantir proteções adequadas de dados biométricos, que de acordo com o Artigo 9 do GDPR são classificados como uma categoria especial de dados.  A utilização de dados biométricos foi submetida a uma análise de legalidade. 

Diretrizes: O uso de dados biométricos deve passar por uma revisão legal, portanto, eles precisam ser fornecidos como parte da coleta de evidências. Se não houver, solicite o modelo que seria usado (para marcar sua prontidão). 

Não compatível:

O exame jurídico sobre o tratamento de dados biométricos deve conter o seguinte:

• Base legal de processamento (um ou mais dos seguintes):

• Listar uma condição válida para o processamento de dados biométricos (uma ou mais das seguintes opções):

• Consideração dada ao uso de alternativas, em vez de dados biométricos.

Se alguma das opções acima estiver ausente ou apenas executada em um nível superficial, esse controle poderá ser marcado como não compatível.

Exemplo de evidência:

Fontes:

- Artigo 9 do GDPR – Processamento de Categorias Especiais de Dados: Art. 9 GDPR – Processamento de Categorias Especiais de Dados Pessoais - Regulamento Geral de Proteção de Dados (GDPR)

- ICO 'Como processamos dados biométricos legalmente?': Como processamos dados biométricos legalmente? | ICO

Controle nº 15 – Insights de Dados

Fornecer evidências de que as métricas mostram apenas dados agregados e anônimos, sem dados individualmente identificáveis. O locatário deve ser capaz de configurar o limite inferior do nível de agregação preferencial, com um mínimo absoluto de cinco permitido pelo produto. Fornecer evidências de que os dados biométricos passaram pela revisão legal, estão protegidos e os usuários são informados e têm a opção de ativar/desativar a coleta de dados biométricos. 

Intenção: a intenção desse controle é garantir que você implementou e está mantendo o status de dados anônimos e pseudonimizados durante todo o ciclo de vida dos dados. (Consulte

Diretrizes: Para ajudar a demonstrar que esse controle está em vigor, evidências via GUI ou CLI devem ser fornecidas para demonstrar:

• Configuração em nível de usuário para os limites mais baixos de níveis de agregação. 

• Um exemplo de métricas. 

Avalie se o usuário pode configurar um limite para seus níveis de agregação preferenciais para um mínimo de 5. A evidência deve demonstrar que apenas o anonimizado está presente na amostra de métricas. 

Não compatível:

• Os usuários não são capazes de personalizar seus níveis de agregação para um mínimo de 5, ou a habilidade técnica necessária para fazer isso não pode ser esperada do usuário típico. 

• Os dados pessoais estão presentes na amostra métrica; por exemplo: nome, sobrenome, RG, número de cliente, número de telefone, endereço de e-mail, endereço postal, dados bancários, parentes próximos, etc. 

Exemplo de evidência: capturas de tela das definições de configuração, mostrando os detalhes específicos. 

Amostra de métricas coletadas. Talvez pergunte sobre o processo para alcançar o anonimato. 

RGPD

A maioria das organizações processará dados que são potencialmente dados de cidadãos europeus (titulares de dados). Onde os dados de QUALQUER assunto de dados são processados, as organizações precisarão atender ao Regulamento Geral sobre a Proteção de Dados (GDPR). Isso se aplica tanto aos Controladores de Dados (você está capturando diretamente esses dados) quanto aos Processadores de Dados (você está processando esses dados em nome de um Controlador de Dados). Embora esta seção não cubra todo o regulamento, ela aborda alguns dos principais elementos do GDPR para ajudar a obter alguma garantia de que a organização está levando o GDPR a sério. 

Controle nº 16

Fornecer evidências que demonstrem a adesão aos direitos do titular dos dados, mostrando:

• Facilitação de SAR (Solicitação de Acesso ao Titular): documentação que confirma que os titulares dos dados são informados sobre seu direito de acessar seus dados pessoais e podem enviar SARs (Solicitações de Acesso do Titular) à sua organização. 

• Descoberta de dados e cumprimento de SAR: evidência da capacidade de sua organização de localizar e recuperar todos os dados pessoais pertencentes a um titular de dados individual em todos os sistemas e repositórios em resposta a um SAR. 

Intenção: A intenção desse controle é garantir que mecanismos adequados estejam em vigor para que os titulares dos dados façam solicitações sobre seus dados pessoais mantidos pela organização e que o atendimento de solicitações legítimas seja completo. (Consulte o Artigo 15 do GDPR). 

Diretrizes: A) O Aviso de Privacidade deve conter detalhes sobre como fazer um SAR, que pode ser usando os seguintes métodos:

• Usar um formulário da Web fornecido pela organização

• Usando um endereço de email fornecido pela organização

• Usar um número de telefone/webchat fornecido pela organização

• Usando uma autoridade supervisora (por exemplo, a ICO no Reino Unido)

Solicitar evidências do método em vigor; capturas de tela devem ser suficientes. 

B) Um RoPA ou documento similar pode ser usado para identificar os locais onde residem os dados pessoais pertencentes ao titular dos dados, seja digital ou como parte de sistemas de arquivamento (físicos). 

Alternativamente, os exercícios de descoberta eletrônica podem alcançar o mesmo resultado. 

Solicitar evidências do processo/fluxo de trabalho que seria usado para cumprir um SAR e uma explicação sobre como foi determinado que o processo é completo e não perderia nenhum dado pessoal relacionado ao titular dos dados. 

Não compatível:

A) Nenhuma informação é fornecida no site da organização (normalmente no Aviso de Privacidade). 

B) As evidências indicam que o processo de coleta de dados pessoais não é completo ou pode carecer de detalhes técnicos (por exemplo, nenhum nome/local fornecido para bancos de dados). 

Exemplo de evidência:

A) A seguir estão exemplos de quais evidências poderiam ser fornecidas para cobrir o ponto A). 

• Formulário da Web:

Fonte: Solicitação de acesso ao assunto - Police Care UK

• Email address/phone number:

Fonte: Qual? Política de Privacidade - Qual?

• Webchat:

Fonte: Faça uma solicitação de acesso ao assunto para HMRC - GOV.UK

• Por meio de uma Autoridade de Supervisão (por exemplo, o ICO):

Fonte: Faça sua solicitação de acesso ao assunto | ICO 

B) Artefatos de evidência fornecidos Detalhamento de fluxos de trabalho ou descrições de processos com detalhes técnicos suficientes, que poderiam ser plausivelmente usados para cumprir o SAR.    A próxima captura de tela demonstra exemplos de evidências da capacidade de uma organização de localizar e recuperar todos os dados pessoais relacionados a um titular de dados específico de um Banco de Dados SQL do Azure em resposta a uma SAR (Solicitação de Acesso do Titular). O exemplo mostra um administrador executando um procedimento armazenado predefinido no SQL do Azure Editor de Consultas para recuperar registros associados a um identificador exclusivo de assunto de dados em várias tabelas de banco de dados de produção. 

A próxima captura de tela demonstra uma evidência de exemplo da capacidade de uma organização de localizar e recuperar todos os dados pessoais relacionados a um titular de dados específico de uma Conta de Armazenamento do Azure em resposta a uma SAR (Solicitação de Acesso ao Titular). O exemplo mostra um administrador localizando todos os documentos associados a um identificador de entidade de dados exclusivo no Armazenamento de Blobs do Azure, demonstrando a capacidade da organização de identificar e recuperar dados pessoais não estruturados armazenados no ambiente.

Controle nº 17

FALHA DIFÍCIL

Forneça o Aviso de Privacidade que deve conter todos os elementos necessários da seguinte forma:

• A identidade e os detalhes de contato da organização e o DPO (Diretor de Proteção de Dados), se aplicável. 

• Os tipos de dados pessoais que sua organização trata (nome, sobrenome, número do cliente, endereço de email, número de telefone etc.). Além disso, as fontes de dados pessoais (por exemplo, de onde vêm os dados pessoais), caso a organização não os tenha obtido diretamente dos titulares dos dados. 

• A(s) finalidade(s) do processamento de dados pessoais. 

• A base legal do processamento de dados pessoais (incluindo interesses legítimos, quando relevante). 

• Partes com as quais sua organização compartilha dados pessoais. 

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

• Detalhes dos direitos dos titulares dos dados:

• Direito de ser informado

• Direito de acesso

• Direito de retificação

• Direito de apagar

• Direito à limitação do tratamento

• Direito à portabilidade dos dados

• Direito de oposição

• Direitos em relação à tomada de decisão automatizada, incluindo a criação de perfis

• Os detalhes sobre qualquer transferência de dados pessoais para um país terceiro e as salvaguardas tomadas. 

• O direito de apresentar uma reclamação a uma autoridade supervisora, fornecendo detalhes de contato da autoridade supervisora (por exemplo, o ICO no Reino Unido). 

Intenção: a intenção é garantir que o Aviso de Privacidade publicado contenha detalhes suficientes, incluindo os elementos e princípios acima, de acordo com o GDPR Capítulo 3. 

Diretrizes: de acordo com o Controle 10.c, por meio do qual você deve publicar um Aviso de Privacidade que abrange o serviço incluído na Certificação do Microsoft 365. Este Aviso de Privacidade deve conter os elementos e princípios destacados acima. 

Não compatível:

Consulte o Controle 10.c. 

Exemplo de evidência:

Observação: Seu próprio Aviso de Privacidade deve refletir com precisão sua inscrição e site reais. O aviso deve ser publicado e disponibilizado publicamente no site da empresa.  

HIPAA (Lei de Portabilidade e Responsabilidade de Seguros de Saúde)

A Lei de Portabilidade e Responsabilidade de Seguros de Saúde de 1996 (HIPAA) é uma legislação federal aplicável a cidadãos americanos e organizações de saúde. É importante observar que essa legislação também abrange quaisquer organizações fora dos EUA que processem dados de saúde de cidadãos americanos. A introdução da legislação determinou que o Secretário do Departamento de Saúde e Serviços Humanos dos EUA (HHS) desenvolvesse regulamentos que protegessem a privacidade e a segurança de certas 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 identificáveis individualmente transmitidas por mídia eletrônica, mantidas em mídia eletrônica ou transmitidas ou mantidas em qualquer outra forma ou meio. Quando os dados de integridade de QUALQUER assunto de dados forem processados, as organizações precisarão atender à HIPAA. 

A HIPAA tem duas legislações que precisam ser consideradas: 'A Regra de Privacidade', ou Padrões para Privacidade de Informações de Saúde Individualmente Identificáveis, que descreve os padrões nacionais para a proteção de certas informações de saúde, e 'Os Padrões de Segurança' para a Proteção de Informações de Saúde Protegidas Eletrônicas, também conhecido como 'Regra de Segurança'. Este último estabelece um conjunto nacional de padrões de segurança para proteger certas informações de saúde que são mantidas ou transferidas em formato eletrônico. 

Em uma visão geral de alto nível, 'A Regra de Segurança' é uma implementação prática das proteções oferecidas pela 'Regra de Privacidade'. Ele descreve as medidas técnicas e não técnicas que as "entidades cobertas" devem implementar para garantir a segurança das "informações eletrônicas de saúde protegidas" (e-PHI) dos indivíduos. Embora esta seção não cubra toda a regulamentação, ela aborda alguns dos principais elementos da HIPAA para ajudar a obter alguma garantia de que a organização está cumprindo a conformidade com o requisito e que a organização está protegendo as informações de saúde que processa. 

Controle nº 18

Forneça evidências que verifiquem a conformidade da sua organização com a Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA), fornecendo evidências de que:

• Aviso de Práticas de Privacidade (NPP) e Treinamento da Força de Trabalho: Um Aviso de Práticas de Privacidade está em vigor e um programa de treinamento da força de trabalho sobre o manuseio de Informações de Saúde Protegidas (PHI) sob a HIPAA é estabelecido para funcionários, contratados, fornecedores e outras partes relevantes. 

• Proteções para informações eletrônicas de saúde protegidas (ePHI): sua organização implementou proteções administrativas, físicas e técnicas conforme exigido pela Regra de Segurança HIPAA para garantir a confidencialidade, integridade e disponibilidade de todas as PHI eletrônicas (ePHI) que cria, recebe, mantém ou transmite. 

• Políticas de gerenciamento de risco: Sua organização possui políticas e medidas de gerenciamento de risco em vigor para se proteger contra quaisquer ameaças ou perigos razoavelmente previstos à segurança ou integridade do ePHI. 

Intenção: A intenção deste subponto é garantir que as organizações tenham estabelecido protocolos que sirvam como procedimentos padrão para gerenciar informações de saúde, lidar com emergências e interrupções de serviço e acesso da equipe a informações e treinamento de saúde. Além disso, espera-se que as organizações mantenham e descrevam essas proteções administrativas como parte de seu programa de segurança HIPAA. Esse é um aspecto crucial para cumprir os regulamentos da HIPAA. 

Diretrizes: Isso seria evidenciado pelo fornecimento da documentação estabelecida da organização descrevendo a política e o procedimento da HIPAA. Os analistas de certificação analisarão isso para garantir que todas as informações fornecidas no controle sejam abordadas. 

Exemplo de evidência: as capturas de tela mostram instantâneos de uma política HIPAA. Observação: a expectativa é que os ISVs compartilhem a documentação real da política/procedimento de suporte e não simplesmente forneçam uma captura de tela. 

Observação: a expectativa é que um ISV compartilhe a documentação de política/procedimento de suporte abrangente real e não simplesmente forneça uma captura de tela. 

Intenção:

Para entender a intenção deste subponto e garantir a conformidade com a Regra de Segurança, as "entidades cobertas" devem primeiro saber como os termos de confidencialidade, integridade e disponibilidade são definidos no § 164.304:

Confidencialidade: "a propriedade de que os dados ou informações não são disponibilizados ou divulgados a pessoas ou processos não autorizados". 

Integridade: "a propriedade de que os dados ou informações não foram alterados ou destruídos de maneira não autorizada." 

Disponibilidade: "a propriedade de que os dados ou informações são acessíveis e utilizáveis mediante solicitação por uma pessoa autorizada." 

A intenção desse requisito é que as organizações implementem proteções/medidas técnicas, como controles de acesso, auditoria, integridade e transmissão dentro da infraestrutura de TI para garantir a confidencialidade do ePHI, mantendo sua integridade e disponibilidade para usuários autorizados. 

Diretrizes:

Podem ser apresentadas provas através de definições dos mecanismos de protecção utilizados para garantir que os dados ePHI são protegidos em conformidade com o requisito de controlo. Esses mecanismos podem incluir controles de acesso, procedimentos de acesso de emergência, RBAC, criptografia etc. 

Exemplo de evidência: controles de acesso e integridade

A próxima captura de tela mostra que existe uma lista de acesso autorizado de indivíduos que têm permissões para lidar com locais de armazenamento ePHI e é mantida no documento de política HIPAA. Além disso, nas capturas de tela após a lista de inventário aprovada, pode-se observar que há acesso de gravação limitado no cluster, com apenas o administrador e o analista de manutenção de banco de dados podendo ler e gravar no cluster. 

A próxima captura de tela tirada de um dos bancos de dados de armazenamento ePHI no Atlas Mongo demonstra que apenas usuários autorizados têm o acesso documentado e que todas as contas têm IDs de usuário exclusivas para garantir a responsabilidade. 

A primeira captura de tela mostra o local de armazenamento principal/cluster de banco de dados para ePHI. 

A segunda captura de tela demonstra que os usuários aprovados têm apenas as funções e o acesso documentados.

As próximas duas capturas de tela mostram uma exibição mais granular de cada uma das funções atribuídas e todas as permissões associadas que estão de acordo com a aprovação de acesso acima.

Cada função personalizada tem um conjunto de permissões e escopo de acesso.

Por fim, a próxima captura de tela demonstra, de uma perspectiva de rede, que apenas o intervalo de IP autorizado que é a rede corporativa segura tem permissão de acesso ao cluster.

Exemplo de evidência: controles de auditoria

Essas capturas de tela mostram que o registro em log e os alertas são implementados para o cluster de banco de dados. A primeira captura de tela mostra que os alertas estão habilitados. Observe que a expectativa é que as evidências fornecidas também mostrem as regras de alerta que foram definidas com base na necessidade/implementação da organização. A segunda captura de tela mostra que a auditoria de banco de dados está sendo habilitada. 

A próxima captura de tela mostra o histórico de acesso ao cluster de banco de dados que está sendo gravado. A expectativa é que os alertas sejam definidos e baseados nos logs de auditoria e qualquer acesso não autorizado que não atenda às condições predefinidas dispare um alerta.

As duas últimas capturas de tela mostram que os logs de auditoria são gerados para o cluster de banco de dados e que os logs podem ser exportados para análise.

Observe que a expectativa é que haja um processo em vigor para que os logs de auditoria gerados sejam analisados, evidências do processo de revisão também devem ser fornecidas. Se isso for feito programaticamente, as capturas de tela das definições de configuração da ingestão de log na plataforma/solução de log usada, bem como capturas de tela das regras, deverão ser fornecidas para análise. 

Exemplo de evidência: criptografia e controles de transmissão

As próximas capturas de tela demonstram que o local de armazenamento tem dados em repouso criptografados por padrão. Observe que, se a criptografia não for executada pela plataforma usada por padrão e suas próprias chaves de criptografia estiverem em uso, a expectativa é que essas chaves sejam adequadamente protegidas e evidências são fornecidas para demonstrar isso. 

As próximas duas capturas de tela demonstram que o local de armazenamento tem dados em trânsito criptografados por padrão. A primeira captura de tela demonstra que uma API de dados está habilitada com permissões de 'leitura e gravação'.

Uma verificação SSL do ponto de extremidade demonstra que os dados em trânsito são criptografados via TLS 1.2.

Exemplo de evidência: controles de disponibilidade e recuperação

A próxima captura de tela demonstra que o cluster de banco de dados é replicado em três regiões para garantir a disponibilidade. Isso é feito por padrão pelo Mongo Atlas. Além disso, o backup está habilitado e está ativo.

A captura de tela a seguir mostra o dashboard de backup do cluster, que também demonstra que um snapshot já foi criado.

As próximas duas capturas de tela demonstram que uma política de backup está em vigor para executar backups agendados em diferentes pontos no tempo (PIT).

O diagrama a seguir indica que há uma política de retenção para instantâneos e PIT (restauração pontual).

Intenção: A intenção deste subponto está alinhada com a regra de segurança que foi desenvolvida para garantir flexibilidade e escalabilidade para que uma "entidade coberta" possa implementar políticas, procedimentos e soluções tecnológicas adequadas ao tamanho da entidade, sua estrutura organizacional e seus riscos específicos, bem como seu apetite por risco. Do ponto de vista prático, isso significa que as medidas de segurança apropriadas implementadas dependerão da natureza dos negócios da "entidade coberta", bem como de seu tamanho e recursos. 

É vital que todas as organizações realizem uma análise de risco abrangente para descobrir possíveis riscos e vulnerabilidades à confidencialidade, integridade e disponibilidade da e-PHI. Por meio dessa análise de risco, as organizações podem implementar controles de segurança apropriados para mitigar esses riscos identificados. 

Diretrizes: As evidências podem ser fornecidas por meio do resultado da análise de risco. Se a análise de risco for realizada e mantida através de uma plataforma em linha, devem ser fornecidas capturas de ecrã de todos os resultados. 

Exemplo de evidência: As próximas capturas de tela mostram instantâneos do processo de avaliação de risco, seguidos pela análise de risco que foi realizada para determinar até que ponto os controles são implementados corretamente e operam conforme planejado para proteger o ePHI. A segunda captura de tela mostra uma análise de risco para os riscos identificados na avaliação de risco e os controles e mitigações de compensação implementados para diminuir o nível de risco. 

Exemplo 1 – Instantâneo do processo de avaliação de risco dentro da política HIPAA e análise de risco realizada

Observação: esta captura de tela mostra um snapshot de um documento de análise de risco, este é apenas um exemplo, e a expectativa é que os ISVs compartilhem a documentação real e não simplesmente forneçam uma captura de tela.

Exemplo 2 – Capturas de tela do processo de avaliação de risco dentro da política HIPAA e análise de risco realizada (mantida na plataforma Confluence Cloud)

A segunda captura de tela mostra uma análise de risco para os riscos identificados na avaliação de risco e os controles e mitigações de compensação implementados para diminuir o nível de risco. Podemos ver que isso existe e é mantido na plataforma de nuvem do Confluence.

Controle nº 19

Fornecer evidências de que:

Sua organização estabeleceu e implementou um Plano de Backup de Dados e um Plano de Recuperação de Desastre como parte de seu Plano de Contingência, de acordo com as Salvaguardas Administrativas da Regra de Segurança HIPAA sob 45 CFR §164.308(a)(7)(ii)(A) (Plano de Backup de Dados) e 45 CFR §164.308(a)(7)(ii)(B) (Plano de Recuperação de Desastres). 

Intenção: A Regra de Privacidade define quais partes das Informações de Saúde Protegidas (PHI) são cobertas pela lei e proíbe usos e divulgações indevidas de PHI. A intenção deste subponto é que uma organização deve limitar o acesso e o uso de e-PHI apenas àqueles que precisam dela para fins autorizados e que devem cumprir a regra mínima necessária, que exige que eles usem ou divulguem apenas a quantidade mínima de e-PHI necessária para cumprir sua finalidade pretendida. 

Uma combinação de salvaguardas técnicas e administrativas deve estar em vigor para restringir o uso de ePHI e garantir que o risco de divulgação da ePHI seja reduzido. 

Diretrizes: As evidências fornecidas precisam mostrar as salvaguardas técnicas em vigor, como tecnologias e mecanismos que estão em uso para proteger as PHI eletrônicas e como os controles da organização marcam o acesso e a movimentação desses dados. 

Exemplo de evidência: as próximas capturas de tela mostram a Prevenção Contra Perda de Dados do Microsoft Purview (DLP), que é uma plataforma integrada que permite que as organizações gerenciem suas políticas DLP em um único local centralizado. 

Você pode observar abaixo que uma política "U.S. HIPAA Enhanced" está habilitada, isso fornece a capacidade de impedir que os usuários colem dados confidenciais em sites específicos, incluindo email pessoal, prompts de IA generativa, sites de mídia social e muito mais quando acessados por meio de um navegador da web compatível. 

A próxima captura de tela fornece uma visão geral mais abrangente da política, incluindo o escopo ao qual ela é aplicada. A política é definida para todas as contas em locais como SharePoint, Dispositivos, OneDrive etc.

Ao selecionar a opção "Editar política", é exibida uma visão mais granular das configurações específicas disponíveis.

As próximas duas capturas de tela mostram a definição de conteúdo e as condições que devem ser atendidas para que a política seja aplicada.

A política abrange vários tipos de dados confidenciais, bem como um conjunto de classificadores.

A próxima seção mostra as ações configuradas para serem tomadas quando as condições mostradas nas capturas de tela anteriores forem atendidas.

A captura de tela a seguir mostra que a política DLP está definida para impedir que os usuários copiem e colem informações confidenciais, como informações de identificação pessoal (PII) dos bancos de dados internos da organização em suas contas de email pessoais, chatbots e sites de mídia social em navegadores com suporte.

Por fim, as notificações do usuário são configuradas para notificar e fornecer orientação aos usuários durante o tratamento de dados ePHI.

A captura de tela a seguir mostra o painel de configuração para gerar alertas quando ocorre um incidente.

Intenção: A intenção deste subponto é que uma organização deve treinar sua equipe sobre como lidar com e-PHI de forma segura e adequada, e que eles devem aplicar políticas e procedimentos para garantir a conformidade com a Regra de Segurança. 

Diretrizes: As evidências fornecidas precisam demonstrar que o treinamento HIPAA é realizado sobre como lidar com ePHI e que existem registros de frequência e conclusão do treinamento. Quando aplicável, isso pode ser respaldado pela documentação da política e pelos materiais de treinamento usados. 

Exemplo de evidência: os exemplos a seguir mostram as evidências potenciais que podem ser enviadas para demonstrar que o treinamento apropriado da HIPAA ocorre de acordo com a política. 

A próxima captura de tela mostra uma snapshot da política HIPAA com uma seção específica descrevendo o requisito de treinamento. Observe que este é apenas um exemplo e não um documento/implementação abrangente, a expectativa é que o ISV tenha um processo estabelecido que seja aplicável à sua organização. 

Exemplo 1 – Treinamento de usuários da HIPAA por meio do processo administrativo

Na próxima captura de tela, o slide de visão geral do curso mostra um resumo dos objetivos do curso. Se o treinamento for desenvolvido internamente, os materiais de treinamento deverão ser fornecidos para revisão. Observe que o material completo deve ser enviado e não apenas uma captura de tela do resumo.

A captura de tela a seguir mostra o registro de presença dos funcionários que participaram do treinamento. O registro também mostra a pontuação do passe, bem como a próxima data programada do treinamento.

O segundo exemplo demonstra como o Microsoft 365 Defender pode ser usado para definir e iniciar campanhas de treinamento.

Exemplo 2 – Treinamento de usuários da HIPAA por meio da Plataforma de Simulação de Ataque do Microsoft 365 Defender (todos os usuários)

A captura de tela anterior mostra a campanha de treinamento de segurança da HIPAA, a duração total em minutos, bem como o status de conclusão. A próxima captura de tela fornece uma visão geral dos usuários aos quais o treinamento foi atribuído e o status do treinamento que demonstra a conclusão bem-sucedida.

Exemplo 3 – Treinamento de Usuário HIPAA por meio da Plataforma de Simulação de Ataque do Microsoft 365 Defender (Usuário individual)

Enquanto o exemplo anterior se concentrou em demonstrar que todos os usuários concluíram a campanha anual de treinamento, o exemplo final mostra evidências direcionadas que demonstram a conclusão de um funcionário.

Você pode observar nas duas capturas de tela anteriores que, assim que a campanha de treinamento foi lançada, cada funcionário recebeu um e-mail confirmando a atribuição e a data de vencimento do treinamento, bem como os módulos atribuídos, duração, etc.

Usando o link disponível na notificação por email, a captura de tela a seguir mostra a página Atribuições de treinamento para o usuário e os dois módulos que foram concluídos.

Intenção: de acordo com a regra de segurança da HIPAA, um plano de backup de dados e um plano de recuperação de desastres são obrigatórios para qualquer "entidade coberta" que lide com informações eletrônicas de saúde protegidas (ePHI). Tais planos fazem parte da estratégia de contingência que visa garantir a disponibilidade e segurança das ePHI em caso de emergência ou outra ocorrência que danifique os sistemas que contêm ePHI. 

A intenção do plano de backup de dados é criar e manter cópias idênticas recuperáveis do ePHI, isso também deve incluir testes periódicos dos backups para garantir que a recuperação dos dados seja possível. A intenção do plano de recuperação de desastres é restaurar quaisquer possíveis dados perdidos no caso de um desastre, e isso deve especificar as etapas que devem ser tomadas para restaurar o acesso aos dados, incluindo como os arquivos devem ser restaurados a partir de backups. 

Diretrizes: Forneça a versão completa do plano/procedimento de recuperação de desastres, que deve abranger o plano de backup e o plano de recuperação. Forneça o documento PDF/Word real se estiver em uma versão digital, alternativamente, se o processo for mantido por meio de uma plataforma online, fornecer uma exportação em PDF ou, se não for possível exportar devido a limitações da plataforma, forneça capturas de tela cobrindo toda a política. 

Exemplo de evidência: a próxima captura de tela mostra instantâneos da Política de Segurança HIPAA contendo uma visão geral do procedimento de backup geral e de alto nível e do plano de Recuperação de Desastres. 

Observação: esta captura de tela mostra um snapshot do documento de política/processo, este é apenas um exemplo, e a expectativa é que os ISVs compartilhem a documentação de política/procedimento de suporte abrangente real e não simplesmente forneçam uma captura de tela.

Manuais

Murdoch D. (2018) Manual da Equipe Azul: Edição de Resposta a Incidentes: Um guia de campo condensado para o Respondente de Resposta a Incidentes de Segurança Cibernética. 2ª Edição, Editora: Plataforma de Publicação Independente CreateSpace.

Referências

• Action Fraud Cyber Crime reporting Disponível em: (Acessado em: https://www.actionfraud.police.uk/ 10/12/2023).

• UE. (2021) Lista de verificação do GDPR para controladores de dados Disponível em: (Acessado em: https://gdpr.eu/checklist/ 10/12/2023).

• Microsoft. (2018) Log de Eventos (Windows Installer) Disponível em: Log de Eventos (Acessado em: 05/03/2024).

• Tecnologias Positivas. (2020) Como abordar o desenvolvimento seguro de software Disponível em: software-development/(Acessado em: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure- 12/10/2023).

• Regulamento (UE) 2016/679 do Parlamento Europeu e do Conselho, de 27 de abril de 2016, relativo à proteção das pessoas singulares no que diz respeito ao tratamento de dados pessoais e à livre circulação desses dados e que revoga a Diretiva 95/46/CE (Regulamento Geral sobre a Proteção de Dados) (Texto relevante para efeitos do EEE) (2016) Disponível em: (Acessado em: https://www.legislation.gov.uk/eur/2016/679/contents 10/12/2023).

• Métricas de segurança. (2020) Guia de métricas de segurança para conformidade com PCI DSS. Disponível em: (Acessado em: https://info.securitymetrics.com/pci-guide-202010/12/2023).

• Williams J. OWASP Risk Ranking Disponível em: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (Acessado em: 10/12/2023).

• Qualys. (2014) SSL Labs: Novas notas para problemas de confiança (T) e incompatibilidade (M) Disponível em: mismatch-m-issues (Acessado em: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and- 10/12/2023).

• NIST SP800-61r2: Guia de Tratamento de Incidentes de Segurança do Computador Disponível em: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (Acessado em: 10/12/2023).

• Criando um pipeline de CI/CD com o Azure Pipelines e o Google Kubernetes Engine | .NET

• Google Cloud (Acessado em: 10/10/2023).

• O Plano de Recuperação de Desastres em: https://www.sans.org/white-papers/1164/ (Acessado em: 10/10/2023).

• https://github.com/ (Acessado em: 10/10/23).

• Modelos de Política de Segurança em: https://www.sans.org/information-security-policy/ (Acessado em: 10/10/23).

• https://www.openedr.com/ (Acessado em: 10/02/23).

• https://www.atlassian.com/software/confluence (Acessado em: 10/10/23).

• https://www.atlassian.com/software/jira (Acesso em 28/09/23).

• Plano de Continuidade de Negócios (BCP) Modelo de exercício de mesa em: https://www.pivotpointsecurity.com/services/business-continuity-management/table-top-exercise-template/ (Acessado em: 10/10/23).

• Resumo da Regra de Segurança HIPAA | HHS.gov (Acessado em: 18/10/2023).

• Leis de privacidade de informações de saúde na era digital: HIPAA não se aplica - PMC (nih.gov) (Acessado em: 18/10/2023).

• Qual é o objetivo da HIPAA? Atualização 2023 (hipaajournal.com) (Acesso em: 18/10/2023).

• O que é considerado PHI sob HIPAA? Atualização de 2023 (hipaajournal.com) (Acesso em: 18/10/2023).

• Políticas e Procedimentos HIPAA (hipaajournal.com) (Acesso em: 18/10/2023).

• Projetando políticas & políticas administrativas da HIPAA | Dash Solutions (dashsdk.com) (Acessado em: 18/10/2023).

• 45 CFR § 164.304 - Definições. | Código Eletrônico de Regulamentos Federais (e-CFR) | Direito dos EUA | LII

• / Instituto de Informação Legal (cornell.edu) (Acesso em: 18/10/2023).

• O que é conformidade com HIPAA? Leis & regras da HIPAA | Proofpoint UK (Acesso em: 18/10/2023).

• Regras, Regulamentos e Padrões de Segurança HIPAA (training-hipaa.net) (Acessado em: 18/10/2023).

• Resumo da Regra de Segurança HIPAA | HHS.gov (Acessado em: 18/10/2023).

• SP 800-66 Rev. 1, Um Guia de Recursos Introdutórios para Implementar aRegra de Segurança da Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA) | CSRC (nist.gov) (Acessado em: 18/10/2023).

• A Regra de Segurança | HHS.gov (Acessado em: 18/10/2023).

• https://www.hipaajournal.com/hipaa-encryption-requirements (Acessado em: 19/10/2023).

• https://www.hipaajournal.com/hipaa-privacy-rule/ (Acessado em: 19/10/2023).

• https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (Acessado em: 19/10/2023).

• https://www.tausight.com/the-ultimate-guide-to-electronic-protected-health-information- ephi/ (Acessado em: 19/10/2023).

• Configurar criptografia — Manual do MongoDB (acessado em: 19/10/2023).

• https://its.ucsc.edu/policies/docs/hipaa-risk-analysis.doc (Acessado em: 19/10/2023).

• Prevenção Contra Perda de Dados do Microsoft Purview: anúncio da disponibilidade geral de vários recursos

• Hub de Comunidade da Microsoft (Acessado em: 24/10/2023).

• 45 CFR § 164.308 - Salvaguardas administrativas. | Código eletrônico de regulamentos federais (e-CFR)

• | Direito dos EUA | LII / Instituto> de Informação Legal (cornell.edu) (Acesso em: 24/10/2023).

• Quando devemos fornecer informações de privacidade? | ICO (Acessado em: 11/08/2023).

• Como devemos redigir nossas informações de privacidade? | ICO (Acessado em: 11/08/2023).

• Accountability Framework | ICO (Acessado em: 11/08/2023).

• ISO 27001 Requisito 5.1 - Liderança & Compromisso | ISMS.online (Acessado em: 11/08/2023).

• Plataforma de Navegação Online (OBP) (iso.org) (Acesso em: 11/08/2023).

• Cláusula 5.3 Papéis Organizacionais, Responsabilidades e Autoridades - Treinamento ISO (Acessado em: 11/08/2023).

• 5.3 Funções, Responsabilidade e Autoridade (iso9001help.co.uk) (Acesso em: 11/08/2023).

• Desidentificação e reidentificação de PII em conjuntos de dados em larga escala usando a Proteção de Dados Confidenciais| Centro de Arquitetura de Nuvem | Google Cloud (acessado em: 11/08/2023).

• Desidentificação de dados confidenciais | Documentação sobre proteção de dados confidenciais | Google Cloud (acessado em: 11/08/2023).

• Um guia para segurança de dados | ICO (Acessado em: 11/08/2023).

• Transferências internacionais de dados | ICO (Acessado em: 11/08/2023).

• Gerenciamento e segurança de registros | ICO (Acessado em: 11/08/2023).

• ISO 27701 - Gerenciamento de Informações de Privacidade (acessado em: 11/08/2023).

• Sistema de Gerenciamento de Informações de Privacidade (PIMS) ISO 27701 | ISMS.Online (Acessado em: 11/08/2023).

Imagens/texto extraídos de documentos da Microsoft

• https://www.sans.org/information-security-policy/ (Acessado em: 18/02/21).

• Obtenha análise comportamental e detecção de anomalias (Acessado em: 05/03/24).

• O que são alertas do Azure Monitor? (Acessado em: 05/03/24).

• Obtenha análise comportamental e detecção de anomalias

• (Acessado em: 05/03/24).

• Gerenciar e responder a alertas de segurança no Microsoft Defender para Nuvem (Acessado em: 05/03/24).

• Gerenciar e responder a alertas de segurança no Microsoft Defender para Nuvem (Acessado em: 05/03/24).

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

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

• Transparent Data Encryption para o Banco de Dados SQL, a Instância Gerenciada de SQL e o Azure Synapse Analytics (Acessado em: 05/03/24).

• Início Rápido: Criar uma atribuição de política para identificar recursos não compatíveis (Acessado em: 05/03/24).

• Configurar a Proteção Avançada contra Ameaças para o Banco de Dados SQL do Azure (acessado em:05/03/24).

• Backup e restauração no Banco de Dados do Banco de Dados do Azure para MySQL - Servidor Flexível (Acessado em: 05/03/24).

• Inventário de certificados (Acessado em: 05/03/24).

• Backup e restauração no Banco de Dados do Banco de Dados do Azure para MySQL (Acessado em: 05/03/24).

• https://github.com/microsoft/presidio/blob/main/docs/samples/deployments/data- factory/presidio-data-factory-template-gallery-http.md (Acessado em: 11/08/2023).

Saiba mais

• Exemplo de guia de evidências - Visão geral
• Exemplo de guia de evidências - Operações