Saiba mais sobre a chave disponibilidade da Chave de Cliente
A chave de disponibilidade é uma chave raiz gerada e provisionada automaticamente quando você cria uma política de criptografia de dados. O Microsoft 365 armazena e protege a chave de disponibilidade. A chave de disponibilidade é funcionalmente como as duas chaves raiz que você fornece para a Chave do Cliente. A chave de disponibilidade envolve as chaves uma camada inferior na hierarquia de chaves. Ao contrário das chaves que você fornece e gerencia no Azure Key Vault, você não pode acessar diretamente a chave de disponibilidade. Os serviços automatizados do Microsoft 365 gerenciam a chave de disponibilidade de forma programática. Esses serviços iniciam operações automatizadas que nunca envolvem acesso direto à chave de disponibilidade.
A principal finalidade da chave de disponibilidade é fornecer a capacidade de recuperação da perda inesperada de chaves raiz que você gerencia. A perda pode ser resultado de má gestão ou ação mal-intencionada. Se você perder o controle de suas chaves raiz, entre em contato com Suporte da Microsoft para obter assistência com o processo de recuperação usando a chave de disponibilidade. Use a chave de disponibilidade para migrar para uma nova Política de Criptografia de Dados com novas chaves raiz que você provisiona.
O armazenamento e o controle da chave de disponibilidade são deliberadamente diferentes das chaves Key Vault do Azure por três motivos:
- A chave de disponibilidade fornece uma capacidade de recuperação, "break-glass" se o controle sobre as chaves Key Vault do Azure for perdido.
- A separação de controles lógicos e locais de armazenamento seguros fornece defesa em profundidade e protege contra a perda de todas as chaves e seus dados, de um único ataque ou ponto de falha.
- A chave de disponibilidade fornece uma funcionalidade de alta disponibilidade se os serviços do Microsoft 365 não conseguirem alcançar as chaves hospedadas no Azure Key Vault devido a erros transitórios. Essa regra só se aplica à criptografia de serviço do Exchange. O Microsoft SharePoint e o OneDrive nunca usam a chave de disponibilidade, a menos que você instrua explicitamente a Microsoft a iniciar o processo de recuperação.
O compartilhamento da responsabilidade de proteger seus dados usando várias proteções e processos para o gerenciamento de chaves acaba reduzindo o risco de que todas as chaves (e, portanto, seus dados) sejam permanentemente perdidas ou destruídas. A Microsoft fornece autoridade exclusiva sobre a desabilitação ou destruição da chave de disponibilidade quando você deixa o serviço. Por design, ninguém na Microsoft tem acesso à chave de disponibilidade: ela só é acessível pelo código de serviço do Microsoft 365.
Para obter mais informações sobre como proteger chaves, visite o Centro de Confiança da Microsoft.
Dica
Se você não é um cliente E5, use a avaliação das soluções do Microsoft Purview de 90 dias para explorar como os recursos adicionais do Purview podem ajudar sua organização a gerenciar as necessidades de segurança e conformidade de dados. Comece agora no hub de testes do portal de conformidade do Microsoft Purview. Saiba mais detalhes sobre os termos de inscrição e avaliação.
Windows 365 suporte para a Chave de Cliente do Microsoft Purview está em versão prévia pública e está sujeita a alterações.
Usos da chave de disponibilidade
A chave de disponibilidade fornece capacidade de recuperação para cenários em que um malefator externo ou insider mal-intencionado rouba o controle do cofre de chaves ou quando a má gestão inadvertida resulta em perda de chaves raiz. Essa funcionalidade de recuperação se aplica a todos os serviços do Microsoft 365 compatíveis com a Chave do Cliente. Os serviços individuais usam a chave de disponibilidade de forma diferente. O Microsoft 365 usa apenas a chave de disponibilidade das maneiras descritas nas próximas seções.
Exchange
Além da capacidade de recuperação, o Exchange usa a chave de disponibilidade para garantir a disponibilidade de dados durante problemas operacionais transitórios ou intermitentes, relacionados ao serviço que acessa chaves raiz. Quando o serviço não consegue alcançar nenhuma das chaves do cliente no Azure Key Vault devido a erros transitórios, o serviço usa automaticamente a chave de disponibilidade. O serviço NEVER vai diretamente para a chave de disponibilidade.
Sistemas automatizados no Exchange podem usar a chave de disponibilidade durante erros transitórios. O uso da chave de disponibilidade dá suporte a serviços de back-end automatizados, como antivírus, descoberta eletrônica, Prevenção Contra Perda de Dados do Microsoft Purview, movimentações de caixa de correio e indexação de dados.
SharePoint e OneDrive
Para o OneDrive amd do SharePoint, a chave de disponibilidade nunca é usada fora do recurso de recuperação. Você deve instruir explicitamente a Microsoft a usar a chave de disponibilidade durante um cenário de recuperação. As operações de serviço automatizadas dependem exclusivamente das chaves do cliente no cofre do Azure Key. Para obter informações detalhadas sobre como a hierarquia de chaves funciona para esses serviços, confira Como o SharePoint e o OneDrive usam a chave de disponibilidade.
Segurança da chave de disponibilidade
A Microsoft compartilha a responsabilidade da proteção de dados com você, instanciando a chave de disponibilidade e tomando medidas extensas para protegê-la. A Microsoft não expõe o controle direto da chave de disponibilidade aos clientes. Por exemplo, você só pode rolar (girar) as chaves que possui no Azure Key Vault. Para obter mais informações, consulte Rolar ou girar uma Chave do Cliente ou uma chave de disponibilidade.
Repositórios secretos de chave de disponibilidade
A Microsoft protege as chaves de disponibilidade em repositórios de segredos internos controlados pelo acesso, como o Key Vault do Azure voltado para o cliente. Implementamos controles de acesso para impedir que os administradores da Microsoft acessem diretamente os segredos contidos. As operações da Secret Store, incluindo rotação e exclusão de chaves, ocorrem por meio de comandos automatizados que nunca envolvem acesso direto à chave de disponibilidade. As operações de gerenciamento de repositórios secretos são limitadas a engenheiros específicos e exigem escalonamento de privilégios por meio de uma ferramenta interna, o Lockbox. O escalonamento de privilégios requer a aprovação e a justificativa do gerente antes de ser concedido. A caixa de bloqueio garante que o acesso esteja associado à revogação automática de acesso após a expiração do tempo ou a saída do engenheiro.
As chaves de disponibilidade do Exchange são armazenadas em um repositório secreto do Exchange Active Directory. As chaves de disponibilidade são armazenadas com segurança dentro de contêineres específicos do locatário no Controlador de Domínio do Active Directory. Esse local de armazenamento seguro é separado e isolado do repositório de segredos do SharePoint e do OneDrive.
As chaves de disponibilidade do SharePoint e do OneDrive são armazenadas em um repositório de segredos interno gerenciado pela equipe de serviço. Esse serviço de armazenamento de segredos protegido tem servidores front-end com pontos de extremidade do aplicativo e um Banco de Dados SQL como o back-end. As chaves de disponibilidade são armazenadas no Banco de Dados SQL. Chaves de criptografia do repositório secreto encapsulam (criptografar) as chaves de disponibilidade. As chaves do repositório de segredos usam uma combinação de AES-256 e HMAC para criptografar a chave de disponibilidade em repouso. As chaves de criptografia do repositório secreto são armazenadas em um componente logicamente isolado do mesmo Banco de Dados SQL e são criptografadas com chaves RSA-2048 contidas em certificados gerenciados pela autoridade de certificado da Microsoft (AC). Esses certificados são armazenados nos servidores front-end do repositório secreto que executam operações no banco de dados.
Defesa em profundidade
A Microsoft emprega uma estratégia de defesa detalhada para impedir que atores mal-intencionados impactem a confidencialidade, integridade ou disponibilidade dos dados do cliente armazenados no Microsoft Cloud. Controles preventivos e detetives específicos são implementados para proteger o repositório secreto e a chave de disponibilidade como parte da estratégia de segurança abrangente.
O Microsoft 365 foi criado para evitar o uso indevido da chave de disponibilidade. A camada de aplicativo é o único método por meio do qual as chaves, incluindo a chave de disponibilidade, podem ser usadas para criptografar e descriptografar dados. Somente o código de serviço do Microsoft 365 tem a capacidade de interpretar e percorrer a hierarquia de chaves para atividades de criptografia e descriptografia. Existe isolamento lógico entre os locais de armazenamento de Chaves do Cliente, chaves de disponibilidade, outras chaves hierárquicas e dados do cliente. Esse isolamento atenua o risco de exposição de dados no caso de um ou mais locais serem comprometidos. Cada camada na hierarquia tem recursos internos de detecção de intrusão 24x7 para proteger dados e segredos armazenados.
Os controles de acesso são implementados para impedir o acesso não autorizado a sistemas internos, incluindo armazenamentos secretos de chave de disponibilidade. Os engenheiros da Microsoft não têm acesso direto aos repositórios de segredos da chave de disponibilidade. Para obter mais detalhes sobre controles de acesso, examine Controles de Acesso Administrativo no Microsoft 365.
Os controles técnicos impedem que o pessoal da Microsoft faça logon em contas de serviço altamente privilegiadas, o que poderia ser usado por invasores para representar os serviços da Microsoft. Por exemplo, esses controles impedem a entrada interativa.
Controles de registro em log e monitoramento de segurança são outra proteção de defesa detalhada implementada que mitiga o risco para os serviços da Microsoft e seus dados. As equipes de serviço da Microsoft implantam soluções de monitoramento ativo que geram alertas e logs de auditoria. Todas as equipes de serviço carregam seus logs em um repositório central onde os logs são agregados e processados. As ferramentas internas examinam automaticamente os registros para confirmar se os serviços estão funcionando em um estado ideal, resiliente e seguro. Atividade incomum é sinalizada para revisão adicional.
Qualquer evento de log que indique uma possível violação da Política de Segurança da Microsoft é imediatamente chamado à atenção das equipes de segurança da Microsoft. A segurança do Microsoft 365 configurou alertas para detectar tentativas de acesso a repositórios secretos de chave de disponibilidade. Alertas também serão gerados se o pessoal da Microsoft tentar entrar interativamente em contas de serviço, o que é proibido e protegido por controles de acesso. A segurança do Microsoft 365 também detecta e alertas sobre desvios do serviço Microsoft 365 de operações normais de linha de base. Os malfeitores que tentam usar indevidamente os serviços do Microsoft 365 disparariam alertas, resultando no despejo do infrator do ambiente de nuvem da Microsoft.
Usar a chave de disponibilidade para se recuperar da perda de chave
Se você perder o controle das Chaves do Cliente, a chave de disponibilidade fornecerá a capacidade de recuperar e criptografar novamente seus dados.
Procedimento de recuperação do Exchange
Se você perder o controle das Chaves do Cliente, a chave de disponibilidade fornecerá a capacidade de recuperar seus dados e colocar seus recursos do Microsoft 365 afetados novamente online. A chave de disponibilidade continua a proteger seus dados enquanto você se recupera. Em alto nível, para se recuperar totalmente da perda de chave, crie um novo DEP e mova recursos afetados para a nova política.
Para criptografar seus dados com novas Chaves do Cliente, crie novas chaves no Azure Key Vault, crie um novo DEP usando as novas Chaves do Cliente e atribua o novo DEP às caixas de correio atualmente criptografadas com o DEP anterior para o qual as chaves são perdidas ou comprometidas.
Esse processo de reencritação pode levar até 72 horas e é a duração padrão quando você altera um DEP.
Procedimento de recuperação do SharePoint e do OneDrive
Para SharePoint e OneDrive, a chave de disponibilidade nunca é usada fora do recurso de recuperação. Você deve instruir explicitamente a Microsoft a iniciar o uso da chave de disponibilidade durante um cenário de recuperação. Para iniciar o processo de recuperação, entre em contato com a Microsoft para ativar a chave de disponibilidade. Depois de ativada, a chave de disponibilidade é usada automaticamente para descriptografar seus dados, permitindo que você criptografe os dados com um DEP recém-criado associado a novas Chaves do Cliente.
Essa operação é proporcional ao número de sites em sua organização. Depois de chamar a Microsoft para usar a chave de disponibilidade, você deverá estar totalmente online em cerca de quatro horas.
Como o Exchange usa a chave de disponibilidade
Quando você cria um DEP com a Chave do Cliente, o Microsoft 365 gera uma CHAVE DEP (Chave de Política de Criptografia de Dados) associada a esse DEP. O serviço criptografa a Chave DEP três vezes: uma com cada uma das chaves do cliente e uma vez com a chave de disponibilidade. Somente as versões criptografadas da Chave DEP são armazenadas e uma chave DEP só pode ser descriptografada com as chaves do cliente ou a chave de disponibilidade. A chave DEP é usada para criptografar chaves de caixa de correio, que criptografam caixas de correio individuais.
O Microsoft 365 segue esse processo para descriptografar e fornecer dados quando os clientes estão usando o serviço:
Descriptografe a chave DEP usando a Chave do Cliente.
Use a chave DEP descriptografada para descriptografar uma chave de caixa de correio.
Use a chave de caixa de correio descriptografada para descriptografar a caixa de correio em si, permitindo que você acesse os dados na caixa de correio.
Como o SharePoint e o OneDrive usam a chave de disponibilidade
A arquitetura e a implementação do SharePoint e do OneDrive para a Chave do Cliente e a chave de disponibilidade são diferentes do Exchange.
Quando uma organização se move para chaves gerenciadas pelo cliente, o Microsoft 365 cria uma TIK (chave intermediária específica da organização). O Microsoft 365 criptografa o TIK duas vezes, uma vez com cada uma das chaves do cliente, e armazena as duas versões criptografadas do TIK. Somente as versões criptografadas do TIK são armazenadas e um TIK só pode ser descriptografado com as chaves do cliente. O TIK é então usado para criptografar chaves do site, que são usadas para criptografar chaves de blob (também chamadas chaves de partes de arquivo). Dependendo do tamanho do arquivo, o serviço pode dividir um arquivo em vários pedaços de arquivo cada um com uma chave exclusiva. Os blobs (partes de arquivo) são criptografados com as chaves de blob e armazenados no serviço de armazenamento de Blobs do Microsoft Azure.
O Microsoft 365 segue esse processo para descriptografar e fornecer arquivos ao cliente quando os clientes estiverem usando o serviço:
Descriptografe o TIK usando a Chave do Cliente.
Use o TIK descriptografado para descriptografar uma chave do site.
Use a chave de site descriptografada para descriptografar uma chave de blob.
Use a chave de blob descriptografada para descriptografar o blob.
O Microsoft 365 descriptografa um TIK emitindo duas solicitações de descriptografia para o Azure Key Vault com um pequeno deslocamento. O primeiro a concluir fornece o resultado, cancelando a outra solicitação.
Caso você perca o acesso às chaves, o Microsoft 365 também criptografa o TIK com uma chave de disponibilidade e armazena essas informações junto com os TIKs criptografados com cada Chave do Cliente. O TIK criptografado com a chave de disponibilidade é usado somente quando você chama a Microsoft para alistar o caminho de recuperação quando você perde o acesso às chaves, maliciosamente ou acidentalmente.
Por motivos de disponibilidade e escala, TIKs descriptografados são armazenados em cache em um cache de memória limitado por tempo. Duas horas antes de um cache TIK expirar, o Microsoft 365 tenta descriptografar cada TIK. Descriptografar os TIKs estende o tempo de vida do cache. Se a descriptografia TIK falhar por um período significativo de tempo, o Microsoft 365 gerará um alerta para notificar a engenharia antes da expiração do cache. O Microsoft 365 inicia a operação de recuperação somente se você chamar, o que envolve descriptografar o TIK com a chave de disponibilidade armazenada no repositório secreto da Microsoft e integrar o locatário novamente usando o TIK descriptografado e um novo conjunto de chaves do Azure Key Vault fornecidas pelo cliente.
A partir de hoje, a Customer Key está envolvida na cadeia de criptografia e descriptografia de dados de arquivo do SharePoint armazenados no repositório de blobs do Azure, mas não em itens de lista do SharePoint ou metadados armazenados no Banco de Dados SQL. O Microsoft 365 não usa a chave de disponibilidade para Exchange e SharePoint e OneDrive, além do caso descrito, que é iniciado pelo cliente. O acesso humano aos dados do cliente é protegido pelo Customer Lockbox.
Gatilhos de chave de disponibilidade
O Microsoft 365 dispara a chave de disponibilidade apenas em circunstâncias específicas. Essas circunstâncias diferem por serviço.
Gatilhos para Exchange
O Microsoft 365 lê o DEP ao qual a caixa de correio é atribuída para determinar a localização das duas Chaves do Cliente no Azure Key Vault.
O Microsoft 365 escolhe aleatoriamente uma das duas Chaves do Cliente do DEP e envia uma solicitação ao Azure Key Vault para desembrulhar a chave DEP usando a Chave do Cliente.
Se a solicitação para desembrulhar a chave DEP usando a Chave do Cliente falhar, o Microsoft 365 enviará uma segunda solicitação ao Azure Key Vault, desta vez instruindo-a a usar a chave de cliente alternativa (segunda).
Se a segunda solicitação para desembrulhar a chave DEP usando a Chave do Cliente falhar, o Microsoft 365 examinará os resultados de ambas as solicitações.
Se o exame determinar que as solicitações falharam ao retornar um ERRO do sistema:
O Microsoft 365 dispara a chave de disponibilidade para descriptografar a chave DEP.
Em seguida, o Microsoft 365 usa a chave DEP para descriptografar a chave da caixa de correio e concluir a solicitação do usuário.
Nesse caso, o Azure Key Vault não pode responder ou inacessível devido a um ERRO transitório.
Se o exame determinar que as solicitações falharam ao retornar o ACCESS DENIED:
Esse retorno significa que ações deliberadas, inadvertidas ou mal-intencionadas foram tomadas para tornar as chaves do cliente indisponíveis (por exemplo, durante o processo de limpeza de dados como parte da saída do serviço).
Nesse caso, a chave de disponibilidade é apenas para ações do sistema e não para ações do usuário, a solicitação do usuário falha e o usuário recebe uma mensagem de erro.
Importante
O código de serviço do Microsoft 365 sempre tem um token de logon válido para raciocínio sobre dados do cliente para fornecer serviços de nuvem de adição de valor. Portanto, até que a chave de disponibilidade tenha sido excluída, ela pode ser usada como um fallback para ações iniciadas pelo Exchange, como criação de índice de pesquisa ou movimentação de caixas de correio. Isso se aplica a erros transitórios e solicitações ACCESS DENIED ao Azure Key Vault.
Gatilhos para SharePoint e OneDrive
Para o OneDrive amd do SharePoint, a chave de disponibilidade nunca é usada fora do recurso de recuperação e os clientes devem instruir explicitamente a Microsoft a iniciar o uso da chave de disponibilidade durante um cenário de recuperação.
Auditar logs e a chave de disponibilidade
Sistemas automatizados no Microsoft 365 processam todos os dados à medida que ele flui pelo sistema para fornecer serviços de nuvem, por exemplo, antivírus, descoberta eletrônica, prevenção de perda de dados e indexação de dados. O Microsoft 365 não gera logs visíveis para o cliente para essa atividade. Além disso, o pessoal da Microsoft não acessa seus dados como parte dessas operações normais do sistema.
Registro em log da chave de disponibilidade do Exchange
Quando o Exchange acessa a chave de disponibilidade para fornecer serviço, o Microsoft 365 publica logs visíveis ao cliente acessíveis no portal de Segurança e Conformidade. Um registro de log de auditoria para a operação de chave de disponibilidade é gerado sempre que o serviço usa a chave de disponibilidade. Um novo tipo de registro chamado "Customer Key Service Encryption" com o tipo de atividade "Fallback to Availability Key" permite que os administradores filtrem os resultados da pesquisa do Log de Auditoria Unificada para exibir registros de chave de disponibilidade.
Os registros de log incluem atributos como data, hora, atividade, ID da organização e ID da política de criptografia de dados. O registro está disponível como parte dos Logs de Auditoria Unificada e está acessível na guia Pesquisa de Logs de Auditoria portal de conformidade do Microsoft Purview.
Os registros de chave de disponibilidade do Exchange usam o esquema comum atividade de gerenciamento do Microsoft 365 com parâmetros personalizados adicionados: ID da política, ID da versão da chave de escopo e ID da solicitação.
Registro em log da chave de disponibilidade do SharePoint e do OneDrive
O log da chave de disponibilidade ainda não está disponível para esses serviços. Para SharePoint e OneDrive, a Microsoft só ativa a chave de disponibilidade para fins de recuperação quando instruída por você. Como resultado, você já conhece todos os eventos em que a chave de disponibilidade é usada para esses serviços.
Chave de disponibilidade na hierarquia chave do cliente
O Microsoft 365 usa a chave de disponibilidade para envolver a camada de chaves mais baixa na hierarquia de chave estabelecida para criptografia de serviço da Chave do Cliente. Existem hierarquias de chave diferentes entre os serviços. Algoritmos de chave também diferem entre chaves de disponibilidade e outras chaves na hierarquia de cada serviço aplicável. Os algoritmos de chave de disponibilidade usados pelos diferentes serviços são os seguintes:
As chaves de disponibilidade do Exchange usam o AES-256.
As chaves de disponibilidade do SharePoint e do OneDrive usam RSA-2048.
Criptografia de criptografia usada para criptografar chaves para o Exchange
Criptografia de criptografia usada para criptografar chaves para o SharePoint
