BETA
This is a BETA experience. You may opt-out by clicking here

More From Forbes

Edit Story

Access Control In The Cloud: Choosing The Right System For Your Business Security

Forbes Technology Council

Art Poghosyan is CEO and Co-founder of Britive, a leading identity and access management company.

Speed and agility are two of the reasons cloud adoption has skyrocketed across multiple vertical industries. The giant leaps forward in accelerating software development lifecycles (SDLC) within the tech sector get the most attention, but infrastructure-as-a-service (IaaS) and software-as-a-service (SaaS) technologies have had impacts just as profound in media and entertainment, retail, telecom, logistics and elsewhere.

Yet just as cloud has accelerated value-generating business workflows, it has also expanded attack surfaces—creating new vulnerabilities and exacerbating existing risks.

In the cloud, organizations must rely on identity and access management (IAM), privilege access management (PAM) and zero-trust technologies. As a result, IAM complexities within the cloud and applications have grown exponentially—as have the associated security risks.

Traditionally, organizations relied on role-based access control (RBAC) to secure access to resources. An account would have a designated role, and that role would have permission to access resources. That is what was used in the early days of the cloud—it was no different from how identities were managed using Active Directory from years ago. That is where RBAC for cloud was born—the fundamental idea that you have an account, and this account has permissions that give you access to things like developer tools and code resources.

However, as cloud adoption grew, the RBAC model became untenable in complex environments. Microservices turned the value chain of account > permissions > resource upside down. With microservices, you now have a resource that exists before access is granted. How would you like to provide or get access to that resource? That is where you start to distinguish things like granting access based on the attributes of the resource in question or even by policy so you can start with the resource first and build your way back.

This is why increasing numbers of organizations are addressing today's evolving access needs and security threats by implementing attribute-based access control (ABAC) or policy-based access control (PBAC). However, all three models—RBAC, ABAC and PBAC—have inherent value and explicit use cases.

Centralizing access permissions by role is inherently inflexible—it cannot accommodate large, fast-moving organizations where cross-disciplinary teams coalesce around a specific business priority. Consider a company setting out to launch a new video streaming service that would involve content producers, UX and backend developers, product designers, marketing staff and others. Given the sensitivity of the project, the default for new lines of business is that only director-level marketing staff and senior producer-level content executives qualify for access, but several junior-level staff members need to be on the team. An administrator needs to be brought in to resolve access issues, which is not a model that can scale. These problems can have a non-trivial impact on time to value.

ABAC can solve these issues, especially when it comes to removing the need for human administrators to intervene when access questions arise. It is far more flexible because access rights are granted not as "role = marketing director" but in more nuanced ways—"department = content production" or "resource = video UX code." Location-based or time-based attributes can be brought into the picture as well so that access rights can be sunsetted or assigned dynamically within specific windows. This is all made possible through code and Boolean decision trees (IF = CTO, THEN = full access). It is also a way to accommodate the access needs of fluid, fast-moving teams where roles and responsibilities can shift on a dime.

The drawback to ABAC is that it requires considerable upfront work as well as access to the kinds of planning and coding resources found within large organizations.

PBAC can offer all of the advantages of ABAC (scalable, automated) while also enabling fine-grained entitlements, access and authorization as portable code or even (with some vendors) through a plain language interface. It shifts the focus to protecting resources through a zero trust/least privilege access model, which aligns with the cloud's ephemeral nature. Resources remain static, but access to them is temporary. For example, PBAC lets you bake security policies into the development process, which charts a safe and sustainable course for businesses to follow and scale.

PBAC can also support key business drivers. When an LPA policy is implemented via code, it facilitates fast CI/CD processes and resource pipelines. Consider that PBAC would empower our video streaming development team to scan and retrieve the users, roles and privileges from each cloud system being used on the project. This information would then be correlated with user identity information, flagging privileged users for review to ensure the right people have the right levels of access to work efficiently.

After users, groups and roles are reviewed, policies are generated to dynamically grant and revoke administrative privileges. As complexity grows, PBAC can support the scanning and reviewing of each cloud service to ensure permissions and privileges are used appropriately by those who require elevated permissions to support applications and the business. With PBAC, authentication and authorization remain in place as important safeguards, but the security of the resource becomes the central organizing principle.

Still, the PBAC approach has its own drawbacks. Crafting effective policies is key to automating access controls, yet this can be a time-consuming, complex process requiring specialized skill sets. Effective IAM processes and procedures are foundational to PBAC, but few teams outside of enterprise-grade organizations have them in place.

Implementing PBAC best practices is likely to be an iterative process evolving from RBAC basics, but I believe it's a process well worth the effort nonetheless.


Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?


Follow me on Twitter or LinkedInCheck out my website