Configurando o SDK de criptografia AWS de banco de dados - AWS SDK de criptografia de banco de dados

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Configurando o SDK de criptografia AWS de banco de dados

Nossa biblioteca de criptografia do lado do cliente foi renomeada para SDK de criptografia de AWS banco de dados. Este guia do desenvolvedor ainda fornece informações sobre o DynamoDB Encryption Client.

O SDK AWS de criptografia de banco de dados foi projetado para ser fácil de usar. Embora o SDK AWS de criptografia de banco de dados tenha várias opções de configuração, os valores padrão são cuidadosamente escolhidos para serem práticos e seguros para a maioria dos aplicativos. No entanto, talvez seja necessário ajustar sua configuração para melhorar a performance ou incluir um atributo personalizado em seu design.

Seleção de uma linguagem de programação

O SDK AWS de criptografia de banco de dados para DynamoDB está disponível em várias linguagens de programação. As implementações de linguagem são projetadas para serem totalmente interoperáveis e oferecer os mesmos atributos, embora possam ser implementadas de maneiras diferentes. Normalmente, você usa a biblioteca compatível com sua aplicação.

Seleção de chaves de encapsulamento

O SDK AWS de criptografia de banco de dados gera uma chave de dados simétrica exclusiva para criptografar cada campo. Não é necessário configurar, gerenciar ou usar as chaves de dados. O SDK AWS de criptografia de banco de dados faz isso por você.

No entanto, você deve selecionar uma ou mais chaves de empacotamento para criptografar cada chave de dados. O SDK de criptografia de banco de dados da AWS é compatível com chaves do KMS de criptografia simétrica e chaves KMS RSA assimétricas AWS Key Management Service (AWS KMS). Ele também é compatível com chaves simétricas AES e chaves assimétricas RSA que você fornece em tamanhos diferentes. Você é responsável pela segurança e durabilidade de suas chaves de empacotamento, por isso recomendamos que você use uma chave de criptografia em um módulo de segurança de hardware ou em um serviço de infraestrutura de chaves, como AWS KMS.

Para especificar suas chaves de empacotamento para criptografia e decodificação, use um token de autenticação. Dependendo do tipo de token de autenticação usado, é possível especificar uma chave de empacotamento ou várias chaves de empacotamento do mesmo tipo ou de tipos diferentes. Se você usar várias chaves de empacotamento para empacotar uma chave de dados, cada chave de empacotamento criptografará uma cópia da mesma chave de dados. As chaves de dados criptografadas (uma por chave de empacotamento) são armazenadas na descrição do material armazenada junto com o campo criptografado. Para descriptografar os dados, o SDK de criptografia de AWS banco de dados deve primeiro usar uma de suas chaves de encapsulamento para descriptografar uma chave de dados criptografada.

