IAM Ephemeral access
One of the most common methods of establishing a secure remote connection between a client and a server is by using the Secure Shell protocol and SSH key pairs which are configured for the client and the server separately. Typically, this type of access is called privileged access, since the connection is made to environments with highly valuable or sensitive information. However, key configuration is often manual and time-consuming especially in fast-moving multi-cloud and hybrid environments, where access needs are often temporary and changes are constant.
Moreover, SSH keys never expire by default and can be self-provisioned without proper governance and often provide too much privilege for the task at hand, which decreases the security posture of the environment.
Ephemeral, certificate-based access operates differently. While the connections are still established using existing encryption protocols (SSH/RDP/HTTPS), the primary method of access to the target host is authorized using various industry-standard certificates. Even if the target server does not support certificate-based access, there are other options available.
ContentsHow do ephemeral certificates work? User access configuration Target system access configuration OpenSSH certificates Windows RDP access Non-certificate access Ephemeral certificate based solutions
How do ephemeral certificates work?
In ephemeral certificate-based authorization, the target systems are accessed without the need for permanent access credentials, explicit access revocation or traditional SSH key management.
For each session, the ephemeral certificate:
is issued from the Certificate Authority, which serves as the trusted third party
is based on various industry-standard methods, the chief example being the short-lived X.509 certificate
encodes the target user ID for security
has a short lifetime (5 minutes) after which it auto-expires
The access is also called ‘credentialess’, since on establishing the connection the user does not handle access credentials at all. Instead, the user logs in to the Certificate Authority each time he or she wants to establish a remote connection without having permanent authorization to the environment.
User access configuration
The Certificate Authority controls access to the target system based on user roles, which are created based on rules. The rules for particular roles are generated according to security policies and access requirements. The Certificate Authority fetches the rules for each role from the IAM system and uses them to determine proper authentication. This system alleviates setting up access for each individual user and enables streamlined updates to groups of users.
Target system access configuration
The target systems must be configured to support credentialess access. The configuration is static, meaning that it needs to be done only once when the servers are provisioned. Credentialess access does not change if user roles/job functions change or users are added or removed from the identity management system. The target systems must be re-provisioned only if there are changes in the roles and their mappings to the operating system level accounts that define which access roles have the right to perform which functions on the target server.
The configurations that allow credentialess access are like templates that serve a function. This means that multi-cloud instances (such as Amazon Web Services, Microsoft Azure, Google Cloud or OpenStack) can be scaled up and down at will, but the templates remain immune to the changes and continue to provide access as per purpose, for example, access to financial data, system databases, production environment etc.
Ephemeral certificates in conjunction with secure protocols
The SSH access is implemented with OpenSSH certificates. The certificates encode the user roles and the SSH server configuration on the target server maps the roles into the operating system level accounts.
Windows RDP access
The Windows RDP access is implemented with a virtual smart card. The Certificate Authority acts as the smart card in RDP authentication. The smart card’s certificate is created on-demand when the user opens the RDP connection. The certificate is enrolled for an ephemeral keypair which is discarded after the authentication has been completed. The virtual smart card authentication is fully automated and invisible for the end users.
If the target server does not support OpenSSH or RDP certificates, the Certificate Authority uses role keys instead. The role keys are standard SSH keypairs. The public key associated with the role key is configured for the file that defines which private keys are allowed to access the target host, and the corresponding private key is held in the Certificate Authority secure key storage. The user will never get access to the private key that is associated with the role. Users can only use it indirectly via the Certificate Authority to authenticate and authorize the access, based on their access role defined in the Certificate Authority.
Ephemeral certificate based solutions
SSH.COM has developed a comprehensive set of just-in-time (JIT) Zero Trust solutions that support ephemeral certificates for user or machine ID authentication. This helps to mitigate the risk of managing digital keys, privileged passwords and other secrets (like API tokens or certificates) by greatly reducing their numbers in IT infrastructures. Learn more about the SSH.COM's Zero Trust and Just-in-time (JIT) solutions here.