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 usa a eDEK, pede ao seu KMS para a desencriptar numa DEK e, depois, desencripta os seus dados
Como funciona a encriptação EKM?
Consulte o nosso artigo para obter informações detalhadas: Visã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 para desencriptar a eDEK de volta para a DEK.
A OpenAI coloca as minhas DEKs em cache?
Sim — apenas em memória. Isto é feito por razões de desempenho, para evitar aceder ao seu KMS em cada pedido de encriptação/desencriptação de dados. As DEKs nunca são gravadas em armazenamento.
Permissões da cloud
Que permissões terá a OpenAI no meu KMS?
Apenas as permissões que nos conceder através da política que definir. Precisamos apenas, no mínimo, das operações Encrypt/Decrypt. Crie também uma nova chave no KMS da sua cloud para a OpenAI, em vez de reutilizar quaisquer 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 concluídos: 1. reconheceu a identidade da OpenAI (através de trust policy, workload identity, etc., dependendo do fornecedor de cloud), 2. criou uma política para aceder ao KMS e 3. atribuiu à identidade da OpenAI a permissão para aceder à política. Se apenas criar o KMS sem concluir 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 pela 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 executa realmente a encriptação/desencriptação é um detalhe de implementação opaco para nós.
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 pedir um par de chaves DEK/eDEK)
A cada 1 hora para o 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 mais antigas. A rotação de chave encripta os dados com uma nova chave, mas mantém o acesso de leitura aos dados mais antigos.
O que acontece se eu revogar a minha chave mestra?
Se uma chave for revogada ou se as permissões forem removidas, o espaço de trabalho acabará por deixar de funcionar assim que as chaves em cache expirarem. Nessa altura, a OpenAI deixará de conseguir desencriptar os dados armazenados ou encriptar novos dados. Na prática, os dados são “destruídos”.
Com que rapidez a revogação produz efeitos?
A OpenAI coloca DEKs em cache na memória por motivos de desempenho e resiliência. Normalmente, a revogação produz efeitos 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?
Não é recomendado testar a revogação num espaço de trabalho de produção, porque isso 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 ao associar uma nova chave?
Não. Depois de a chave ser perdida, os dados tornam-se irrecuperáveis por conceção. A única solução é 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 chaves?
A solução 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 um 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 descontinuar a utilização de CMEK é criar um novo espaço de trabalho — os dados encriptados existentes permanecerão permanentemente inacessíveis.
O que acontece quando eu 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 do KMS (ARN ou nome da chave) permanece o mesmo 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 os dados antigos quando eu rodo a minha chave mestra?
Não. O novo material criptográfico só será usado para encriptar novos dados.
Quanto tempo demora até que a rotação ou a revogação de uma chave produzam efeito?
1 hora. Isto acontece porque as DEK/eDEKs são colocadas em cache na memória e revalidamos estas entradas com o seu KMS de hora a hora.
Mudança do identificador do KMS
Mudar o identificador do 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 mudar o meu identificador do KMS para um espaço de trabalho ChatGPT?
Se confirmar que a intenção é revogar a sua chave, podemos ajudá-lo a fazê-lo para um espaço de trabalho ChatGPT. Tenha em atenção que, quando o ARN do KMS é atualizado, os dados mais antigos permanecerão inacessíveis, pelo que acabará com uma mistura de dados inacessíveis e acessíveis após a alteração.
A OpenAI pode ajudar-me a mudar o meu identificador do KMS para um projeto de API?
Se estiver a usar a API, a API facilita o arquivo e a criação de novos projetos, por isso arquive antes o projeto cujos dados já 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 mudar regularmente o meu identificador do KMS por minha iniciativa?
Isto não é recomendado, uma vez que provavelmente não pretende revogar a sua chave regularmente. No entanto, ainda o pode fazer se utilizar 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 trocar a qualquer momento o identificador KMS subjacente para o qual o alias aponta, de modo a emitir uma revogação de chave.
Comportamento 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 à GA e não são esperados passos de migração. O principal risco é que algumas funcionalidades de casos limite possam ainda não suportar conteúdo encriptado devido a percursos 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 a GA?
Não. Os espaços de trabalho que utilizam a beta de encriptação serão automaticamente suportados na GA sem qualquer ação do utilizador.
Detalhes técnicos adicionais
Encriptação de envelope & permissões
Temos de conceder permissões GenerateDataKey à OpenAI para EKM?
Não. A OpenAI só requer 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 de envelope para os dados dos clientes?
Sim. A OpenAI usa um modelo de encriptação de envelope:
KMS do cliente: Gere as Key Encryption Keys (KEKs). A OpenAI nunca vê nem armazena as KEKs.
Infraestrutura da OpenAI: Gera e gere Data Encryption Keys (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 para desencriptar a eDEK, recupera a DEK e desencripta o conteúdo.
Porque escolheu a OpenAI este modelo em vez de deixar o KMS gerir tanto as KEKs como as DEKs?
Existem duas abordagens comuns à encriptação de envelope:
KEKs e DEKs geridas pelo KMS:
Prós: implementação mais simples, sem necessidade de manter infraestrutura de encriptação.
Contras: cada pedido de encriptação/desencriptação acede ao KMS, aumentando a latência, o custo e introduzindo um ponto único de falha.
KEKs geridas pelo KMS / DEKs geridas pela OpenAI (a nossa abordagem):
Prós: latência e custo significativamente mais baixos, melhor escalabilidade e fiabilidade, e funcionamento contínuo durante falhas parciais do KMS (até ao TTL da cache de DEK).
Contras: implementação ligeiramente mais complexa do lado da OpenAI.
Este design permite à OpenAI oferecer fortes garantias de segurança, minimizando ao mesmo tempo 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 dentro dessa janela de uma hora.
Volume de pedidos KMS & observabilidade
Vemos muito menos pedidos KMS do que o número de mensagens dos utilizadores. Estes números deveriam coincidir?
Não, não terão uma correlação direta.
Como a OpenAI coloca 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 cada operação de encriptação ou desencriptação. Como resultado, deve esperar:
Menos pedidos KMS do que interações dos utilizadores.
Picos ocasionais quando as DEKs em cache expiram (cerca de cada hora) ou quando é necessário aceder a dados encriptados mais antigos.
Chamadas adicionais ao recuperar dados históricos, por exemplo, quando um utilizador continua uma conversa de longa duração e é necessário carregar DEKs mais antigas.
O número exato de pedidos KMS depende do estado da cache, do comportamento do utilizador, dos padrões de acesso aos dados e da duração da conversa e, por isso, não terá correlação direta com o volume de mensagens.