Role-Based Access Control (RBAC)
Designating Who Can Do and See What
RBAC Options Today
IRI software makes it easy for data and information stewards to control the data that Data Warehouse ETL architects, business users, governance teams, and report designers can access or affect. The ability to mask data during movement, manipulation, and reporting (for example), allows you to build data stewardship into your processes.
The platform-agnostic and server-independent nature of IRI software also means that you can use existing frameworks like LDAP and Active Directory object assignments to manually apply role based access controls (RBAC) at various levels (data, metadata and executable files). In addition, access to masked data in products like IRI FieldShield can be controlled through differential access to job scripts and field encryption keys. For example, authorized users with a copy of the FieldShield executable (or DDM library) and correct script (or application) and decryption key will be able to see original plaintext values, whereas everyone else would not; they would only see the ciphertext at rest.
IRI metadata access and activity can be further role-managed through free Eclipse team plug-ins like Git, CVS, and Subversion, or the erwin EDGE (AnalytiXDS data governance) platform's IAM-controlled release manager for ETL, data quality, data masking, etc. projects in the IRI Voracity platform (which includes FieldShield, DarkShield, et al). You can also control access to the IRI Workbench client itself, or to the workspaces for Voracity and/or constituent products like FieldShield, at the O/S or VM level.
In addition, IRI is now developing job-, data source-, and field-level data governance architecture for (IAM/authentication and lineage logs directly within its core SortCL program, which runs Voracity, FieldShield, NextForm and RowGen jobs. This will enforce role definition and segregation at uniquely granular levels of each job so you can role-control more than just data store and column access, but also specific field functions and values/ranges.
Multiple options for permission-denied behavior as determined in a secure policy file created by the 'governor' in IRI Workbench and LDAP/AD folder definitions should also be supported in this framework: