Basic Principles:

  • We ask for read only IAM access to your AWS accounts.
  • The access is to AWS metadata not to your customer data.
  • We custom tailor the AWS access for least privilege.
  • All data in our systems is encrypted at rest and in transit.
  • Our staff have audited access to your data only when necessary.

AWS recommends that third parties (like us) access your accounts using an IAM role:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html

We comply fully with those recommendations.

The IAM role we ask you to create has a bespoke security policy attached to it. This is because the AWS-provided ReadOnlyAccess policy provides too much access. It allows reading files in S3 and data in DynamoDB, amongst other things. We need only access to your AWS metadata, which means in general that we only ask for Describe* and List* (the specifics of this depend on the individual AWS service).

We provide a standard CloudFormation script as part of our onboarding process which makes the creation of the IAM role simple. We recommend that you review the details of the IAM policy in that script before you run it for the first time.

We hold ourselves to the highest security standards. In our own infrastructure, we align ourselves with ISO 27001 and the CIS AWS Foundations Benchmark. We have regular internal and external penetration tests performed on the Stax application. There is mandated use of MFA to access Stax systems, and keys are regularly rotated.

For paid plans, we're more than happy to go through your internal security approvals. We've done this many times at companies large and very large, so we don't anticipate any problems.

Did this answer your question?