Menu

Skip to content
  • Home
  • Media
  • Privacy Policy
  • About me

Protect external AWS accounts with Veeam N2WS Backup & Recovery

Posted on April 23, 2019April 20, 2019 by Luca Dell'Oca
0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×

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.

Some theory

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:

https://support.n2ws.com/portal/kb/articles/what-are-the-required-minimal-aws-permissions-roles-for-cpm-operation

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.

Share this:

  • Twitter
  • Facebook
  • LinkedIn
  • Email
  • Tumblr
  • Pinterest
  • Reddit
  • WhatsApp
  • Pocket
This entry was posted in Tech and tagged assume role, aws, backups, cpm, cross account, iam, nw2s, veeam. |

Post navigation

← Learning how to use terraform in vCloud Director
Configure Veeam N2WS copies to S3 and export them via backup copies →

Search

Sponsors

Latest posts

  • A first look at the new Veeam SOSAPI
  • Create a S3 Bucket with Object Lock in Scality Artesca for Veeam
  • Back to blogging, with a new object-ive!
  • Run your small DNS server with MaraDNS
  • Veeam Backup for GCP and Multi-tenancy
  • Home
  • Media
  • Privacy Policy
  • About me
creative commonswww.virtualtothecore.com @ all right reserved.
This work by Luca Dell'Oca is licensed under a Creative Commons Attribution - Non Commercial - No Derivs 3.0 Unported
0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×