This document discusses security considerations for designing a data warehouse. It states that security is paramount but should not constrain the goal of making data widely accessible. Various aspects of security are addressed, including user access classification and restriction, data classification, network requirements, documentation of security policies, auditing of data access and changes, and handling of views. Maintaining security adds complexity and requires planning access controls, auditing, and testing to ensure proper functioning.

2. •A data warehouse by nature is an open, accessible system.
•Aim : Make large amounts of data easily accessible to the
users
•Any Security restrictions seen as obstacles to that goal,
become constrains on the design of data warehouse.
•This is not to say that security is not important; on the
contrary ,security is paramount to ensuring that the data
itself remains clean,consistent and integral.

3. •It is important to establish early any security and audit
requirements that will be placed on the data warehouse.
•Clearly, adding security will affect performance and design
of data warehouse.
Security can affect many different parts of the data
warehouse such as
User Access
 Data Load
 Data Movement
 Query Generation

4. Data Classification
 Based on sensitivity
 Based by role or job function
User Classification
 Based on Department,Section,Group etc..
(User access hierarchy )
 Based on their role
(Role access hierarchy )

5. Data warehouse Inc.
Sales Marketing
Snr Analyst
Analyst Analyst
Administrator Aggregation Detailed
Database Reference Summarized Detailed
Admin Data Data Sales data Sales data

6. Data
Ware House
Sales Marketing
Data Mart Data Mart
Users Users

7. Data warehouse Inc.
Sales Marketing
Analyst Administrator Snr Analyst Analyst Administrator
Analyst Analyst Administrator
Analyst Analyst
Analyst
Detailed Reference Summarized Detailed
Sales data Data Sales data Customer Data

8. Select
customer,account_number,sum(value),count(transaction_id)
From
txn_last_quarter
Where
transaction_date
between ‘01-jun-96’ and ‘30-jun-96’
Group by
customer account _number
---------------------------------------Restricting users by using views as--------------------------------------------
Create view sales_lq as
Select
customer,account_number,sum(value),count(transaction_id)
From
txn_last_quarter
Where
transaction_date
between ‘01-jun-96’ and ‘30-jun-96’
and
account_id<>123456789
Group by
customer account _number

9. Create view sales_lq as
Select
customer,account_number,sum(value),count(transaction_id)
From
txn_last_quarter
Where
transaction_date
between ‘01-jun-96’ and ‘30-jun-96’
and
account_id<>123456789
or
account_id<>234567891
Group by
customer account _number
•Where possible, avoid the use of views to enforce data access restrictions. They can
rapidly become a nightmare to maintain.
•Use Multiple Tables instead of views also creates duplication and overheads.
•Create a dummy field in position or nullify it from the user.

10. •Legal Requirements
The design team will require some analysts with knowledge and experience of
business area.
•Audit Requirements
connections
•disconnections
•data access
•data change
Understand the reasons for each audit requirement.
Only implement those that are genuinely required for local, company and
security reasons.

11. •Network Requirements
When doing the security requirements capture it is important not to overlook issues
such as network security.
 encryption of data needed?
 which network routes the data can take?
•Data Movement
 Where is the flat file is stored?
 who ha access to that disk space?
 do you backup encrypted or decrypted versions?
 do these backups need special tapes to store ?
 who has access to these tapes ?
 Where that temporary table to be held ?
 how do we make such tables visible ?

12. •Documentation
It is probably better to document all the restrictions as part of a seperate data
warehouse security policy document.
 Data Classifications
 User Classifications
 Network Requirements
 Data Movement and storage requirements
 All audible actions
•High Security Environments
Trusted RDBMS
! Trusted RDBMS will generally run on trusted operating systems.
 Covert channels
! Avoid creating covert channels that Inadvertently make information
about data available.
! Covert channels are not typically a problem, as the majority of data
warehouses do not require such high level of security.

13. •Views
Some of the common restrictions that may apply to the handling of views are
 restricted Data Manipulation Language(DML) operations,
 lost query optimization paths.
 restriction on parallel processing of view projections.
•Data Movement
Different ways in which bulk data movement can occur
 data loads
 aggregation creation
 results temporary tables
 data extracts
•AUDITING

14. •APPLICATION DEVELOPMENT
Extra Security code may be needed for each of the process managers :
 load manager
 warehouse manager
 query manager
•Data Base Design
If a table has three indexes ,three constraints, and five views on it, each copy
of the table will probably add not just the copy but 11 other objects to the database as
well.
•Testing
Further security additions will increase the complexity of the programme cause
increase in errors during testing phase and also additional added functionality to be