Replies: 2 comments 3 replies
-
Good question. We've had on our road-map for quite a while to have signed commits, but this requires content addressable hashing to make work properly. For encryption we generally just use encryption at rest on disk. One could also theoretically have commits which were stored with layers encrypted so that they could be pushed and pulled around but only queried when access to a key was presented by the one doing the query. None of this really exists as yet unfortunately and everything basically has to be done in either application code or FS at the minute. |
Beta Was this translation helpful? Give feedback.
-
just notice I didn't mention the typical very wide spread use case for having the need for this combination of requirements
=> All personal data needing, full or partly regulated companies, who need to care for KYC (Know your customers) and AML (Anti Money laundry) processes:
|
Beta Was this translation helpful? Give feedback.
-
Just a question: when thinking about having some nodes whose data needs encryption -> is there a proven practice on how to do that best?
Is there a possibility on database level, or needs this be done purely on application level?
Background:
there are some security standards where encryption on disk-level or partition-level encryption isn't sufficient anymore (e.g. PCI DSS 4.0, future-dated requirements)
PS: couldn't find anything about this topic in doc via google
site:https://terminusdb.com/docs/ encryption
Beta Was this translation helpful? Give feedback.
All reactions