<a id="protect-data"></a>

# Protect Data in Confluent Platform

Confluent Platform components by default are not configured to support data protection features,
including encryption and log redaction. To protect your data, you must configure
your Confluent Platform components to support data protection features. The following sections
cover topics related to protecting the data in your Confluent Platform clusters.

Client-Side Field Level Encryption (CSFLE) is the recommended approach to protecting sensitive
data, however Client-Side Payload Encryption (CSPE) can be used in cases where you are unable to use CSFLE, for example:

- A clear schema is not yet defined or the schema is highly dynamic.  If the schema is not known, a simple Avro “bytes”
  schema can be used with CSPE.
- The schema is extremely large, for example thousands of fields, making manual tagging impractical.
- A CISO team or internal mandate requires full payload encryption for all data within a message.
- You need to move to production quickly and plan to evolve your schema and adopt CSFLE later.

It is recommended that you follow this hierarchy for sensitive data governance:

1. Send all data to Confluent without client-side encryption to fully leverage managed services like Flink and Kafka Connect.
2. If client-side encryption is absolutely required for compliance, use [Client-Side field level encryption (CSFLE)](cspe.md#use-client-side-payload-encryption).
   Only use CSPE if no other option fits.

#### Feature Comparison: CSFLE vs. CSPE

| Feature                | CSFLE                                                                                       | CSPE                                                                                |
|------------------------|---------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------|
| **Encryption Scope**   | Encrypts specific, sensitive fields.                                                        | Encrypts the entire message payload.                                                |
| **Rule Definition**    | Requires defining fields via tags.                                                          | No tag definition is required since the entire payload is encrypted.                |
| **Rule Type**          | Uses the `ENCRYPT` rule type (Domain Rule).                                                 | Uses the **ENCRYPT_PAYLOAD** rule type (Encoding Rule).                             |
| **Access Granularity** | Allows separation of encrypted and non-encrypted fields; fields not encrypted are readable. | Provides all-or-nothing access to the data; the consumer accesses all data or none. |
| **Rule Structure**     | Schema Subject + Tags + KEK.                                                                | Schema Subject + KEK.                                                               |

## Protect sensitive data using Client-Side Field Level Encryption

Use CSFLE to add an extra layer of security for specific data fields,
to help ensure that even if data is accessed without authorization, it remains
unreadable without the decryption keys.

To learn more, see [Protect Sensitive Data Using Client-Side Field Level Encryption on Confluent Platform](csfle/overview.md#csfle-overview).

## Protect sensitive data using Client-Side Payload Encryption

Use Client-Side Payload Encryption (CSPE) to easily encrypt entire messages at the payload or
message level. This feature provides comprehensive security assurance without the operational
burden of field-by-field encryption.

To learn more, see [Protect Sensitive Data Using Client-Side Payload Encryption on Confluent Platform](cspe.md#use-client-side-payload-encryption).

### Encrypt data in motion using TLS

- [Encrypt TLS](encrypt-tls.md#encrypt-tls)

### Redact Confluent logs

- [Redact Confluent Logs](log-redaction.md#log-redaction)

In addition to the standard Kafka security support, you can store sensitive data
(such as passwords, API tokens, and certificates) using secrets management available
in Confluent Platform or using external secrets management tools.

To learn more about secrets management in Confluent Platform, see [Secrets Management](../compliance/secrets/overview.md#secrets).