[Labs] Centrify's SSH Gateway Explored - On Premises, AWS, Azure and GCP

This article illustrates the steps to set-up a lab to test the SSH Gateway capability of Infrastructure Service.  This capability provides secure access to on premises or IaaS (AWS, Azure or Google Cloud Platform) systems leveraging the Secure Shell protocol (SSH+File Transfer).

Background
Centrify Infrastructure Services provides a full-fledged secure shell and file transfer capability (SSH Gateway).  This "jumpbox"  supports all the core features of the platform including multi-factor authentication, workflow, real-time monitoring and session capture and replay.

Goals of this Lab

• Identity Consolidation:
  • Leverage existing Organizational Directory Services.
  • Accomodate for user populations outside the organization (e.g. Federation, other Directories, etc).
• Usability:  Provide secure access to systems running the SSH Service without visiting the Centrify portal.
• Access Control:  Align with best practices for security access controls, like:
  • Identity Assurance via Multi-factor Authentication.
  • Adherence to the Least Privilege principle  (users shall only access systems and accounts that they have a business need to access).
• Auditability:
  • Event tracking (who, what, when).
  • Allow the real-time proctoring of shell sessions as well as the session recording to be replayed later (e.g. PCI DSS 10.2.2).
• Simplicity and multi-use:  Provide these capabilities with minimal infrastructure or to reuse components of Centrify Infrastructure Service (E.g. leverage other services like AD or LDAP Proxy, or RDP jumpbox services).

Requirements

• A Centrify Infrastructure Services instance (SaaS or Customer Managed) - 17.10 and above.
• A Centrify Connector running the SSH gateway in all the subnets required for SSH jumpbox access.
• A handful of test systems running the SSH Service.
• SSH and sFTP client software.
• If testing "true MFA": An OATH OTP, configured RADIUS token or enrolled Mobile Authenticator.
• Familiarity with Centrify Infrastructure Services.
  • Policy and Authentication Profiles.
  • A configured "Corporate IP Range." 
  • Familiarity with CPS Roles, Permissions and Sets.
