Overcoming the Identity or Infrastructure Duplication to Secure Linux Instances in Public Clouds

Background
Securing Linux instances in public (or private) clouds often requires the duplication of infrastructure (or additional overhead) just to be able to provide basic services like authentication.  Centrify just debuted a new client that leverages a capability called Identity Broker.  This allows users of Centrify privilege service to extend authenticaiton to Linux systems using Active Directory, LDAP, Google Directory and others without the need to implement extensions to AD or LDAP or any supporting infrastructure (like site-to-site VPNs).

The Challenges (AWS as an example)
In previous blog posts, we discussed the additional controls that can be implemented on top of Amazon's IAM and cryptography-based capabilities.  The model suggested the use of Active Directory and Centrify Server Suite.
Regardless of the solution, organizations need to find ways to extend this infrastructure by using these techniques:

• Re-creation of infrastructure (e.g. standing-up Active Directory or LDAP-like infrastructure)
• Network extension (e.g. treating the public cloud like a branch by implementing site-to-site VPNs)
• Capability duplication (e.g. implementing software and services in AWS)

In this article we'll discuss how organizations can leverage Centrify Privilege Service and the new Linux Agent (Identity Broker) to secure Linux instances and extend Enterprise Identity out to public clouds without the need of the additional overhead.

Centrify Privilege Service

Privilege Service is Centrify's answer to the traditional "password-driven" use cases (the industry refers as Shared Account Password Management, Privilege Session Management, etc);  however unlike other solutions, there are several capabilities areas that set it apart from the traditional "Password Vault"

• Flexible deployment:  Both as SaaS and On Premises  (in fact, it was designed as a SaaS solution first)
• Identity Sourcing and Federation built-in (includes Identity Service, this means support for AD, LDAP, Google and others  plus simplified SAML-based federation and 3K+ ready web and mobile apps)
• Policy, Workflow and MFA Engine:  Policies for time and geo-location, RBAC, step-up authentication and Multi-factor including Smartcard, plus a built-in access request system (+ServiceNow integration)
• Infrastructure Extensibility:  Privilege Service can be extended to any network using a Windows-based Centrify Connector via web protocols.

New Linux Agent
The new Linux agent takes advantage of a capability called "Identity Broker" this allows the bridging of identities known to Centrify Privilege Service;  this is done via the Centrify connector.  This means that the overhead of duplicating enterprise identity infrastructure or extending the enterprise to the public network can be avoided in this particular use case;  all that is required is to deploy a Centrify connector wherever you want to extend Password-related services and Linux authentication.  Let's show an illustration.

Company X needs to provide identity-based reporting and attestation of who has access to their public cloud EC2 instances in AWS;  their primary identity source is AD.  They could have used any model (independent forest, one-way trust + site2site VPN or RODC) to extend AD to AWS  or they could have deployed Amazon IAM roles and used SSH keys; but any of these models implied additional overhead.  With CPS and Identity Broker, all they did is this:

With this model, CompanyX not only can accomodate their corporate IT users, but external entities as well.  And as we discussed before, password, session and additional services are consolidated as well, both on premises and on any public cloud.  Plus

• No need to deploy "jumpboxes" to the private clouds (limits exposure)
• Shared account passwords for local accounts (Linux, Windows) or databases (like Amazon RDS) can be controlled
• Access Request provides the assurance of "documented approvals" to sensitive systems
• Deploy MFA or access only from the OnPrem network as additional controls.

Agent Architecture
The client architecture is using UNIX frameworks like Name Service Switch (Identity) and Pluggable Authentication Modules (Auth).  It also supports offline login as well as direct or proxy-based user/password or OAUTH-based enrollment codes (very useful for automation). This client implements the CLI tookit for setting, retrieving or deleting credentials under management.

Supported Platforms
Platforms supported in the initial release - more on the way

UNIX Identity
Following on the legacy of Server Suite, the new agent generates identity like DirectControl in workstation mode.
Login - user's short name (must use the fully-qualified name the first time)
UID - auto-generated based on the GUID
Primary group - auto-private (same as UID)
GECOS - the display name in Centrify Identity Service
Home/Shell - configurable in the Settings tab.

Since most public clouds don't need legacy identity (for services like NFS), this makes the client very lightweight.

Automation
There's an implied expectation of DevOps "friendliness" when a private or public cloud solution is implemented.  The new Linux agent leverages enrollment codes for this capability.

Centrify provides a sample AWS script that can be used with enrollment codes in the User Data field or with any other framework like OpsWorks (see attachment)

Identity Broker
Privilege Service can accomodate several identities, including:

Note that it can accommodate identities from Active Directories without any trust relationships.
These identities can be aggregated using Identity Service Roles:

 Roles, in turn can be assigned the AgentAuth privilege on a Linux Resource:

As you can see the model works like this:
Users or groups from Identity Sources are added to CIS Roles that are granted the AgentAuth right in CPS.

Basic Commands
Agent Operation

