Security is paramount at every layer of the infrastructure stack, from the underlying hardware to the application itself. The advent of cloud and hybrid IT models has extended this conversation off-premise when creating cloud-enabled applications.

This is the first post in a cloud security series on topics ranging from the shared responsibility model to the intricacies associated with identity and access management, just to name a few. These posts build on cloud security best practices covered in our recently released ebook, 5 Best Practices for Cloud Security, and our detailed look at security in the CenturyLink Cloud Security Overview.

Today’s blog discusses the shared responsibility model and the least privilege principle. These two lay the foundation for most security decisions when adopting and leveraging cloud-based infrastructure resources. Without them, businesses using cloud may not know when or how to secure their environments or what actions authenticated users can take.

Shared Responsibility Model

The shared responsibility model describes an understanding between the cloud provider and its users, where the provider manages security of the cloud and users managesecurity in the cloud. Security of the cloud normally constitutes physical assets, underlying network and IT infrastructures, and foundational cloud services, such as storage, compute and networking. Security in the cloud constitutes all other security related activities, including managing users, data, applications and middleware.

Most leading cloud providers apply this model, because they understand users must take responsibility for the entities and assets they control. At the same time, it allows cloud providers to focus on increasing their security posture for the entities and assets that they control. As a result, cloud providers leverage and evolve security best practices to provide the most secure environments available. According to Dimensional Research, cloud providers have become so proficient at providing secured IT infrastructure that many CIOs are beginning to move to the cloud to become more secure. We’ve come a long way!

Least Privilege Principle

Although not as well known, the least principle is just as important as the shared responsibility model, because it describes what authenticated users can do within a secured environment. There is an important nuance to this definition that relates to the ‘least privilege’ phrase: “can do” versus “cannot do”. The least privilege principle implies that authentication and authorization are two separate domains that must be taken into account by the identity and access management system, and that authentication does not suggest full access to all assets within the account in question.

To the contrary, least privilege assumes that authenticated users have zero access and usage rights until specified by the account administrator. This assumption ensures that intruders cannot access or make changes within an account, particularly at the service and resource levels.

Least privilege also safeguards against ‘friendly’ interference by users who should not be able to take certain actions or be able to access certain services or resources. For instance, business users should not be able to access or make changes to servers that run their applications. However, they should be able to access and make changes to documents and other objects stored within an object storage service.

Although the least privilege principle is an incredibly powerful security control, it can also be very difficult to administer, as it employs permissions models built from highly granular policies that address circumstances specific to a particular account. As a result, administrators need to not only understand an account’s circumstances, but to also create relational models that describe how policies relate to one and other within hierarchies.

In order to solve this complexity, role based access control (RBAC) systems are integrated into the control providers’ control panels. These systems are either native to the control panel or provided by third parties who have access to permission models. The latter option implies that a prescribed trust agreement has been set up among the cloud provider, third party provider and user. While trust agreements are inherently secure, they do require an extra setup step and management as relationships change.

CenturyLink Cloud provides an RBAC system within the Control portal (see screen shot below) in order to alleviate cumbersome maintenance of permission models and need for third party trust agreements. The RBAC system goes two steps further by offering eight different roles used frequently within an account, as well as providing an intuitive UI and an API for customizing these roles or creating new ones as the account requires. To learn more about CenturyLink Cloud’s RBAC system, see Bryan Friedman’s post or download the Cloud Security Overview.

Conclusion

These two security principles are the foundation of a secure cloud deployment. Moreover, if a cloud provider does not make it easy for enterprises to employ these principles, many adoption issues can ensue. But today, thanks to the right security foundations, enterprises and governments are adopting cloud for all types of use cases and applications. The momentum continues to build…

The next two posts will address other security best practices and tools used by providers and users. Look for these to be published in the next few days.