Skip to main content

Metadata handling

Discover best practices for setting the values of the metadata used in Piiano Vault​

Vault keeps your data safe and encrypts data by default. Vault provides its features using internal structures, internal metadata, and customer metadata. This metadata is saved unencrypted, but Vault protects it with anti-tampering mechanisms to avoid malicious changes. This metadata should, therefore, not include PII.

This reference lists the metadata used in Vault and provides best practices to avoid using PII in this metadata.

note

Consider the information listed here when planning your schema, IAM policy, and supporting configuration.

Internal database structures​

  1. IDs: Every object has a GUID and Snowflake ID. Snowflake IDs are internal only and never leave the vault. You can supply an ID as a GUID for objects stored in Vault, implying it is not sensitive.
  2. Time-related metadata- Timing metadata about the objects appears in all collections. This metadata includes the properties created_at, modified_at, and deleted_at.

Application data​

  1. IAM: All roles, users, and policies are saved unencrypted. Therefore, there is the potential to expose PII.

    Users are commonly applications connecting to the Vault, such as WebApp or ServiceName. There should be no PII exposure here.

    Where the user is a person, PII could be exposed. When granting a person access to Vault, create a username that doesn’t include PII information. For example, use. generic technical usernames, such as support or an alias with initials, such as user_jd (for John Doe), that can’t be easily and directly attributed to a person. Also, consider using a JWT token, instead of an API token, for human users and API tokens for applications.

  2. Collection and property names: Use generic names for collections, such as Customers, Payments, etc., and for property names, such as email, ssn, etc.

  3. Objects:

    1. Whether an object is archived is saved as a boolean flag.
    2. _tenant_id is saved in clear text. Use a GUID or another non-sensitive ID. Don’t include your tenant or customer name in this field.

  4. Tokens:

    1. Type: The token type, such as PCI, Deterministic, etc.
    2. Tags: Use generic tag names. Don’t include PII in your tags, such as email or customer name. Instead, use a hashed value of a customer email or name. Do the same if your application ID is, for example, an email address.
    3. Scope: The default scope is default. Use generic scope names. Don’t include PII in your scopes. Instead, use a hashed value.

  5. Request Headers

    1. The X-Request-ID and X-Pvault-Request-ID shouldn’t contain PII.
    2. The X-Tenant-Id shouldn’t contain PII, similar to the advice about tenant ID in objects.

On this page