• cinfo – obtain information about the agent
• cenroll – enroll the identity platform and enable features
• cunenroll – leave the platform and optionally delete resource and any managed accounts
• cflush – flush the local cache

AAPM

• csetaccount – add a managed account for the resource
• cgetaccount – obtain a managed account’s password
• cdelaccount - delete a managed account's password

HOWTO - Implement a cross-platform mixed DBA Role (Oracle+SQL Server) using Centrify Server Suite

What you'll need

• Active Directory and a Centrify Zone
• Centrify Access Manager and access to perform the configuration
• A UNIX or Linux System and the Centrify Enterprise Edition Agent (DirectControl/DZ & DirectAudit)
• A Windows System and the Centrify Enterprise Edition Windows Agent (DZWin/DAWin)
• Two Active Directory Groups and a test user.

Planning

Privileges Based on Roles
In the previous entry, you saw how we conquered the issue of limiting access to systems based on business need-to-know and how we can create a SuperUser-like role across platforms.  Now it's time to implement a true Role Based governance model.  Just like with any capability (security included) you must achieve balance on the people-process-technology triad, in the context of Roles, its key is to understand how people use privileges in their job functions, implement a process around it and leverage the technology to implement it.  Here's an oversimplified example for DBAs in a mixed Oracle and SQL Server shop.

How DBAs access systems:   SSH and Toad on Linux and RDP on Windows
Typical tasks needed for operations:  In Linux, DBAs need to run the sqplus command as the Oracle account and switch user to oracle.  In Windows, DBAs need to run SQL Server Manager and to manipulate the SQL Server Service.
Typical tasks needed for change-control:  DBAs need to elevate to Root during upgrades and installations.

In my fictitious company, I will allow the SSH PAM access role and the commands to run sqlplus and switch to oracle.  The Sysadmin role (that allows to elevate to root) will only be granted with a change-control number and duration.

This process needs to be adjusted because of two things:

• Resistance to change
  I guarantee you that users will initially think that you're making their jobs harder and will try to find ways to resist.
• Nuances around how people perform their jobs
  For example, a Windows DBA may also need access to SQL Server Configuration tools; or a UNIX DBA may like to switch user without profile  (su oracle, instead of su - oracle).

So be ready to have a review of roles and rights with certain cadence, to add/remove commands or apps; as well a to make usability adjustments.  Make it part of your attestation process.

In our example, we'll use the Centrify-Model-Mixed-Role-DBAs group to provision this role.

Access Based on Roles
The concept continues to be the same as the previous post, but now you are further breaking down your access governance model based on your needs.  For example:  you may have a DEV-QA-PROD train for an application and you can grant access just to that set of systems, and you can classify systems based on that model;  This is where your investment in Centrify Professional Services can pay the most.   In my example, I'll just use a Computer Role called Mixed Database Servers, based on an AD group called Centrify-Model-Mixed-CR-Database Servers.

Security Operations Requirements
In the previous example we leveraged both the UNIX Syslog and the Windows Event log to augment log collection capabilities.  Since DirectAudit data is contained inside a SQL server database, this is another repository that can be tapped by log aggregators.  Since DirectAudit provides session data, information gathered from security operations can be further investigated by looking at session data.

Provisioning
Here the principles continue to be the same as the previous entry. Granting or revoking the role or making a system part of the collective is performed via AD Group Membership (Manually with ADUC, Programmatically with PowerShell or Scripting and controlled via any Workflow engine)

Planning for Platforms
Same exceptions apply:  IBM AIX with LAM enabled don't allow the breakdown of PAM access rights.

Implementation
Just like the previous entry, remember that these steps can be automated via Centrify adedit on UNIX/Linux or Centrify Access Module for PowerShell as well as the DirectManage SDK.

Recap: Rights go into Roles, Roles are configured and Assigned to AD Principals in a Given Scope (zone, child zone, computer role or individual computer)

Step 1:  Create the AD Groups for the Computer Role and to assign the Roles

1. Manually you can open Active Directory Users and Computers (ADUC)
2. Navigate to your designated OU, right click > New > Group.
3. Select the appropriate scope and give it a name.  In our case we repeat this for both Centrify-Model-Mixed-CR-Database Servers and Centrify-Model-Mixed-Role-DBAs

Step 2:  Create the Mixed Database Systems Computer Role

1. Open Access Manager and right-click your Zone > Authorization > Computer Roles and Select Create New Computer Role.
2. In the New Computer Role window, give it a name (Mixed Database Systems), description and browse for the Centrify-Model-Mixed-CR-Database Servers group.  Then Press OK.

Step 3:  Create the DBA commands to be used in UNIX and Linux platforms

SQL Plus as Oracle
Creating this command requires a bit of research. Information about the diversity of platforms, versions and their differences are relevant. For example, in my environment, I’m using Oracle Express 11G running on Linux.

Another important detail has to do with the environment variables. I want to conserve them in this case so sqlplus has all it needs to launch correctly:

