One of the main focus of this year for me as a cloud architect at Veeam, is to learn as much as possible about public cloud technologies, and how our software solutions can interact with them. I started a few weeks ago to deep dive into our solutions for Amazon Web Services, using N2WS Backup & Recovery. One of the things I’ve learned is how to create a dedicated account to protect other accounts.
AWS has an amazing security platform, thanks to the way they developed over time their IAM (Identity and Access Management) system. I’ve used extensively IAM and I’m a huge fan of it, but as much as it can protect our AWS resources, there’s like always a point where someone will have enough powers to damage something.
The idea in our software is to completely bypass this problem, by allowing a customer to be protected using another account where backups and replicas are stored. In this way, even if the production account is compromised and data are deleted, the backups are stored into another account, that cannot be accessed from the other one.
This solution can also be offered “as a service” if the two accounts are a customer and a service providers.
N2WS software runs inside this dedicated account, and has the option to access another account. To do so, it needs some permissions that have to be created into the protected account. How to configure this is the main topic of this article.
How to allow the master account to access target resources
The easiest way to do so is by creating simple IAM accounts. This could be easy, but after a while it may become complicated to manage all those keys: either we change them often to avoid compromisations, or at some point some lazy admin will let them age too much, and expose the target to security issues.
For this reason, it’s way better to use IAM roles, but at the beginning it may be a bit complicated to understand how to properly configure them. Let’s see how they work.
Let’s assume we have two AWS accounts: Master is the one where all the backups are managed, and Target is the account that we want to protect. We need to configure a role in the Target account that allows Master to login and complete its tasks against the protected resources.
So, once we log into the target account, we open the IAM management and we start the creation of a new role.
Step 1: Create a new policy
In AWS IAM of the Target account, create a new policy. You can use the json files available here:
In the zip file at the end of the page, you will find a file called aws_policy_permissions_Advanced_Enterprise_BYOL.json, this one already has all the needed permissions to allow external accounts to access the target resources.
Step 2: Create a new role
Select Another AWS account and retrieve the account ID of the Master account to be placed here. In the following step, select the policy we just created:
Review the configuration, give a name to the role and create it:
The role is created, and can now be used into our software.
Step 3: Add target account to N2WS
In the N2WS console, we go into Accounts, and we create a local account that can do DR operations. We have called it master_dr. Once we have this one, we create another one, like this:
By using the option Assume Role, we tell the software to connect to the target account (identified by its ID, that I have obfuscated, and to announce itself as the Master account first (remember in step 2 we said that source is our Master, it’s not like everyone can connect to the target account…), and that it wants to assume the role CPM_assume_role that we also created before. In this way, we can connect to target and run the tasks we want, doing it from the master account.
Step 4: create backups
We can now go into the policies, and create a new one, like this:
As you can see, we use target_bkp as the account to run the tasks, and thanks to this, Master can do backups of EC2 instances running at Target:
For now, backups are stored as EBS snapshots into the target account, so still vulnerable to attacks. We’ll see in the next post how to move those backups into the Master account, and even outside of AWS.