Conceitos de criptografia
Fluxo de alto nível
Você controla uma chave mestra na sua nuvem que a OpenAI nunca vê.
Sua chave mestra é usada para criptografar as chaves de criptografia de dados (DEKs) utilizadas pela OpenAI.
A OpenAI usa as DEKs para criptografar seus dados em repouso. Uma DEK é criptografada pela sua chave mestra, gerando uma eDEK (DEK criptografada), que é armazenada juntamente com seus dados.
Para ler os dados, a OpenAI utiliza o eDEK, solicita ao seu KMS que o descriptografe em um DEK e, em seguida, descriptografa seus dados.
Como funciona a criptografia EKM?
Consulte nosso artigo para obter informações detalhadas: Visão geral do OpenAI Enterprise Key Management (EKM)
A OpenAI armazena meus DEKs?
Não - armazenamos as DEKs criptografadas (eDEKs), que são geradas pelo seu KMS. Para descriptografar os dados, solicitamos ao seu KMS que descriptografe o eDEK de volta para o DEK.
O OpenAI armazena em cache meus DEKs?
Sim, apenas na memória. Isso visa melhorar o desempenho e evitar sobrecarregar o seu KMS a cada solicitação de criptografia/descriptografia de dados. As DEKs nunca são gravadas no armazenamento.
Permissões na nuvem
Que permissões a OpenAI terá no meu KMS?
Somente as permissões que você nos conceder por meio da política que você definir. Precisamos, no mínimo, de operações de criptografia/descriptografia. Por favor, crie também uma nova chave no seu KMS na nuvem para a OpenAI, em vez de reutilizar quaisquer chaves existentes que tenham finalidades de produção.
Quando a OpenAI obtém permissão para acessar meu KMS?
Todas estas etapas devem ter sido concluídas: 1. você reconheceu a identidade da OpenAI (por meio de política de confiança, identidade de carga de trabalho etc., dependendo do provedor de nuvem), 2. você criou uma política para acessar o KMS e 3. você atribuiu à identidade da OpenAI a permissão para acessar a política. Se você criar o KMS sem seguir todos esses passos, a OpenAI não terá acesso.
Preciso armazenar minha chave mestra na nuvem?
Não, você decide como gerenciar sua chave mestra. Você pode optar por uma solução gerenciada na nuvem ou por uma solução externa onde sua chave é armazenada separadamente. A OpenAI só precisa chamar as operações de criptografia/descriptografia no seu KMS - como a chave mestra realmente realiza a criptografia/descriptografia é um detalhe de implementação que nos é opaco.
Ciclo de vida da chave
Rotação DEK/eDEK (Controlada pela OpenAI)
Com que frequência os DEKs/eDEKs são rotacionados?
A cada 24 horas no caminho de criptografia (solicitando um par de chaves DEK/eDEK)
A cada hora para o caminho da chave de descriptografia (DEK -> eDEK)
Preciso fazer alguma coisa quando o DEK mudar?
Não - a rotação DEK/eDEK é feita dentro da OpenAI. Enquanto sua chave mestra permanecer válida, quaisquer eDEKs criptografados por ela poderão continuar sendo descriptografados para a DEK, que será então usada para descriptografar seus dados.
Rotação e revogação da chave mestra (controladas por você)
Com que frequência ocorrem a rotação e a revogação de chaves?
Isso é determinado por você, já que a OpenAI não tem visibilidade da sua chave mestra.
Qual a diferença entre rotação de chaves e revogação de chaves?
A revogação de chaves remove o acesso a dados criptografados com chaves antigas. A rotação de chaves criptografa os dados usando uma nova chave, mas mantém o acesso de leitura aos dados antigos.
O que acontece se eu revogar minha chave mestra?
Se uma chave for revogada ou as permissões forem removidas, o espaço de trabalho eventualmente deixará de funcionar assim que as chaves em cache expirarem. Nesse ponto, a OpenAI não consegue mais descriptografar dados armazenados nem criptografar novos dados. Na prática, os dados são "triturados".
Com que rapidez a revogação entra em vigor?
A OpenAI armazena DEKs em cache na memória para melhorar o desempenho e a resiliência.OpenAI A revogação normalmente entra em vigor dentro de uma hora, após as chaves em cache expirarem e a revalidação falhar.
É possível testar a revogação de forma segura?
Não é recomendável testar a revogação em um ambiente de produção, pois isso tornará os dados existentes permanentemente inacessíveis. No entanto, os clientes podem (e devem) testar a revogação em um ambiente de sandbox para verificar o comportamento correto e validar suas suposições de confiança.
Se uma chave for revogada permanentemente, o espaço de trabalho poderá ser recuperado anexando uma nova chave?
Não. Uma vez perdida a chave, os dados tornam-se irrecuperáveis por projeto. A única solução é criar um novo espaço de trabalho.
O que devemos fazer se um espaço de trabalho se tornar inacessível devido a alterações de teclas?
A solução esperada é a criação de um novo espaço de trabalho. A atualização do KMS não recuperará os dados existentes.
Qual é o plano de contingência caso decidamos parar de usar o CMEK?
Atualmente, não existe um plano de recuo. Após a criação de um espaço de trabalho com o CMEK, todos os dados associados são criptografados usando chaves gerenciadas pelo cliente e não podem ser acessados sem elas. A única maneira de interromper o uso do CMEK é criar um novo espaço de trabalho — os dados criptografados existentes permanecerão permanentemente inacessíveis.
O que acontece quando eu giro minha chave mestra?
Será gerado um novo material criptográfico para criptografia, de modo que as novas solicitações de criptografia usarão a nova chave. No entanto, o identificador KMS (ARN ou nome da chave) permanece o mesmo e os dados antigos ainda podem ser descriptografados. Muitos provedores de nuvem oferecem rotação automática de chaves (AWS, GCP, Azure).
A OpenAI recriptografa dados antigos quando você rotaciona sua chave mestra?
Não. O novo material criptográfico será usado apenas para criptografar novos dados.
Quanto tempo leva para que uma rotação ou revogação de chave entre em vigor?
1 hora. Isso ocorre porque os DEKs/eDEKs são armazenados em cache na memória e nós revalidamos essas entradas com o seu KMS a cada hora.
Alterando o identificador KMS
Alterar o identificador KMS é uma revogação ou uma rotação de chaves?
Revogação da chave. Uma única chave não consegue descriptografar dados criptografados por outra chave.
A OpenAI pode me ajudar a trocar meu identificador KMS para um espaço de trabalho do ChatGPT?
Se você confirmar que a intenção é revogar sua chave, podemos ajudá-lo a fazer isso para um espaço de trabalho do ChatGPT. Observe que, ao atualizar o ARN do KMS, os dados mais antigos permanecerão inacessíveis, resultando em uma mistura de dados acessíveis e inacessíveis após a alteração.
A OpenAI pode me ajudar a alterar meu identificador KMS para um projeto de API?
Se você estiver usando a API, ela facilita o arquivamento e a criação de novos projetos. Portanto, em vez disso, arquive o projeto cujos dados não estão acessíveis, registre uma nova configuração EKM com a OpenAI e crie um novo projeto de API com a nova chave KMS.
E se eu quiser alterar meu identificador KMS regularmente por conta própria?
Isso não é recomendado, pois provavelmente você não deseja revogar sua chave regularmente. No entanto, você ainda pode fazer isso se usar um provedor de nuvem que suporte um alias de chave KMS (exemplo da AWS). Você pode registrar esse alias de chave KMS com a OpenAI e, em seguida, no seu provedor de nuvem, poderá substituir o identificador KMS subjacente apontado pelo alias a qualquer momento para revogar a chave.
Comportamento Beta vs. Comportamento GA
Existem riscos conhecidos ou alterações no nível do sistema ao usar a versão beta da criptografia em produção?
O ambiente beta é funcionalmente equivalente ao ambiente GA, e não são esperadas etapas de migração. O principal risco é que alguns recursos de casos extremos podem ainda não suportar conteúdo criptografado devido a caminhos de código incompletos. Esses casos são raros e estão sendo ativamente resolvidos. Os dados são totalmente criptografados e protegidos, independentemente desses problemas potenciais.
Haverá alguma etapa de migração da versão beta para a versão GA?
Não. Os espaços de trabalho que utilizam a versão beta da criptografia serão automaticamente compatíveis com a versão GA, sem necessidade de ação do usuário.
Detalhes técnicos adicionais
Criptografia de envelope e permissões
Precisamos conceder permissões GenerateDataKey à OpenAI para o EKM?
Não. A OpenAI requer apenas permissões de criptografia e descriptografia na sua chave KMS. A permissão GenerateDataKey não é necessária para a integração com o EKM.
A OpenAI utiliza criptografia de envelope para dados de clientes?
Sim. A OpenAI usa um modelo de criptografia de envelope:
KMS do cliente: Gerencia as chaves de criptografia (KEKs). A OpenAI nunca vê nem armazena os KEKs.
Infraestrutura OpenAI: Gera e gerencia chaves de criptografia de dados (DEKs). Cada DEK é criptografado (encapsulado) com seu KEK antes do armazenamento.
Fluxo de dados:
Os dados do cliente são criptografados com uma DEK.
Essa DEK é criptografada com sua KEK, produzindo uma eDEK.
O eDEK é armazenado junto com os dados criptografados.
Para descriptografar os dados, a OpenAI solicita ao seu KMS que descriptografe o eDEK, recupera o DEK e descriptografa o conteúdo.
Por que a OpenAI escolheu esse modelo em vez de deixar o KMS gerenciar tanto os KEKs quanto os DEKs?
Existem duas abordagens comuns para criptografia de envelope:
KEKs e DEKs gerenciados pelo KMS:
Vantagens: Implementação mais simples, sem necessidade de manter infraestrutura de criptografia.
Desvantagens: Cada solicitação de criptografia/descriptografia atinge o KMS, aumentando a latência, o custo e introduzindo um ponto único de falha.
KEKs gerenciados pelo KMS / DEKs gerenciados pela OpenAI (Nossa abordagem):
Vantagens: Latência e custo significativamente menores, melhor escalabilidade e confiabilidade, e operação contínua durante interrupções parciais do KMS (até o TTL do cache DEK).
Contras: Implementação um pouco mais complexa por parte da OpenAI.
Esse design permite que a OpenAI ofereça fortes garantias de segurança, minimizando o risco operacional e o custo para os clientes.
Com que frequência os DEKs são rotacionados?
Cada DEK é rotacionado aproximadamente a cada 60 minutos. Isso proporciona isolamento temporal — mesmo que uma DEK fosse comprometida de alguma forma, o impacto ficaria limitado aos dados criptografados dentro desse período de uma hora.
Volume de solicitações e observabilidade do KMS
Observamos um número muito menor de solicitações KMS do que o número de mensagens de usuários. Esses números devem coincidir?
Não, elas não terão correlação direta.
Como a OpenAI armazena DEKs em cache na memória por motivos de desempenho, as chamadas KMS são feitas apenas quando uma DEK precisa ser descriptografada — e não em todas as operações de criptografia ou descriptografia. Como resultado, você pode esperar:
Menos solicitações KMS do que interações do usuário.
Picos ocasionais ocorrem quando os DEKs em cache expiram (aproximadamente a cada hora) ou quando dados criptografados mais antigos precisam ser acessados.
Chamadas adicionais são necessárias ao recuperar dados históricos, como quando um usuário continua uma conversa longa e DEKs mais antigos precisam ser carregados.
O número exato de solicitações KMS depende do estado do cache, do comportamento do usuário, dos padrões de acesso a dados e da duração da conversa e, portanto, não terá correlação direta com o volume de mensagens.