Deckhand supports encrypting the
data section of documents at-rest to
secure sensitive data. This encryption behavior is triggered by setting
metadata.storagePolicy: encrypted. It is solely the document author’s
responsibility to decide the appropriate storagePolicy for the data contained
in the document.
Note that encryption of document data incurs runtime overhead as the
price of encryption is performance. As a general rule, the more documents
storagePolicy: encrypted, the longer it will take to render the
documents, particularly because Barbican has a built-in restriction
around retrieving only one encrypted payload a time. This means that
if 50 documents have
storagePolicy: encrypted within a revision, then
Deckhand must perform 50 API calls to Barbican when rendering the documents
for that revision.
Encrypted documents, like cleartext documents, are stored in Deckhand’s
database, except the
data section of each encrypted document is replaced
with a reference to Barbican.
Supported Data Types¶
However, Deckhand will attempt to use Barbican’s other secret types where
possible. For example, Deckhand will use “public” for document types with kind
Deckhand supports redacting sensitive document data, including:
- to avoid exposing the Barbican secret reference, in the case of the “GET documents” endpoint
- to avoid exposing actual secret payloads, in the case of the “GET rendered-documents” endpoint
- to avoid reverse-engineering where sensitive data is substituted from or into (in case the sensitive data is derived via Document Substitution)
See the Deckhand API Documentation for more information on how to redact sensitive data.