Criptografia de dados

• A capacidade de cifrar os datos confidenciais dentro de um banco, mas não necessariamente todo o arquivo de dados,
• Uma capa de segurança adicional para proteger o acesso aos dados,
• Encriptação não baseada em hardware, você controla a chave (conforme às exigências das empresas de hosting externas).

Nota: para saber mais sobre como 4D maneja as perguntas de segurança, consulte a Guía de segurança de 4D.

4D oferece dois modos de cifrado diferentes, que respondem a duas necessidades diferentes:

• Cifrado assimétrico, baseado em um par de chaves. A criptografia se realiza com a chave pública, enquanto que o descifrado exige a chave privada.
  Este modo é adequado para assegurar intercâmbios de dados através de uma rede, já que permite a autenticação e o cifrado.
  Em 4D, se implementa mediante os comandos GENERATE ENCRYPTION KEYPAIR, ENCRYPT BLOB e DECRYPT BLOB. 

• Cifrado simétrico, onde se utiliza a mesma chave tanto para o cifrado como para o descifrado.
  Este é o modo adequado para o cifrado de datos locais. Em 4D, este modo, que se utiliza para cifrar o arquivo de dados, se detalha nesta seção. É compatível com os comandos de tema .

A criptografia de dados em 4D se baseia nos seguintes conceitos:

• Granularidade: o cifrado se realiza a nível de tabela. As tabelas que contêm dados confidenciais estão marcadas como "criptografáveis" na estrutura do banco de dados (arquivo .4db). Para saber mais sobre como configurar tabelas criptografáveis, consulte o parágrafo Encriptable.
• Chave de criptografia: as tabelas são cifradas mediante uma chave AES, gerada utilizando um algoritmo SHA-256 a partir de uma "frase passe de senha" dada. A chave de cifrado pode ser armazenada em um arquivo em um dispositivo externo, como uma pendrive, que poderia conectar-se ao servidor apenas quando for necessário.
• Chaveiro: quando tiver proporcionado uma chave de cifrado válida para um arquivo de dados cifrados, ela é guardada na memória no chveiro 4D. Portanto, o arquivo de dados pode ser fechado e voltará a abrir sem proporcionar a chave (através de um dispositivo ou com o método dataStore.provideDataKey( )). Na configuração cliente/servidor, o chaveiro é armazenado no servidor. O chaveiro é esvaziado quando 4D se fechar.
• Frase Passe de senha: a frase passe de senha é uma versão mais segura de uma senha comum, pode conter uma grande qantidade de caracteres e se utiliza para gerar a chave de cifrado. A mesma frase passe sempre dará como resultado a mesma chave de cifrado.
• Cifrado simétrico: a mesma chave de criptografia se utiliza para cifrar e descifrar dados.
• Leitura e escritura de dados cifrados: quando tiver proporcionado uma chave de cifrado válida a um arquivo de dados cifrados:
  • Todas as modificações de dados em tabelas criptografáveis são cifrados automaticamente no disco.
  • Todos os dados carregados de tabelas criptografáveis são descifradas automaticamente na memória
• Arquivos de destino: o cifrado se aplica a todos os arquivos que manejam dados: .4dd, .journal, .4dIndex.   

 Advertência: se perder a chave de cifrado e a frase passe, será impossível, mesmo para os serviços técnicos de 4D, acessar aos datos cifrados.

Encryption in 4D is based upon a simple, two-step scenario:

Step 1: Selecting tables to encrypt

• The developer selects tables to be encrypted at the database structure level (see Encryptable).
• For perfomance reasons, only tables containing sensitive data need to be selected. 
• No encryption is done at this step, users can work normally, without data encryption.

Step 2: Encrypting selected data

• When deploying an application (if requested by the customer), the developer enables encryption using the Maintenance and security center (MSC), or with the 4D language.
• Encryption is then propagated to all pre-selected tables. 
• Encrypted data is automatically decrypted when read and re-encrypted when saved, if the encryption key has been provided. 

Note: The 4D keychain is only valid during the running 4D session. It is kept in memory and is automatically deleted when the 4D application is closed.

This graphic includes the following steps:

1. When the user tries to open an encrypted data file, 4D looks for a valid encryption key in the 4D keychain. If found, access (read/write) to the encrypted data  is granted.
2. If no valid encryption key is found in the 4D keychain, 4D scans all connected devices (at first level) to find a .4DKeyChain file containing a valid encryption key (see Storing data encryption keys in files below).
3. At this step, the data file is actually open. If no valid encryption key is provided, no read/write access is possible on encrypted data.
4. The user can, however, provide a valid data encryption key by:
   
   • connecting a device containing the .4DKeyChain file and calling the Discover data key command,
     or
   • entering the passphrase with the dataStore.provideDataKey( ) method.

   If a valid data encryption key is provided, read/write access is allowed on encrypted data.

5. Each time a valid encryption key is found, it is added to the 4D keychain. A connected device containing an encryption key does not need to remain connected once the encryption key has been added to the 4D keychain. 

You can create data encryption key files in order to store them on external devices (e.g., USB keys or external disks) so that 4D can use them automatically at startup or after a call to Discover data key to decrypt data (see above). Once a valid encryption key has been found, it is stored in memory in the 4D keychain and used during the entire session. At this step, the external device can be disconnected.

An encrypted key file must comply with the following rules:

• The file name must have the .4DKeyChain extension. For example, "myKeys.4DKeyChain".
• It must be a text file formatted in JSON.
• It can contain one or more encryption key(s) and/or passphrase(s) in JSON objects or collections of objects; each object must contain an encodedKey or passPhrase property. See the New data key command to learn how to generate a key file. 
• The file must be stored at the root of the external device
• Multiple .4DKeyChain files can be used simultaneously.

Here is an example of a key file containing three keys: