# Security in AWS Resource Access Manager
Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that is built to meet the requirements of the most security-sensitive organizations.
Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS compliance programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to AWS Resource Access Manager (AWS RAM), see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
This documentation helps you understand how to apply the shared responsibility model when using AWS RAM. The following topics show you how to configure AWS RAM to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your AWS RAM resources.
**Topics**
+ [Data protection in AWS Resource Access Manager](data-protection.md)
+ [Identity and access management for AWS Resource Access Manager](security-iam.md)
+ [Logging and monitoring in AWS RAM](security-monitoring.md)
+ [Compliance validation for AWS Resource Access Manager](compliance-validation.md)
+ [Resilience in AWS Resource Access Manager](disaster-recovery-resiliency.md)
+ [Infrastructure security in AWS Resource Access Manager](infrastructure-security.md)
+ [Access AWS Resource Access Manager using an interface endpoint (AWS PrivateLink)](vpc-interface-endpoints.md)
# Data protection in AWS Resource Access Manager
The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in AWS Resource Access Manager. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3.
+ Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
+ If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with AWS RAM or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.
# Identity and access management for AWS Resource Access Manager
AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. Administrators in IAM control who can be *authenticated* (signed in) and *authorized* (have permissions) to use AWS resources. By using IAM, you create principals, such as roles, users, and groups in your AWS account. You control the permissions that those principals have to perform tasks using AWS resources. You can use IAM for no additional charge. For more information about managing and creating custom IAM policies, see [Managing IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage.html) in the *IAM User Guide*.
**Topics**
+ [How AWS RAM works with IAM](security-iam-policies.md)
+ [AWS managed policies for AWS Resource Access Manager](security-iam-awsmanpol.md)
+ [Using service-linked roles for AWS RAM](using-service-linked-roles.md)
+ [Example IAM policies for AWS RAM](security-iam-policies-examples.md)
+ [Example service control policies for AWS Organizations and AWS RAM](security-scp.md)
+ [Disabling resource sharing with AWS Organizations](security-disable-sharing-with-orgs.md)
# How AWS RAM works with IAM
By default, IAM principals don't have permission to create or modify AWS RAM resources. To allow IAM principals to create or modify resources and perform tasks, you perform one of the following steps. These actions grant permission to use specific resources and API actions.
To provide access, add permissions to your users, groups, or roles:
+ Users and groups in AWS IAM Identity Center:
Create a permission set. Follow the instructions in [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) in the *AWS IAM Identity Center User Guide*.
+ Users managed in IAM through an identity provider:
Create a role for identity federation. Follow the instructions in [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*.
+ IAM users:
+ Create a role that your user can assume. Follow the instructions in [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*.
+ (Not recommended) Attach a policy directly to a user or add a user to a user group. Follow the instructions in [Adding permissions to a user (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*.
AWS RAM provides several AWS managed policies that you can use that will address the needs of many users. For more information about these, see [AWS managed policies for AWS Resource Access Manager](security-iam-awsmanpol.md).
If you need finer control over the permissions you grant to your users, you can construct your own policies in the IAM console. For information about creating policies and attaching them to your IAM roles and users, see [Policies and permissions in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) in the *AWS Identity and Access Management User Guide*.
The following sections provide the AWS RAM specific details for building an IAM permission policy.
**Contents**
+ [Policy structure](#structure)
+ [Effect](#iam-policies-effect)
+ [Action](#iam-policies-action)
+ [Resource](#iam-policies-resource)
+ [Condition](#iam-policies-condition)
## Policy structure
An IAM permission policy is a JSON document that includes the following statements: Effect, Action, Resource, and Condition. An IAM policy typically takes the following form.
```
{
"Statement":[{
"Effect":"",
"Action":"",
"Resource":"",
"Condition":{
"":{
"":""
}
}
}]
}
```
### Effect
The *Effect* statement indicates whether the policy allows or denies a principal permission to perform an action. The possible values include: `Allow` and `Deny`.
### Action
The *Action* statement specifies the AWS RAM API actions for which the policy is allowing or denying permission. For a complete list of the allowed actions, see [ Actions defined by AWS Resource Access Manager](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsresourceaccessmanager.html#awsresourceaccessmanager-actions-as-permissions) in the *IAM User Guide*.
### Resource
The *Resource* statement specifies the AWS RAM resources that are affected by the policy. To specify a resource in the statement, you need to use its unique Amazon Resource Name (ARN). For a complete list of the allowed resources, see [ Resources defined by AWS Resource Access Manager](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsresourceaccessmanager.html#awsresourceaccessmanager-resources-for-iam-policies) in the *IAM User Guide*.
### Condition
*Condition* statements are optional. They can be used to further refine the conditions under which the policy applies. AWS RAM supports the following condition keys:
+ `aws:RequestTag/${TagKey}` – Tests whether the service request includes a tag with the specified tag key exists and has the specified value.
+ `aws:ResourceTag/${TagKey}` – Tests whether the resource acted on by the service request has an attached tag with a tag key that you specify in the policy.
The following example condition checks that the resource referenced in the service request has an attached tag with the key name "Owner" and a value of "Dev Team".
```
"Condition" : {
"StringEquals" : {
"aws:ResourceTag/Owner" : "Dev Team"
}
}
```
+ `aws:TagKeys` – Specifies the tag keys that must be used to create or tag a resource share.
+ `ram:AllowsExternalPrincipals` – Tests whether the resource share in the service request allows sharing with external principals. An external principal is an AWS account outside of your organization in AWS Organizations. If this evaluates to `False`, then you can share this resource share with accounts only in the same organization.
+ `ram:PermissionArn` – Tests whether the permission ARN specified in the service request matches an ARN string that you specify in the policy.
+ `ram:PermissionResourceType` – Tests whether the permission specified in the service request is valid for the resource type that you specify in the policy. Specify resource types using the format shown in the list of [shareable resource types](shareable.md).
+ `ram:Principal` – Tests whether the ARN of the principal specified in the service request matches an ARN string that you specify in the policy.
+ `ram:RequestedAllowsExternalPrincipals` – Tests whether the service request includes the `allowExternalPrincipals` parameter and whether its argument matches the value you specify in the policy.
+ `ram:RequestedResourceType` – Tests whether the resource type of the resource being acted on matches a resource type string that you specify in the policy. Specify resource types using the format shown in the list of [shareable resource types](shareable.md).
+ `ram:ResourceArn` – Tests whether the ARN of the resource being acted upon by the service request matches an ARN that you specify in the policy.
+ `ram:ResourceShareName` – Tests whether the name of the resource share being acted upon by the service request matches a string that you specify in the policy.
+ `ram:ShareOwnerAccountId` – Tests the account ID number of the resource share being acted upon by the service request matches a string that you specify in the policy.
# AWS managed policies for AWS Resource Access Manager
AWS Resource Access Manager currently provides several AWS RAM managed policies, which are described in this topic.
**Topics**
+ [AWSResourceAccessManagerReadOnlyAccess](#security-iam-managed-policies-AWSResourceAccessManagerReadOnlyAccess)
+ [AWSResourceAccessManagerFullAccess](#security-iam-managed-policies-AWSResourceAccessManagerFullAccess)
+ [AWSResourceAccessManagerResourceShareParticipantAccess](#security-iam-managed-policies-AWSResourceAccessManagerResourceShareParticipantAccess)
+ [AWSResourceAccessManagerServiceRolePolicy](#security-iam-managed-policies-AWSResourceAccessManagerServiceRolePolicy)
+ [Policy updates](#security-iam-awsmanpol-updates)
In the preceding list, you can attach the first three policies to your IAM roles, groups, and users to grant permissions. The last policy in the list is reserved for the AWS RAM service's service-linked role.
An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles.
Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases.
You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services.
For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*.
## AWS managed policy: AWSResourceAccessManagerReadOnlyAccess
You can attach the `AWSResourceAccessManagerReadOnlyAccess` policy to your IAM identities.
This policy provides read-only permissions to the resource shares that are owned by your AWS account.
It does this by granting permission to run any of the `Get*` or `List*` operations. It doesn't provide any ability to modify any resource share.
**Permissions details**
This policy includes the following permissions.
+ `ram` – Allows principals to view details about resource shares owned by the account.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ram:Get*",
"ram:List*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
## AWS managed policy: AWSResourceAccessManagerFullAccess
You can attach the `AWSResourceAccessManagerFullAccess` policy to your IAM identities.
This policy provides full administrative access to view or modify the resource shares that are owned by your AWS account.
It does this by granting permission to run any `ram` operations.
**Permissions details**
This policy includes the following permissions.
+ `ram` – Allows principals to view or modify any information about the resource shares that are owned by the AWS account.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ram:*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
## AWS managed policy: AWSResourceAccessManagerResourceShareParticipantAccess
You can attach the `AWSResourceAccessManagerResourceShareParticipantAccess` policy to your IAM identities.
This policy provides principals the ability to accept or reject resource shares that are shared with this AWS account, and to view details about these resource shares. It doesn't provide any ability to modify those resource shares.
It does this by granting permission to run some `ram` operations.
**Permissions details**
This policy includes the following permissions.
+ `ram` – Allows principals to accept or reject resource share invitations and to view details about the resource shares that are shared with the account.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ram:AcceptResourceShareInvitation",
"ram:GetResourcePolicies",
"ram:GetResourceShareInvitations",
"ram:GetResourceShares",
"ram:ListPendingInvitationResources",
"ram:ListPrincipals",
"ram:ListResources",
"ram:RejectResourceShareInvitation"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
## AWS managed policy: AWSResourceAccessManagerServiceRolePolicy
The AWS managed policy `AWSResourceAccessManagerServiceRolePolicy`can be used only with the service-linked role for AWS RAM. You can't attach, detach, modify, or delete this policy.
This policy provides AWS RAM with read-only access to your organization's structure. When you enable integration between AWS RAM and AWS Organizations, AWS RAM automatically creates a service-linked role named [AWSServiceRoleForResourceAccessManager](https://console.aws.amazon.com/iam/home#/roles/AWSServiceRoleForResourceAccessManager) that the service assumes when it needs to look up information about your organization and its accounts, for example, when you view the organization's structure in the AWS RAM console.
It does this by granting read-only permission to run the `organizations:Describe` and `organizations:List` operations that provide details of the organization's structure and accounts.
**Permissions details**
This policy includes the following permissions.
+ `organizations` – Allows principals to view information about the organization's structure, including the organizational units, and the AWS accounts they contain.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"organizations:DescribeAccount",
"organizations:DescribeOrganization",
"organizations:DescribeOrganizationalUnit",
"organizations:ListAccounts",
"organizations:ListAccountsForParent",
"organizations:ListChildren",
"organizations:ListOrganizationalUnitsForParent",
"organizations:ListParents",
"organizations:ListRoots"
],
"Resource": "*"
},
{
"Sid": "AllowDeletionOfServiceLinkedRoleForResourceAccessManager",
"Effect": "Allow",
"Action": [
"iam:DeleteRole"
],
"Resource": [
"arn:aws:iam::*:role/aws-service-role/ram.amazonaws.com/*"
]
}
]
}
```
------
## AWS RAM updates to AWS managed policies
View details about updates to AWS managed policies for AWS RAM since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the AWS RAM Document history page.
| Change | Description | Date |
| --- | --- | --- |
| AWS Resource Access Manager started tracking changes | AWS RAM documented its existing managed policies and started tracking changes. | September 16, 2021 |
# Using service-linked roles for AWS RAM
AWS Resource Access Manager uses AWS Identity and Access Management (IAM)[ service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to the AWS RAM service. Service-linked roles are predefined by AWS and include all the permissions that AWS RAM needs to call other AWS services on your behalf.
A service-linked role makes configuring AWS RAM easier because you don’t have to manually add the necessary permissions. AWS RAM defines the permissions of its service-linked roles, and unless defined otherwise, only AWS RAM can assume its service-linked roles. The defined permissions include both a trust policy and a permissions policy, and that permissions policy cannot be attached to any other IAM entity.
For information about other services that support service-linked roles, see [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes **in the **Service-Linked Role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service.
## Service-Linked Role Permissions for AWS RAM
AWS RAM uses the service-linked role named `AWSServiceRoleForResourceAccessManager` when you enable sharing with AWS Organizations. This role grants permissions to the AWS RAM service to view organization details, such as the list of member accounts and which organizational units each account is in.
This service-linked role trusts the following service to assume the role:
+ `ram.amazonaws.com`
The role permissions policy named AWSResourceAccessManagerServiceRolePolicy is attached to this service-linked role, and allows AWS RAM to complete the following actions on the specified resources:
+ Actions: read-only actions that retrieve details about your organization's structure. For the complete list of actions, you can view the policy in the IAM console: [AWSResourceAccessManagerServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSResourceAccessManagerServiceRolePolicy$jsonEditor).
For a principal to turn on AWS RAM sharing within your organization, that principal (an IAM entity such as a user, group, or role), must have permission to create a service-linked role. For more information, see [Service-Linked Role Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.
## Creating a Service-Linked Role for AWS RAM
You don't need to manually create a service-linked role. When you turn on AWS RAM sharing within your organization in the AWS Management Console, or run the [EnableSharingWithAwsOrganization](https://docs.aws.amazon.com/ram/latest/APIReference/API_EnableSharingWithAwsOrganization.html) in your account using the AWS CLI or an AWS API, AWS RAM creates the service-linked role for you.
Call `enable-sharing-with-aws-organizations` to create the service linked role in your account.
If you delete this service-linked role, then AWS RAM no longer has permissions to view the details of your organization's structure.
## Editing a service-linked role for AWS RAM
AWS RAM does not allow you to edit the AWSResourceAccessManagerServiceRolePolicy service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM. For more information, see [Editing a Service-Linked Role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*.
## Deleting a Service-Linked Role for AWS RAM
You can use the IAM console, the AWS CLI or the AWS API to manually delete the service-linked role.
**To manually delete the service-linked role using IAM**
Use the IAM console, the AWS CLI, or the AWS API to delete the `AWSResourceAccessManagerServiceRolePolicy` service-linked role. For more information, see [Deleting a Service-Linked Role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
## Supported Regions for AWS RAM Service-Linked Roles
AWS RAM supports using service-linked roles in all of the Regions where the service is available. For more information, see [AWS Regions and Endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html) in the *Amazon Web Services General Reference*.
# Example IAM policies for AWS RAM
This topic includes examples of IAM policies for AWS RAM that demonstrate sharing specific resources and resource types and restricting sharing.
**Topics**
+ [Allow sharing of specific resources](#owner-share-specific-resources)
+ [Allow sharing of specific resource types](#owner-share-resource-types)
+ [Restrict sharing with external AWS accounts](#control-access-owner-external)
## Example 1: Allow sharing of specific resources
You can use an IAM permission policy to restrict principals to associating only specific resources with resource shares.
For example, the following policy limits principals to sharing only the resolver rule with the specified Amazon Resource Name (ARN). The operator `StringEqualsIfExists` allows a request if either the request doesn't include a `ResourceArn` parameter, or if it does include that parameter, that its value exactly matches the specified ARN.
For more information about when and why to use `...IfExists` operators, see [...IfExists condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_IfExists) in the *IAM User Guide*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["ram:CreateResourceShare", "ram:AssociateResourceShare"],
"Resource": "*",
"Condition": {
"StringEqualsIfExists": {
"ram:ResourceArn": "arn:aws:route53resolver:us-west-2:123456789012:resolver-rule/rslvr-rr-5328a0899aexample"
}
}
}]
}
```
------
## Example 2: Allow sharing of specific resource types
You can use an IAM policy to limit principals to associating only specific resource types with resource shares.
The actions, `AssociateResourceShare` and `CreateResourceShare`, can accept principals and `resourceArns` as independent input parameters. Therefore, AWS RAM authorizes each principal and resource independently, so there could be multiple [request contexts](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-reqcontext.html). This means when a principal is being associated to a AWS RAM resource share, the `ram:RequestedResourceType` condition key is not present in the request context. Similarly, when a resource is being associated to a AWS RAM resource share, the `ram:Principal` condition key is not present in the request context. Therefore, to allow `AssociateResourceShare` and `CreateResourceShare` when associating principals to the AWS RAM resource share, you can use the [`Null` condition operator](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_Null).
For example, the following policy limits principals to sharing only Amazon Route 53 resolver rules and allows them to associate any principal to that share.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "AllowOnlySpecificResourceType",
"Effect": "Allow",
"Action": ["ram:CreateResourceShare", "ram:AssociateResourceShare"],
"Resource": "*",
"Condition": {
"StringEquals": {
"ram:RequestedResourceType": "route53resolver:ResolverRule"
}
}
},
{
"Sid": "AllowAssociatingPrincipals",
"Effect": "Allow",
"Action": ["ram:CreateResourceShare", "ram:AssociateResourceShare"],
"Resource": "*",
"Condition": {
"Null": {
"ram:Principal": "false"
}
}
}
]
}
```
------
## Example 3: Restrict sharing with external AWS accounts
You can use an IAM policy to prevent principals from sharing resources with AWS accounts that are outside of its AWS organization.
For example, the following IAM policy prevents principals from adding external AWS accounts to resource shares.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "ram:CreateResourceShare",
"Resource": "*",
"Condition": {
"Bool": {
"ram:RequestedAllowsExternalPrincipals": "false"
}
}
}]
}
```
------
# Example service control policies for AWS Organizations and AWS RAM
AWS RAM supports service control policies (SCPs). SCPs are policies that you attach to elements in an organization to manage permissions within that organization. An SCP applies to all AWS accounts [under the element to which you attach the SCP](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_policies_inheritance_auth.html). SCPs offer central control over the maximum available permissions for all accounts in your organization. They can help you to ensure your AWS accounts stay within your organization’s access control guidelines. For more information, see [ Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_type-auth.html) in the *AWS Organizations User Guide*.
## Prerequisites
To use SCPs, you must first do the following:
+ Enable all features in your organization. For more information, see [Enabling all features in your organization](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html) in the *AWS Organizations User Guide*
+ Enable SCPs for use within your organization. For more information, see [Enabling and disabling policy types](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_enable-disable.html) in the *AWS Organizations User Guide*
+ Create the SCPs that you need. For more information about creating SCPs, see [ Creating and updating SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp-create.html) in the *AWS Organizations User Guide*.
## Example Service Control Policies
**Contents**
+ [Example 1: Prevent external sharing](#example-one)
+ [Example 2: Prevent users from accepting resource share invitations from external accounts outside your organization](#example-two)
+ [Example 3: Allow specific accounts to share specific resource types](#example-three)
+ [Example 4: Prevent sharing with the entire organization or with organizational units](#example-four)
+ [Example 5: Allow sharing with only specific principals](#example-five)
+ [Example 6: Prevent resource shares with RetainSharingOnAccountLeaveOrganization enabled](#example-six)
The following examples show how you can control various aspects of resource sharing in an organization.
### Example 1: Prevent external sharing
The following SCP prevents users from creating resource shares that allow sharing with principals that are outside of the sharing user's organization.
AWS RAM authorizes APIs separately for each principal and resource listed in the call.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ram:CreateResourceShare",
"ram:UpdateResourceShare"
],
"Resource": "*",
"Condition": {
"Bool": {
"ram:RequestedAllowsExternalPrincipals": "true"
}
}
}
]
}
```
------
### Example 2: Prevent users from accepting resource share invitations from external accounts outside your organization
The following SCP blocks any principal in an affected account from accepting an invitation to use a resource share. Resource shares that are shared to other accounts in the same organization as the sharing account don't generate invitations and are therefore not affected by this SCP.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ram:AcceptResourceShareInvitation",
"Resource": "*"
}
]
}
```
------
### Example 3: Allow specific accounts to share specific resource types
The following SCP allows *only* accounts `111111111111` and `222222222222` to create new resource shares that share Amazon EC2 prefix lists or to associate prefix lists with existing resource shares.
AWS RAM authorizes APIs separately for each principal and resource listed in the call.
The operator `StringEqualsIfExists` allows a request if either the request doesn't include a resource type parameter, or if it does include that parameter, that its value exactly matches the specified resource type. If you're including a principal you must have `...IfExists`.
For more information about when and why to use `...IfExists` operators, see [...IfExists condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_IfExists) in the *IAM User Guide*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ram:AssociateResourceShare",
"ram:CreateResourceShare"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": [
"111111111111",
"222222222222"
]
},
"StringEqualsIfExists": {
"ram:RequestedResourceType": "ec2:PrefixList"
}
}
}
]
}
```
------
### Example 4: Prevent sharing with the entire organization or with organizational units
The following SCP prevents users from creating resource shares that share resources with an entire organization or with any organizational units. Users *can* share with individual AWS accounts in the organization, or with IAM roles or users.
AWS RAM authorizes APIs separately for each principal and resource listed in the call.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ram:CreateResourceShare",
"ram:AssociateResourceShare"
],
"Resource": "*",
"Condition": {
"StringLike": {
"ram:Principal": [
"arn:aws:organizations::*:organization/*",
"arn:aws:organizations::*:ou/*"
]
}
}
}
]
}
```
------
### Example 5: Allow sharing with only specific principals
The following example SCP allows users to share resources with *only* organization `o-12345abcdef,` organizational unit `ou-98765fedcba`, and AWS account `111111111111`.
If you're using an `"Effect": "Deny"` element with a negated condition operator, like `StringNotEqualsIfExists`, the request is still denied even if the condition key is not present. Use a `Null` condition operator to check if a condition key is absent at the time of authorization.
AWS RAM authorizes APIs separately for each principal and resource listed in the call.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ram:AssociateResourceShare",
"ram:CreateResourceShare"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"ram:Principal": [
"arn:aws:organizations::123456789012:organization/o-12345abcdef",
"arn:aws:organizations::123456789012:ou/o-12345abcdef/ou-98765fedcba",
"111111111111"
]
},
"Null": {
"ram:Principal": "false"
}
}
}
]
}
```
------
### Example 6: Prevent resource shares with RetainSharingOnAccountLeaveOrganization enabled
The following SCP prevents users from creating or modifying resource shares when the `ram:RetainSharingOnAccountLeaveOrganization` condition key is set to `true`.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ram:CreateResourceShare",
"ram:AssociateResourceShare",
"ram:DisassociateResourceShare"
],
"Resource": "*",
"Condition": {
"Bool": {
"ram:RetainSharingOnAccountLeaveOrganization": "true"
}
}
}
]
}
```
# Disabling resource sharing with AWS Organizations
If you previously enabled sharing with AWS Organizations and you no longer need to share resources with your entire organization or organizational units (OUs), you can disable sharing. When you disable sharing with AWS Organizations, all organizations or OUs are removed from the resource shares that you have created and they lose access to the shared resources. External accounts (accounts added to the resource share via invitation) will not be impacted, and will continue to be associated with the resource share.
**To disable sharing with AWS Organizations**
1. Disable trusted access to AWS Organizations using the AWS Organizations [disable-aws-service-access](https://docs.aws.amazon.com/cli/latest/reference/organizations/disable-aws-service-access.html) AWS CLI command.
```
$ aws organizations disable-aws-service-access --service-principal ram.amazonaws.com
```
**Important**
When you disable trusted access to AWS Organizations, principals within your organizations are removed from all resource shares and lose access to those shared resources.
1. Use the IAM console, the AWS CLI, or the IAM API operations to delete the **AWSServiceRoleForResourceAccessManager** service-linked role. For more information, see [Deleting a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) in the *IAM User Guide*.
# Logging and monitoring in AWS RAM
Monitoring is an important part of maintaining the reliability, availability, and performance of AWS RAM and your AWS solutions. You should collect monitoring data from all parts of your AWS solution so that you can more easily debug a multi-point failure if one occurs. AWS provides several tools for monitoring your AWS RAM resources and responding to potential incidents:
**Amazon EventBridge**
Delivers a near-real-time stream of system events that describe changes in AWS resources. EventBridge enables automated event-driven computing, as you can write rules that watch for certain events and trigger automated actions in other AWS services when these events happen. For more information, see [Monitoring AWS RAM using EventBridge](using-eventbridge.md).
**AWS CloudTrail**
Captures API calls and related events made by or on behalf of your AWS account and delivers the log files to an Amazon S3 bucket that you specify. You can identify which users and accounts called AWS, the source IP address from which the calls were made, and when the calls occurred. For more information, see [Logging AWS RAM API calls with AWS CloudTrail](cloudtrail-logging.md).
# Monitoring AWS RAM using EventBridge
Using Amazon EventBridge, you can set up automatic notifications for specific events in AWS RAM. Events from AWS RAM are delivered to EventBridge in near-real time. You can configure EventBridge to monitor events and invoke targets in response to events that indicate changes to your resource shares. Changes to a resource share trigger events for both the owner of the resource share and the principals that were granted access to the resource share.
When you create an event pattern, the source is `aws.ram`.
**Note**
Take care writing code that depends on these events. These events are not guaranteed, but are emitted on a best effort basis. If an error occurs when AWS RAM attempts to emit an event, the service tries several more times. However, it can time out and result in the loss of that specific event.
For more information, see the Amazon EventBridge User Guide.
## Example: Alerting on resource share failures
Consider the scenario where you want to share Amazon EC2 capacity reservations with other accounts in your organization. Doing this is a good way to reduce your costs.
However, if you don't meet all of the [prerequisites for sharing a capacity reservation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-sharing.html#sharing-cr-prereq), then it can silently fail performing the asynchronous tasks involved in sharing resources. If the share operation fails, and your users in other accounts attempt to launch instances with one of those capacity reservations, then Amazon EC2 acts as if the capacity reservation was full and launches the instance as an on-demand instance instead. This can result in higher than expected costs.
To monitor for resource share failures, set up an Amazon EventBridge rule that alerts you whenever an AWS RAM resource share fails. The following tutorial procedure uses an Amazon Simple Notification Service (SNS) topic to notify all topic subscribers whenever EventBridge discovers a resource sharing failure. For more information about Amazon SNS, see the [Amazon Simple Notification Service Developer Guide](https://docs.aws.amazon.com/sns/latest/dg/).
**To create a rule that notifies you when resource sharing fails**
1. Open the [Amazon EventBridge console](https://console.aws.amazon.com/events).
1. In the navigation pane, choose **Rules**, and then in the **Rules** list, choose **Create rule**.
1. Enter a name and optional description for your rule, then choose **Next**.
1. Scroll down to the **Event pattern** box, and choose **Custom patterns (JSON editor)**.
1. Copy and paste the following event pattern:
```
{
"source": ["aws.ram"],
"detail-type": ["Resource Sharing State Change"],
"detail": {
"event": ["Resource Share Association"],
"status": ["failed"]
}
}
```
1. Choose **Next**.
1. For **Target 1**, under **Target type**, choose **AWS service**.
1. Under **Select a target**, choose **SNS topic**.
1. For **Topic**, choose the SNS topic to which you want to publish the notification. This topic must already exist.
1. Choose **Next**, and then choose **Next** again to see to review your configuration.
1. When you're satisfied with your options, choose **Create rule**.
1. Back on the **Rules** page, ensure that your new rule is marked **Enabled**. If necessary, choose the radio button next to your rule name, and then choose **Enable**.
As long as that rule is enabled, any AWS RAM resource share that fails generates an SNS alert to the recipients of the topic you published to.
You can also confirm that shared capacity reservations are accessible to the accounts you shared them with by attempting to [view them in the Amazon EC2 console from those accounts](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-sharing.html#identifying-shared-cr).
# Logging AWS RAM API calls with AWS CloudTrail
AWS RAM is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in AWS RAM. CloudTrail captures all API calls for AWS RAM as events. The calls captured include calls from the AWS RAM console and code calls to the AWS RAM API operations. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket that you specify, including events for AWS RAM. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in **Event history**. Use the information collected by CloudTrail to determine the request that was made to AWS RAM, the requesting IP address, the requester, when it was made, and additional details.
For more information about CloudTrail, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
## AWS RAM information in CloudTrail
CloudTrail is enabled on your AWS account when you create the account. When activity occurs in AWS RAM, that activity is recorded in a CloudTrail event along with other AWS service events in **Event history**. You can view, search, and download recent events in your AWS account. For more information, see [Viewing Events with CloudTrail Event History](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
For an ongoing record of events in your AWS account, including events for AWS RAM, create a trail. A *trail* enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all AWS Regions. The trail logs events from all Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see the following:
+ [Creating a trail for your AWS account](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [AWS service integrations with CloudTrail logs](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configuring Amazon SNS Notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Receiving CloudTrail log files from multiple Regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail log files from multiple accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
All AWS RAM actions are logged by CloudTrail and are documented in the [AWS RAM API Reference](https://docs.aws.amazon.com/ram/latest/APIReference/). For example, calls to the `CreateResourceShare`, `AssociateResourceShare`, and `EnableSharingWithAwsOrganization` actions generate entries in the CloudTrail log files.
Every event or log entry contains information that helps you determine who made the request.
+ AWS account root credentials
+ Temporary security credentials from an AWS Identity and Access Management (IAM) role or federated user.
+ Long-term security credentials from an IAM user.
+ Another AWS service.
For more information, see the [CloudTrail userIdentity element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Understanding AWS RAM log file entries
A trail is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An event represents a single request from any source and includes information about the requested action, the date and time of the action, request parameters, and so on. CloudTrail log files aren't an ordered stack trace of the public API calls, so they don't appear in any specific order.
The following example shows a CloudTrail log entry for the `CreateResourceShare` action.
```
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "NOPIOSFODNN7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/admin",
"accountId": "111122223333",
"accessKeyId": "BCDIOSFODNN7EXAMPLE",
"userName": "admin"
},
"eventTime": "2018-11-03T04:23:19Z",
"eventSource": "ram.amazonaws.com",
"eventName": "CreateResourceShare",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.1.0",
"userAgent": "aws-cli/1.16.2 Python/2.7.10 Darwin/16.7.0 botocore/1.11.2",
"requestParameters": {
"name": "foo"
},
"responseElements": {
"resourceShare": {
"allowExternalPrincipals": true,
"name": "foo",
"owningAccountId": "111122223333",
"resourceShareArn": "arn:aws:ram:us-east-1:111122223333:resource-share/EXAMPLE0-1234-abcd-1212-987656789098",
"status": "ACTIVE"
}
},
"requestID": "EXAMPLE0-abcd-1234-mnop-987654567876",
"eventID": "EXAMPLE0-1234-abcd-hijk-543234565434",
"readOnly": false,
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
```
# Compliance validation for AWS Resource Access Manager
To learn whether an AWS service is within the scope of specific compliance programs, see [AWS services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) and choose the compliance program that you are interested in. For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/).
You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Your compliance responsibility when using AWS services is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. For more information about your compliance responsibility when using AWS services, see [AWS Security Documentation](https://docs.aws.amazon.com/security/).
# Resilience in AWS Resource Access Manager
The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between Availability Zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures.
For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).
# Infrastructure security in AWS Resource Access Manager
As a managed service, AWS Resource Access Manager is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.
You use AWS published API calls to access AWS RAM through the network. Clients must support the following:
+ Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3.
+ Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.
# Access AWS Resource Access Manager using an interface endpoint (AWS PrivateLink)
You can use AWS PrivateLink to create a private connection between your VPC and AWS Resource Access Manager. You can access AWS RAM as if it were in your VPC, without the use of an internet gateway, NAT device, VPN connection, or Direct Connect connection. Instances in your VPC don't need public IP addresses to access AWS RAM.
You establish this private connection by creating an *interface endpoint*, powered by AWS PrivateLink. We create an endpoint network interface in each subnet that you enable for the interface endpoint. These are requester-managed network interfaces that serve as the entry point for traffic destined for AWS RAM.
For more information, see [Access AWS services through AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html) in the *AWS PrivateLink Guide*.
## Considerations for AWS RAM
Before you set up an interface endpoint for AWS RAM, review [Considerations](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#considerations-interface-endpoints) in the *AWS PrivateLink Guide*.
AWS RAM supports making calls to all of its API actions through the interface endpoint.
VPC endpoint policies are supported for AWS RAM. By default, full access to AWS RAM is allowed through the interface endpoint.
## Create an interface endpoint for AWS RAM
You can create an interface endpoint for AWS RAM using either the Amazon VPC console or the AWS Command Line Interface (AWS CLI). For more information, see [Create an interface endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) in the *AWS PrivateLink Guide*.
Create an interface endpoint for AWS RAM using the following service name:
```
com.amazonaws.region.ram
```
If you enable private DNS for the interface endpoint, you can make API requests to AWS RAM using its default Regional DNS name. For example, `ram.us-east-1.amazonaws.com`.
## Create an endpoint policy for your interface endpoint
An endpoint policy is an IAM resource that you can attach to an interface endpoint. The default endpoint policy allows full access to AWS RAM through the interface endpoint. To control the access allowed to AWS RAM from your VPC, attach a custom endpoint policy to the interface endpoint.
An endpoint policy specifies the following information:
+ The principals that can perform actions (AWS accounts, IAM users, and IAM roles).
+ The actions that can be performed.
+ The resources on which the actions can be performed.
For more information, see [Control access to services using endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) in the *AWS PrivateLink Guide*.
**Example: VPC endpoint policy for AWS RAM actions**
The following is an example of a custom endpoint policy. When you attach this policy to your interface endpoint, it grants access to the listed AWS RAM actions for all principals on all resources.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":
[
{
"Effect": "Allow",
"Principal": "*",
"Action": [
"ram:CreateResourceShare"
],
"Resource": "*"
}
]
}
```
------