Description
Neptune often stores graph relationships and core application models, making protection of stored data important. Storage encryption protects data, logs, automated backups and snapshots. An actually unencrypted cluster lacks this layer of protection.
Encryption does not replace database permissions or network restrictions. Check the actual encryption state and key of the running cluster.
Potential impact
- Unauthorized acquisition of unencrypted storage or backups can expose graph data and sensitive relationships.
- Organizational encryption-at-rest requirements may not be met.
Remediation
- Explicitly set
spec.forProvider.storageEncryptedtotruefor new clusters and update the base templates in Compositions. - Use the default KMS key or a customer managed key that meets organizational requirements, retaining the necessary key permissions.
- An existing unencrypted cluster cannot be encrypted directly. Plan restoration of a snapshot into a new encrypted cluster, checking data consistency and application cutover.
Examples
These are new-cluster excerpts. Configure the required provider settings and networking separately. Also review backup policy: skipFinalSnapshot: true omits the final snapshot on deletion.
Before
apiVersion: neptune.aws.crossplane.io/v1alpha1
kind: DBCluster
metadata:
name: sample-cluster3
spec:
forProvider:
region: eu-central-1
engine: neptune
enableIAMDatabaseAuthentication: true
skipFinalSnapshot: true
The storage-encryption requirement is not explicit. Check the actual cluster state.
After
apiVersion: neptune.aws.crossplane.io/v1alpha1
kind: DBCluster
metadata:
name: sample-cluster
spec:
forProvider:
region: eu-central-1
engine: neptune
enableIAMDatabaseAuthentication: true
skipFinalSnapshot: true
storageEncrypted: true
This requests encryption for a new cluster. It does not migrate existing data or switch applications automatically.