Using Akeyless to Enable Zero-Trust Secure Remote Access

Implementing a Zero-Trust security model ensures your organization isn’t trusting anyone or anything automatically, from inside or outside of your organization. In addition to blocking threats, you also need to monitor and detect activity that puts your organization at risk.

There are 4 key scenarios where Zero-Trust is extremely relevant and actionable (that is, taking the “buzz” to actual measurements):

Admin / Human Access

1. Work-from-home (BYOD) 
2. 3rd-party vendor access (i.e external supplier periodic maintenance tasks)

Machine Access

1. Management Servers with Machine to Machine interaction (i.e CI/CD & Configuration Management)
2. Application access to resources (i.e Kubernetes container that access SQL DB)

Taking it down to earth

Each of the above scenarios would eventually require the same Zero-trust principles to be implemented. In the field of authentication and authorization, there are are three fundamental principles that make up a well-defined zero-trust solution:

• Just-in-Time Access (AKA JIT)
  The first principle requires that humans and machines would only gain access when it’s needed. As an example, when a configuration management system needs to access a Linux server it will use an SSH certificate that was created specifically for that access; meaning there won’t be a permanent ‘open-access’ SSH Key that can be used forever. Generally speaking, according to the JIT approach, secrets (aka credentials) and access permissions are generated on demand and are ephemeral in nature to ensure they become invalid once the required action has been completed.
  
  
• Principle of Least Privilege Approach
  The second principle requires Security Architects to ensure that users (human or machine) within their organization have their access strictly enforced, with only enough access to perform their specific business tasks AND only for the time period they need it. For example, a DevOps engineer needs admin permissions to a Kubernetes Cluster to make configuration changes. They should only gain access to the specific cluster and specifically with the required permissions to perform the task (for the DevOps guys who read this – no worries – this should happen seamlessly without changing the usual way you are used to work).
  
  
• Zero-Standing Permissions (AKA ZSP)
  The 3rd principle actually combines both Just-in-Time Access and the Principle of Least Privilege approach, where it eliminates permanent access, the ‘always allow’ to privileged accounts for both humans or machines. Every request to resources is validated from scratch, including an authentication request. Requests are made only when needed, and the ephemeral nature of zero-standing permissions (ZSP) ensures they’re enabled for specific tasks only. Another major benefit of ZSP is your servers or databases don’t hold sensitive secrets that could be compromised. An example is an SQL database where your users table is completely empty, meaning, no one has constant permission to access the database, as said – “Zero-Standing Permission”. When an identity asks for access it will be granted temporary credentials that would be created at that moment, and would provide the minimum permission required for the minimum time needed to perform the task – “Least Privileged Approach”. This way, an attacker would find it extremely difficult to acquire improper access or escalate privileges from an existing weaker account. 

Why Akeyless is in the best position to provide Zero-Trust?

After reviewing the above principles of Zero-Trust Access, we’ll demonstrate how Akeyless Vault secrets management helps you implement these principles within your environments.

1. Akeyless Vault speaks the language of every machine or human that wishes to gain access
   First, you need the ability to receive the access request. Akeyless enables interconnectivity with any channel, tool and protocol through your preferred method – SDK (Java, Python, Go, JavaScript), CLI, API, Web UI, provides built-in plugins for any DevOps tool and agentless support for SSH, RDP, Kubectl, SQL and Web-application Access.
   
2. Akeyless Vault supports multiple authentication methods and 3rd-party identity providers
   Second, you’d need to authenticate the access requestor using 3rd Party Identity Providers. Akeyless Vault utilizes 3rd-party IdPs for the SSO authorization of the access request to interact with your applications; MFA is supported. Additionally, Akeyless Vault validates the client request with the IdP.
   
3. Provide access, using just-in-time Secrets Creation 
   – The ability to create any type of credentials – Akeyless Vault creates new and temporary credentials for any entity you work with, such as  RDP, SQL, LDAP, AD, AWS-STS and more.
   – The ability to issue a certificate on the spot – Akeyless Vault functions as a Certificate Authority to generate short lived certificates. By doing that, it eliminates the operational burden of updating expired certificates, as well as the security risks associated with certificates that are set far into the future and could be compromised.
   – Creation of minimum privileges for the created credentials/certificates, according the customer’s policy. For example, Akeyless Vault allows to set exact roles in a DB for a temporary user that is created ad-hoc.

4. Ability to delete the credentials, in order to make them temporary and to make sure that eventually there will be a zero standing permission.
   
5. Fine-grained auditing through ongoing monitoring to generate a full audit trail and offer complete transparency into who authorized access and who was given it, when it was granted and when it expired.

Want to see how a Zero-Trust security model works?

Get a demo Akeyless