Operator Access on AWS

Earning trust through transparency

Security is our top priority

We’ve designed AWS from its foundation to be the most secure way for even the most security sensitive organizations to run their workloads. That includes the way we approach operator access.

AWS designs all of its systems to prevent access by AWS personnel to customer data for any unauthorized purposes. We commit to that in our AWS Customer Agreement and AWS Service Terms. AWS operations never require us to access, copy, or move a customer’s data without that customer’s knowledge and authorization.

Core key management and compute service isolation

Many of the AWS core systems and services are designed with zero operator access, including AWS Key Management Service (AWS KMS), Amazon EC2 (through the AWS Nitro System), AWS Lambda, Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Wickr. These services do not have any technical means for AWS operators to access customer data. Instead, systems and services are administered via automation and secure APIs that protect customer data from inadvertent or even coerced disclosure.

Least privilege model

AWS has always used a least privilege model to minimize the number of humans that have access to systems processing customer data. This means we make sure each Amazonian has access only to the minimum set of systems required to do their assigned task or job responsibility, limited to the time when that privilege is needed. Any access to systems that store or process customer data or metadata is logged, monitored for anomalies, and audited. AWS guards against any actions that would disable or bypass these controls.

We also apply the principle of least privilege to the posture of AWS systems and services. AWS exceeds industry standards in this area. AWS Identity and Access Management (IAM) enables customers to articulate fine-grained permissions using IAM roles - this enables customers to carefully control who has access to what. We also add an additional, unique security layer called Forward Access Sessions (FAS) which ensures sensitive permissions are cryptographically contingent on customer authorization. AWS services like Amazon EC2 and Amazon Simple Storage Service (Amazon S3) also let customers encrypt their data so that even AWS cannot use the customer's encryption keys without direct customer authorization. This is enforced by FAS which proves that the customer has authorized this operation. In addition, these actions, known as 'on behalf of' service operations, are logged and made visible to customers in AWS CloudTrail. By design, there is no super-user key that allows AWS services to access customer resources in another service without their implicit authorization.

Continuous monitoring controls

To prevent unmonitored operator access to systems containing customer data, AWS has designed our systems to ensure all administrative operations are centrally logged and monitored. All operator actions are traceable in fine-grained forensic detail to the real human performing the action; there are no shared team accounts providing anonymity. Access is monitored for unusual activity in real time, including potential mistakes or suspicious activities, and the managers and leadership teams of AWS operators, as well as the independent AWS Security organization, are provided periodic summaries of all such activity. This monitoring is multi-level, including on-host logging agents that quickly push local events off-host to a centralized log aggregation system operated by the AWS security team, and real-time alerts if for any reason the on-host agent stops working. This is supplemented by network level monitoring, bastion service monitoring, and other controls.

AWS personnel perform all operations through secure interfaces that ensure that operators have up-to-date and secure workstations, FIPS-validated hardware security tokens, and are correctly authenticated. These interfaces provide AWS operators with temporary short-lived credentials, and also monitor all activity using mechanisms that cannot be over-ridden or bypassed. These secure operator interfaces permit only limited operations that do not disclose customer data, and enforce multi-person approval for sensitive operations.

If it becomes necessary to access internal resources that may store or process customer data, such as to troubleshoot or fix an issue related to a service, we add an additional layer of control to restrict, evaluate, and monitor operator access.

Handling customer support requests

AWS support personnel who assist customers with their support requests do not have access to customer data. All AWS IAM permissions used for support purposes are fully documented and are accessed from dedicated roles that can be disabled by each AWS customer. Any use of these dedicated roles is also logged in AWS CloudTrail.

Secure data centers

AWS operates secure data centers to reduce the risk of network tapping, theft, or other physical attacks. We use the principal of least privilege to vet access requests. Those requests must specify to which layer of the data center the individual needs access, and are time-bound. No electronic storage media is permitted to leave AWS data centers without either being physically destroyed or cryptographically erased using techniques detailed in NIST 800-88. AWS services and systems support always-on encryption for network, memory, and storage. In many cases, there are two or more layers of always-on encryption, ensuring that the only access to data is by the systems responsible for processing that data for customers.

Checks and balances and separation of duties

AWS employs organizational and technical checks and balances to ensure that no security event could go undetected, and no individual or group could subvert important security controls. AWS access control systems and access monitoring systems are intentionally independent and operated by separate teams.

Defense-in-depth security measures

We designed AWS with defense-in-depth security measures including change controls, immutable log capabilities, separation of duties, multi-party approvals, contingent authorization mechanisms, and hands-off operational tooling. These security measures go beyond standard security practices so that the actions taken by AWS operators are safe, transparent, logged, and reviewed.

We’ve implemented permission groups to allocate access to resources, a permissions tool to administer permission group membership, and secure tooling that allows authorized operators to perform system maintenance and troubleshooting without direct access to service resources. We also automatically update membership as employees change roles or exit the company.