Manage Sensitivity Labels
This feature allows you define sensitivity labels as an ordered flat list such as: Unclassified > Confidential > Secret > Top Secret. Each sensitivity label has a defintion, a hide data property (only used when applied to a column/field), and a color (for example confidential can be orange and top secret red).
Sensitivity labels can be manually applied by authorized users (with the Data Classification Editing capability object role assignment ) to any individual object.
there is no inheritance such that setting a schema secret does not make each of its tables and respective columns secret.
However, there are inferred sensitivity labels so that when you apply a sensitivity label to an imported object, e.g. a column, then all the imported objects “downstream” in the data flow lineage will be given at least that level of sensitivity.
Sensitivity labels can also be updated in bulk (e.g. multiple columns at the same time).
Sensitivity labels can be automatically set through automatic data classification detection . For example, a data class SSN can be associated to a sensitivity label called Confidential or GDPR . In such case, any table columns or file fields detected as SSN will also automatically be set with that Confidential or GDPR sensitivity label.
The approval process of data classes also applies to sensitivity labels. In addition, approving a data class detection on a given object also approves its associated sensitivity label.
A sensitivity label may also be assigned to all new imported objects (data elements) on import (harvesting) a model. In addition, on subsequent imports, new data elements will be given the defined sensitivity label, but existing ones will not be changed. This way, one may assign a sensitivity label and even hide the data automatically for every data element in a model on the first harvest and approve or change that assignment, while on subsequent harvests only newly imported data elements will be assigned the automatic sensitivity label.
Sensitivity labels are highly visible in the UI , and can be used in worksheets (queried through Metadata Query Language (MQL) in the UI or the REST API ). Applications can be built to query these sensitivity labels in order to automatically generate / enforce data security on the data stores (e.g. databases or file systems with Rangers). Note that sensitivity labels do not directly set or bypass the role based security of the repository, or automatically hide data from the repository (these actions can be set separately).
Did this page help you?
If you find any issues with this page or its content – a typo, a missing step, or a technical error – let us know how we can improve!