What is orbac? ability to group several authorizations in to profiles to easily add/remove a set of authorizations to an employee

Transcription

1 What is orbac? orbac orbac (opns Role Based Access Control) is a IT security solution that enables a structured, centralized, hierarchical and delegated management of IT privileges. orbac is based on the RBAC concepts and standards, but has no intention being a full NIST-ANSI RBAC implementation. It offers a simple and pragmatic approach to RBAC management, fitting both medium and large organization needs. Because it doesn't implement all the complexity of a full RBAC model it is easy to deploy, easy to configure and easy to operate. orbac is totally based on the Novell IDM solution, using Novell edirectory as a data store and Novell imanager as its web console. When present it uses IDM drivers to provision IT privileges to connected platforms. Essential features of orbac are: ability to define authorizations (like being member of an AD group, being entitled for a VPN access,...) independently of the technical platform owning that authorizations ability to group several authorizations in to profiles to easily add/remove a set of authorizations to an employee ability to automatically assign default profiles to users based on their position into a LDAP tree (= the organization they are part of) and/or their LDAP attributes (= part of their personal characteristics) ability to delegate to people managers, application owners, security officers and/or platform administrators the right to add/remove authorizations to users ability to define which authorization requires an approval (= workflow) before the add/remove operations takes place ability to extract report about who has access to what ability to define which authorization can't be assigned at the same of another authorization (concept of Segregation of Duties SoD), with intelligent management of exceptions to those SoD rules ability to set a time-to-live (duration time or expiration date) to an authorization granted to a user ability to notify system administrators when a change occurred to user privileges concerning the platforms(s) they are accountable for. This is useful for managing non connected platforms; obviously connected platforms are

2 automatically re-programmed to comply with user privileges as defined in orbac orbac is the result of several years experience in medium and large scale projects related to security, Identity Management and/or Access Control. That field experience permitted us to build a solution that, on one hand, is aligned with both industry-standards & best-practices and, on the other hand, is flexible enough to adapt to real-life environments. In short orbac enables companies to: store their access management policies into a central repository provide access control & management in self-service mode integrate RBAC with Identity Management smoothly & elegantly audit and log security-related events easily and centrally create a delegation model that fits business needs take control of IT privileges disseminated over heterogeneous systems reduce costs through self-service, streamlining and automation comply with auditing regulations as HIPAA, Sarbanes-Oxley, Basel-2 and others automate internal processes through electronic forms and workflows report at any time on who has access to what orbac can be delivered as an appliance, as a project or as a SW license. Obviously it requires Novell IDM (formerly DirXML) as an underlying technology to run. Because all interactions with orbac are based on Web forms the solution doesn't require any software to be deployed on users' workstations. Also because Novell IDM is based on a non-intrusive design, no additional software needs to be deployed on servers. This makes orbac very easy to implement in any existing IT infrastructure.

3 RBAC The orbac solution is based on RBAC concepts as described by the NIST institute, and further documented in the ANSI standard (we refer to for more literature on RBAC). Extract from the NIST site: With RBAC, security is managed at a level that corresponds closely to the organization's structure. Each user is assigned one or more roles, and each role is assigned one or more privileges that are permitted to users in that role. Security administration with RBAC consists of determining the operations that must be executed by persons in particular jobs, and assigning employees to the proper roles. Complexities introduced by mutually exclusive roles or role hierarchies are handled by the RBAC software, making security administration easier. orbac provides Web interfaces enabling the creation, edition and deletion of such Roles & Authorizations, and their respective relationships. Another set of interfaces enables authorized persons to assign Roles & Authorizations to Identities within the organization. The end result is the presence, within the underlying directory, of a security reference describing who should have access to what. Further down, when orbac is deployed on an instrumented installation of Novell IDM, this security reference information is used to provision connected platforms, for example adding a user to an Active Directory group to grant him required privileges on a file or folder. orbac description Architecture The 'orbac server' is an appliance type server. It typically sits in the data center and is connected through port 80 & 443 (HTTP & HTTPS), both by administrators, end users and security officers. The orbac server is populated by, one one side, a list of all Identities and, on the other side, a list of Authorizations. Those Authorizations are then grouped into Profiles or Roles so that they are easier to assign to Identities. Relationships between Identities and Roles are then managed through web interfaces with self-service possibilities. Each time a Role is granted or removed to/from an Identity (eventually going through a workflow-based approval process), the orbac engine calculates the impact of the change, converting nested Role and Profiles into individual Authorizations. Then orbac starts communicating the change to affected system(s), either through the underlying Novell IDM provisioning features or using s (sent to systems' administrators for further execution).

