Atualizado em: 21 de julho de 2022
Visão geral
Veja o que discutiremos nesta publicação técnica
O que é criptografia?
A criptografia é usada principalmente para proteger o conteúdo de uma mensagem, de modo que somente o destinatário pretendido possa lê-la. Ela se dá por meio da substituição do conteúdo por dados irreconhecíveis, que podem ser compreendidos somente pelo destinatário pretendido. É assim que a criptografia se tornou um método para proteger os dados daqueles que podem querer roubá-los.
Criptografia é a ação de alterar os dados com um processo de codificação especial para que eles fiquem irreconhecíveis (criptografados). Em seguida, você pode aplicar um processo especial de decodificação e receberá os dados originais de volta (descriptografados). Ao manter o processo de decodificação em segredo, ninguém mais pode recuperar os dados originais dos dados criptografados.
O processo de codificação segue um algoritmo de criptografia, como o AES 256, que é público. No entanto, o processo em si depende da chave, que é usada para criptografar os dados e decodificá-los para recuperar os dados originais.
A chave é mantida em segredo. Sem ela, qualquer pessoa que consiga acessar os dados verá apenas um "texto cifrado", que não terá significado real. Desse modo, os dados ficam protegidos.
Por que criptografamos seus dados
A camada final de proteção: embora uma estratégia de segurança abrangente ajude uma empresa a proteger os dados contra hackers, a criptografia assume a posição final contra tentativas de roubar seus dados. Ela finaliza a proteção garantindo que seus dados não sejam danificados nem roubados no caso de uma violação de segurança.
Privacidade: a criptografia é uma garantia para a preocupação com a privacidade na Internet. A criptografia ajuda a proteger a privacidade transformando informações pessoais em dados que poderão ser lidos apenas pelas partes que precisam deles. Quando você interage conosco e armazena seus dados em nossos servidores, a criptografia nos ajuda a garantir que você tenha privacidade absoluta.
O que queremos dizer com "dados"
Existem dois tipos de dados com os quais lidamos:
- Dados do cliente: Os dados que você armazena conosco por meio do Qntrl. Normalmente, esses dados são manipulados pelo Qntrl por meio de uma conta do cliente que pode ser identificada em nosso banco de dados de Gerenciamento de identidade e acesso (IAM). Dependendo do nível de confidencialidade dos dados e dos requisitos do usuário, alguns dados do cliente são criptografados, embora alguns não sejam. Dados confidenciais são aqueles que podem causar danos a indivíduos ou organizações quando expostos.
- Dados derivados: os dados que não são fornecidos diretamente por você, mas são derivados de seus dados. Por exemplo, tokens de autenticação, IDs exclusivos, URLs e relatórios etc. são armazenados conosco. Dependendo do nível de confidencialidade, alguns dados derivados são criptografados, enquanto outros não são.
Nas seções subsequentes, "dados" refere-se aos dados que são criptografados.
Criptografia em trânsito
Quando você usa o Qntrl, seus dados na Internet passam do seu navegador para o nosso data center ou outros terceiros (ao usar integrações de terceiros). A criptografia de dados em trânsito protege seus dados contra ataques "man-in-the-middle".
Há dois cenários em que os dados em trânsito são criptografados:
- Quando os dados são transferidos do seu navegador para nossos servidores.
- Quando os dados dão transferidos do nosso servidor para servidores que não são do Qntrl (de terceiros)
Entre você e o Qntrl
O Qntrl estabeleceu políticas rígidas para adaptar o Transport Layer Security (TLS) a todas as suas conexões. O TLS garante uma conexão segura entre você e os servidores do Qntrl, permitindo a autenticação de ambas as partes envolvidas na conexão e a criptografia de dados transferidos. O protocolo TLS garante que nenhum terceiro pode interceptar ou adulterar a comunicação entre você e o Qntrl.
O Qntrl estabeleceu políticas rígidas para adaptar o Transport Layer Security (TLS) a todas as suas conexões. O TLS garante uma conexão segura entre você e os servidores do Qntrl, permitindo a autenticação de ambas as partes envolvidas na conexão e a criptografia de dados transferidos. O protocolo TLS garante que nenhum terceiro pode interceptar ou adulterar a comunicação entre você e o Qntrl.
Entre o Qntrl e terceiros
Seguimos o protocolo https durante nossa comunicação com terceiros. Para transações que envolvem dados confidenciais e casos de uso, usamos criptografia assimétrica, que utiliza um sistema de chaves públicas e privadas para criptografar e descriptografar dados.
Para esse método, geramos um par de chaves públicas e privadas em nosso Sistema de gerenciamento de chaves (KMS), que cria, armazena e gerencia chaves em todos os serviços. Criptografamos esses pares usando uma chave mestre, e os pares de chaves criptografadas são armazenados no próprio KMS. A chave mestre é armazenada em um servidor separado.
Disponibilizamos chaves públicas a terceiros através dos certificados enquanto armazenamos a chave privada no KMS e, após a autenticação, os dados criptografados são descriptografados no KMS.
Criptografia em repouso
Há dois níveis principais de criptografia:
- Criptografia da camada de aplicação
- Criptografia completa de disco baseada em hardware
A estratégia para criptografar dados no nível do aplicativo depende de onde e como os dados são armazenados:
- Banco de dados (DB) - armazenado como tabelas
- Sistema de arquivos distribuídos (DFS) - armazenado como arquivos
- Criptografia URL
- Backup
- Registros
- Cache
A imagem abaixo descreve uma visão ampla de nossa estratégia de criptografia:
Criptografia do nível do aplicativo
Sempre que você usa o Qntrl, isso envolve dados: os dados que você fornecer e os dados que armazenamos em seu nome como parte do serviço. Os dados podem ser recebidos como um arquivo ou como campos de dados. Cada uma dessas categorias é tratada de forma diferente em relação à forma como é criptografada.
Esta seção lida com a criptografia em repouso no nível do aplicativo.
Criptografia de banco de dados
Os dados confidenciais inseridos no aplicativo ou os dados de serviço são armazenados em nosso banco de dados como tabelas. Os dados nessas tabelas são criptografados de acordo com o padrão AES 256 com o modo AES/CBC/PKCS5Padding. Os dados criptografados em repouso variam de acordo com os serviços que você escolher. Saiba mais sobre os dados que criptografamos em nossos serviços. No entanto, dependendo da sensibilidade do campo de dados e da escolha e do requisito do usuário, o nível de criptografia varia.
Há dois níveis de criptografia de banco de dados:
- De acordo com o nível de confidencialidade dos dados
- De acordo com a funcionalidade de pesquisa
Observação: a partir de agora, vamos nos referir a um cliente ou a uma organização que usa o Qntrl e tem um número limitado de usuários como uma “Organização”.
De acordo com o nível de confidencialidade dos dados
Nível 1: este é o nível padrão de criptografia que fazemos para dados de todas as organizações. Neste nível, nosso KMS cria uma chave para cada organização. Os dados correspondentes a essa organização serão criptografados usando essa chave. A chave é criptografada usando uma chave mestre, e a chave criptografada é armazenada em um servidor separado.
Nível 2: fazemos esse nível de criptografia para Informações de identificação pessoal (PII). Esta categoria inclui campos como números de conta bancária, números de identificação e dados biométricos.
Neste nível, o KMS gera uma chave exclusiva para cada coluna na tabela. Todos os dados em uma coluna específica serão criptografados usando a chave gerada para essa coluna. Essas chaves são novamente criptografadas usando uma chave mestre e armazenadas em um servidor separado.
De acordo com a funcionalidade de pesquisa
Um Vetor de Inicialização (VI) é um valor aleatório que inicia o processo de criptografia. Esse valor aleatório garante que cada bloco/unidade de dados criptografe de forma diferente. Isso também significa que criptografar os mesmos dados duas vezes gera diferentes textos cifrados.
Por que o VI é importante?
Se você não tinha VI e usou o modo Encadeamento de blocos de cifra (CBC) apenas com sua chave, dois conjuntos de dados que começam com dados idênticos produzirão primeiros blocos idênticos. Os VIs impossibilitam que a criptografia de dois dados distintos crie os mesmos pares de entrada/saída (no nível de cifra de blocos e usando a mesma chave), mesmo quando um tem alguma relação com o outro (incluindo, mas longe de limitado a, começando com o mesmo primeiro bloco).
Quando cada solicitação de criptografia habilita o uso de um VI aleatório, o primeiro bloco é diferente. O invasor não pode deduzir nada que possa ajudá-lo a decodificar os dados criptografados.
Criptografia de preservação de igualdade: este é o nível padrão de criptografia para todas as tabelas. Neste nível, toda a tabela de dados obtém um VI. Isso significa que todo o bloco de texto cifrado pode ser usado em uma consulta de pesquisa dentro de uma tabela. Como o VI é o mesmo para todos os dados dentro da tabela, uma pesquisa irá buscar os dados.
Criptografia padrão: neste nível, cada entrada de dados tem um VI. Mesmo que você criptografe a tabela inteira com uma chave, cada entrada de dados criptografados produzirá um texto cifrado exclusivo. Além disso, como o VI é aleatório e exclusivo para cada dado, uma consulta de pesquisa não buscará os dados. Esta é uma opção mais segura do que a variação de "preservação da igualdade".
Em quais situações essas variações serão usadas?
A decisão de escolher uma variação específica geralmente depende do requisito. Se os dados precisarem receber o mais alto nível de proteção, iremos para o Nível 2 com a criptografia padrão. No entanto, se nem todos os campos precisarem de proteção máxima, mas os selecionados forem, a proteção Nível 2 com a versão padrão seria suficiente.
Porém, nem sempre se trata apenas de proteção. Às vezes, os usuários podem querer pesquisar e buscar um campo como "ID de e-mail" para atender às suas necessidades. Nesse caso, uma opção padrão não faria sentido, e buscaremos a variação de "Preservação de igualdade".
Criptografia de arquivo ou DFS
Os arquivos que você cria ou anexa são salvos em nosso sistema de arquivos distribuídos (DFS). Os arquivos criptografados em repouso variam de acordo com os serviços que você escolher. Saiba mais sobre os dados que criptografamos em nossos serviços.
A criptografia é baseada no algoritmo AES 256 padrão, mas o modo de criptografia é CTR ou GCM. No AES 256, o texto sem formatação que precisa ser criptografado é dividido em pacotes de dados ou blocos. Como estamos criptografando o conteúdo dos arquivos aqui, o algoritmo deve garantir que a criptografia de cada bloco seja independente de outro, para que o invasor não obtenha nenhuma informação sobre o arquivo, mesmo que as cifras do bloco estejam comprometidas. Para esse requisito, o modo CTR é ideal.
Assim como na criptografia de banco de dados, a criptografia de arquivos também tem dois níveis:
Nível 1: neste nível, cada organização recebe uma chave. Cada arquivo dessa organização é criptografado usando essa chave, mas com um VI aleatório exclusivo que é armazenado juntamente com o arquivo. Essa chave é novamente criptografada usando uma chave mestre e armazenada no KMS.
Nível 2: neste nível, cada arquivo é fornecido com uma chave exclusiva e é criptografado usando essa chave. Cada chave usada para criptografar um arquivo é criptografada novamente usando uma chave mestra, e a chave criptografada é armazenada junto com o arquivo no DFS. Essa chave mestra é exclusiva para o serviço ou aplicativo e é armazenada e gerenciada no KMS.
Criptografia URL
Os links de convite ou qualquer outra comunicação entre nós pode envolver a transmissão de dados confidenciais nos URLs. Para proteger essa comunicação, partes de um URL são criptografadas. Se houver algo que possa ser identificado no URL, por exemplo, o ID de um documento, essa peça será criptografada.
Essa criptografia tem dois níveis: uma chave por organização ou uma chave por URL. Mais uma vez, isso é decidido pelo nível de confidencialidade dos dados no URL.
Criptografia de backup
Nós criamos backups com base em duas programações: diária e semanal. Os servidores de backup são equipados com o mesmo nível de proteção dos servidores principais. Todos os dados que tomamos como backup serão criptografados em repouso. Usamos o algoritmo AES 256 para criptografia e armazenamos as chaves em um servidor separado. Também temos Data Centers (DC) redundantes que garantem alta disponibilidade. Esses DCs também têm uma cópia de seus dados criptografados, sendo copiados como o DC principal.
Criptografia de logs
O Qntrl Logs usa o Sistema de arquivos distribuídos da Hadoop (HDFS) para armazenar e gerenciar logs. Usamos a tecnologia de criptografia da Hadoop Inc para criptografar os dados enquanto o gerenciamento de chaves é controlado pelo nosso KMS.
Criptografia do cache
Usamos o software de código-fonte aberto Redis para armazenar e gerenciar os dados de cache. O cache contém dados que são usados repetidamente na operação do serviço e precisam ser armazenados por um determinado período. Às vezes, os dados podem ser armazenados em cache para melhorar o serviço ou para solucionar problemas. Se algum dado contiver informações pessoais confidenciais, escolheremos criptografá-las.
Gerenciamento de chaves
Nosso Serviço de gerenciamento de chaves (KMS) interno cria, armazena e gerencia chaves em todos os serviços. Possuímos e mantemos as chaves usando o KMS. No momento, não temos a provisão para criptografar dados com chaves de propriedade do cliente.
Há diferentes tipos de chaves usadas em diferentes estágios de criptografia:
Chave de criptografia de dados (DEK): a chave usada para converter os dados de texto sem formatação em texto cifrado ou a chave usada para criptografar os dados.
Chave de criptografia de chave (KEK): a chave usada para criptografar a DEK e é específica de serviço. Ela fornece uma camada extra de segurança.
Chave mestra: a chave usada para criptografar a KEK. Essa chave é armazenada em um servidor isolado para segurança.
Como o KMS funciona?
Todos os tipos de criptografia estão de acordo com o algoritmo AES 256. De acordo com esse algoritmo, os dados são tratados como "blocos" que devem ser criptografados. Independentemente de ser um campo no banco de dados ou um arquivo no DFS, a criptografia começa quando um bloco de dados é criptografado usando uma DEK.
Essa DEK é criptografada ainda mais, com uma KEK. A KEK é novamente criptografada usando uma chave mestre que é armazenada em um servidor separado. Aqui estão os elementos que precisam ser gerenciados:
- Dados criptografados
- DEKs
- DEKs criptografadas
- KEKs
- KEKs criptografadas
- Chave mestra
O KMS gerencia esses elementos da seguinte maneira:
Iniciar solicitações
Usuário autenticado para o Zoho Service e solicita dados
Criptografia em trânsito
Criptografia baseada em TLS
Front-end do aplicativo
Direciona o tráfego para servidores de aplicativos
Servidor de aplicativos
Inicia o processo de criptografia
Serviço de gerenciamento de chaves
Gera/recupera a chave de criptografia de dados (DEK)
Servidor mestre
Gera/recupera a criptografia de chave (KEK)
Banco de dados KMS
Armazena DEK criptografada
Serviço de gerenciamento de chaves
Retorna DEK para criptografia
Criptografar agente
Criptografa dados usando DEK
Armazenamento
Armazena dados criptografados
Como as chaves são geradas?
O KMS gera chaves de 256 bits em conformidade com o protocolo AES 256, juntamente com um vetor de inicialização (VI). Como já discutimos, o VI garante que o primeiro bloco de dados criptografados seja aleatório. É por isso que o mesmo texto sem formatação é criptografado em diferentes textos cifrados com a ajuda dos VIs.
O KMS gera essas chaves e o VI usando uma biblioteca segura Java e um gerador de números aleatórios seguro.
Onde as chaves são armazenadas?
As DEKs geradas no KMS são criptografadas com o uso de uma KEK. Isso fornece uma camada adicional de segurança. As DEKs criptografadas são armazenadas no banco de dados do KMS.
Separamos as chaves fisicamente (armazenamos em locais diferentes), desse modo, um invasor que obtém uma chave não pode obter a retenção de outras chaves relacionadas também. Criptografamos a KEK usando uma chave mestre e a armazenamos em um servidor separado.
Para o Zoho Workdrive, fornecemos uma camada adicional de segurança para os documentos armazenados em repouso.
Um invasor não conseguirá comprometer os dados simplesmente segmentando o KMS sozinho.
As chaves são seguras?
Separação física: conforme discutido anteriormente, a chave mestra permanece em um servidor fisicamente separado e seguro. Isso dificulta que um invasor comprometa DEKs e KEKs.
Controle de acesso: o controle de acesso nos ajuda a evitar o uso indevido e o acesso sem precedentes às chaves. Uma Lista de controle de acesso (ACL) permite que somente os serviços selecionados acessem as chaves selecionadas. Sempre que uma chave for acessada, isso será feito por meio da autenticação, e o processo é gravado em log. Auditorias regulares desses logs ajudam a monitorar o processo.
O acesso a servidores de gerenciamento de chaves é restrito, por padrão, e permitido somente a pessoal específico da Zoho Corp. Qualquer outro acesso gera um tíquete e é permitido somente após a aprovação da gerência.
Rotação de chaves: usamos um sistema de rotação de chaves no qual alteramos a chave mestra raiz periodicamente, o que garante segurança adicional. Quando uma nova chave mestre e um VI são gerados, isso significa que as chaves no banco de dados também devem ser revisadas. Portanto, todas as chaves no banco de dados são primeiro pesquisadas e descriptografadas usando a chave mestre antiga e criptografadas novamente usando a nova chave mestre, sendo atualizadas no banco de dados.
O fornecimento para acionar manualmente a rotação das chaves está disponível, para lidar com situações críticas que possam surgir.
Disponibilidade de chaves: se o armazenamento primário de discos em um data center (DC) falhar, haverá um auxiliar e um auxiliar secundário para backup, que conterá os mesmos dados que o DC principal. O auxiliar e o auxiliar secundário têm as DEKs criptografadas, como o principal.
Quais dados criptografamos em nossos serviços?
As opções e os níveis de criptografia para uma entrada de dados específica são decididos por você, por nós ou pelo consenso de ambos.
Encontre os dados criptografados pelo Qntrl abaixo.
Campos criptografados no Qntrl
- Todos os endereços de e-mail de usuário, da equipe e externos
- URLs, parâmetros e cabeçalhos de webhook
- Tokens de autenticação usados para integração
- Arquivos anexados em cartões e comentários
- Dados de campo personalizados criptografados
Saiba como criptografar dados de campos personalizados aqui.
Criptografia de disco completo
Empregamos unidades de autocriptografia (SEDs) para dar suporte à criptografia completa de disco baseada em hardware.
O SED é uma unidade de disco rígido (HDD) ou unidade de estado sólido (SSD) com um circuito de criptografia integrado na unidade. A autocriptografia significa simplesmente que todos os dados gravados na mídia de armazenamento são criptografados pela unidade de disco antes de serem gravados e descriptografados pela unidade de disco quando são lidos.
As unidades SED estão em conformidade com FIPS 140-2 ou unidades compatíveis com TCG. O algoritmo de criptografia configurado para os SEDs é o algoritmo AES. A chave usada para criptografar e descriptografar é a de comprimento 256.
Há dois tipos de chaves usadas em SEDs, a chave de criptografia de dados (DEK) e a chave de autenticação (AK).
Chave de criptografia de dados: esta chave é usada para criptografar/descriptografar os dados na unidade. Essa chave é gerada por um fornecedor durante o processo de fabricação. Quando obtemos novos servidores com unidades SED, geramos a chave por motivos de segurança.
Chave de autenticação: esta chave criptografará DEK e será usada para bloquear e desbloquear a unidade. As chaves de autenticação são geradas com uma política forte e armazenadas em nosso Sistema de gerenciamento de chaves. A mesma chave será transferida para cada servidor de forma segura quando habilitarmos a criptografia nos servidores. Estamos usando o gerenciamento de chaves locais (LKM) para gerenciar a chave de autenticação.
Observação: atualmente, a criptografia de disco completo baseada em hardware é aplicável por padrão para o Qntrl nos data centers da Europa (UE), Austrália (AU) e Japão (JP).
Conclusão
Criptografamos dados confidenciais de clientes quando eles são armazenados, quando eles estão em trânsito pela Internet e quando estão viajando entre nossos DCs. No entanto, a criptografia é apenas uma parte de nossa estratégia de segurança. Inovamos constantemente e nos esforçamos para melhorar a proteção de dados implementando os mais recentes protocolos e tecnologia. Para saber mais sobre nossa estratégia de segurança completa, acesse https://www.zoho.com/security.html