Multi-Factor Authentication for Cloud Environments
Multi-factor (two-factor or more), authentication systems require a user to provide multiple pieces of evidence to prove their identity. This evidence typically includes some combination of the following:
- Something the user knows (a password or PIN)
- Something the user has (a smart card or hardware token)
- Something the user is (biometric characteristics like a fingerprint or retinal scan)
This type of authentication is designed to significantly reduce the likelihood of an account being compromised or access being granted to an unauthorized party. And it works really well on shared systems where multiple users might login at different points in the day.
But the cloud is an entirely different animal, and traditional two-factor authentication that requires the user to have direct, physical access to the device in use, simply doesn't work. For example, you cannot use a smart card or fingerprint reader to access a device in Amazon's cloud.
Gazzang zTrustee™ offers a unique multi-factor solution built for cloud environments. Rather than requiring a biometric characteristic or a physical card or token, zTrustee uses designated people or processes as a second factor. For example, when an administrator enters their SSH credentials to begin a secure transfer of data to a partner, that login would trigger an email alert to one, two, or more, "trustees," asking whether the SSH session should be authorized.
If the trustees verify that the administrator logging in is a trusted person, they can authorize the session, and the zTrustee Server will release the key to the user. If one of the trustees believes the access request to be fraudulent, they can deny the key release, and the SSH session will not begin. At no time during this process does the trustee ever see or have access to the SSH credentials. To the individuals deciding whether to authorize or deny the SSH key release, the key is nothing more than an opaque object.
A trustee can also be a process that determines the validity of your request. For example, if a token or key request is made from a system with an unauthorized IP address, the zTrustee server will automatically reject it. Other multifactor authentication policies zTrustee allows you to establish include but are not limited to the following:
- Time of day- A login must occur within a scheduled window of time.
- Retrieval limits- An object can be set to expire after a certain amount of retrievals.
- Time to live- Access to an object or URL can be governed by a time limit, so an authenticated session can be limited by an expiring URL.
As an additional layer of security, zTrustee provides a thorough audit log of all access denials, giving security officers unprecedented visibility into who, or in some cases, what, is attempting to start an unauthorized session.
This unique approach to multi-factor authentication does not require the user to have access to the server, making it the perfect solution for the cloud. Click here for more zTrustee use cases.