This glossary defines common terms that you might see as you're working with Piiano
A mechanism that allows or prohibits the use of an API operation or CLI command by a user as part of identity and access management. See Access control in How IAM works for more details. Compare to Data access control.
Access control allows or prohibits the use of API.
Data access control fine-tunes the access rights to a specific object.
Data associated with an object in the same or another collection. Vault supports relationships between objects in collections based on PERSONS and DATA schemas.
Data from an application or system that resides in Vault.
Data about an individual stored in a Vault collection.
Personal Identifiable Information (PII)
Data that can be used, alone or in combination, to identify an individual. Examples of PII data include full names, social security numbers, phone numbers, and email addresses. The collection and processing of PII is governed by regulations such as General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA).
PII data types
Data types specific to PII, such as those for social security numbers, phone numbers, and email addresses.
A mechanism that defines a user's access to the capabilities of or data stored in Vault. For example, to access all properties of a person, a user needs the policy for accessing unsafe REST APIs and CLI commands.
The definition of a field in a source system stored in Vault.
A reason for issuing API. CLI uses
maintenance as the default reason. For the complete list of built-in reasons, see Policies. To specify a custom reason, set the
other and use the
adhoc_reason to specify the actual reason.
Vault maintains the following named resources: data types, properties, and transformations. See the specification and examples in Policies.
A collection of access control capabilities and data access policies. See Users and roles.
An identifier that replaces data in the source system to provide additional security for sensitive information. Users with an appropriate policy can use the token to obtain the original data value.
A mechanism for reducing the sensitivity of personal data, for example, by returning only the day and month from a date of birth field.
Privacy by design
Privacy by design is planning – taking all privacy considerations into account as part of the development – and implementing a system and architecture that fully supports individual rights and protects people's data. Such an architecture should normally have a data inventory, retention policies, minimization policies, consent management support, security mechanisms, etc., for sensitive data. In privacy, having control over the data is key – knowing who, when, and where the data was collected from and consulting this metadata when the data is being processed.
Security by design
Security by design is the planning and implementation of a system that should be foundationally secure. Typically such a system employs principles such as zero trust, chain of trust, attack surface reduction, isolation and segregation, access controls, input sanitization and verification, monitoring, etc. A key goal is building an architecture that is robust to implementation bugs as much as possible.