Role-based access control
Determine who can do and see what
RBAC options today
The 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 influence. The ability to mask data (e.g.) during movement, manipulation, and reporting allows you to build data governance into your processes.
The platform-independent and server-independent nature of IRI software also means you can leverage existing frameworks like LDAP and Active Directory object mappings to manually apply role-based access controls (RBAC) at different levels (data, metadata, and executables). Furthermore, access to masked data in products such as IRI FieldShield controlled through differentiated access to job scripts and field encryption keys. Authorized users with a copy of the executabfieldield executable (or DDM library) and a correct script (or application) and decryption key, for instance, would be able to see the original plaintext values, whereas everyone else would not; they would only see ciphertext at rest.
Access to IRI metadata and activity can be done through free Eclipse team plugins such as Git, CVS and Subversion, or the IAM-controlled Release Manager of erwin EDGE (AnalytiXDS data governance)Platform for ETL, data quality, data masking, etc. projects in the IRI-Voracity-Platform (including FieldShield, DarkShield, etc.) will continue to be rolled out and managed. You can also access the client to IRI Workbench and control over work areas for Voracity and/or component products like FieldShield at the O/S or VM level.
Read this Data Governance FAQs, in order to understand how IRI software products currently support RBAC in detail.
Coming soon
Furthermore, IRI is now developing an architecture for data management at the order, data source, and field levels for IAM/authentication and provenance logging directly within its core program. SortCL, which executes Voracity, FieldShield, NextForm, and RowGen jobs. DarkShield logging is already in place and being expanded. This current work will enforce role definition and separation at uniquely granular levels for each job, allowing you to control not only datastore and column access, but also specific field functions and values/ranges in a role-governed manner.
Within this framework, several options for behavior upon permission denial should also be supported, which are defined in a secure policy file created by the „Governor“ in the IRI Workbench and in LDAP/AD folder definitions:
Each runtime execution (masking job) is associated with a high-granularity log data output to a machine-readable JSON file. The data is either subjected to direct analytical queries within Voracity or dynamically integrated with SIEM tools such as Splunk Enterprise Security (via the VoracityApp for Splunk or Splunk Universal Forwarder) exchanged. After indexing, the IRI log data are automatically monitored for example via an Adaptive Response Framework or actions via phantom Playbook triggering alerts.