[
https://issues.apache.org/jira/browse/HDDS-17096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siyao Meng updated HDDS-17096:
------------------------------
Description:
THREAT_MODEL.md does not say what a GDPR bucket (created with
{{--enforcegdpr}}) guarantees, so findings about it cannot be routed to a §8
property or a §9 non-property. The feature is a crypto-erasure aid: the Ozone
shell marks keys written into such a bucket with the GDPR flag, the client
encrypts them with a random per-key secret that the OM stores in the key
metadata (in a TDE bucket the key is encrypted with TDE instead), and on delete
the OM removes the secret (and, in a TDE bucket, the encrypted data key). It is
not encryption at rest; TDE is (§8 item 6).
Add a §9 entry stating this, including what it does not cover: the secret is
returned to readers of the key and has copies in the Ratis log and RocksDB
files until purged or compacted, in OM DB copies (checkpoints, Recon) and in OM
snapshots; stored blocks are not authenticated; keys written through the S3
Gateway or ofs/o3fs are not marked, so they are not GDPR encrypted.
Also add a §11a known non-finding for a recurring report class: key names that
are visible, despite a per-key ACL that denies READ, to a principal who can
list the bucket or the parent path (for example through recursive listStatus,
listKeys or a snapshot diff). Per-key and prefix ACLs control access to a key's
content and metadata, not the visibility of its name in listings.
was:
THREAT_MODEL.md does not say what a GDPR bucket (created with
{{--enforcegdpr}}) guarantees, so findings about it cannot be routed to a §8
property or a §9 non-property. The feature is a crypto-erasure aid: the Ozone
shell marks keys written into such a bucket with the GDPR flag, the client
encrypts them with a random per-key secret that the OM stores in the key
metadata (in a TDE bucket the key is encrypted with TDE instead), and on delete
the OM removes the secret (and, in a TDE bucket, the encrypted data key). It is
not encryption at rest; TDE is (§8 item 6).
Add a §9 entry stating this, including what it does not cover: the secret is
returned to readers of the key and has copies in the Ratis log and RocksDB
files until purged or compacted, in OM DB copies (checkpoints, Recon) and in OM
snapshots; stored blocks are not authenticated; keys written through the S3
Gateway or ofs/o3fs are not marked, so they are not GDPR encrypted.
Summary: Document GDPR bucket guarantees and key name visibility in
THREAT_MODEL.md (was: Document GDPR bucket guarantees in THREAT_MODEL.md)
> Document GDPR bucket guarantees and key name visibility in THREAT_MODEL.md
> --------------------------------------------------------------------------
>
> Key: HDDS-17096
> URL: https://issues.apache.org/jira/browse/HDDS-17096
> Project: Apache Ozone
> Issue Type: Task
> Components: documentation, Security
> Reporter: Siyao Meng
> Assignee: Siyao Meng
> Priority: Major
> Labels: pull-request-available
>
> THREAT_MODEL.md does not say what a GDPR bucket (created with
> {{--enforcegdpr}}) guarantees, so findings about it cannot be routed to a §8
> property or a §9 non-property. The feature is a crypto-erasure aid: the Ozone
> shell marks keys written into such a bucket with the GDPR flag, the client
> encrypts them with a random per-key secret that the OM stores in the key
> metadata (in a TDE bucket the key is encrypted with TDE instead), and on
> delete the OM removes the secret (and, in a TDE bucket, the encrypted data
> key). It is not encryption at rest; TDE is (§8 item 6).
> Add a §9 entry stating this, including what it does not cover: the secret is
> returned to readers of the key and has copies in the Ratis log and RocksDB
> files until purged or compacted, in OM DB copies (checkpoints, Recon) and in
> OM snapshots; stored blocks are not authenticated; keys written through the
> S3 Gateway or ofs/o3fs are not marked, so they are not GDPR encrypted.
> Also add a §11a known non-finding for a recurring report class: key names
> that are visible, despite a per-key ACL that denies READ, to a principal who
> can list the bucket or the parent path (for example through recursive
> listStatus, listKeys or a snapshot diff). Per-key and prefix ACLs control
> access to a key's content and metadata, not the visibility of its name in
> listings.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