Recomendamos usar um dos AWS KMS chaveiros sempre que possível. O SDK AWS de criptografia de banco de dados fornece o AWS KMS chaveiro e o AWS KMS chaveiro hierárquico, o que reduz o número de chamadas feitas para. AWS KMS Para especificar um AWS KMS key em um chaveiro, use um identificador de AWS KMS chave compatível. Se você usar o AWS KMS chaveiro hierárquico, deverá especificar o ARN da chave. Para obter detalhes sobre os identificadores de chave de uma AWS KMS chave, consulte Identificadores de chave no Guia do AWS Key Management Service desenvolvedor.

  • Ao criptografar com um AWS KMS chaveiro, você pode especificar qualquer identificador de chave válido (ARN da chave, nome do alias, ARN do alias ou ID da chave) para uma chave KMS de criptografia simétrica. Se você usar uma chave do RSA KMS assimétrica, deverá especificar o ARN da chave.

    Se você especificar um nome de alias ou ARN de alias para uma chave KMS ao criptografar, o SDK de criptografia de banco de dados da AWS salvará o ARN da chave atualmente associado a esse alias; ele não salvará o alias. As alterações no alias não afetam a chave do KMS usada para descriptografar suas chaves de dados.

  • Por padrão, o AWS KMS chaveiro descriptografa registros no modo estrito (onde você especifica chaves KMS específicas). Em um token de autenticação de descriptografia, você deve usar um ARN de chave para identificar AWS KMS keys .

    Quando você criptografa com um AWS KMS chaveiro, o SDK AWS de criptografia de banco de dados armazena o ARN da chave AWS KMS key na descrição do material com a chave de dados criptografada. Ao descriptografar no modo estrito, o SDK de criptografia de AWS banco de dados verifica se o mesmo ARN da chave aparece no chaveiro antes de tentar usar a chave de encapsulamento para descriptografar a chave de dados criptografada. Se você usar um identificador de chave diferente, o SDK AWS de criptografia de banco de dados não reconhecerá nem usará o AWS KMS key, mesmo que os identificadores se refiram à mesma chave.

  • Ao descriptografar no modo de descoberta, não especifique chaves de empacotamento. Primeiro, o SDK AWS de criptografia de banco de dados tenta descriptografar o registro com a chave ARN armazenada na descrição do material. Se isso não funcionar, o SDK AWS de criptografia de banco de dados solicita AWS KMS a descriptografia do registro usando a chave KMS que o criptografou, independentemente de quem é proprietário ou tem acesso a essa chave KMS.

Para especificar uma chave AES bruta ou um par de chaves RSA brutas como chave de empacotamento em um token de autenticação, você deve especificar um namespace e um nome. Ao descriptografar, você deve usar exatamente o mesmo namespace e nome para cada chave de empacotamento bruta que você usou ao criptografar. Se você usar um namespace ou nome diferente, o SDK do AWS Database Encryption não reconhecerá nem usará a chave de empacotamento, mesmo que o material da chave seja o mesmo.

Criação de um filtro de descoberta

Ao descriptografar dados criptografados com chaves do KMS, é uma prática recomendada descriptografar no modo estrito, ou seja, limitar as chaves de empacotamento usadas somente às que você especificar. No entanto, se necessário, você também poderá descriptografar no modo de descoberta, onde você não especifica nenhuma chave de empacotamento. Nesse modo, AWS KMS pode descriptografar a chave de dados criptografada usando a chave KMS que a criptografou, independentemente de quem possui ou tem acesso a essa chave KMS.

Se você precisar descriptografar no modo de descoberta, recomendamos que você sempre use um filtro de descoberta, que limita as chaves KMS que podem ser usadas às de uma partição especificada. Conta da AWS O filtro de descoberta é opcional, mas é uma prática recomendada.

Use a tabela a seguir para determinar o valor da partição do seu filtro de descoberta.

Região Partition
Regiões da AWS aws
Regiões da China aws-cn
AWS GovCloud (US) Regions aws-us-gov

O exemplo a seguir mostra como criar um filtro de descoberta. Antes de usar o código, substitua os valores de exemplo por valores válidos para sua partição Conta da AWS e.

Java
// Create the discovery filter DiscoveryFilter discoveryFilter = DiscoveryFilter.builder() .partition("aws") .accountIds(111122223333) .build();
C# / .NET
var discoveryFilter = new DiscoveryFilter { Partition = "aws", AccountIds = 111122223333 };

Trabalhar com bancos de dados multilocatários

Com o SDK AWS de criptografia de banco de dados, você pode configurar a criptografia do lado do cliente para bancos de dados com um esquema compartilhado, isolando cada inquilino com materiais de criptografia distintos. Ao considerar um banco de dados multilocatário, reserve um tempo para analisar seus requisitos de segurança e como a multilocação pode afetá-los. Por exemplo, o uso de um banco de dados multilocatário pode afetar sua capacidade de combinar o SDK de criptografia AWS de banco de dados com outra solução de criptografia do lado do servidor.

