Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 59 Next »

This article 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




Was this helpful?

Topics Discussed

  • No labels