Client-Side Field Level Encryption FAQs¶
What is client-side field level encryption (CSFLE)?¶
CSFLE is a mechanism that encrypts specific fields to ensure that sensitive data is never stored in plaintext. The encryption and decryption of these fields is performed client-side, meaning that the sensitive data is never sent in plaintext. This mechanism is designed to protect sensitive data from unauthorized access.
- All sensitive data should be encrypted on clients such as Kafka producers and consumers.
- Organizations own and manage the encryption keys in their own key management system (KMS).
- Confluent does not have access to the encryption keys or data in plaintext.
- CSFLE is based on existing governance capabilities like Schema Registry and tags.
Why should I use client-side field level encryption?¶
Here are some reasons to use CSFLE:
- Confluent employees, including SRE and Engineering, cannot access sensitive data.
- Sensitive data cannot be exposed through third-party tools such as Amazon S3, Datadog, Splunk, or other tools.
- CSLFE meets important compliance requirements for data privacy and security.
Which fields should be encrypted?¶
- Only encrypt fields that contain sensitive data. For example, encrypt fields that contain personally identifiable information (PII) such as social security numbers, credit card numbers, or other sensitive data.
- Do not encrypt fields that are used for filtering or sorting. For example, fields used for filtering or sorting should not be encrypted because encrypted data cannot be filtered or sorted.
- Encryption and decryption processes in field-level encryption execute on your clients. Sensitive data is encrypted before it is stored or transmitted, and then decrypted when it needs to be accessed by authorized users, producers, or consumers.
What encryption algorithm is used?¶
By default, the data encryption key uses the Advanced Encryption Standard (AES) algorithm in Galois/Counter Mode (GCM) with 256-bit keys (also referred to as AES-256-GCM).