In This Document
Was this document useful?
Have a suggestion for the Armor Knowledge Base? Send a message to firstname.lastname@example.org.
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.
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
- Access control
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
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).
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.
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: