Limit data collection to only necessary attributes for user profiles.
389-DPC-001 - severity: medium
| Field | Value |
|---|---|
| Control ID | 389-DPC-001 |
| Severity | medium |
| Type | preventive |
| Owner | IT Operations |
| Status | authored |
| NIST 800-53 | SI-12, PT-3 |
| DISA SRG | SRG-APP-000516 |
Rationale¶
Collecting and storing more personal or sensitive attributes than an application actually requires directly increases the blast radius of a data breach: every additional populated attribute is a liability that attackers can exfiltrate and that regulators can audit. Under GDPR data-minimisation requirements (Article 5(1)(c)) and HIPAA minimum-necessary rules, retaining attributes beyond operational need creates compliance exposure even before any breach occurs. Schema bloat also increases the effort of applying correct access controls, because each custom attribute must be covered by ACIs - unused attributes that lack deny rules provide unnecessary read access to anyone with directory query rights. NIST SP 800-53 SI-12 and PT-3 directly require limiting the retention and collection of personally identifiable information to the minimum necessary for the authorised purpose.
Check¶
Review the attribute types and object classes actually in use for over-collection.
dsconf <instance> schema attributetypes list
Remediation¶
Remove unnecessary custom attributes/object classes and document the minimal required attribute set.
# Identify unused custom attributes/object classes from the schema list and the data,
# then remove them, e.g.:
dsconf <instance> schema attributetypes remove <unused-attribute-name>
# (verify the exact remove subcommand with `dsconf <instance> schema attributetypes --help`)
References¶
Implementation Notes¶
This is primarily a data-governance and process control that is enforced through schema hygiene. Before removing any attribute type or object class, audit the live data to confirm the attribute is unpopulated or unused - removing a schema element that is still referenced in entries will break those entries and may cause replication errors. The dsconf <instance> schema attributetypes list output distinguishes server-built-in types from custom ones; focus the review on custom entries added outside of the standard RFC 2252/4519 attribute set. The exact subcommand for removing attribute types is version-dependent - verify the available subcommands with dsconf <instance> schema attributetypes --help before running a removal in production. Document the approved minimal attribute set in a data dictionary and use it as the baseline for future schema change reviews.