Product

Deploying a Secure Data Protection as a Service Solution with Rubrik Polaris

Rubrik - Deploying a Secure Data Protection as a Service Solution with Rubrik Polaris - Deploying a Secure Data Protection as a Service Solution with Rubrik Polaris

Cloud security is one of the topics du jour in the enterprise IT space. In fact, it’s a big enough topic that Amazon Web Services (AWS) hosted their own security conference, AWS re:Inforce, back in June. It highlights the challenge with securing your data in the cloud,  especially if you are using tools and approaches that were not designed for security from the start. Not adhering to good security practices exposes cloud customers to the potential risk of being hacked and having data stolen.

To assist customers and partners with building secure solutions, AWS has codified recommended practices and principles into the security pillar of their AWS Well-Architected Framework. The Well-Architected Framework is a tool for evaluating the soundness of any solution running on AWS and leveraging their services. The framework is comprised of five conceptual areas called pillars, including the security pillar

So where does Rubrik Polaris fit into this picture? We previously announced the general availability of AWS native protection support in Rubrik Polaris, our Software-as-a-Service (SaaS) platform for cloud data management. Now, we want to explore how Polaris is able to build a secure solution for protecting Amazon EC2 instances and Amazon EBS volumes using the recommended practices and principles outlined in the security pillar.

In particular, we want to call out four design principles that have been built into the design of Rubrik Polaris and it’s support of Amazon EBS snapshots. As cited in the AWS security pillar web page and white paper, they are:

  1. Keep people away from data: Create mechanisms and tools to reduce or eliminate the need for direct access or manual processing of data. This reduces the risk of loss or modification and human error when handling sensitive data.
  2. Protect data in transit and at rest: Classify your data into sensitivity levels and use mechanisms, such as encryption, tokenization, and access control where appropriate.
  3. Implement a strong identity foundation: Implement the principle of least privilege and enforce separation of duties with appropriate authorization for each interaction with your AWS resources. Centralize privilege management and reduce or even eliminate reliance on long-term credentials.
  4. Automate security best practices: Automated software-based security mechanisms improve your ability to securely scale more rapidly and cost effectively. Create secure architectures, including the implementation of controls that are defined and managed as code in version-controlled templates.

We addressed principle 1 in a blog post explaining how Rubrik uses a construct called the SLA Domain to simplify and automate the lifecycle management of Amazon EBS snapshots and AMIs. In a second blog post, we discussed how Rubrik supports encryption of Amazon EBS snapshots to ensure data backups are protected end-to-end, as recommended in principle 2 above. In  this post, let’s focus on how Rubrik implements principles 3 and 4.

Implement a Strong Identity Foundation

The principle of implementing a strong identity foundation states that users and applications should only have the minimum access and privileges to AWS resources  required. For example, a SaaS application such as Rubrik Polaris should only have access to the AWS resources needed to manage Amazon EBS snapshots and have permission only to do what is specifically required to manage the lifecycle of those snapshots. This includes the ability to initiate snapshot creation, perform restores, and launch new volumes from those snapshots.

AWS also recommends using IAM roles instead of IAM users to delegate access across accounts so an application, such as Polaris, can manage resources without a permanent user having to be created in the customer account. The latter is a legacy approach where an admin account would be created and assigned to a third-party application. This approach is now anathema to a strong security posture. The benefits of An IAM role are that it be easily rotated or revoked and is not associated with a password or access key which can be hacked, as is the case with a regular IAM user.

The workflow for using IAM roles to delegate access across accounts follows three basic steps:

  1. Establish trust between the customer account (ID number 999999999999) and the SaaS vendor account (ID number 111111111111). We start by creating an IAM role and defining the vendor account as a trusted entity and specifying a permissions policy that allows trusted users to protect AWS resources in the customer account.
  2. Modify the IAM group policy so that a user in the vendor account will have permission to assume the newly -created IAM role. Optionally, we can explicitly deny users (such as a Testing group) the ability to use the role.
  3. The vendor account user invokes the Switch Role operation to assume the newly created IAM role so it can access AWS resources on behalf of the customer.

Rubrik Polaris implements AWS best practice for cross-account management through a CloudFormation template (more on that later) that generates and configures the necessary IAM principles, including users and roles, to delegate access from the customer account to a Polaris SaaS account.

The CloudFormation template, when launched, performs the following steps: 

  1. Create a CrossAccount IAM role, with the specific permissions required to protect and  recover Amazon EC2 and Amazon EBS, in the specified customer account.
  2. Grant the Rubrik AWS account access to the newly-created role as a trusted entity.
  3. Send the Rubrik AWS account an Amazon Simple Notification Service (SNS) notification about the new role with the role’s Amazon Resource Number (ARN).
  4. Rubrik will create a new IAM user dedicated to the customer account, which Polaris will use to assume the new role when needed.

Automate Security Best Practices

As noted above, we use AWS CloudFormation to automate cross-account management delegation to Polaris instead of providing written steps. This approach corresponds to the principle of automating security best practices. It provides a repeatable and secure process that customers can rely on, particularly as they scale their environment and deploy Polaris to manage more of their AWS accounts.

Launching the CloudFormation template from the Polaris dashboard starts up the AWS CloudFormation console and prompts the user to actually run the template. Running the template creates the CrossAccount IAM role, which will be assumed by a rubrik-polaris user in order to protect AWS resources.

Automate Security Best Practices with Rubrik Polaris

The template then assigns required IAM policies to the newly created role. One policy establishes a trust relationship that allows a Polaris account to assume the CrossAccount IAM role.

A second policy establishes the set of permissions required for Polaris to manage AWS native protection.

AWS native protection with Polaris

An Amazon SNS notification is then sent to Polaris and the CrossAccont IAM role ARN is populated and stored in the Polaris account.

Once the CloudFormation stack and all necessary resources have been created, Polaris is ready to discover and manage the customer’s Amazon EBS snapshots and AMIs.

The AWS Well-Architected Framework and its security pillar should be followed by customers and partner alike and is critical for creating solutions that can be fully trusted. The software used to protect customer data and resources should enforce those same principles. To find out more about Rubrik Polaris and how we securely protect your AWS environment, please visit our Cloud Solutions page.