Data Warehouse Security
Security
Requirement
Need
to define
data warehouse security requirements for an information management
requirements specification and want practical timesaving suggestions?
Information security requirements are specified in the requirements
specification. They should specify who should have access to the
information and who should be allowed to use it.
Sounds easy?
We know who the users are, why not just list their names? Good idea,
but consider a typical information management project:
- Data resides in a source system, and can be
accessed by authorized
users;
- Data is extracted to a staging area;
- It is transformed and possibly moved to a
clearinghouse;
- It is loaded to a data warehouse; and
- Extracted from the data warehouse and loaded
into a data mart where end
users can access it for analytic or reporting purposes.
Each stage of the data movement process involves a certain
security risk.
Source
system
extract
Some organizations have very stringent requirements. They will
not allow external systems to access source data directly e.g. we have
a
requirement to extract data from a credit card transaction
processing system but the policy does not permit this—Instead,
an extract file must be created by the source system and “pushed” to
the staging area. The requirements specification should reference this
security policy.
Staging area
Staging areas are usually a “landing” spot for source data extracts and
this is one place where all data is available for a brief period of
time. Requirements must define access rights, if any, and
should also include requirements for data disposal so that sensitive
data is protected after it leaves the staging area.
Staging areas and/or clearinghouses may also store data that is
rejected for quality issues—Sometimes this data remains in the
staging area until it is corrected by a new feed and sometimes it is
corrected by a data steward—In all cases, security requirements must be
defined.
Data
warehouse
Some organizations let users make ad-hoc data extracts directly from
the data warehouse and others only allow approved processes to extract
data. Access privileges must be specified.
There may be a requirement to aggregate
sensitive data e.g.
Suppose we
have a data warehouse which includes health care prescriber personal
data. We decide to integrate an external data source which identifies
all prescriptions issued within a certain sample area—Although the
"prescriptions written” data does not identify the care giver
or the
patient, it might be possible to determine this if the sample area
is very small e.g. one prescriber and two patients. In this case, we
may
need to specify a requirement to aggregate
data if the sample area falls below a certain threshold.
Data marts
Requirements need to specify which users have access to data
and any data aggregation (for security reasons) specifications.
Other
security considerations
- Consider requirements for other sensitive
corporate data e.g. human resource data;
- Think about test data requirements—Is there a
need to “black-out”
sensitive data?
- Is there any security concerns for project
documentation e.g. are
detail design specifications of value to competitors and if so, what
are the requirements to prevent unauthorized access; and
- Ensure that the requirements specifications
refer to the information
management data security policy to ensure common understanding of all
data warehouse security requirements.
Summary…
The requirements specification should refer to the information
management data security policy for general requirements, and it
should clearly define project related data warehouse security
requirements
and testing requirements.
|
