Kivera and AWS

AWS Services, Actions and Parameters

Imagine being a security engineer tasked with enforcing three critical controls for EC2:

• Ensuring that EC2 instances are not made public.
• Ensure EC2 data volumes are encrypted using a customer-managed encryption key.
• Only granting specific users the authority to delete an EC2 instance.

At face value these are simple controls, yet to achieve these through native AWS services such as IAM, SCPs, Permission Boundaries, and Resource Based Policies, you may hit a wall. Why? Because the depth of AWS preventive controls stops at an action level.

Kivera goes further, providing teams with preventive capabilities that go deeper than IAM, extending controls down to the parameters of an API call to AWS.

Continuing with the EC2 example, using IAM, you can permit specific users to create the EC2 instances by granting them the "RunInstances" permission. However, within "RunInstances," there are 102 individual parameters that you might want to control. These parameters include public access, encryption, subnets, security groups, data volume configurations, and many more (for a comprehensive list of available parameters, here).

Herein lies the challenge: for controls 1 and 2 listed above, native AWS services like SCPs, IAM, and Permission Boundaries fall short. They simply cannot enforce controls at this granular level because they stop at the action level, 'RunInstances.'

However, for control 3, IAM would be a sufficient measure to ensure that only specific users can delete an EC2 instance. Additionally, resource-based policies and SCPs could be utilized to specify which specific EC2 instances a user is permitted to delete.

Kivera's cloud security solution, on the other hand, delves deeper, enabling more detailed preventive measures down to the parameters of an API call.