1. Strategy
2. People
3. Process
4. Metrics
5. Applications
6. Data
7. Architecture
This is the third column that will explore the key considerations of the "Data" focus area.
In Parts 1 and 2 of my columns on "Data" I discussed sourcing , integration and master data management considerations, but there are other important data-related topics to consider, especially:
- Data security management, and
- Data quality management.
Data Security Management
"You've got to make sure that only the right people can see this information."
This type of statement is regularly heard by BI project teams who are working to build an enterprise BI/DW applications. On the surface, requests of this type often sound straightforward, but the more you learn about the security requirements the more complex they can become to implement.
In this column, when discussing security, I am primarily referring to "authorization" - meaning who can see what information. "Authentication" is another security-related topic, but typically BI teams will just adopt whatever standard authentication approaches and technologies are being used within the company. Usually these capabilities are provided by the IT teams that manage the corporate network, and most of the modern BI tools support the standard authentication mechanisms for defining users, passwords and groups.
Why is Security Important?
In most corporations there are typically many factors driving the need for robust information security, including:
Employee data privacy. Core information about employees such as salaries, raises and demographic information is often subject to very tight security restrictions. Companies with operations in Europe are subject to the European Union's "Directive on Data Protection" which limits what information about European employees can be stored or shared even within a company.
Customer data privacy. Incidents of "identity theft" often occur when an employee steals customer information such as names and addresses, Social Security numbers and credit card numbers.
Insider trading concerns. Public companies need to restrict who can see "material non-public information" such as information about quarterly financial performance that has not yet been released. This results in restrictions on who can see information about:
- Revenues and/or expenses
- Forecasts for revenues and/or expenses
General need-to-know restrictions. Companies often want their people to see only the information relevant to their span of control. Things like industry, customers, region, product line, operational unit, HR organization and financial cost centers. Sometimes it's OK for employees to see information about other's span of control, but sometimes they are only allowed to see a summary of the information for comparison purposes rather than the more detailed information
Ensuring trust of data owners. Often companies have people responsible for "owning" data related to particular subject areas, such as finance, HR and customer. These owners want to make sure when they allow the BI team to pull this data into the BI/DW databases that it is being properly secured. Without a data security management approach verifiable by the data owners, they may be reluctant to allow the BI/DW team to use this information
Why is Security Authorization Difficult to Implement?
Let's consider a scenario where a group of users are only supposed to see a particular subset of financial data such as revenue data for the Northeast region.
In this case, you'd want to ensure they can't inadvertently access information they shouldn't see, no matter what tools they are using. This means you'll need to have security rules consistently applied across all the tools being used in your BI application such as EDW and data mart RDBMS, relational reporting tool(s), the OLAP DBMS and OLAP UI tool(s), etc. One challenge is that many of these tools have different methods for controlling information access - especially when you have tools from multiple vendors. But it can still be true even when all the technologies come from a single vendor.
Additionally, this type of requirement will drive the need for controlling "column level" access (due to the revenue-only requirement) and "row level" access (due to the Northeast region-only requirement). Different BI tools also have differing methods for handling these types of security requirements.
What to Do?
First, try to avoid carrying the most sensitive data (for example Social Security numbers) in your BI data stores if at all possible. This is a reliable way to ensure people don't get access to this information outside of the normal business processes that are managed by the transaction systems.
Next, determine the method by which you are going to manage the authentication rules in your BI technologies.
- You could try to do this manually by having someone make updates using the security management capabilities of each of the individual tools. Unfortunately, this may inadvertently leave holes if something is missed. If one of these "holes" is exploited by an unscrupulous end-user, bad consequences could result. Also, doing manual updates this way makes auditing the process more difficult. Questions such as "Who has access to the data right now?," "Who had access to that data three weeks ago?" or "When were access changes made?" may be very difficult to answer
- Another approach is to build a custom security management application. This application would collect information about the available groups of data (such as financial information, sales data, etc.) and where this data exists (this table, this cube, this report) as well as what groups of users should be allowed to see this information. It would then apply these rules to all of the technology layers using the appropriate command syntax for each tool. It would also keep track of the changes, thereby allowing the auditing questions to be easily answered.
Be the first to comment on this post using the section below.