AWS Data Access Policy

Our Information Security approach revolves around minimizing and protecting the data we need access to:

We use a least-privilege approach to gain access to cloud cost & usage, billing metadata on a non-intrusive basis.
We operate in a way that makes it easy to isolate and audit what we’re doing.
We do not need access to the data within your cloud accounts/projects, or the ability to affect technical operation or configuration of your cloud services.

We combine policies, procedures and technical controls to ensure a consistently robust approach is maintained through our people and technology. We adhere to industry recognized standards such as ISO 27001 and ISO 9001. Security obligations are reflected in our contractual agreements with customers, cloud vendors, suppliers and partners.

Data Access

We will only ever request access to, and store, the minimum information we need. This varies by cloud provider and for:

Potential customers using our Savings Review to evaluate our service.
Customers using our rate optimization services to reduce their cloud spend.
Customers who also use us as their cloud reseller.

Data Approach

Data Security approach

At Strategic Blue we control access internally through a number of role based access roles. This ensures that we as a company, and our staff, as individuals, have only the minimum access required to deliver our value. We enforce security through multiple technical controls, ensuring that only the necessary access is granted based on job roles.

Access is managed centrally via AWS Organizations, which consists of multiple linked accounts and a single Payer Account that also serves as the management account.
A dedicated Strategic Blue AWS account acts as a bastion service for authentication, utilizing AWS Identity & Access Management (IAM) and Multi-Factor Authentication (MFA).
Staff members have specific role-based permissions that define the actions they can perform.

Staff Access for Rate Optimization

Administrator access to commitment holding accounts (created specifically for our use when you onboard): Portfolio Management Team
Reserved Instance and Saving Plan commitment management: Portfolio Management team
AWS Payer Account level Cost and Usage read-only (e.g. Cost Explorer, account information, consolidated billing, free tier, budgets and service quotas): Account Managers, Technical Account Managers, Portfolio Management Team, Finance Team

It should also be noted that our developers have no direct access to production accounts.

Staff Access for Reseller cloud services

Root account access (as required by AWS): limited to only two SC cleared, long-serving senior employees.
Administrator account access: limited to only two SC cleared, long-serving senior employees. Provided by dedicated user accounts isolated from their accounts used for standard tasks.
AWS Organization configuration (e.g. account consolidation/ deconsolidation and apply Security Control Policies): Technical Account Managers, Portfolio Management Team
AWS Budgets and anomaly detection configuration: Technical Account Managers
Creating and authorizing payments: Finance Team
AWS Support ticket management: Account Managers, Technical Account Managers, Portfolio Management Team, Finance Team

Data required when evaluating our service

Our Savings Review provides an assessment of your current AWS rate optimization approach based on read-only access to your AWS Cost and Usage Report.

We can
- read the bucket that holds your CUR
- describe the definition of your CUR
- list linked accounts and their tags
We can't
- view data in your accounts
- change how you use the clou
- access your code or network information

Our portal guides you through the process of providing this access. It describes the access needed and how we use it. You provide the AWS Account number of any payer account(s) you wish to be included in our review, a descriptive name for this account for ease of reference, and the name of the S3 bucket that contains the Cost and Usage Report.

The details you provide are inserted into a Cloud Formation template as the “Trusting Account” and “Billing Bucket Name”. The template creates a “StrategicBlueMasterAccountReader” role which grants S3 data access to a dedicated Strategic Blue authentication account. The authentication account acts as a bastion service between our systems and operators, and your AWS usage. The access provided is to:

list linked accounts and their tags, so that we can discover information about the child accounts that sit underneath the registered payer account.
describe report definitions, so that we can discover what Cost and Usage Reports (CURs) have been set up. This allows us to confirm the right level of reporting exists to perform our analysis of spend.
read the S3 bucket in which CURs are stored. We need to read this CUR data in order to perform our analysis of spend.

Our portal provides a link that opens your AWS console to review the template before you apply it. This means you see exactly what will be granted and will remain in complete, independent control of when you grant it. From your AWS console you can remove our access at any time you like without any reliance on our portal.

Data required as a rate optimization customer

The access needed to deliver our rate optimization services is described in relation to standard AWS Accounts, Organization and reporting structures:

The templates below provide the technical detail of the clearly defined roles, each for a dedicated Strategic Blue authentication account, which acts as a bastion service.

Read data about the payer account

We can list organization accounts and their tags, describe Cost and Usage Report definitions and read the S3 bucket that holds those reports (template).