4 Web browser HTTPS LDAP (Novell edirectory) server with Identities, Roles & Authorizations Active Directory (file & print services) Novell imanager (Web-based console with delegation & Self-service) ROOT Novell IDM (provisioning)... Identities (Users from Intranet & Extranet) orbac catalog (Roles Profiles, Authorizations, SoD rules,...) orbac extensions orbac execution (Approvals, Time-to-live & s) Operations (placeholder ) Application Server (with database) Intranet -1 Intranet -2 Extranet -1 Users Roles Authorization Catalog Group s OU structure Applications & Profiles Pending Rejected request requests Approved requests Admin Srvs Technical objects orbac is totally integrated into the Novell IDM infrastructure. The architecture of orbac is very simple, and all components are totally integrated into the Novell IDM solution: the RBAC store is the Novell edirectory itself (thanks to schema extensions) the approval status are stored in Novell edirectory objects the approval process is handled by a custom Novell IDM driver the auditing is composed of time-stamped Novell edirectory objects the delegation model is based on Novell edirectory ACL model the User Interface is composed of Novell imanager plug-ins The orbac server itself can be deployed as a Virtual Machine or as a dedicated machine. In both cases it runs on any x86 (32 bits) compatible server with, as a minimum, 512Mb RAM and 4Gbytes disk.

5 based communication Using the SMTP support integrated into Novell IDM, orbac can communicate to any stakeholder in different scenario; this makes orbac very easy to deploy within existing environments with immediate benefits for the organization. However, as explained later, adding native connectivity between orbac and managed IT systems permits better process automation. based communication is used when: A change in granted Authorizations needs to be approved before being processed. In that scenario orbac use s to notify the responsible person(s) about the pending request. An approved change (grant or revoke) in assigned Authorizations needs to be communicated to (a) system administrator(s), and the affected IT system(s) are not natively connected with orbac through a Novell IDM driver. In this scenario the communication is used to notify the system administrator about changes he should perform using his management console of choice. This method, independent from the presence of any Novell IDM connectivity, enables the deployment of a RBAC management model even if IT systems are not connected to orbac. An event (or a process) needs to be triggered in a non IT system. It might be necessary to trigger a process that is not yet computerized when an Identity is assigned a role (for example a process to initiate the purchase order for a mobile phone is started when someone receives the 'Helpdesk' role). In such a case, an is sent to the process owner so that all events related to the granted role (both computerized and not computerized) are managed through one single tool. Segregation of Duties Both in real-life and in the RBAC theory it is possible to have mutually exclusive roles. Also some best-practices, or even laws, dictate that one person with Role A can't be assign Role B at the same time; this is called «Segregation of Duties» (SoD). orbac natively supports the SoD concept through definition of «Excluded Profiles». However our experience shows that, in real-life, the pre-defined SoD rules are sometimes too tight and some exceptions may apply (on either a permanent or temporary basis). orbac provides the required flexibility to handle those exceptions: a user, manager or IT person can request the granting of two mutually exclusive profiles but, in such a case, he is notified about the exceptional aspect of such a request, and an special approval workflow is initiated (for example with a «Security Officer» added to the approval list). The approver then clearly sees that the request is exceptional (because it violates a SoD rule), but he can still accept if