• Understanding of the communication paths for CPS (e.g. between connector and instance (HTTPS), between connector and SSH Servers (standard SSH port TCP 22).  Note that these ports are customizable.
• Understading of Infrastructure Services Role-based Access Control.

Conceptual Diagram


This diagram showcases the major components, the location, firewall rules, and additional details depend on the environment.

Diagram for this Lab


High-level Implementation Steps
AWS

• In this implementation, I'm using an AWS VPC as my "corporate HQ"  it has an AD domain, some systems (Windows and Linux) as well as a hosted AD domain.  This will allow me to have different user populations.
• I am leveraging an existing Active Directory and DirectAudit infrastructure.
• Launched a Windows 2012 R2 instance with a public IP address, Fthis instance is in a security group,  that allows inbound HTTPS and SSH from the internet to the instance, plus it can reach the rest of the systems internally, including AD (to allow for it to be joined).
• For internet name resolution, I created a CNAME record in the rpdemo.net DNS domain for the cps record that resolves to the public DNS name for the EC2 instance above
• Obtained a publicly rooted certificate, and exported it with the private key for Privilege Service to use.
• Installed Privilege Service (on-premises) in single-master mode (no HA);
  Note:  The single-master configuration does not provide HA or allows for upgrades.  This is for testing purposes only.
• Added a Centrify connector with the adproxy and SSH gateway services.
• Configured Privilege Service to use my ISP's IP address as part of the corporate IP range.  This is to provide the assurance that only I can access it.
• Configured 2 roles:  An Administrator, and a Least Access role.
• Configured Workflow for the resources.

Microsoft Azure

• Created inbound rules that allow the connector in AWS to reach the systems over RDP and SSH.
  Note: Depending on the services needed, an additional connector in Azure (or GCP) is needed.
• Launched existing Windows and Linux systems.

Test Matrix (Success Criteria)

Category	Description	Result
Identity Consolidation	Users from Active Directory and Centrify Directory can access systems via Web Portal or SSH Gateway.	Pass
Identity Assurance with MFA	Users must use an MFA or Step-up method to authenticate via Web portal or SSH Gateway.	Pass
Policy	Users can only access from a specific subnet.	Pass
Least Access	Users can only access the systems based on business need to know via Web Portal or SSH Gateway.	Pass
Access Request	Users must request temporary access to shared accounts.	Pass
Monitoring (real time)	SSH/RDP – Sessions can be monitored in real time. SFTP – Active sessions can be tracked.	Pass
Advanced Auditing	Sessions can be reviewed after the fact (indexing, replay, etc.)	Pass
Infrastructure Simplicity and Reuse	The same components can be used for other capabilities (e.g. RDP, etc).	Pass

Test Videos
Identity Consolidation and  Assurance with MFA

Policy, Least Privilege and Access Request

Real-time Monitoring  + Session Capture and Replay

Infrastructure Simplicity and Reuse

A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory - Part 5

Background
This is the fifth and final article in the series titled "A Playbook to secure your Amazon AWS Infrastructure using Centrify and Active Directory" in the previous post we discussed how to integrate your Linux and Windows systems to Centrify zones in AWS Active Directory for the purposes of authentication and privilege management.

In this article we'll discuss how to use Centrify Privilege Service to provide shared account password management, privilege session management and recording and strong access controls.  Here are the detailed goals:

• To provide a redundant secure point of access for AWS-hosted systems
• To provide password lifecycle services:  request-approve-check-out-check-in-rotate-auto/rotate
• To provide temporary access (sessions and password checkouts)
• To provide application to application password management capabilities
• To provide advanced jumpbox access to SSH and RDP systems in AWS
• To be able to proctor in real time
• To be able to review session transcription and provide session replay
• To provide advanced access controls like strong authentication, time-fencing, geo-fencing and more
• To continue to leverage Active Directory or use other identity schemes(LDAP, Google Directory, Social Identity, Centrify Cloud Directory or even a SAML IdP as the identity source)
• Minimize exposure by eliminating the need for elastic IPs (publicly facing)

Centrify Privilege Service Architecture
I've written about CPS in the community before, for some features and demos review this article:  http://centrifying.blogspot.com/2015/08/in-depth-centrify-privilege-service.html

In summary, it is a SaaS-based Password Manager and Jump Box (in Gartner speak, provides SAPM, PSM and AAPM), however it uses the assets of identity service:  Federation, Workflow, AD-Bridge, Multifactor Authentication and more.  CPS has a connector-based architecture like this:


This means that there are several ways to use Privilege Service in IaaS scenarios.  However, I will focus on this type of design:

The benefit oft his design is that it allows flexibility. Here are some highlights:

• The single source of identity continues to be the on-premises Active Directory.  AD Principals (like groups) can be used to control entitlements like who can access the management portal, check out passwords, modify resources, etc.
• Allows for connected or disconnected AWS connectivity.  Cloud Connectors in AWS act as jumpboxes, regardless of the EC2 scheme (domain-joined or not) the connectivity is centralized.
• Advanced Controls like
  • Step-up authentication:  Centrify MFA, OATH OTP, Phone factor, SMS, Email, PKI/Smartcard
  • Allow access only from corporate network: Users must be on-premises to access AWS assets
  • Geo-fencing:  access can be limited to only corporate locations.
  • Workflow:  Resource and password check-outs can use an access request system (Centrify or ServiceNOW)
  • Temporary access control.
• Time-to-Market:  Password and session access can be deployed in minutes by launching an instance and deploying a cloud connector.  The same goes for internal datacenters.

We'll discuss some planning and provide some implementation/verification videos:

Planning
Stakeholders:   Infrastructure Lead, Directory Services Lead, Security lead, AWS SME, UNIX/Linux or Windows image lead, Database (SQL Server) SME etc.

Discussion topics:

• What are the systems that need to be accessed?
  The answer to this question has implications for AWS security groups.  For example, the security group where Cloud Connectors will be residing must be able to establish connections over port 22 (SSH) and 3389 (RDP).
• What are the user populations that need access to AWS systems?
  This determines the identity stores.  User populations can be full-time employees, contractors, vendors, etc.  Depending on the existing strategy, maybe not all users have AD accounts, this is where identity flexibility of CPS becomes handy.  Some examples:
  - Temporary contractors may be provisioned in the Centrify Cloud Directory instead of AD.
  - Perhaps ADFS has been implemented or partners need access, in that case CPS can be the service provider in a federation relationship.
• What are the groups that should manage the system?  what are their entitlements?
  The answer to this question has directory service and functional implications.
• What are the security controls to be put in place?  (strong auth, geo-fencing, time-based controls, workflow/approvals)
  The data classification of the systems determines the controls that should be in place.  The most basic could be that all AWS access must be generated from the corporate IP range, and access to the portal requires strong authentication.
• Password Management lifecycle questions:
  Should approvals be required for password checkouts?  Should multiple password check-outs allowed? should passwords be rotated in a specific interval?  Should password health be monitored? should password be allowed from mobile devices? Should passwords for temporary systems be managed?  Should active directory account passwords be managed?
• Password Storage
  Should the Centrify Secure Storage be used or is a physical or hardware HSM (Safenet SecureKey) available?
• Will AAPM or self-registration be needed?
  The answer to this question has implications for AWS images or DevOps.  Centrify provides a Linux package (CLI toolkit); this allows for automation and automatic system registration.
• Monitoring and Reporting
  What events should be sent to log aggregation (SIEM) platforms?  What reports should be generated and who are the consumers of these reports?
• Attestation
  What is the process of validating that certain privileged users should have (or continue to have) access to certain resources?
• Session Recording
  What is the data retention policy for audited sessions?  How many concurrent sessions (SSH/RDP) can be expected?
  These topics are covered in depth in Chapter 2 of the DirectAudit Administrator's guide. 

Implementation
In this example, I will use an AWS environment with Active Directory to:

• Add a cloud connector for privilege service session management
• Manually register some EC2 Linux and Windows systems for jumpbox accesss
• Manually manage the password of a local Linux, Windows and Active Directory domain account.
• Use two AD groups:  AWS-CPS-Full Access and AWS-CPS-Read-only access. Members of the 2nd group must request access for password checkouts or proxied sessions.
• Enforce Strong Authentication.
• Using the CLI toolkit for CLI password checkouts and manual and automatic.

Moderation note:  Due to the blog's 20K character limitation, videos will be used.

Requirements for this Lab

• An AWS instance with Active Directory (managed by you or hosted by Amazon)
  • Two AD groups:  AWS-CPS-FullControl & AWS-CPS-Limited
  • A Domain Administrator to authorize the cloud connector
  • Outbound Internet connectivity via single-attached Elastic IP or Internet gateway (preferred)
• From Centrify you'll need:
  • A Centrify Privilege Service evaluation or production tenant with sysadmin-like credentials.
  • The Installation bits for Centrify DirectAudit
• A domain-joined system for:
  a) Centrify Cloud Connector (although not recommended, this can be the DC if running a simple lab).  Cloud connectors require outbound HTTPS connectivity and to act as jumpboxes for Linux and Windows systems, they should have connectivity over TCP ports 22 and 3389  (or your custom ports if changed).
  b) DirectAudit components:  this will be the not recommended all-in one scenario (Database/Collector/Agent). 
• Test Linux and Windows EC2 instances.
• Optional:  An Android/iOS mobile device for Touch/OTP MFA or a Yubikey 4 or NEO for OATH OTP

Requirements Verification

Installing a Cloud Connector

Installing DirectAudit

Configuring Roles for CPS Access


Configuring Workflow and Approvals

Using the CLI Tookit (AAPM)


Managing Active Directory Domain Account Passwords

Session Management, Proctoring, Capture and Replay

Dashboards and Reports

Advanced Controls (Policies, Authentication Profiles, Strong Authentication)


Adjustments
Some of the adjustments that can be made include:

1. Password storage:  HSM or Secure Centrify Storage
2. Different directory sources for different user populations
3. Smart Card Authentication
4. Bulk import of systems
5. CLI tookit baked into master AWS EC2 Linux instance.
6. Use of PowerShell to automatically register Windows accounts
7. Limited visibility of resources using the Privilege Portal login right.

End of Series - Conclusion
This ends the series on AWS and hopefully you've seen how the Centrify product lines:  Server Suite, Privilege Service and Identity Service work together to secure your AWS environments while balancing operational efficiency and productivity.