Nomenclature

We have some terminology that may be entirely intuitive and some specific to the product. We have some common terms defined below.

Structure

Organization

Shared accounts where users can collaborate across many vaults at once.

Vault

A partition for storing data within a VGS organization. An organization can have many vaults.

User

An individual account that can be added to an organization, to work on a certain vault, and forthcoming, have different defined roles.

Product Terms

Client

An entity that makes a request through the VGS platform.

Credentials

Outbound routes and all sftp proxies are authenticated. Credentials are required to access these zones.

Route

An endpoint exposed to a customer that allows sending data from one point to another. A Route has a source and a destination that determines the flow of traffic through the vault. Filters are then attached to the Route to determine what data is transformed and segmented as it passes through the Route.

Filter

A set of conditions that define when data should be operated on as it passes through a Route. When the conditions are evaluated to true, then a set of operations (pipeline) are executed according to the phase.

Record

An entry in the vault. A record has raw value, fingerprint and identifier. Identifiers present on redacted data and used to find the raw value on data revealing. Identifier can have multiple formats, currently supported record identifier formats are UUID, PDF, and FP (format preserving).

Records currently come in two varieties:

  1. Aliases - text based records
  2. Documents - binary based records, for example PDFs

Redact

To remove sensitive information from the payload and replace them with a different value.

Reveal

To restore sensitive data pieces on previously redacted payload.

Operation

A transformation or action on information. When a filter is matched it will apply a series of operations on the matched data.

* OPERATIONs before the REDACT or REVEAL of the data
* OPERATIONs after the REDACT or REVEAL of the data

Storage

The storage value controls how aliases are stored. A persistent mode allows storing data on a permanent basis. Volatile storage has an expiration of 1 hr.

Pipeline

A set of operations. The output of each operation in the pipeline is the input for the subsequent operation.

Phase

Each message passed through a route has a phase.

  1. Request
  2. Response

Upstream Host

The host that sits of the remote side of the route from the client who is initiating the request.

Upstream URI

Upstream host + path.

Target

The part of the payload passing through the proxy that will be operated on when a policy is matched (can be HEADER or BODY).

Alias Formats

Formats comes in several varieties to choose from based on your use case.

  1. Generic - VGS Alias: Can be used for any piece of data, alphanumeric data is fine. Format returns a surrogate value like tok_sandbox_xxxxxxxxxxxxxxxxxxxxxxxxx where the x’s are alphanumeric characters.
  2. Generic - Numeric Length Preserving: Can be used for any number that needs to have it’s length maintained for form validation or other reasons where the length returned matters.
  3. Payment Card - Format Preserving, Luhn Valid (6T4): To be used for Payment cards when you need them to still go through a validation check and capture the BIN (Bank Identification Number) and the last four digits. Example 4111111111111111 becomes something like 4111119381251111.
  4. Payment Card - Format Preserving, Luhn Valid (T4): To be used for Payment cards where you do not need a BIN but it is still Luhn Valid to pass validation checks on your system. 5555555555554444 would become something like 9399630812244444.
  5. Payment Card - Prefixed, Luhn Valid, 19 Digits Fixed Length: This format makes it easy to distinguish between real sensitive data and the surrogate values. For example 4012888888881881 turns into 9914040119524511881 The prefix here is 99 with 1 reserved for versioning of this format.