Security

When you build systems on AWS infrastructure, security responsibilities are shared between you and AWS. This shared responsibility model reduces your operational burden because AWS operates, manages, and controls the components including the host operating system, the virtualization layer, and the physical security of the facilities in which the services operate. For more information about AWS security, visit AWS Cloud Security.

IAM roles

IAM roles allow customers to assign granular access policies and permissions to services and users on the AWS Cloud. This solution creates IAM roles that grant the solution’s Lambda functions access to create Regional resources.

Secrets management

This solution leverages AWS Secrets Manager to securely store user-specified OAuth credentials and tokens. The solution generates a secret using a JSON text string with predefined key-value pairs. The secret is identified by a unique key name. The solution restricts access to this secret through IAM policies, allowing only specific Lambda functions that need it for operation to access this secret.

OAuth credentials handling

The Amazon SageMaker instance has limited permissions: to only access the sample notebooks from the deployed artifacts S3 bucket; and to invoke the Lambda functions needed to use the TPS and WFM microservices. The SageMaker instance does not have access to data contained within the solution. The notebooks send requests to Lambda using Boto3, with IAM policies restricting its functionality to invoke these functions only. The notebooks are optional and only serve as examples of how to use Boto3 to invoke the Lambda functions.

This solution provides a notebook and a Lambda function to guide users through the authorization process to Amazon Ads. After a user retrieves their authorization code from Login with Amazon (LwA), they can input their client ID, client secret, and authorization code into Secrets Manager. The user can invoke the OAuth Lambda. This Lambda retrieves access and refresh tokens, storing them in Secrets Manager for future API calls. For added security, the SageMaker notebook has constrained permission to only invoke the Lambda function (it does not have access to Secrets Manager). Also, there is no input required from the user to invoke the Lambda function as the required values are stored in Secrets Manager ahead of time. This Lambda function has restricted permission that can only update the specific secret created by this solution.

When users make requests to Amazon Marketing Cloud, the Lambda functions in WFM read the client ID and access token stored in Secrets Manager. If the access token has expired, the Lambda functions retrieve a new one using the client ID, client secret, and refresh token stored in Secrets Manager, and then save the new access token for future use.

Since the Lambda functions are the only resources that require access to Secrets Manager, we limit their policies to only include permissions for accessing and updating the secret. This ensures that no other resources can modify the secret, and the Lambda functions are the only ones responsible for managing it.

Security recommendations

Create admin roles

We recommend that the admin create IAM roles and policies to control other users' access to the AWS resources created by this solution. Each user must have only the minimum permissions required to perform specific job functions. For more information, see Access management for AWS resources.

Rotate secrets

This solution uses Secrets Manager to store users' OAuth2 credentials, authorization code, access token, and refresh token. OAuth2 credentials are associated with the security profile created in LwA, and the refresh token remains valid until the user who granted authorization revokes it. Therefore, we recommend rotating the OAuth2 credentials and refresh token based on their enterprises' password rotation policy. See Rotate AWS Secrets Manager secrets.

What to do if your tokens are compromised?

An access token represents an advertiser's consent for a client to access that advertiser's data and services. Each access token remains valid for sixty minutes. Users can refresh these tokens using the refresh token provided during initial authorization. This refresh token remains valid for a year or until authorization is revoked. After a successful request using a refresh token, the same refresh token is returned along with a new access token. Therefore, if the tokens are compromised, the impact must be analyzed with the corresponding advertiser and advertiser client. We recommend that users contact LwA to get tailored recommendations for their specific scenario. See the LwA page for more information about access tokens and refresh tokens.

If you suspect that your tokens have been compromised, you must take the following actions, though these are not exhaustive:

1. Invalidate the tokens and delete the security grant from LwA.

2. Delete the entries in Secrets Manager.