Se você tiver vários usuários executando operações de criptografia em seu banco de dados, poderá usar um dos AWS KMS chaveiros para fornecer a cada usuário uma chave distinta para usar em suas operações criptográficas. Gerenciar as chaves de dados para uma solução de criptografia do lado do cliente multilocatária pode ser complicado. Recomendamos organizar seus dados por locatário sempre que possível. Se o locatário for identificado pelos valores da chave primária (por exemplo, a chave de partição em uma tabela do Amazon DynamoDB), será mais fácil gerenciar suas chaves.

Você pode usar o AWS KMS chaveiro para isolar cada inquilino com um chaveiro distinto e. AWS KMS AWS KMS keys Com base no volume de AWS KMS chamadas feitas por inquilino, talvez você queira usar o AWS KMS chaveiro hierárquico para minimizar suas chamadas para. AWS KMS O chaveiro AWS KMS hierárquico é uma solução de armazenamento em cache de materiais criptográficos que reduz o número de AWS KMS chamadas usando chaves de ramificação AWS KMS protegidas persistentes em uma tabela do Amazon DynamoDB e, em seguida, armazenando localmente em cache materiais de chave de ramificação usados em operações de criptografia e descriptografia. Você deve usar o AWS KMS chaveiro hierárquico para implementar a criptografia pesquisável em seu banco de dados.

Criação de beacons assinados

O SDK AWS de criptografia de banco de dados usa beacons padrão e beacons compostos para fornecer soluções de criptografia pesquisáveis que permitem pesquisar registros criptografados sem descriptografar todo o banco de dados consultado. No entanto, o SDK AWS de criptografia de banco de dados também oferece suporte a beacons assinados que podem ser configurados inteiramente a partir de campos assinados em texto simples. Os beacons assinados são um tipo de farol composto que indexa e executa consultas complexas em campos e. SIGN_ONLY SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT

Por exemplo, se você tiver um banco de dados multilocatário, talvez queira criar um beacon assinado que permita consultar seu banco de dados em busca de registros criptografados pela chave de um locatário específico. Para ter mais informações, consulte Consultar beacons em um banco de dados multilocatário.

Você deve usar o AWS KMS chaveiro hierárquico para criar beacons assinados.

Para configurar um beacon assinado, forneça os valores a seguir.

Java

Configuração de farol composto

O exemplo a seguir define as listas de peças assinadas localmente na configuração do beacon assinado.

List<CompoundBeacon> compoundBeaconList = new ArrayList<>(); CompoundBeacon exampleCompoundBeacon = CompoundBeacon.builder() .name("compoundBeaconName") .split(".") .signed(signedPartList) .constructors(constructorList) .build(); compoundBeaconList.add(exampleCompoundBeacon);

Definição da versão do Beacon

O exemplo a seguir define as listas de peças assinadas globalmente na versão beacon. Para obter mais informações sobre como definir a versão do beacon, consulte Usando beacons.

