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.
See these Data Governance FAQs to understand how IRI software products currently support RBAC in more detail.
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. DarkShield logging is already taking place, and expanding. This current work 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:
Associated with each runtime (masking job) execution is highly granular log data is output to a machine-readable JSON file. The data is subject to analytic queries directly in Voracity, or shared dynamically with SIEM tools like Splunk Enterprise Security (via the Voracity app for Splunk or Splunk Universal Forwarder). Once indexed, the IRI log data is automatically monitored to trigger alerts via an Adaptive Response Framework or actions per a Phantom Playbook, for example.