Conceitos de encriptação
Fluxo de alto nível
Controla uma chave mestra na sua cloud que a OpenAI nunca vê
A sua chave mestra é usada para encriptar chaves de encriptação de dados (DEKs) usadas pela OpenAI
A OpenAI usa as DEKs para encriptar os seus dados em repouso. Uma DEK é encriptada pela sua chave mestra, gerando uma eDEK (DEK encriptada), que é armazenada juntamente com os seus dados
Para ler os dados, a OpenAI pega na eDEK, pede ao seu KMS que a desencripte para uma DEK e, em seguida, desencripta os seus dados
Como funciona a encriptação EKM?
Consulte o nosso artigo para obter informações detalhadas: Descrição geral do OpenAI Enterprise Key Management (EKM)
A OpenAI armazena as minhas DEKs?
Não — armazenamos as DEKs encriptadas (eDEKs), que são geradas pelo seu KMS. Para desencriptar os dados, pedimos ao seu KMS que desencripte a eDEK de volta para a DEK.
A OpenAI mantém as minhas DEKs em cache?
Sim — apenas na memória. Isto é feito por motivos de desempenho, para evitar aceder ao seu KMS em todos os pedidos de encriptação/desencriptação de dados. As DEKs nunca são escritas em armazenamento.
Permissões na cloud
Que permissões terá a OpenAI no meu KMS?
Apenas as permissões que nos conceder através da política que definir. Só precisamos, no mínimo, das operações Encrypt/Decrypt. Crie também uma nova chave no seu KMS na cloud para a OpenAI, em vez de reutilizar chaves existentes que tenham fins de produção.
Quando é que a OpenAI obtém permissões para aceder ao meu KMS?
Todos estes passos têm de ter sido realizados:
Reconheceu a identidade da OpenAI (através de uma política de confiança, identidade de carga de trabalho, etc., dependendo do fornecedor de cloud).
Criou uma política para aceder ao KMS.
Atribuiu à identidade da OpenAI a permissão para aceder à política.
Se apenas criar o KMS sem realizar todos estes passos, a OpenAI não terá acesso.
Tenho de armazenar a minha chave mestra na minha cloud?
Não — cabe-lhe a si decidir como gerir a sua chave mestra. Pode ter uma solução gerida na cloud ou uma solução externa, em que a sua chave é armazenada separadamente. A OpenAI só precisa de chamar operações de encriptação/desencriptação no seu KMS; a forma como a chave mestra realiza efetivamente essas operações é um detalhe de implementação que nos é opaco.
Ciclo de vida das chaves
Rotação de DEK/eDEK (controlada pela OpenAI)
Com que frequência são rodadas as DEKs/eDEKs?
A cada 24 horas no caminho de encriptação (ao solicitar um par de chaves DEK/eDEK)
A cada 1 hora no caminho da chave de desencriptação (DEK -> eDEK)
Tenho de fazer alguma coisa quando a DEK muda?
Não — a rotação de DEK/eDEK é feita dentro da OpenAI. Desde que a sua chave mestra permaneça válida, quaisquer eDEKs encriptadas pela sua chave mestra podem continuar a ser desencriptadas para a DEK, que é depois usada para desencriptar os seus dados.
Rotação e revogação da chave mestra (controladas por si)
Com que frequência ocorrem a rotação e a revogação de chaves?
Isto é determinado por si, uma vez que a OpenAI não tem visibilidade sobre a sua chave mestra.
Qual é a diferença entre rotação de chave e revogação de chave?
A revogação de chave remove o acesso a dados encriptados com chaves antigas. A rotação de chave encripta os dados com uma nova chave, mas mantém o acesso de leitura aos dados antigos.
O que acontece se eu revogar a minha chave mestra?
Se uma chave for revogada ou as permissões forem removidas, o espaço de trabalho acabará por deixar de funcionar quando as chaves em cache expirarem. Nesse momento, a OpenAI deixa de conseguir desencriptar dados armazenados ou encriptar novos dados. Na prática, os dados ficam «destruídos».
Com que rapidez entra em vigor a revogação?
A OpenAI mantém DEKs em cache na memória por motivos de desempenho e resiliência. Normalmente, a revogação entra em vigor no prazo de uma hora, assim que as chaves em cache expiram e a revalidação falha.
A revogação pode ser testada em segurança?
Testar a revogação num espaço de trabalho de produção não é recomendado, porque tornará permanentemente inacessíveis os dados existentes. No entanto, os clientes podem (e devem) testar a revogação num ambiente sandbox para verificar o comportamento correto e validar os seus pressupostos de confiança.
Se uma chave for revogada permanentemente, o espaço de trabalho pode ser recuperado associando uma nova chave?
Não. Depois de a chave se perder, os dados tornam-se irrecuperáveis por conceção. A única medida corretiva é criar um novo espaço de trabalho.
O que devemos fazer se um espaço de trabalho ficar inacessível devido a alterações de chave?
A medida corretiva esperada é criar um novo espaço de trabalho. Atualizar o KMS não recuperará os dados existentes.
Qual é o plano de reversão se decidirmos deixar de usar CMEK?
Atualmente, não existe plano de reversão. Depois de um espaço de trabalho ser criado com CMEK, todos os dados associados são encriptados com chaves geridas pelo cliente e não podem ser acedidos sem elas. A única forma de deixar de usar CMEK é criar um novo espaço de trabalho — os dados encriptados existentes permanecerão permanentemente inacessíveis.
O que acontece quando rodo a minha chave mestra?
Será gerado novo material criptográfico para encriptação, pelo que os novos pedidos de encriptação usarão a nova chave. No entanto, o identificador KMS (ARN ou nome da chave) permanece igual e os dados antigos continuam a poder ser desencriptados. Muitos fornecedores de cloud oferecem rotação automática de chaves (AWS, GCP, Azure).
A OpenAI volta a encriptar dados antigos quando rodo a minha chave mestra?
Não. O novo material criptográfico será usado apenas para encriptar novos dados.
Quanto tempo demora a entrar em vigor uma rotação ou revogação de chave?
1 hora. Isto acontece porque as DEK/eDEKs são mantidas em cache na memória e revalidamos estas entradas com o seu KMS de hora a hora.
Alterar o identificador KMS
Alterar o identificador KMS é uma revogação de chave ou uma rotação de chave?
Revogação de chave. Uma chave não consegue desencriptar dados encriptados por outra chave.
A OpenAI pode ajudar-me a alterar o identificador KMS de um espaço de trabalho ChatGPT?
Se confirmar que a intenção é revogar a sua chave, podemos ajudá-lo a fazê-lo num espaço de trabalho ChatGPT. Tenha em conta que, quando o ARN do KMS for atualizado, os dados mais antigos permanecerão inacessíveis, pelo que, após a alteração, ficará com uma combinação de dados inacessíveis e acessíveis.
A OpenAI pode ajudar-me a alterar o identificador KMS de um projeto de API?
Se estiver a usar a API, a API facilita o arquivamento e a criação de novos projetos. Por isso, arquive antes o projeto cujos dados, de qualquer forma, não estão acessíveis, registe uma nova configuração EKM na OpenAI e crie um novo projeto de API com a nova chave KMS.
E se eu quiser alterar regularmente o meu identificador KMS por conta própria?
Isto não é recomendado, pois provavelmente não vai querer revogar a sua chave regularmente. No entanto, pode fazê-lo se usar um fornecedor de cloud que suporte um alias de chave KMS (exemplo da AWS). Pode registar esse alias de chave KMS na OpenAI e, depois, no seu fornecedor de cloud, pode substituir a qualquer momento o identificador KMS subjacente para o qual o alias aponta, para emitir uma revogação de chave.
Comportamento em beta vs. GA
Existem riscos conhecidos ou alterações ao nível do sistema ao usar a beta de encriptação em produção?
O ambiente beta é funcionalmente equivalente ao GA, e não se esperam passos de migração. O principal risco é que algumas funcionalidades de casos-limite ainda possam não suportar conteúdo encriptado devido a caminhos de código incompletos. Estes casos são raros e estão a ser resolvidos ativamente. Os dados estão totalmente encriptados e protegidos, independentemente destes potenciais problemas.
Haverá passos de migração da beta para GA?
Não. Os espaços de trabalho que usam a beta de encriptação serão automaticamente suportados em GA sem qualquer ação do utilizador.
Detalhes técnicos adicionais
Encriptação por envelope e permissões
Precisamos de conceder permissões GenerateDataKey à OpenAI para EKM?
Não. A OpenAI requer apenas permissões Encrypt e Decrypt na sua chave KMS. A permissão GenerateDataKey não é necessária para a integração EKM.
A OpenAI usa encriptação por envelope para os dados dos clientes?
Sim. A OpenAI usa um modelo de encriptação por envelope:
KMS do cliente: gere as chaves de encriptação de chaves (KEKs). A OpenAI nunca vê nem armazena as KEKs.
Infraestrutura da OpenAI: gera e gere chaves de encriptação de dados (DEKs). Cada DEK é encriptada (encapsulada) com a sua KEK antes do armazenamento.
Fluxo de dados:
Os dados do cliente são encriptados com uma DEK.
Essa DEK é encriptada com a sua KEK, produzindo uma eDEK.
A eDEK é armazenada juntamente com os dados encriptados.
Para desencriptar dados, a OpenAI pede ao seu KMS que desencripte a eDEK, obtém a DEK e desencripta o conteúdo.
Porque escolheu a OpenAI este modelo em vez de deixar o KMS gerir tanto KEKs como DEKs?
Existem duas abordagens comuns à encriptação por envelope:
KEKs e DEKs geridas pelo KMS:
Vantagens: implementação mais simples, sem necessidade de manter infraestrutura de encriptação.
Desvantagens: cada pedido de encriptação/desencriptação passa pelo KMS, aumentando a latência e o custo, e criando um ponto único de falha.
KEKs geridas pelo KMS / DEKs geridas pela OpenAI (a nossa abordagem):
Vantagens: latência e custo significativamente mais baixos, melhor escalabilidade e fiabilidade, e continuidade de operação durante falhas parciais do KMS (até ao TTL da cache de DEK).
Desvantagens: implementação ligeiramente mais complexa do lado da OpenAI.
Este desenho permite à OpenAI oferecer garantias de segurança fortes, minimizando simultaneamente o risco operacional e o custo para os clientes.
Com que frequência são rodadas as DEKs?
Cada DEK é rodada aproximadamente a cada 60 minutos. Isto proporciona isolamento temporal — mesmo que uma DEK fosse de alguma forma comprometida, o impacto ficaria limitado aos dados encriptados nessa janela de uma hora.
Volume de pedidos KMS e observabilidade
Vemos muito menos pedidos KMS do que mensagens de utilizadores. Estes números deviam corresponder?
Não, não terão uma correlação direta.
Como a OpenAI mantém DEKs em cache na memória por motivos de desempenho, as chamadas ao KMS só são feitas quando uma DEK precisa de ser desencriptada — não em todas as operações de encriptação ou desencriptação. Assim, deve esperar:
Menos pedidos KMS do que interações de utilizadores.
Picos ocasionais quando as DEKs em cache expiram (aproximadamente a cada hora) ou quando é necessário aceder a dados encriptados mais antigos.
Chamadas adicionais ao obter dados históricos, por exemplo quando um utilizador continua uma conversa longa e é necessário carregar DEKs mais antigas.
O número exato de pedidos KMS depende do estado da cache, do comportamento dos utilizadores, dos padrões de acesso aos dados e da duração das conversas, pelo que não terá uma correlação direta com o volume de mensagens.