Self-Service Role Requests for Just-in-Time Privilege
Minimize security risk by enabling administrators to systematically request a new role to obtain the rights they need to perform tasks. Access request for privileged roles enables organizations to grant temporary privileges and roles with a flexible, just-in-time model that accommodates fluctuating business needs.
Minimize Cyber Risk Exposure & Limit Lateral Movement
-
Reduce risk by minimizing the attack surface with temporary, time-bound privileged access to on-premises and cloud-based infrastructure.
-
Automatically limit the duration for which approvals are valid.
Self-Service Role Requests for Just-In-Time Privilege
Enable administrators to log in as themselves and elevate privilege by systematically requesting a new role assignment to obtain the rights they need to perform tasks. Self-service request system facilitates the request for the specified role and time period, and if approved will automatically revoke that entitlement upon expiration.
Time-Bound Privileged Access
Minimize the attack surface by enabling temporary, and time-bound access to privileged accounts and privileged roles for just-in-time privilege. Grant IT admins access to privileged account credentials, remote management sessions or when they need to temporarily modify their role assignment for performing additional admin tasks. Optionally, monitor privileged sessions for suspicious activity and terminate instantly. Prove that access controls are working as designed with reporting on approved privileged access versus actual access to critical infrastructure.
Privilege Elevation Request via Third Party Solutions
Reduce the risk of data breaches by requiring approval for IT users who need access to systems with privileged roles. IT users of the ServiceNow® asset management and configuration management database (CMDB) or SailPoint Technologies® identity governance and administration solutions can request usage of a role with privileges to access specific servers for a designated time period. Approvals are granted or denied through a workflow-based management process.
Learn how the Privilege Elevation Service minimizes the risk exposure to cyber-attacks caused by individuals with too much privilege.
See Centrify Privilege Elevation Service in Action
Centrify Privilege Elevation Service: Just Enough, Just-in-Time Privilege
Watch this video to learn how Centrify Zero Trust Privilege Services help establish a just enough, just-in-time privilege approach across on-premise and cloud infrastructure
-
Tony Goulding: Let me set the stage. Our favorite administrator, Zack Admin is a Centrify administrator responsible for managing Centrify tools and application on both Linux and Windows computers. We're going to experience Centrify Privileged Access Security through his eyes, on a typical day.
Tony Goulding: First we'll look at his interactions on Linux, then Windows, then we'll look at a cross-platform capability.
Tony Goulding: So I'm at the Centrify Password Vault portal. I'll enter my password and as you can see, I'm being asked for a 2nd factor of authentication as a means of identity assurance…this is the first of many layered throughout Zack's activities and is part of Centrify's "MFA Everywhere" capability. Note that you have full flexibility on a per user or per resource basis to apply MFA or not - your choice based on context and your specific security needs and
Tony Goulding: I'll select Email for this one. There's the Outlook notification. I'll open that up and click Continue With Authentication to approve. That was successful. I'll close this browser tab and go back.
Tony Goulding: I was immediately logged in. So from here, I want to do some Centrify administration on Linux so I'll click on Systems to navigate to the list of managed resources.
Tony Goulding: I want to login to the Red Hat box, so I'll right-click to bring up the contextual menu and get a list of accounts I'm allowed to access, based on my role.
Tony Goulding: I'm going to log in with a shared account, "CENTRIFYADMIN". Note that best practice is to login as yourself for full accountability, but there are times when you have no choice but to login with a shared account so we need extra security controls to ensure it's not being abused or misused.
Tony Goulding: The first step is to request approval as denoted by the lock icon. So let's do that.
Tony Goulding: I'll enter some rationale and send it off.
Tony Goulding: Workflow will route this request to an one or more approvers. Let's switch screens to the Cloud Admin and approve.
Tony Goulding: I'll navigate to the Requests page…Coincidentally, you see an email alert advising a pending request, which is also visible at the top of the list.
Tony Goulding: Let's open that up and approve. As you see, the approver can specify whether to grant temporary or permanant access. We'll give Zack 5 minutes to get his work done.
Tony Goulding: Now, back on Zack's session, note the padlock icon is now gone and we can log into the box.
Tony Goulding: Before we get to the interactive Linux session though, we see a second example of MFA. This time, it's MFA on session initiation - at the portal level. Oh and there's the approval email from the last step. Let me close that notification out.
Tony Goulding: This time, let's choose an SMS Text message. There's the notification. I'll click on that and approve.
Tony Goulding: Eh voila, I'm now logged into my Linux machine.
Tony Goulding: Now, since this is an account with minimal accountability, i.e., it's a shared account not tied to an individual user, we can put restrictions on what's permitted. In this case, we've established a restricted shell. We're able to prevent the user from running any commands except those we have approved in a white-list.
Tony Goulding: As a Centrify admin though, Zack can run Centrify tools, such as ADINFO.
Tony Goulding: Of course as an alternative approach, we could have given Zack a regular shell and via roles, granted him permission to run specific applications with elevated privilege.
Tony Goulding: OK, let's exit from here and move our attention to Windows.
Tony Goulding: Here, let's login using Zack's AD account. Once again, we see MFA at work. However this time, it's MFA down at the OS level - at the Windows Credential Provider layer.
Tony Goulding: We're querying the Centrify Identity Platform for 2nd factors specific to Zack. Let's just go with SMS again.
Tony Goulding: There's the notification, let's approve and we're logged in.
Tony Goulding: For this part of the demo, Zack has 3 Centrify apps at his disposal. We've enabled various levels of security, so let's look at them 1-by-1 starting with the Licensing Service.
Tony Goulding: If I just run this, you see it's asking for admin credentials. Since, for best practice, Zack has logged in as himself with minimum privileges and the administrator password is securely vaulted, Zack can't do this.
Tony Goulding: However, he's been given a Centrify role allowing him to RUN WITH ADMINISTRATOR PRIVILEGE. Now he's able to run the app. When he closes it, he's back down to least privilege again.
Tony Goulding: For the next example, he again runs the app with Privilege. However, we consider this app to be more sensitive and so Zack has to assure his identity via a 2nd factor.
Tony Goulding: The Centrify Identity Platform provides a valid list of 2nd factors and Zack picks one. After approval, the application runs.
Tony Goulding: Now on to the final example. Zack tries to run the Centrify Audit Analyzer app with Privilege. However, he has not been assigned a Centrify role. So, he goes back to his portal to request access.
Tony Goulding: For this demo, we've only give him one role to choose from, so he selects that. Let's enter some rationale, choose the type and duration of access, and log an associated trouble Ticket number…
Tony Goulding: Back as Cloud Admin the approver, let's go to the Requests list… and approve the request.
Tony Goulding: So now, back on the Windows system, let's try again to Run with Privilege. The role was automatically assigned and Zack is able to view the Centrify session recordings.
Tony Goulding: Now for a cross-platform access demo. Let's see how Centrify's patented hierarchical Zoning mechanism tied to Active Directory allows us to grant cross-platform roles. I.e., roles that can contain a mix of Linux, UNIX, Windows, even Mac privileges, so you're not forced to manage roles and rights separately for each platform type.
Tony Goulding: In this example, Zack wants to edit the SSH Config file on Linux and run the Centrify Connection Test tool on Windows.
Tony Goulding: Let's begin with Linux and login with a shared "Cross Platform" account. I'll fast-forward through the MFA…
Tony Goulding: As you see, he has read-only access to the SSH Config file and doesn't have a Centrify role to elevate privilege.
Tony Goulding: Over to Windows, we'll login with the same shared account. Again, he doesn't have permission to run the Centrify app.
Tony Goulding: As before, he could request the role but instead, let's take a look under the covers to show how Centrify Zones can work cross-platform.
Tony Goulding: I've opened the Centrify Access Manager, where roles are centrally managed through AD. Note I have Linux and Windows computers located in separate Child Zones so I can manage roles for each platform type. However, I can also define and apply roles at the parent zone level, that will apply cross-platform.
Tony Goulding: Here in the ROLE DEFINITIONS, I have created a CROSS PLATFORM ROLE.
Tony Goulding: Inside it, I've assigned a Linux right to edit SSH CONFIG and a Windows right to run the Centrify Connection Test tool. Let's assign this role to our shared Cross Platform account.
Tony Goulding: I'll pick the role from the list…and search AD for the cross platform account to assign it to.
Tony Goulding: That's done.
Tony Goulding: Back on the Linux box, let's try that command again…success!
Tony Goulding: Back on Windows, let's run the Test Tool again…success!
Tony Goulding: Centrify is the only vendor with the ability to assign a single role to a single AD account granting privileges across multiple platforms.
Tony Goulding: We've demonstrated various ways to protect ourselves using legitimate IT admin scenarios. But what about malicious activity. Can we monitor and alert on the execution of specific commands or changes to files? This next scenario could be a malicious attacker or even a well-meaning but somewhat lazy internal IT admin who simply wants to get the job done quickly.
Tony Goulding: Here, Zack has decided to install a back-door SSH key on the Linux boxes he manages. That way, he can log in with a single click instead of having to go to the vault and request approval to checkout the root password every time he needs to perform some maintenance which could be multiple times per day.
Tony Goulding: He begins at the Centrify password vault. In the list of available accounts for the Red Hat box, he checks out the password. We're not going to repeat the access request and MFA steps as we've already demonstrated them.
Tony Goulding: So with the password in-hand, Zack opens a local Terminal session and uses the password to log into the Linux box.
Tony Goulding: He navigates to the folder where the root "authorized_keys" file is kept.
Tony Goulding: Now he proceeds to create a new SSH key. The public key will be appended to the root authorized_keys file and the private key will be copied to Zack's local system.
Tony Goulding: Before Zack moves to install the public key, however, see the notifications on screen (and on my iPhone). Let's open the text message we received.
Tony Goulding: As you can see, even before Zack has installed the SSH key backdoor, IT has been notified of its creation and can take immediate corrective action. Even though the vault and its session recording has been bypassed, Centrify's host-level session recording provides full forensic level details.
Tony Goulding: As a final demo, let's look at how MFA can be improved to accommodate unforeseen situations. Typically, MFA depends on static policies which presume you know what kind of compromises are routine. It's also on or off, i.e., there may be low-risk situations that don't warrant 2FA but users are still burdened with having to go through it every time.
Tony Goulding: As you see, my current location is in Santa Clara on the US West Coast.
Tony Goulding: I'm going to attempt to login to Windows server TG-Demo.
Tony Goulding: Based on prior behavior the system recognizes my action as being within acceptable norms, i.e., at a Low risk level. So I got single sign on to the server.
Tony Goulding: Now, you see I've set my location to the US East Coast in Secaucus New Jersey. I never log in from here, so as you can see, I'm being prompted for a second factor of authentication. The analytics engine has assessed this as medium risk activity. I'm going to approve the SMS request and try logging in again from Secaucus to show that the analytics engine will learn from correct responses to MFA challenges. As you see, this time I'm logged in…the activity has been re-classified as low risk based on my prior response.
Tony Goulding: Finally, I've set my location to Russia. The analytics engine will take various factors including time of day, location, user velocity (i.e., the practicality of logging in from Russia only minutes after logging in from the US East Coast) and determine this to be high risk. Our policy is set to deny access in this situation as you can see on the screen.
Tony Goulding: If we go to our analytics portal, we can see the events. I have search criteria I baked earlier so I'll navigate to that to isolate events specifically for me. There they are.
Tony Goulding: Here you see my login from Centrify HQ assessed as low risk. Above that are the 2 logins from Secaucus, the first being medium and prompting for MFA, the second being reassessed as Low based on the success of the MFA challenge. Finally you see the high risk event located in Russia.
Tony Goulding: So to recap some of the benefits of the capabilities you've seen in this demo:
- Centrify provides a single integrated set of services for securing individual accounts with privilege as well as shared privileged accounts.
- Our goal is a "zero trust model" supported by Just Enough Privilege granted Just In Time
- Our platform provides MFA everywhere you need it using traditional static policies or advanced behavioral analytics.
- We support true cross-platform privilege elevation with a common role model
- Auditing and monitoring where you need it, at the shell, process, proxy, and host OS level for complete visibility
- Centrify is supporting the hybrid enterprise by extending these capabilities consistently across the data center and public and private clouds