Switching to the Oracle account
Some DBAs may need to do a simple (no profile) elevation, or they would want the opposite, Centrify offers the flexibility of Regular or Global expressions.

Service Control for the Oracle Service
More research required. In my environment, the service is oracle-xe and I will limit the directives available for service.


Step 4:  Create the DBA commands to be used in Windows platforms

SQL Server Management Studio
Windows application rights provide a lot of flexibility. Some key highlights

• You can consolidate several applications in a single command
• Applications can be defined manually, by looking at local or remote processes or by browsing directly to the file.
  
• Application arguments can be evaluated with or without case sensitivity
• Application types can be further broken down (e.g. exe, bat, cmd, vbs, ps1, etc.)
• Additional criteria can be added based on the file metadata (e.g. version, company, etc)
• Application rights can be executed in 3 different contexts
  • As a service account: the user in the role does not need to know the credentials.
  • As a member of an AD group without persistent membership
  • As a member of a Windows built-in group (like Power Users, etc.)
    

In the case of the SQL Server Management studio, I have a Windows native deployment with a SQL management account. I can easily use an AD group, but since I have this privilege elevation mechanism, I don’t need to fall into the bad habit sharing that account - there are many other ways to accomplish the same objective.

Stop, start and query the SQL Server Service command
I'm choosing to use the service control command line utility (sc.exe) in the context of the local administrator account to provide the DBA with the ability to control the SQL server service.  The alternative today is to grant the DBA administrator rights, which they can use to stop other services (like the AV or firewall).


Step 5: Creating, configuring, assigning the role and provisioning a user
This process follows exactly the same steps of the previous post. Keep in mind that the Windows rights will be for remote (RDP or Citrix) and to add the UNIX and Windows rights after the role is created.

The role assignment will be performed at the Computer Role level, so it only applies to computers provisioned into that group. Finally you can add your test user to the group that gets the role assigned.

Part of our process dictates that if they do need higher privileges, they can request it based on a change control approval.


Step 6: Verifying and the rights on the UNIX/Linux system
To view the role attributes and definition, use the dzinfo command

$ dzinfo
User: thomasf
Forced into restricted environment: No

  Role Name        Avail Restricted Env
  ---------------  ----- --------------
  Mixed            Yes   None
  DBA/Global

    Effective rights:
        Password login
        Non password login
        Allow normal shell

    Audit level:
        AuditIfPossible

    Always permit login:
        false


  PAM Application  Avail Source Roles
  ---------------  ----- --------------------


Privileged commands:
  Name             Avail Command               Source Roles
  ---------------  ----- --------------------  --------------------
  DBA Oracle -     Yes   service oracle-xe     Mixed DBA/Global
  oracle-xe              start|stop|status|re
  service                start
  control/Global
  DBA Oracle -     Yes   su oracle             Mixed DBA/Global
  switch to
  oracle
  no-profile/Glob
  al
  DBA Oracle -     Yes   sqlplus *             Mixed DBA/Global
  sqlplus as
  oracle/Global
  DBA Oracle -     Yes   su - oracle           Mixed DBA/Global
  switch to
  oracle with
  profile/Global

To view the command definitions, use the dzdo –l command

$ dzdo -l
AD Password:
User thomasf may run the following commands on this host:
    (root) service oracle-xe start|stop|status|restart
    (oracle) sqlplus *
    (root) su oracle
    (root) su - oracle

To use your privileges via privilege elevation use dzdo

$ dzdo service oracle-xe restart
Shutting down Oracle Database 11g Express Edition instance.
Stopping Oracle Net Listener.

Starting Oracle Net Listener.
Starting Oracle Database 11g Express Edition instance.

Finally, and for the benefit of security operations, all privilege elevation continues to be written to syslog:

Dec 27 15:15:53 engcen6 dzdo:  thomasf : TTY=pts/3 ; PWD=/home/thomasf ; 
USER=root ; COMMAND=/sbin/service oracle-xe restart

Step 7: Verifying and the rights on the Windows system

In Windows, to view the role definition, you can open the Authorization Center in the System Tray, the role definitions tab shows the applications defined for the role, double clicking provides a deeper dive.
 
To use your privileges, in the GUI you can use the Run as role shell extension, pick the role and the application will be launched as defined. Finally, just like with UNIX, privileged elevation will be logged in the Windows Event Log.
 

Step 8: Session Capture and Replay with Audit Analyzer
Audit analyzer provides a very neat view of what's going on with your audited systems;   in the left pane you have queries and categories, on the right side you can see the sessions.  The columns include the AD user, the client and server systems, the status of the session, etc.


If you drill down into a session, you can see an index of the commands or events that happened during the session.


Looking at a replay, provides you with the event data +  a video of the terminal or Windows session.


Reconstructing what happened (especially on Windows platforms) is as simple as just watching and controlling like a DVR.


Finally, let's look at this scenario and do some testing:

This article is a repost of  a two-part series I wrote for the Centrify Community.