Table of Contents Table of Contents
Previous Page  82 / 96 Next Page
Information
Show Menu
Previous Page 82 / 96 Next Page
Page Background

W H I T E P A P E R

© 2017 Persistent Systems Ltd. All rights reserved. 82

www.persistent.com

Column-based security – Most DB engines provide out-of-the-box column-level permissions to be set for a

role or user or a group of users.

Deriving access control policies based on OLTP or source data is not recommended and rather should be

based on how users of DWwill be accessing the data and for what purpose.

Metadata-based security model

This approach is common when enterprises want to control the data access at a more fine-grain level or

driven by applying certain business rules like organization hierarchy with

certain policies relevant to the business, where DB provided roles/groups are not sufficient. For example,

in a workforce analytics, there can be contractor workers who are part of an organization hierarchy but

certain labor account and employee related policies are also to be enforced simultaneously.

In this approach a custom layer is built, where list of objects, their permissions to various users, or groups,

or roles, is configured.

While projecting the data out of the DW via views, views have to be joined with these custom metadata

objects and, based on the logged user; the view is filtered to provide access to the allowed rows or

columns.

The configuration of metadata can also be xml-driven or defined in a json file; however, it cannot be directly

used in views and warrants a building a thin access layer on top of the DW.

Column-based – When DB provided column permissions are not enough and some business rules need

to be enforced based on user login, then sensitive data can be either masked or projected via stored

procedures or routines which project only the required columns where the users have access to.

This is a cost-intensive and performance-overhead adaptation, so such requirements have to be considered

carefully.

OLAP / data cube security

OLAP is meant to provide quality inputs to the end-users in a reasonably quick time. Thus, growth in the

number of users accessing the cube increases over a period of time and demands a good security model.

Most vendors provide framework to access control the OLAP cubes.

Since OLAP is exploratory analysis in nature, security controls may hinder the access to the data and

therefore good auditingmechanism should be in place.

Data Encryption

rd

If the data in the DW is to be accessed by 3 party systems (say web services or vendors), it must be

transported with encryption enabled.

Encryption over the wire prevents malicious users from intercepting data they might not otherwise have

access to.