Five ways to manage authorization in the cloud
The public cloud is being rapidly incorporated by organizations, allowing them to store larger amounts of data and applications with higher uptime and reduced costs, while at the same time, introducing new security challenges.
One of the more prominent challenges is identity management and authorization. Since the beginning of cloud computing, authorization techniques in the cloud have evolved into newer models, which acknowledge the many different services that now come together to form a company’s network.
These approaches take into account the growing number of security blind spots and weak points in the cloud environment. Instead of being connected by wire within the confines of a corporate network, most of these new services are open to the internet, expanding the attack surface of the company’s infrastructure.
Here are five key developments to consider for managing authorization in the cloud.
Centralized management vs distributed services
In a traditional on-premise environment, all users were generally maintained by a single server which would serve each application, whether to give or deny access. In a cloud environment, each service has its own set of permissions and identities, and its own API to maintain and enforce them. This makes configuration much more difficult, and opens a Pandora’s box of configuration mistakes, leading to cloud-based attacks.
In order to manage users on a single platform, it is common to use a single external authorization service. You give the authorization service credentials to an account that can create temporary roles or manage your accounts on each other cloud service you use. With this, users can be defined on a single platform, but the identity provider needs to be trusted not to perform malicious actions and, when it does, it may be harder to track down from where these actions originated.
Cloud authorization methods vary, including MAC – where each app owns individual access permissions, DAC – where each app requests permissions from an external permissions app, RBAC – where the authorization service owns roles with different privileges on the cloud service, and ABAC – where access is based on request attributes and policies.
Each cloud service has its own set of tools, permissions, logging format and interface, making security a new challenge for each app. It is important to note the differences between cloud services, and choose the right one based on your needs. Ensure that you can always tell who is accessing your sensitive data, and for what reason, and that each access originated from a legitimate source.
A zero trust architecture is based on the assumption that no service, server, role or client in your network can be trusted. Always double check access requests to sensitive data, enforce the use of MFA, monitor changes in behaviour, and implement a principle-of-least-privileged model. If you can define how each user is supposed to behave, and what data they can access, you know how to monitor these users.
API users should be restricted according to the originating device, and by monitoring their behaviour patterns, and privileged APIs should be restricted to run only from the company’s internal network. Finally, users should be continuously authenticated with MFA and monitored with anti-virus software.
A credential leak can occur anywhere, from a compromised personal computer to a database server. Therefore, in every step of the way to access classified information, the user needs to be authorized. If, for example, an external authorization service is used and that service has a strong account on a web app, that web app should ensure that the strong account was used by the service and not by a man-in-the-middle.
When a web server requests access to classified information, it should come from a legitimate flow, and not just from someone with a shell on the machine. A sudden change in the number of connected devices, or use of a rarely used API call can indicate a credential compromise.