We only collect data regarding billing and instances such as the quantity, class and region as this will enable us to make recommendations. We use this to provide our recommendations, apply discounts and produce your insights and usage dashboard for reporting.

Review data with “AWS Billing and Cost Management”

We verify our optimization actions have been correctly applied by AWS, view usage, billing and savings plan information (template).

Commitment-holding account access control

We buy, change and sell reserved instance and savings plan commitments in dedicated holding accounts. These accounts are created specifically for us. They generate no usage and are used to isolate our activities, simplify auditing and create clear commitment ownership. We have admin access to these accounts.

Reserved Instance Marketplace

We grant our commitment holding accounts the ability to sell unused Reserved Instance commitments when required on the AWS Reserved Instance Marketplace (template). This is optional for customers where we are not also the AWS reseller.

Data required when we are your cloud reseller

If we are also acting as your AWS reseller registration of your Cloud Provider Accounts with us is in accordance with the terms, conditions and provisions given by AWS to any reseller. As an Advanced Consulting Partner, we use the End Customer Account Model (ECAM) with resold (not Partner led) AWS support. This means you own each Linked AWS Account with technical support provided directly from AWS. With this arrangement we require no access to your AWS Accounts.

We continue to use an AWS best practice RBAC, IAM and SCP approach to grant access on a least privilege basis. This is secured through a dedicated Strategic Blue authentication account, which acts as a bastion service.

We have access to cost and usage metadata about your accounts. We use this to provide our recommendations, apply discounts and produce your insights and usage dashboard for reporting.

When acting as your AWS reseller, AWS requires us to own the associated AWS Payer Account. If you use the Payer Account to manage organization level services for operational and security purposes we will provide you this access.

In accordance with best practice, we create an Administrator role within the Payer Account, not in any linked accounts. This role is only used in exceptional circumstances such as when there is an issue which cannot be resolved with the other roles. The role is assigned to only two individuals within Strategic Blue, both of whom are SC Cleared. This account further reduces the need to use root access which is secured through strong passwords, multi-factor authentication and we do not create API access keys for these accounts. If you are not comfortable with Strategic Blue having this level of access to the management account, you may request to retain the MFA details, so that any root actions are performed with full knowledge and auditability. At the very minimum we require you to change the root email to a Strategic Blue provided one.

Data Access FAQS

Do you have access to my systems and data once consolidated?

No. Access within sub accounts has to be explicitly granted and does not flow from a master account into a linked child account. Customers should not use the OrganizationAccountAccessRole within linked accounts. We actively monitor where this role could provide us more access than we require to notify customers if they are inadvertently using this role.

Do you have access to the IP address information of my servers?

We have no access to IP addresses or server names, unless, contrary to best practice, you have chosen to include it within cost tags. We have no access to VPC and subnet information, nor any access to data flow logs and information.

How do you control who has access to my data?

Staff have very limited access to client information beyond the monthly cloud spend which is managed by the Finance team for billing purposes and the recommendations report which is managed by the Account management team. Access to systems and file shares is managed on a ‘need to know’ basis.

Can you give examples of how you adhere to privacy legislation. i.e. GDPR?

Our sales & marketing team holds (potential) customer information for the purposes of information updates & sales, which is handled appropriately with the required opt-out options.

Our Account management team holds and maintains basic customer information (name, email, job title) as required to contact you to perform our business function.

We do not have any access to any of your customer information.

Can you create an account on my behalf?

For AWS services, when we are acting as your AWS cloud reseller, we operate under the End Customer Account Model (ECAM) within the AWS Solution Provider program. We prefer for customers to create their own AWS Accounts, which are then consolidated into one of our AWS Master Payer accounts. This ensures that customers have accepted the AWS terms & conditions for service delivery, and are the correctly registered owner of the account. When we are the reseller, we can do this on your behalf, but it must be noted that we are creating customer accounts and not Strategic Blue accounts.

One or more accounts will be created in your organization for purchasing and managing commitments. As the reseller we will do this, but where we are not the reseller then we shall ask you to create these on our behalf. These separate and dedicated accounts ensure that no access to customer usage accounts is required to purchase commitments.

How do you confirm non-recoverable deletion of data?

Non-recoverable deletion of data is managed by AWS. “When an object is deleted from Amazon S3, removal of the mapping from the public name to the object starts immediately, and is generally processed across the distributed system within several seconds. Once the mapping is removed, there is no remote access to the deleted object. The underlying storage area is then reclaimed for use by the system.”

More information : AWS Security.