The Unfinished Business of Business Intelligence Part 3
On a need to know basis: securing the data, content, navigation and tool access
As soon as possible – possibly even before the BI tool selection has been finalized – the business must be consulted and guided to understand the best approaches to security:
Data – in what ways must the data coming from the database be secured? Row-level security is the most obvious approach; often it can be controlled either through the queries generated by the BI tool – therefore governed by the BI applications team – or else through customized views or Virtual Private Databases (VPDs) that are implemented by the DBAs. Columnar security may be required, in which case choosing either columnar omission or obfuscation must be discussed; the BI tool’s columnar security capabilities must be clearly understood. An often overlooked requirement is Single Sign-On to the Database (SSO2DB): the corporation may require end-to-end auditing of an individual’s access all the way from desktop logon to database access. Not every BI tool supports SSO2DB, and implementing SSO2DB requires collaboration across virtually all of the previously discussed areas of expertise.
Content – reports and dashboards – implicitly secure data through omission: the BI content only shows the intended type of data. Behind the implicit restriction of data access there are these considerations:
a. Feature/function access – all of the major BI products offer very fine-grained control over what an end-user can do, ranging from viewing content to creating the map between the business model and the physical data sources. Each major BI product has its own authorization idiosyncrasies, often involving implicit, non-intuitive hierarchies of access that require time and expertise to understand.
b. Inferential security – in many institutions an unauthorized end-user must not even be aware that certain content exists, as that knowledge would reveal sensitive institutional intent or strategy. This concern can manifest itself in both specific pieces of content – such as the heading of an obfuscated column, or in the navigation across folders where a user can infer something from the title of a report or folder.
c. Cross-user access – even a properly restricted end-user can cause problems if content created by that user can be seen by unauthorized users. A less obvious and sometimes significant issue is an end-user developing and sharing content that is not intrinsically sensitive, but calculations in the content are either incorrect or contradict other more broadly published content; the ways in which certain users are allowed to share their work must also be taken into account.
Navigation to content – thanks to the ubiquity of Microsoft Windows in the corporate world, everybody initially believes that organizing content into a BI tool’s folder hierarchies and then setting permissions is straightforward; the fact is that none of the major BI tools use the underlying OS’s folder security to control access to content. Some tools can restrict access to folder traversal independently of folder viewing, while others do not; this is just one example of where the BI tool’s content navigation metaphor must be thoroughly understood.