6 the justification is considered as valid. Naturally all those events are audited within orbac audit trace. Temporary grants In some cases it might be necessary to grant privileges to an Identity for a limited period of time. This can certainly be the case when exceptionally granting privileges conflicting with an SoD rule (see previous chapter), when an Identity replaces a colleague during a sickness, when someone participates in a specific phase of a project etc... What happens typically is that the Identity (or his hierarchy) requests additional privileges when needed, but never requests the revoke of those privileges when they are not needed or justified anymore. As a consequence Identities tend to accumulate privileges overtime, and soon get far more privileges than effectively required. Because orbac natively supports a TTL (Time-to-live) parameter per granted privilege, it becomes very easy to define an «automatic revocation date». Thanks to such a feature the total set of privileges of a user is automatically cleaned up from grants that are no more justified. The next version of orbac will add a feature to pre-notify the person N days before the revocation date so that extra time can be requested before the privileges are removed. Delegation With self-service enabled on a central repository that contains all your Identities and all your roles & privileges within the organization, you don't want any specific user to be able to assign (or send requests for assignments) any role to everyone. Also you don't want everyone be able to create new roles, attach privileges to roles, define SoD rules between roles or profiles, approve grant requests etc... To better control who can do what within orbac, our solution uses a powerful and advanced delegation model that enables very fine granularity. The web user interface is also dynamically adapted to delegated functions, displaying only available function to an authenticated user. orbac permits delegation of the following items: Manage Identities-Roles-Profiles relationships: on one hand you can define what other Identities an Identity can «manage». By default orbac proposes a hierarchical model where a manager can only view other users subordinated to him/her. When necessary, the orbac administrator (and/or a Security Officer) can define

7 other scopes, for example enabling the «purchasing» application owner view all users from the IT department. on another hand, orbac can limit the number of Roles & Profiles a specific user can see, and thus assign. It is indeed not ideal to let, for example, an accounting manager view roles like Sales Representative, at least for ergonomic reasons. Manage approvals: Each request is a dedicated edirectory object, and the approval process consists of changing an attribute on those edirectory objects. As such the edirectory ACL determines who can approve a specific request. Per default the profile or role owner, plus a security officer, are set in the ACL of a workflow object. This can be easily customized within orbac. Add/remove Identities: Typically the underlying Novell IDM solution is responsible to synchronize the Identities with an external source (for example a HR database) The administrator can enable Identities creation (for example for external contractors) and delegate that feature to people managers or security officers. Extract reports: orbac has a built-in reporting functionality the delegation model enables restrictions to reporting Because the delegation model is entirely based on Novell edirectory ACLs, the flexibility is almost unlimited. Also because that model is very similar to ACLs on files and folders on a standard Windows server, it is very to understand and to manage. Workflows orbac can use either its own (simple) workflow mechanism or the Novell IDM version 3 (and upwards) solution. The built-in mechanism is very simple and limited to 1 or 2 approvals (per request) running in parallel. This enables the RBAC administrator to define, for example, that a specific Role or Profile requires the approval of the hierarchical manager and the application owner to be effectively granted. Obviously workflows with only one required approval can be defined too; even Roles without any approval associated to them are possible. A new pending request triggers an notification to the approver(s), who then can log in into the (web based) imanager console to approve (or reject) the

8 request. At that point in time the approver(s) has to opportunity to add a TTL (timeto-live) to the granted Role or Profile, for example accepting the VPN access Profile for a period of 2 months. In that last scenario orbac will automatically remove the VPN access Profile after the 2 months period for that specific user. When combined with Novell IDM version 3 workflows (the so-called Advanced Provisioning module), the possibilities are even more extended, with support for 1, 2 or 3 steps workflows, sequential and parallel, automatic re-routing after a time-out and more. Integration with IDM solutions Many customers leverage their investments in IDM technologies to further integrate orbac in process automation. Thanks to IDM «connectors», the effective privileges granted to an Identity (as defined in orbac) are communicated to connected platforms and therefor enforced. This typically happens through remote management of group memberships (for example in Microsoft Active Directory), access control tables in a database (for example for home made applications) and/or manipulation of LDAP attributes in a directory (for example for a LDAP aware Internet proxy server).the tight integration of orbac within the industry leading Novell IDM solution opens the door to maximum connectivity to plenty of platforms. Reports The web console of orbac gives access (to authorized users) to the reporting module. This component permits easy extract of information related to: List of users with a specific Role or Profile assigned to them List of SoD rules currently defined in the system List of Authorizations currently attached to a Profile List of Profiles currently attached to a Role List of users which have an exception on a currently defined SoD rule List of Roles or Profile grants previously approved by a specific person List of Roles or Profile grants previously rejected by a specific person List of Roles of Profiles that a specific user can approve The reporting module is easy to extend and customize (JAVA and Web Services technology) to meet specific customer requirements.

9 Clone user To easy day-to-day administration, and to better support the hire new employee and move employee scenario, orbac has a clone user function that copies the currently assigned oles and Profiles of one user to another. This simple function is a great time savers for line managers that have to grant the same privileges to multiple employees.