TABLE OF CONTENTS
The key challenge with remediation is ensuring the highest security of the process. A traditional approach to performing remediation involves granting owner access. To make changes to your cloud resources, most CSPM solutions typically require read/write permissions. As virtually every cloud object might need remediation at some point, granting a third-party full owner-level access to your entire cloud creates huge risk and can potentially open a backdoor. It also violates the principle of least privilege when you should always aim to assign only needed privileges to the necessary resources instead of allowing full admin access to everything.
Another common approach to executing remediation consists of installing remote agents (functions) across all cloud accounts on the customers’ side. However, in this case you need to deal with security and maintenance of these agents on your own – in addition to managing an already complex cloud environment. This comes with complexity and increases maintenance cost of an organization's cloud infrastructure. To overcome these challenges and maintain the ease of use, Aqua uses the Remediation Security Model approach.
Aqua Auto-Remediation Security Model was developed with a security-first mindset to ensure security and reliability at every step of the remediation process. This is a unique security model that uses a temporary token (rotating 6-digit code) to connect to your cloud account. To implement the necessary fix, Aqua gets access only to specific settings within services and for a limited amount of time. The token is never stored by Aqua, and the customer only provides it (manually or automatically) upon request. This is a very secure and granular way of performing remediation.
Generic architecture of the Auto-Remediation Security Model
Aqua cloud assumes a read-only role with the customer cloud account and retrieves secret key that is specific to that customer account. Aqua will not store the secret key anywhere. Using the secret key and the current time, a one-time token code is generated. This token code is only valid for 5 minutes and then it automatically gets expired. The generated token code is used to assume a write role that helps in remediating the customer account.
In the customer account, token rotation occurs every 5 minutes through a trigger that generates a secret, gets the new token code, assumes write role and remediates the customer account.
The auto-remediation model in AWS works exactly the same as explained in the above generic architecture.
In Azure, additionally, a Hash-based Message Authentication Code (HMAC) is generated from the Token Code that authenticates remediator app registration with the customer's Azure account.
Did you find it helpful?Send feedback