Simplified Enterprise User Security

How EUS Can Help Simplify And Secure Your User Management Processes 

Enterprise User Security (EUS) has been around for over a decade, but has recently begun to see an uptake in interest. This is in part due to growing security concerns around managing and protecting Enterprise User accounts. As organizations grow in personnel and infrastructure, it becomes increasingly difficult to organize and govern enterprise user accounts. This is where EUS comes in. EUS is a one stop shop for administering user identity, credentials and password policies. It has the ability to enable separation of duties, manage privileges across multiple databases (DBs, and by leveraging LDAP structure, it can be used to utilize group membership - an extremely powerful for enterprise organizations.

So how does EUS work?

The following two diagrams briefly explain the difference between provisioning users in an environment with EUS versus an environment without EUS. 

Before EUS:

In this first diagram, let us imagine that there is a LDAP Directory in use and that it is Active Directory (AD) as seen on the right side. This company has a large employee base and uses AD to manage their Microsoft window accounts. You will notice that there is no connection between the Database and Directory environments. In many cases, companies will have a need to create a user account for certain employees in both locations. Prior to EUS being implemented, a Database Administrator (DBA) would have to create a separate account for that user in every single database they need access to and grant each account the required privileges. In addition to the DB accounts, an Identity admin would have to create a account for that user in AD.

After EUS:

In this case, provisioning a user in AD and granting him access to the appropriate databases becomes much simpler. After configuring EUS, all an Identity Admin would have to do is create that user in AD, then add him to the appropriate groups within AD. 

EUS works by utilizing an additional LDAP directory schema to manage mappings between AD User, Groups, Database Users and Roles. This schema is called the “Oracle Context” and is managed by a Oracle Directory. In the example above we are showing the Oracle Directory to be Oracle Unified Directory (OUD), but it can be any of the Directories included in the Directory Suite Plus collection. The diagram below will provide a better understanding of how these mappings work. 

In this diagram you will see two sides, Grantees and DB Global Roles. The HR_DEVELOPER Enterprise Role is mapping these two sides together, created in the EUS console on Enterprise Manager and stored in the Oracle Context on OUD. This Role has the capability of Mapping existing users and groups in AD to DB Global Roles on Oracle Databases. In addition, the AD Group HR_DEV and the user Judy Dinch are mapped to four different databases and their corresponding global roles. If a user is added to the HR_DEV Group in AD, then they will automatically be granted access to the four DB Global Roles listed under DB Global Roles. 

Not only does this make provisioning a breeze, but it also simplifies all other account management processes. In our experience, many clients have both strict deprovisioning and password policy rules. If an employee leaves a company, all that needs to happen with EUS is that the user account get disabled in AD. That one act will disable the user’s access across all databases which they had access to. Same thing goes for password changes. In addition to the user only having to remember one password now, users will only need to change their password in one location for that change to be reflected across the board. It is a solution that adds security through simplicity, a combination that could greatly benefit all enterprise organizations. 

In addition to simplifying and securing enterprise user account management, organizations can see huge productivity gains for DBAs. With EUS, clients are able to delegate tasks such as provisioning user accounts and granting user access to less skilled individuals instead of the DBA team. Day to day DBA tasks such as access issues, password resets and job changes can be delegated to an EUS Administrator. In addition to account management, the LDAP directory schema used to manage EUS has the capability of enabling database names services in the directory. This will make it possible to eliminate the DBA’s job of managing TNSNAMES files across all clients and servers. 

Since this is the case, teams will find that DBA’s will now have some time freed up to work on higher-value database activities such as design, implementation and performance tuning. You may be thinking that there is will be an extensive ramp-up process for someone to learn how to execute the processes that DBA’s had to handle in the past but that is not the case. Because EUS utilizes Enterprise Manager console as its administrative interface, an Administrator will be able to easily manage all tasks from a single familiar interface. 

By consolidating enterprise user management to a single source of truth, EUS has the capability to greatly simplify and secure current processes as well as provide major productivity gains. Many clients benefit from using EUS in their custom environments.

If you have any questions about how EUS could help your organization, please feel free to contact us.

Avoid Disaster with a Multi-Data Center System

Is Your Company Prepared For A Data Disaster? 

Disaster Recovery (DR) is a term that all heavily computer-dependent companies should be familiar with. It involves policies and procedures put in place to recover vital technology systems from natural or human-induced disasters. 

In the event a company’s system goes down, a Disaster Recovery plan should be in place to ensure productivity isn’t heavily impacted. Such recovery strategies can include clustering, using load balancers and utilizing Multi-Data Center (MDC) Architecture. 

Imagine a system with:

• only one data center containing many application servers in a cluster

• multiple database instances in a Real Application Cluster (RAC)

• many web servers behind a load balancer

If the entire database goes down, that single point of failure will render all of those components useless. This is where DR planning pays off. Having well-implemented MDC Architecture ensures a company will have a DR plan for this instance, and productivity will not go down with the database. 

The MDC approach can be used to distribute load between multiple data centers, as well as prevent an outage if an entire data center goes down. A data center acts as a single system with its own policies, data stores, applications, clusters and load balancers. There are three MDC topologies that can be utilized: Active-Active, Active Standby-Passive and Active-Hot Standby. 

In the Active-Active topology, each data center would be in a different location while a global load balancer in front of the MDC system would send users to one data center. The global load balancer can determine which data center to send users to by using either geolocation or the application they are trying to access. The data centers can be configured to allow data to be transferred among them. Applications can make use of data centers with this configuration because data will be the same. If a data center goes down or traffic spikes, a user can be seamlessly transferred to the next available data center by the global load balancer. 

In the Active Standby-Passive topology, one of the data centers remains passive or shutdown while the primary data center is up and active. If there is a problem with the primary data center, the passive data center will be brought up to replace it until the problem is resolved. 

The Active-Hot Standby topology is similar, with the difference being that all data centers remain up; however, only the primary data center will be used until it fails. While the primary data center is catering to users, the standby data centers will still be reading data from the primary to properly fill in should it become unavailable. 

To keep data centers identical, manual replication would have to be performed, which can be a time-consuming task. It can consist of manually exporting policies from one data center and manually importing them to another. Oracle Access Manager (OAM) has a feature for MDC called Automated Policy Synchronization (APS) that makes maintaining those data centers less intimidating. In an OAM MDC system, a single data center will be configured as the “master,” while others will be configured as “clones.” APS is an automated replication mechanism that pulls changes from the master and replicates them to each of the clones. For a clone to be involved in APS, a replication agreement must be created between it and the master. This functionality was added in OAM 11.1.2.2 and reduces the time needed to update all of the clone data centers by removing the need for administrators to update them manually.                 

For large enterprises that rely on their OAM systems in order to complete their work, the MDC approach will be the way to go when thinking about disaster recovery. With it, there will always be a backup data center available should one of them go down. 
            

---

PROFESSIONAL SERVICES - SENIOR SYSTEMS ENGINEER

EUS Enterprise Roles Developer Use Case

Oracle's Enterprise User Security feature continues to gain adopters who want to centralize account management across all Oracle databases in the enterprise. EUS simplifies and increases quality in processes for adding user accounts, managing credentials, eliminating orphaned accounts, and more.

Organizations who need more convincing may want to take a closer look at theEnterprise Role concept of EUS. Enterprise Roles can actually multiply the economic and security benefits that EUS brings, by introducing a framework for managing database privileges across applications and test levels.

The structure of the Enterprise Role is a pair of collections maintained in the Oracle directory:

• The first collection (Grantees) is of the individuals and/or groups who have access to the Enterprise Role. The organization manages group membership in their enterprise LDAP directory, such as AD.

• The second collection (DB Roles) contains the privileges, in the form of a list of distinct database roles. Each entry in the list contains the identification of a database and a specific role on that database. Therefore, a single enterprise role can span several databases, granting one or more distinct roles on each of those databases.

An interesting application of this has come up in a couple of our customer engagements. The use case involves several development teams who need access to their respective application schemas. Typically, developers hold full modify access (SELECT, INSERT, UPDATE, DELETE) to application data in lower test levels, but only SELECT access in user acceptance and production levels. Let's look at an example:

2 Application Schemas:

• HUM_RSRCE

• PRICING

5 Database instances spanning 4 Test Levels:

• UNIT (both apps run on DB instance: UNITDB)

• INTEGRATION (both apps run on DB instance: INTGDB)

• USER_ACCEPT (both apps run on DB instance: UACCDB)

• PRODUCTION (HUM_RSRCE runs on prod instance: HRPROD; PRICING runs on prod instance: PRPROD)

Database roles defined to manage schema privileges:

• HR_READ -- select on HUM_RSRCE schema objects

• HR_MODIFY -- select, insert, update, delete on HUM_RSRCE

• PR_READ -- select on PRICING schema objects

• PR_MODIFY -- select, insert, update, delete on PRICING

Identification of users requiring Developer privileges:

• For HUM_RSRCE:

  • Members of the HR_DEV group in AD

  • Judy Stinch, the HR IT Liaison

• For PRICING:

  • Members of the MKT_DEV group in AD

  • John Slough, the Marketing IT Liaison

Without EUS the work required to manage all these users and grants on each database, through repeated development cycles and organization changes, would be tedious and prone to error. Let's look at how EUS simplifies this. First, by implementing EUS-managed Shared Schemas, user account provisioning on the listed databases is no longer necessary.

Next we create EUS Enterprise Roles to manage the privileges against each application schema on each test level. First, the local roles on each database must be altered to designate them as global roles. Then, we create just two enterprise roles and their collections in the EUS directory:

HR_DEVELOPER

• associates those needing Developer privileges against the HUM_RSRCE schema with the appropriate global role in the appropriate test level database

PR_DEVELOPER

• associates those needing Developer privileges against the PRICING schema with the appropriate global role in the appropriate test level database

The diagram below provides the details of the HR_DEVELOPER enterprise role and its containers. The PR_DEVELOPER role would have a similar structure.

The power of this arrangement is obvious. A single object, existing in the directory, manages privileges for a class of users across a series of databases. And the privileges can vary from database to database.

Notice that the roles inside each database are the same from level to level. Because of this consistency, operations such as level promotion or test data refresh can execute without any change to the role or grant structure before or after. The Enterprise Role ensures that developer access is immediately available with privileges appropriate to the level.

In this example, we developed a database-level role structure that doesn't have to change across migration levels, then used EUS Enterprise roles to manage the differences in developer privileges across environments. The result is a configuration with:

• higher, more stable security;

• improved quality out of the development process; and

• lower maintenance costs.

Hub City Media has the world's best team to help bring the benefits of EUS to your organization. Please contact us to schedule a discovery session.

---

SENIOR DBA