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

Centrify's Value Proposition - Part 3: Privileged User/Identity Management with Least Priviliege

In the third part of this series, we'll discuss how Centrify provides solutions for privileged user/identity management and maintains these principles:

a) Eliminates identity silos

b) Implements strong access controls without interfering with the user experience

c) Use what you have: infrastructure, processes, knowledge (less IT fragmentation)

d) Promotes operational efficiency

e) Provides strategic value, rather than tactical solutions

Organizations come to Centrify for privileged identity management or privileged user management because of combinations of the following challenges or circumstances:

•  Overall: They want to increase accountability and implement strong privileged user identity and access controls based on a common identity repository.
• They have Active Directory and multiple platforms, but primarily for UNIX, Linux and Windows
• They have a traditional (on-premise only) or hybrid (public/private cloud) enterprise
• They want to eliminate the use of shared credentials or persistent administrative accounts (root, administrator, “-a”, etc)
• Their existing solution does not provide flexibility on grouping systems based on a security governance model
• They might have chosen to implement a password-centric approach as their unique strategy and they’ve come to realize that their users are less productive (or supportive), that they’ve duplicated identity silos and that ultimately, their systems (the main goal) aren’t protected by it.
• On UNIX: They understand that using sudo/sudoers, although it’s mature may not be enough for high-risk, highly-regulated enterprises; they are tired of the complexities of managing a sudoers file and want more granularity and flexibility
• They want a higher-degree of control on how their users access systems (beyond just granting/denying access) cross platform.
• On Windows, they want to eliminate the problem of the Local Administrator, are conscious of the “pass the x” attacks and want to eliminate the “camping” issue with “-a” accounts.
• They need to provide separation of duties (operational rights vs governance rights)
• They need timely reporting of who has access to what system(s), what are their privileges, and what granted them access to do this.
• They don’t want to deviate from existing processes or realized that by implementing point solutions or “best of breed” they ended-up fragmenting their IT in the context of processes.
• They have regulatory requirements that they need to meet or exceed.  These may be SOx, PCI DSS, HIPAA, NERC, FERC, etc.
• They want to solve the Shared Account Password issue, but they want a solution that reflects the state of modern trends (they hybrid datacenter, IaaS, mobile-first, etc)
• They have high-security requirements like FIPS, solutions common-criteria certified, perhaps they rely heavily on Smart Cards.
• They want log aggregation that is simple to their native tools (ARCSight, LogLogic, Splunk, etc)
• They may need to go beyond the traditional security operations and provide session capture and replay from anywhere (remote or via console) because today they don't have that capability, are required to have it or simply, they might have gone the "jumpbox" route to realize that they are missing crucial sessions.
• They hate having to invest in multiple solutions to enforce the same basic security principles.  Each time they do, this may mean:
  - Evaluate a product
  - Invest or procure new hardware or software
  - Add additional infrastructure
  - Train or hire specialist
  - Maintain the solution down the road
  - Manage the vendor relationship

Here's a technical demonstration on how Centrify delivers this value:

The key differentiation areas are:

• AD Orientation - implemented in more of 90% of enterprises, users use a unique identity.
• Centrify Zones - unique patented way to create groups of systems in Active Directory
• Granularity of Access Controls - control HOW users log in to systems
• Granularity of Privileges - no need to know the privileged account password.
• Simple privilege elevation:  sudo-like tool in UNIX/Linux, shell and command line on Windows.
• No proprietary magic on how events are stored: no need to have a central system just to know who did what and when - need to rely on a central system to correlate who had a privileged account.
• Quick attestation and robust reporting - the data is in AD.
• Separates the operational tasks versus the governance tasks - to enforce SoD
• Works in multiple core platforms:  UNIX, Linux and Windows
• Protects your systems: Provides end-to-end enforcement of the rules as well as session capture and replay.

Finally, the end user experience is not affected, no identity silos are created  and your AD infrastructure, processes and technology are reused.  We propose that the "least access/least privilege" approach to Privileged Identity/Super User Privilege Management should be used at least in 80% of the use cases.

In the next post we're going to talk about the next 20%, this includes Shared Account Password Management, Proxied/Brokered/JumpBox initiated sessions (what gartner calls Privilege Session Management).