Recently Amazon Web Services announced their Amazon Verified Permissions service as being generally available.
What’s this service for? Is IAM dead? Long live Verified Permissions? Move aside Cognito, there’s a new AWS identity provider in town? Cloud Infrastructure Entitlement Management (CIEM), you’re not required so just move along, nothing to see here?
Purpose of Amazon Verified Permissions
You’d be forgiven for thinking any of those things. Verified Permissions deals with permissions within your application. It’s not for access or management of the infrastructure in AWS nor is it to replace your own LDAP or Cognito services. So, not an IAM replacement, nor is it for identity management, nor does it replace a CIEM. So what’s it for?
It’s for controlling access to the different components within your application. You have a user who has authenticated into your application. They will be allowed or not allowed access to resources. Verified Permissions describes that access. This user who has been authenticated is a member of that group and so is authorized to read this resource.
“Aha! You mean API Security!” I hear you cry. I think you should get a half point for this answer. API access control could be managed by Verified Permissions, but the security of the API endpoints and their configuration would be covered by something else (hint: Orca Security).
Instead, Amazon Verified Permissions service provides the authorization framework for applications. Typically application developers would build this manually. It’s not a differentiator to an application and it isn’t going to increase your bottom line. That means this fiddly and time-consuming work was often poorly implemented.
Authorization actually becomes quite complicated once you get into it. Consider the complexity of allow lists vs deny lists, precedence in access, and then layering in some meta data as well. Putting more flesh on my example earlier, this authenticated user has been granted access to this resource because they are in a specific group. They should only be able to access this other resource if they have used MFA to authenticate and they are geographically in Europe. In addition they should never access this other resource even if someone inadvertently grants them access through another policy!
That scenario may sound far-fetched but it’s actually quite common for there to be layers of access. Often rules weren’t applied because they would be just too difficult to implement. Think of the cases where users are members of multiple groups, each one with conflicting permissions and you’ll get an idea of why this is tough.
AWS has created a new policy language, Cedar, which AWS hopes will allow compliance and application teams to be able to define human and machine readable policies to cover the above and much, much more.
Amazon Verified Permissions and Orca Security
Now the AWS team has said that they hope to expand this out as a ‘better together’ service with other Amazon services but they aren’t looking to displace anything.
At Orca Security, we are laser-focused on providing comprehensive and context-driven security for all your cloud infrastructure. That means we’ve got you covered for your CIEM needs (and don’t tell AWS, but we will do that across all major cloud service providers!) and will continue to bring you that context-specific detail that elevates your cloud security. Head here to get a demo or learn more about our cloud security platform capabilities by visiting us here.
