AWS prescriptive-guidance documentation change
Summary
Updated breadcrumb navigation, fixed typographical errors (curly quotes to straight quotes), corrected hyperlinks, improved terminology consistency (e.g., 'IAM entities' to 'IAM principals'), and updated references to AWS documentation.
Security assessment
The changes are editorial improvements and documentation maintenance without introducing new security concepts or addressing vulnerabilities. Updates include link corrections, terminology consistency, and typo fixes. No evidence of patching security flaws or responding to incidents exists in the diff.
Diff
diff --git a/prescriptive-guidance/latest/security-reference-architecture/organizations-security.md b/prescriptive-guidance/latest/security-reference-architecture/organizations-security.md index c2b6898ba..e429f977d 100644 --- a//prescriptive-guidance/latest/security-reference-architecture/organizations-security.md +++ b//prescriptive-guidance/latest/security-reference-architecture/organizations-security.md @@ -3 +3 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[AWS Security Reference Architecture](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[AWS Security Reference Architecture (AWS SRA) – core architecture](introduction.html) @@ -12 +12 @@ Influence the future of the AWS Security Reference Architecture (AWS SRA) by tak -With AWS Organizations, you can use [SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) and [RCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) to apply permission guardrails at the AWS organization, OU, or account level. SCPs are guardrails that apply to principals within an organization's account, with the exception of the management account (which is one reason not to run workloads in this account). When you attach an SCP to an OU, the SCP is inherited by the child OUs and accounts under that OU. SCPs do not grant any permissions. Instead, they specify the maximum permissions for an AWS organization, OU, or account. You still need to attach [identity-based or resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) to principals or resources in your AWS accounts to actually grant permissions to them. For example, if an SCP denies access to all of Amazon S3, a principal affected by the SCP will not have access to Amazon S3 even if they are explicitly granted access through an IAM policy. For more information about how IAM policies are evaluated, the role of SCPs, and how access is ultimately granted or denied, see [policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the IAM documentation. +With AWS Organizations, you can use [SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) and [RCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) to apply permission guardrails at the AWS organization, OU, or account level. SCPs are guardrails that apply to principals within an organization's account, with the exception of the management account (which is one reason not to run workloads in this account). When you attach an SCP to an OU, the SCP is inherited by the child OUs and accounts under that OU. SCPs do not grant any permissions. Instead, they specify the maximum permissions available for your principals in an AWS organization, OU, or account. You still need to attach [identity-based or resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) to principals or resources in your AWS accounts to actually grant permissions to them. For example, if an SCP denies access to all of Amazon S3, a principal affected by the SCP will not have access to Amazon S3 even if they are explicitly**** granted access through an IAM policy. For more information about how IAM policies are evaluated, the role of SCPs, and how access is ultimately granted or denied, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the IAM documentation. @@ -14 +14 @@ With AWS Organizations, you can use [SCPs](https://docs.aws.amazon.com/organizat -RCPs are guardrails that apply to resources within an organization’s accounts, regardless of whether the resources belong to the same organization. Like SCPs, RCPs don’t affect the resources in the management account and do not grant any permissions. When you attach an RCP to an OU, the RCP is inherited by the child OUs and accounts under the OU. RCPs provide central control over the maximum available permissions for resources in your organization and currently support a subset of AWS services. When you design SCPs for your OUs, we recommend that you evaluate changes by using the [IAM policy simulator](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html). You should also review the [service last accessed data in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) and use [AWS CloudTrail to log service usage at the API level](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html) to understand the potential impact of SCP changes. +RCPs are guardrails that apply to resources within an organization's accounts, regardless of whether the resources belong to the same organization. Like SCPs, RCPs don't affect the resources in the management account and do not grant any permissions. When you attach an RCP to an OU, the RCP is inherited by the child OUs and accounts under the OU. RCPs provide central control over the maximum available permissions for resources in your organization and currently support a subset of AWS services. When you design SCPs for your OUs, we recommend that you evaluate changes by using the [IAM policy simulator](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html). You should also review the [service last accessed data in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html) and use [AWS CloudTrail to log service usage at the API level](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html) to understand the potential impact of SCP changes. @@ -16 +16 @@ RCPs are guardrails that apply to resources within an organization’s accounts, -SCPs and RCPs are independent controls. You can choose to enable only SCPs or RCPs, or use both policy types together based on the access controls that you want to enforce. For example, if you want to prevent your organization’s principals from accessing resources outside your organization, you enforce this control by using SCPs. If you want to restrict or prevent external identities from accessing your resources, you enforce this control by using RCPs. For more information and use cases for RCPs and SCPs, see [Using SCPs and RCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_authorization_policies.html#when-to-use-scps-and-rcps) in the AWS Organizations documentation. +SCPs and RCPs are independent controls. You can choose to enable only SCPs or RCPs, or use both policy types together based on the access controls that you want to enforce. For example, if you want to prevent your organization's principals from accessing resources outside your organization, you enforce this control by using SCPs. If you want to restrict or prevent external identities from accessing your resources, you enforce this control by using RCPs. For more information and use cases for RCPs and SCPs, see [Using SCPs and RCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_authorization_policies.html#when-to-use-scps-and-rcps) in the AWS Organizations documentation. @@ -20 +20 @@ You can use AWS Organizations declarative policies to centrally declare and enfo -Every AWS account has a single [root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) that has full permissions to all AWS resources by default. As a security best practice, we recommend that you don’t use the root user except for a [few tasks](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) that explicitly require a root user. If you manage multiple AWS accounts through AWS Organizations, you can centrally disable root sign-in and then perform root privileged actions on behalf of all member accounts. After you [centrally manage root access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html) for member accounts, you can delete the root user password, access keys, and signing certificates, and deactivate multi-factor authentication (MFA) for member accounts. New accounts that are created under centrally managed root access have no root user credentials by default. Member accounts can't sign in with their root user or perform password recovery for their root user. +Every AWS account has a single [root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) that has full permissions to all AWS resources by default. As a security best practice, we recommend that you don't use the root user except for a [few tasks](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) that explicitly require a root user. If you manage multiple AWS accounts through AWS Organizations, you can centrally disable root sign-in and then perform root privileged actions on behalf of all member accounts. After you [centrally manage root access](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html) for member accounts, you can delete the root user password, access keys, and signing certificates, and deactivate multi-factor authentication (MFA) for member accounts. New accounts that are created under centrally managed root access have no root user credentials by default. Member accounts can't sign in with their root user or perform password recovery for their root user. @@ -22 +22 @@ Every AWS account has a single [root user](https://docs.aws.amazon.com/IAM/lates -[AWS Control Tower](https://aws.amazon.com/controltower/) offers a simplified way to set up and govern multiple accounts. It automates the setup of accounts in your AWS organization, automates provisioning, applies [guardrails](https://docs.aws.amazon.com/controltower/latest/controlreference/controls.html) (which include preventive and detective controls), and provides you with a dashboard for visibility. An additional IAM management policy, a [permissions boundary](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html), is attached to specific IAM entities (users or roles) and sets the maximum permissions that an identity-based policy can grant to an IAM entity. +[AWS Control Tower](https://aws.amazon.com/controltower/) offers a simplified way to set up and govern multiple accounts. It automates the setup of accounts in your AWS organization, automates provisioning, applies [controls](https://docs.aws.amazon.com/controltower/latest/controlreference/controls-reference.html) (which include preventive and detective controls), and provides you with a dashboard for visibility. An additional IAM management policy, a [permissions boundary](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html), is attached to specific IAM principals (users or roles) and sets the maximum permissions that an identity-based policy can grant to an IAM principal. @@ -24 +24 @@ Every AWS account has a single [root user](https://docs.aws.amazon.com/IAM/lates -AWS Organizations helps you configure [AWS services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html) that apply to all your accounts. For example, you can configure central logging of all actions performed across your AWS organization by using [AWS CloudTrail](http://aws.amazon.com/cloudtrail/), and prevent member accounts from disabling logging. You can also centrally aggregate data for rules that you've defined by using [AWS Config](http://aws.amazon.com/config/), so you can audit your workloads for compliance and react quickly to changes. You can use [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) to centrally manage AWS CloudFormation stacks across accounts and OUs in your AWS organization, so you can automatically provision a new account to meet your security requirements. +AWS Organizations helps you configure [AWS services](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html) that apply to all your accounts. For example, you can configure central logging of all actions performed across your AWS organization by using [CloudTrail,](https://aws.amazon.com/cloudtrail/) and prevent member accounts from disabling logging. You can also centrally aggregate data for rules that you've defined by using [AWS Config](https://aws.amazon.com/config/), so you can audit your workloads for compliance and react quickly to changes. You can use [AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) to centrally manage CloudFormation stacks across accounts and OUs in your AWS organization, so you can automatically provision a new account to meet your security requirements. @@ -26 +26 @@ AWS Organizations helps you configure [AWS services](https://docs.aws.amazon.com -The default configuration of AWS Organizations supports using SCPs as _deny lists_. By using a deny list strategy, member account administrators can delegate all services and actions until you create and attach an SCP that denies a specific service or set of actions. Deny statements require less maintenance than an allow list, because you don't have to update them when AWS adds new services. Deny statements are usually shorter in character length, so it's easier to stay within the maximum size for SCPs. In a statement where the `Effect `element has a value of `Deny`, you can also restrict access to specific resources, or define conditions for when SCPs are in effect. By contrast, an Allow statement in an SCP applies to all resources (`"*"`) and cannot be restricted by conditions. For more information and examples, see [Strategy for using SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html#strategy_using_scps) in the AWS Organizations documentation. +The default configuration of AWS Organizations supports using SCPs as _deny lists_. By using a deny list strategy, member account administrators can delegate all services and actions until you create and attach an SCP that denies a specific service or set of actions. Deny statements require less maintenance than an allow list, because you don't have to update them when AWS adds new services. Deny statements are usually shorter in character length, so it's easier to stay within the maximum size for SCPs. In a statement where the `Effect` element has a value of `Deny`, you can also restrict access to specific resources, or define conditions for when SCPs are in effect. By contrast, an `Allow` statement in an SCP applies to all resources (`"*"`) and cannot be restricted by conditions. For more information and examples, see [Strategies for using SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html) in the AWS Organizations documentation. @@ -32 +32 @@ The default configuration of AWS Organizations supports using SCPs as _deny list - * Ideally, you would use a combination of deny list and allow list strategies. Use the allow list to define the list of allowed AWS services approved to be used within an AWS organization and attach this SCP at the root of your AWS organization. If you have a different set of services allowed per your development environment, you would attach the respective SCPs at each OU. You can then use the deny list to define enterprise guardrails by explicitly denying specific IAM actions. + * Ideally, you would use a combination of deny list and allow list strategies. Use the allow list to define the list of allowed AWS services approved to be used within an AWS organization and attach this SCP at the root of your AWS organization. If you have a different set of services allowed per your development environment, you will attach the respective SCPs at each OU. You can then use the deny list to define enterprise guardrails by explicitly denying specific IAM actions.