Cloud Security Policy Set: Authentication
One of the most significant principles of cybersecurity is the minimization of access privileges. By reducing access rights to only those users and services that absolutely require them, an organization can greatly shrink its attack surface.
The principle of least authority, however, fails without robust authentication methods and their enforcement. Authentication is the verification of an identity, ensuring that an entity attempting to access a resource, data, service, or application is indeed who and what it claims to be. Once confirmed, that identity can then operate with whatever privileges it has been granted. Therefore, actively enforcing authentication policies is critical to the integrity of a remote infrastructure.
Authentication can be divided into three primary types:
- Verification is determined by something the user has
In the cloud environment, this can refer to the cloud provider itself. Cloud engineers trust the APIs they exchange with cloud providers because they trust that as the purveyors of these APIs, cloud companies have their own authentication methods in place.
In a more common example, methods of multi-factor authentication such as texting a code to a user’s phone number trusts that the number is accessible to only the user who supplied it. In other words, authentication can be based on something an identity is in possession of.
- Verification is determined by something the user is
Virtual private networks probably come to mind. Since a virtual private network usually uses IP addresses to identify which machines are permissible, the authenticity of identity can be verified by checking if its IP address is listed among those indicated as allowable within the network. Most modern devices support fingerprint authentication. In order for anyone to unlock the device, their fingerprint must match the allowable prints on file.
This is authentication verified by something inherent to the identity in question.
- Verification is determined by something the user knows
Almost everyone has been asked to provide a password as part of account creation. The assumption is that the user will be the only one who knows this information because they were the ones present at its inception. Similarly, accessing a database often requires providing a username and password.
In this case, the authenticity of identity is determined by something the identity has knowledge of.
The most secure authentication draws from all three factors in order to verify identity. While single-factor authentication (such as a password or token) remains the default method of authentication, the proliferation of account-dependent remote infrastructure has increased the need for authentication based on many different attributes. This is known as multi-factor authentication (often abbreviated as “MFA”).
A common example of multi-factor authentication lies in the use of text messages for password recovery and reset. In order to verify a user’s identity, an application may require the user to provide a code the application will text to the phone number on file for the user. This works because the user has the phone.
Before sending the code to the phone number, the application may first ask the user to provide the rest of the digits in an obscured representation of the phone number the application has on file for the user. This verification assumes the user knows their own phone number.
When the application texts the code to the phone number, the user must now unlock their phone in order to view the code. If the user has enabled thumbprint authentication, the phone unlocks with something the user is.
Because the cloud is public and accessible via API, authentication is paramount to protecting infrastructure, especially when a well-managed cloud relies on the principle of least privilege in order to control access. Since some identities may have more permissions than others, authentication methods can mean the difference between quiet compliance and a security breach.
As described above, multi-factor authentication identity verification on more than one aspect provides a stronger safeguard against intruders. Requiring MFA for access to an organization’s remote estate is the first step of erecting guardrails; enforcing MFA keeps the guardrails in place.
Fortunately, Cloud Custodian provides a robust set of filtering methods for an account resource. The following example pull mode policy enforces password requirements by filtering for non-compliant account resources, remediating them, and notifying the account owner.
The example above is merely one method of enforcing policies to ensure identities are thoroughly authenticated. With Cloud Custodian’s collection of account resource filters and actions, it is easy to imagine how the DSL can support robust verification.
In this next example, the pull mode policy filters for accounts that do not have MFA enabled.
And in the example below, the event-based policy notifies on account logins originating from invalid IP addresses.
For more information, refer to the Cloud Custodian documentation.