List<BeaconVersion> beaconVersions = new ArrayList<>(); beaconVersions.add( BeaconVersion.builder() .standardBeacons(standardBeaconList) .compoundBeacons(compoundBeaconList) .signedParts(signedPartList) .version(1) // MUST be 1 .keyStore(keyStore) .keySource(BeaconKeySource.builder() .single(SingleKeyStore.builder() .keyId(branchKeyId) .cacheTTL(6000) .build()) .build()) .build() );
C# / .NET

Veja o exemplo de código completo: BeaconConfig.cs

Configuração de beacon assinada

O exemplo a seguir define as listas de peças assinadas localmente na configuração do beacon assinado.

var compoundBeaconList = new List<CompoundBeacon>(); var exampleCompoundBeacon = new CompoundBeacon { Name = "compoundBeaconName", Split = ".", Signed = signedPartList, Constructors = constructorList }; compoundBeaconList.Add(exampleCompoundBeacon);

Definição da versão do Beacon

O exemplo a seguir define as listas de peças assinadas globalmente na versão beacon. Para obter mais informações sobre como definir a versão do beacon, consulte Usando beacons.

var beaconVersions = new List<BeaconVersion> { new BeaconVersion { StandardBeacons = standardBeaconList, CompoundBeacons = compoundBeaconList, SignedParts = signedPartsList, Version = 1, // MUST be 1 KeyStore = keyStore, KeySource = new BeaconKeySource { Single = new SingleKeyStore { KeyId = branchKeyId, CacheTTL = 6000 } } } };

Você pode definir suas peças assinadas em listas definidas local ou globalmente. Recomendamos definir suas peças assinadas em uma lista global na versão beacon sempre que possível. Ao definir peças assinadas globalmente, você pode definir cada peça uma vez e depois reutilizar as peças em várias configurações de faróis compostos. Se você pretende usar uma peça assinada apenas uma vez, você pode defini-la em uma lista local na configuração do beacon assinado. Você pode referenciar partes locais e globais na sua lista de construtores.

Se você definir suas listas de peças assinadas globalmente, deverá fornecer uma lista de peças do construtor que identifique todas as maneiras possíveis pelas quais o farol assinado pode montar os campos em sua configuração de farol.

nota

Para definir listas de peças assinadas globalmente, você deve usar a versão 3.2 ou posterior do SDK de criptografia de AWS banco de dados. Implante a nova versão para todos os leitores antes de definir qualquer nova parte globalmente.

Você não pode atualizar as configurações de beacon existentes para definir listas de peças assinadas globalmente.

Nome do beacon

O nome que você usa ao consultar o beacon.

Um nome de beacon assinado não pode ser o mesmo nome de um campo não criptografado. Beacons diferentes não podem ter o mesmo nome.

Dividir caractere

O caractere usado para separar as partes que compõem seu beacon assinado.

O caractere dividido não pode aparecer nos valores de texto simples de nenhum dos campos a partir dos quais o beacon assinado foi construído.

Lista de partes assinadas

Identifica os campos assinados incluídos no farol assinado.

Cada parte deve incluir um nome, uma fonte e um prefixo. A fonte é o SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT campo SIGN_ONLY ou que a peça identifica. A fonte deve ser um nome de campo ou um índice referente ao valor de um campo aninhado. Se o nome da peça identificar a fonte, você poderá omitir a fonte e o SDK do AWS Database Encryption usará automaticamente o nome como fonte. Recomendamos especificar a fonte como nome da parte sempre que possível. O prefixo pode ser qualquer string, mas deve ser exclusivo. Duas partes assinadas em um beacon assinado não podem ter o mesmo prefixo. Recomendamos usar um valor curto que diferencie a parte de outras partes atendidas pelo beacon composto.

Recomendamos definir suas peças assinadas globalmente sempre que possível. Você pode considerar definir uma peça assinada localmente se pretende usá-la apenas em um farol composto. Uma peça definida localmente não pode ter o mesmo prefixo ou nome de uma peça definida globalmente.

Java
List<SignedPart> signedPartList = new ArrayList<>); SignedPart signedPartExample = SignedPart.builder() .name("signedFieldName") .prefix("S-") .build(); signedPartList.add(signedPartExample);
C# / .NET
var signedPartsList = new List<SignedPart> { new SignedPart { Name = "signedFieldName1", Prefix = "S-" }, new SignedPart { Name = "signedFieldName2", Prefix = "SF-" } };
Lista de construtores (opcional)

Identifica os construtores que definem as diferentes maneiras pelas quais as partes assinadas podem ser montadas pelo beacon assinado.

Se você não especificar uma lista de construtores, o SDK do AWS Database Encryption monta o beacon assinado com o construtor padrão a seguir.

  • Todas as partes assinadas na ordem em que foram adicionadas à lista de partes assinadas

  • Todas as partes são obrigatórias

Construtores

Cada construtor é uma lista ordenada de partes do construtor que define uma maneira pela qual o beacon assinado pode ser montado. As partes do construtor são unidas na ordem em que são adicionadas à lista, com cada parte separada pelo caractere de divisão especificado.

Cada parte do construtor nomeia uma parte assinada e define se essa parte é obrigatória ou opcional dentro do construtor. Por exemplo, se você quiser consultar um beacon assinado em Field1, Field1.Field2 e Field1.Field2.Field3, marque Field2 e Field3 como opcionais e crie um construtor.

Cada construtor deve ter pelo menos uma parte obrigatória. Recomendamos tornar obrigatória a primeira parte de cada construtor para que você possa usar o operador BEGINS_WITH nas consultas.

Um construtor será bem-sucedido se todas as partes obrigatórias estiverem presentes no registro. Quando você grava um novo registro, o beacon assinado usa a lista de construtores para determinar se o beacon pode ser montado a partir dos valores fornecidos. Ele tenta montar o beacon na ordem em que os construtores foram adicionados à lista de construtores e usa o primeiro construtor bem-sucedido. Se nenhum construtor for bem-sucedido, o beacon não será gravado no registro.

Todos os leitores e gravadores devem especificar a mesma ordem de construtores para garantir que os resultados da consulta estejam corretos.

Use o procedimento a seguir para especificar sua própria lista de construtores.

  1. Crie uma parte construtora para cada parte assinada para definir se essa parte é necessária ou não.

    O nome da parte do construtor deve ser o nome do campo assinado.

    O exemplo a seguir demonstra como criar partes do construtor para um campo assinado.

    Java
    ConstructorPart field1ConstructorPart = ConstructorPart.builder() .name("Field1") .required(true) .build();
    C# / .NET
    var field1ConstructorPart = new ConstructorPart { Name = "Field1", Required = true };
  2. Crie um construtor para cada forma possível de montar o beacon assinado usando as partes do construtor que você criou na Etapa 1.

    Por exemplo, se quiser consultar Field1.Field2.Field3 eField4.Field2.Field3, você deverá criar dois construtores. Field1 e Field4 podem ser obrigatórios porque foram definidos em dois construtores separados.

    Java
    // Create a list for Field1.Field2.Field3 queries List<ConstructorPart> field123ConstructorPartList = new ArrayList<>(); field123ConstructorPartList.add(field1ConstructorPart); field123ConstructorPartList.add(field2ConstructorPart); field123ConstructorPartList.add(field3ConstructorPart); Constructor field123Constructor = Constructor.builder() .parts(field123ConstructorPartList) .build(); // Create a list for Field4.Field2.Field1 queries List<ConstructorPart> field421ConstructorPartList = new ArrayList<>(); field421ConstructorPartList.add(field4ConstructorPart); field421ConstructorPartList.add(field2ConstructorPart); field421ConstructorPartList.add(field1ConstructorPart); Constructor field421Constructor = Constructor.builder() .parts(field421ConstructorPartList) .build();
    C# / .NET
    // Create a list for Field1.Field2.Field3 queries var field123ConstructorPartList = new Constructor { Parts = new List<ConstructorPart> { field1ConstructorPart, field2ConstructorPart, field3ConstructorPart } }; // Create a list for Field4.Field2.Field1 queries var field421ConstructorPartList = new Constructor { Parts = new List<ConstructorPart> { field4ConstructorPart, field2ConstructorPart, field1ConstructorPart } };
  3. Crie uma lista de construtores que inclua todos os construtores que você criou na Etapa 2.

    Java
    List<Constructor> constructorList = new ArrayList<>(); constructorList.add(field123Constructor) constructorList.add(field421Constructor)
    C# / .NET
    var constructorList = new List<Constructor> { field123Constructor, field421Constructor };
  4. Especifique constructorList ao criar o beacon assinado.