Vormetric Policy Planning

This topic explains, at a high-level, the primary functions for Data Security Manager (DSM). This article also offers Armor's recommendations for creating Vormetric policies.

Video Tutorial

Prerequisites

Before you begin, you must have:

General understanding of the Vormetric product
General knowledge of the directories/folders on your server that potentially contain encrypted data

Primary DSM Functions

DSM serves two main functions:

Transparent File Encryption

Also known as at-rest file encryption, transparent file encryption performs two tasks:

Encrypts data as the data is written onto the disk
Decrypts data as it is read from the disk

Access Control

The DSM configures policies that control access to encrypted directories. These Vormetric-protected directories are called GuardPoints.

These GuardPoints allow the DSM Security Administrator to:

Maintain granular control over which users and processes can access GuardPoints
Create multiple policies for different types of operational usage
- Vormetric policy access controls work beneath, but in relation to the operational system-level access control lists (ACL).

Policy Functions

There are two main parts to every policy:

Security rules
Encryption Key

Each policy contains a set of rules called Access Control Rules. These rules control:

Access to specific GuardPoints
The encryption key used for encrypting and decrypting

When you create these rules, keep in mind that:

The policy's rules read in descending order, similar to firewall rules.
Each policy rule consist of five criteria that must be met before Vormetric grants users or processes permission to access the GuardPoints.
There can be several rules in each policy, but only one encryption key per operational policy.
There can only be one policy per GuardPoint.

Policy Creation

The number of policies to create varies on the type of data and server you want to guard. Different GuardPoints require different access rules; web servers, database servers, and file servers all host different types of sensitive data and should be protected accordingly. Using the same policy for multiple servers may weaken your security.

For instance, a database server typically contains database files (mdf & ldf), backup files (bak), and static files that only the database process itself needs to access. Here, the policy to guard these files may only require one or two rules to grant full access to the process paths for MSSQL or MySQL. This policy in turn will block everything else.

In another example, a file server typically contains PDFs and configuration files that only specific users need to access. Here, the policy to guard these files requires a rule to grant access for these specific users, and not the database process.

To better understand how many policies you should create, Armor recommends that you create a policy for each server role, similar to the following example:

Web_Server_Policy
Application_Server_Policy
Database_Server_Policy
File_Server_Policy

Next Step: Create a Starter Policy with Learn Mode