Up to now, we have looked at understanding the purpose of an MI system and some options for transforming and securing sensitive data. In this piece, we will look at storing data in a way which supports compliance objectives.
The next principle to support the secure and compliant provisioning of data in BW is: store the data in a way which will support the authorisation design.
It is very common to see data models in BW which have been structured entirely around delivering the functionality of the reports, without consideration of the responsibility to secure data, or the engagement of the authorisation team to provide or restrict access to the data as appropriate. In any LSA (layered, scalable architecture) model, there are several layers in the BI environment which can be used to ensure that data is presented to the reports in a fashion which is functional, performs efficiently and is compliant.
In circumstances where there is no option but to import and present data which is sensitive, our next approach to ensure we can make this available to those users who require it, is to ensure it is stored in a location and a format which supports the correct use of authorisations on this data. Segregating sensitive data and ring-fencing it into limited-access info areas within the data warehouse, will support such a design and ensure that roles and analysis authorisations can be structured in a way that provides different levels access.
One method which have proven particularly effective is to configure a virtualisation layer within the BW data warehouse to store multiproviders, which can be used to 'hang' the reports off. By using this method, it is possible for us to authorise end-users of reports on the multiproviders and infoareas on which the reports are built themselves, without the need to provide access to the detailed infoproviders in which the raw data may be stored.
Hanging the reports in this way, with ring-fenced authorisation on the infoareas (which may be aligned to roles) will allow the analysis authorisations, which support the reporting access, to be linked to the roles themselves. This should always be considered as best-practice, as it will allow for automated allocation of analysis authorisations to the users with minimal manual maintenance overheard.
Once your users have access to the data within the reports it is time to think about the final option we have for securing data, the presentation of reports to users, which we will cover in the next entry.
If you have any comments or questions, please feel free to use the comment submission below or email us at: info@turnkeyconsulting.com
