Skip to content

Multiple Accounts Considerations

Jump to bottom
LeBogg edited this page Mar 22, 2021 · 10 revisions

In the following, potential ways to implement multiple accounts (#88) are listed for AWS and Azure respectively. They are either applicable (:heavy_check_mark:) or not (:x:) in the context of the clouditor.

Goal: Account A (e.g. DEV account) allows Account B (CLOUDITOR account) read access to A's resources

AWS

✔️ Assuming Roles

Steps:

  1. DEV creates a role, allowing ("Effect") the CLOUDITOR ("Principal") to assume the role ("Action")
  2. DEV attaches the SecurityAudit policy to the role (no permissions otherwise due to the principle of least privilege)
  3. DEV provides CLOUDITOR the link (e.g. https://signin.aws.amazon.com/switchrole?roleName=<ROLENAME_CREATED_IN_STEP1>&account=<ID_OF_PRINCIPAL>) or ARN (arn:aws:iam::<ID_OF_PRINCIPAL>:role/<ROLENAME_CREATED_IN_STEP1>) to switch roles
  4. CLOUDITOR switches the role

Switching roles can be done via

How it works (see also this answer on stackoverflow):

  • The Security Token Session (STS) provides the CLOUDITOR with temporary credentials consisting of an access key (beginning with ASIA), a secret, and additionally a security token
  • The CLOUDITOR uses these credentials to switch to the role of DEV, which was created in step 1 and has the permissions from step 2
  • No additional costs emerge for assuming roles

Notes:

  • AWS Organizations isn't necessary
  • Roles only within a single partition, e.g. no cross account access between aws and aws-cn (China) partition possible.

❌ AWS Resource Access Manager

"AWS Resource Access Manager (RAM) is a service that enables you to easily and securely share AWS resources with any AWS account or within your AWS Organization. [...] share those resources across accounts in three simple steps: create a Resource Share, specify resources, and specify accounts."

  • Supports organization units (OUs) as principals (better manageable, e.g. put PROD and NON-PROD under one OU)
  • CLOUDITORs access is constrained through its policies and SCPs
  • Limits for number of resources and principals
  • No costs emerge for using AWS RAM
  • Which services can be shared to what extent is limited (see Shareable AWS resources), e.g. DynamoDB or S3 aren't supported.

❌ AWS Config

  • Costs based on number of rule and conformance pack evaluations
  • There are AWS Managed Config Rules and Custom Config Rules
  • NOT TESTED YET

❌ Via AWS Organizations

Besides assuming roles (which does not need an AWS Organization), there is no mechanism in an AWS Organizations to delegate access (e.g. via policy inheritance).

Azure

Changes

  • Updating UI such that it can set up multiple cloud accounts and show the respective scans for the different accounts
  • Data model updates: Right now, only one account per cloud can be stored in the DB.
  • Discovering and scanning have to be adapted to handle multiple accounts
Clone this wiki locally