# Data Access Controls


Article 25 of the GDPR states that the controller “shall implement appropriate technical and organizational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed”. The following AWS access control mechanisms can help customers comply with this requirement by allowing only authorized administrators, users, and applications to get access to AWS resources and customer data. 

# AWS Identity and Access Management (IAM)


## Managing access in the AWS Cloud


[AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) is a service that allows customers to control who can access AWS resources and under what conditions. It enables fine-grained permission management aligned with the GDPR principle of data protection by design.

When a new [AWS account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-creating.html) is created, a [root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) is also created with full administrative privileges. AWS strongly recommends that the root user be used only for essential tasks, such as initial account setup or billing administration. For all other activities, customers should create [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) or [roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) and assign only the permissions necessary to perform specific tasks. This approach aligns with the [principle of least privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) and is foundational to a secure environment.

IAM supports both long-term credentials (for users) and short-term credentials (for roles). For example, customers can use IAM roles to allow an [Amazon EC2](https://aws.amazon.com/ec2/) instance to access objects in an [Amazon S3](https://aws.amazon.com/s3/) bucket or allow a [AWS Lambda function](https://aws.amazon.com/lambda/) to write logs to [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html). The same pattern applies when enabling secure access to services such as [Amazon RDS](https://aws.amazon.com/rds/), [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), or [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/).

## Organizing access across accounts


Customers managing multi-account environments can use [AWS Organizations](https://aws.amazon.com/organizations/) to apply [Service Control Policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) across accounts. SCPs define broad permissions boundaries and can, for instance, restrict actions available to the root user. AWS provides [examples of SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_example-scps.html) to help customers implement common controls.

## Detecting unintended access with IAM Access Analyzer


IAM includes features to help customers continuously monitor how access is granted across their environment. [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) evaluates resource policies and identifies unintended external access. It supports multiple resource types, including [Amazon S3 buckets](https://aws.amazon.com/s3/), [AWS Key Management Service (KMS)](https://aws.amazon.com/kms/) keys, [Lambda functions](https://aws.amazon.com/lambda/), and [SQS queues](https://aws.amazon.com/sqs/).

When used with S3, IAM Access Analyzer can alert customers if a bucket is publicly accessible or shared across AWS accounts. AWS recommends enabling [Block Public Access settings](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html) to prevent unintentional exposure. If access is required for a specific use case, customers should test application behavior and apply precise controls.

## Monitoring root account usage and detecting threats


[AWS GuardDuty](https://aws.amazon.com/guardduty/) can detect when root credentials are used in ways that may signal a security concern. The system generates findings such as [Policy:IAMUser/RootCredentialUsage](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings.html) when root access is detected, enabling customers to investigate and take action.

## Refining permissions with access history


IAM provides [last accessed information](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html), a feature that shows when IAM roles, users, or policies were last used. 

# Temporary Access Tokens Through AWS STS


Customers can use the [AWS Security Token Service (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) to create and provide trusted users with temporary security credentials that grant access to customers' AWS resources. Temporary security credentials work almost identically to the long-term access key credentials that customers provide for their IAM users, with the following differences: 
+ Temporary security credentials are for short-term use. Customers can configure the amount of time that they are valid, from 15 minutes up to a maximum of 12 hours. After temporary credentials expire, AWS does not recognize them or allow any kind of access from API requests made with them. 
+ Temporary security credentials are not stored with the user. Instead, they are generated dynamically and provided to the user when requested. When (or before) temporary security credentials expire, a user can request new credentials, if that user has permissions to do so. 

These differences provide the following advantages when customers use temporary credentials: 
+ Customers do not have to distribute or embed long-term AWS security credentials with an application.
+ Temporary credentials are the basis for roles and identity federation. Customers can provide access to their AWS resources to users by defining a temporary AWS identity for them. 
+ Temporary security credentials have a limited customizable lifespan. Because of this, customers do not have to rotate them or explicitly revoke them when they're no longer needed. After temporary security credentials expire, they cannot be reused. Customers can specify the maximum amount of time the credentials are valid. 

# Multi-Factor-Authentication


For extra security, customers can add two-factor authentication to their AWS account and to IAM users. With multi-factor authentication (MFA) enabled, when customers sign into the [AWS Management Console](https://aws.amazon.com/console/), they are prompted for their credentials (the first factor), as well as an authentication response from their AWS MFA device (the second factor). Customers can enable MFA for their AWS account and for individual IAM users they have created in their account. Customers can also use MFA to control access to AWS service APIs. 

For example, customers can define a policy that allows full access to all AWS API operations in [Amazon EC2](https://aws.amazon.com/ec2/), but explicitly denies access to specific API operations – such as StopInstances and TerminateInstances – if the user is not authenticated with MFA. 

```
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “AllowAllActionsForEC2”,
“Effect”: “Allow”,
“Action”: “ec2:*”,
“Resource”: “*”
},
{
“Sid”: “DenyStopAndTerminateWhenMFAIsNotPResent”,
“Effect”: “Deny”,
“Action”: [
“ec2:StopInstances”,
“ec2:TerminateInstances”
],
“Resource”: “*”,
“Conditions”: {
“BoolIfExists”: {“aws:MultiFactorAuthPresent”:false}
}
}
}
}
```

To add an extra layer of security to Amazon S3 buckets, customers can configure [MFA Delete](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html), which requires additional authentication to change the versioning state of a bucket and permanently delete an object version. MFA Delete provides added security in the event that your security credentials are compromised.

To use [MFA Delete](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html), customers can use either a hardware or virtual MFA device to generate an authentication code. See the [Multi-Factor Authentication page](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) for a list of supported hardware or virtual MFA devices.

# Access to AWS Resources


To implement granular access to your AWS resources, customers can grant different levels of permissions to different people for different resources. For example, customers can allow only some users complete access to [Amazon EC2](https://aws.amazon.com/ec2/), [Amazon S3](https://aws.amazon.com/s3/), [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [Amazon Redshift](https://aws.amazon.com/redshift/), and other AWS Services. 

For other users, you can allow read-only access to only some Amazon S3 buckets; permission to administer only some Amazon EC2 instances, or access to only your billing information. 

The following policy is an example of one method you can use to allow all actions on a specific Amazon S3 bucket and explicitly deny access to every AWS service that is not Amazon S3. 

```
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: “s3:*”,
“Resource”: [
“arn:aws:s3:::bucket-name”,
“arn:aws:s3:::bucket-name/*”
],
},
{
“Effect”: “Deny”,
“NotAction”: “s3:*”,
“NotResource”: [
“arn:aws:s3:::bucket-name”,
“arn:aws:s3:::bucket-name/*”
]
}
]
}
```

You can attach a policy to a user or to a role. For other examples of IAM policies, see [Example IAM Identity-Based Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html). 

# Defining Boundaries for Regional Services Access


As a customer, you maintain ownership of your content, and you select which AWS services can process, store, and host your content. You can choose to store your customer data in any one or more of our European Regions, including EU Regions in France, Germany, Ireland, Italy, Spain, and Sweden. You can also choose to store your customer data in our Regions in Switzerland and in the United Kingdom. Both Switzerland and the United Kingdom have current adequacy decisions under the GDPR permitting the transfer of personal data. You can also use AWS services with the confidence that customer data stays in the AWS Region you select. AWS prohibits – and our systems are designed to prevent – remote access by AWS personnel to customer data for any purpose, including service maintenance, unless that access is requested by you or unless access is required to prevent fraud and abuse, or to comply with law. 

IAM policies provide a simple mechanism to limit access to services in specific Regions. You can add a global condition (aws:RequestedRegion) to the IAM policies attached to your IAM Principals to enforce this for all AWS services. For example, the following policy uses the NotAction element with the Deny effect, which explicitly denies access to all of the actions not listed in the statement if the requested Region is not European. Actions in the [Amazon CloudFront](https://aws.amazon.com/cloudfront/), [AWS IAM](https://aws.amazon.com/iam/), [Amazon Route 53](https://aws.amazon.com/route53/), and [AWS Support](https://aws.amazon.com/contact-us/) services should not be denied because these are popular AWS global services.

```
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “DenyAllOutsideRequestedRegions”,
“Effect”: “Deny”,
“NotAction”: [
“cloudfront:*”,
“iam:*”,
“route53:*”,
“support:*”
],
“Resource”: “*”,
“Condition”: {
“StringNotLike”: {
“aws:RequestedRegion”: [
“eu-*”
]
}
}
}
]
}
```

This sample IAM policy can also be implemented as a Service Control Policy (SCP) in [AWS Organizations](https://aws.amazon.com/organizations/), which defines the permission boundaries applied to specific AWS accounts or Organizational Units (OUs) within an organization. This enables you to control user access to regional services in complex multi-account environments. 

Geo-limiting capabilities exist for newly launched Regions. Regions introduced after March 20, 2019 are disabled by default. You must enable these Regions before you can use them. If an AWS Region is disabled by default, you can use the AWS Management Console to enable and disable the Region. Enabling and disabling AWS Regions enables you to control whether users in your AWS account can access resources in that Region. For more information, see [“enable or disable AWS Regions in your account”](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html). 

## AWS Control Tower


Using [AWS Control Tower](https://aws.amazon.com/de/controltower/), you can configure region deny control which is an elective control with preventive guidance and apply region restrictions to all registered OUs in the Organization. AWS Control Tower offers a group of controls that are designed to enhance your governance over regional boundaries for access to data:
+ *Data residency:* Control over the location of your data.
+ *Granular access:* Access restrictions that limit all access to your data, unless the access is requested by you, or by a partner whom you trust.
+ *Encryption:* Features and controls that help you encrypt data, whether in transit, at rest, or in memory.
+ *Resiliency:* Ability to sustain operations through disruption or disconnection, which is essential in the case of events such as supply chain disruption, network interruption, and natural disaster.

# Control Access to Web Applications and Mobile Apps


AWS provides services for managing data access control within customer applications. If you need to add user login and access control features to your web applications and mobile apps, you can use [Amazon Cognito](https://aws.amazon.com/cognito/). Amazon Cognito user pools provide a secure user directory that scales to hundreds of millions of users. To protect the identity of the users, you can add multi-factor authentication (MFA) to your user pools. You can also use adaptive authentication, which uses a risk-based model to predict when you might need another authentication factor. 

With [Amazon Cognito Identity Pools](https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html) (Federated Identities), you can see who accessed your resources and where the access originated (mobile app or web application). You can use this information to create IAM roles and policies that allow or deny access to a resource based on the type of access origin (mobile app or web application) and Identity Provider.