Categories of Behavior – AWS Security Fundamentals – SCS-C02 Study Guide

Categories of Behavior

The controls provided by AWS Control Tower are broken down into three distinct categories: preventative, detective, and proactive. These are called categories of behavior:

  • Preventative controls disallow actions in your account that could cause it to be non-compliant and are implemented using Service Control Policies (SCPs).
  • Detective controls look for and find compliance violations within your resources and are implemented using AWS Config Rules.
  • Proactive controls scan your resources before they are provisioned and implemented using CloudFormation hooks.

Categories of Guidance

There are also three different levels of controls: mandatory, strongly recommended, and elective controls. These are called categories of guidance:

  • Mandatory controls are always enforced throughout your accounts and cannot be turned off.
  • Strongly recommended controls have been patterned after the AWS Well-Architected Framework best practices, especially in the case of multi-account environments, and should be kept in place.
  • Elective controls are items modeled after rules commonly found in enterprise environments that allow you to lock down or track actions in your AWS accounts.

Security Considerations for Control Tower

Now that you know some of the basic elements of AWS Control Tower, you can consider some of the security responsibilities for which you, as an account holder, are responsible. Since this is regarding account-wide settings with Control Tower, the security is broken down into multiple sections as shown in the points below.

Data Protection

  • Each account should have multi-factor authentication (MFA) enabled.
  • Set up and enable AWS CloudTrail API for both user and system activity.
  • When you communicate with AWS resources, do so via SSL/TLS.

Identity and Access Management (IAM)

  • Once you create your root user, add MFA to the account and only lock it away for account management and service tasks.
  • Use IAM roles to delegate access to services rather than provisioning long-term credentials from accounts, such as access and secret access keys.
  • Use aws:SourceArn if you want only one resource associated with cross-service access.
  • Use aws:SourceAccount if you want to allow any resource in the account to be associated with cross-service use.

Now that you are familiar with the Control Tower service, take a look at the AWS service that compliments Control Tower—AWS Organizations.

AWS Organizations

At its core, AWS Organizations provides you with a hierarchical way of organizing accounts in groups called organizational units (OU). These OUs can then be managed with specific controls from both the overall accounting structure level and the individual OU level.

Figure 2.2 shows an example of an organization with six accounts and four OUs. Two OUs, Infrastructure and Security, are nested under the parent OU, Corporate. This type of hierarchy allows cascading security policies and cost reporting for the child accounts. You can see this type of policy inheritance shown in Figure 2.2, where policies created are applied to specific OUs and cascade down. Separate policies have been applied to both the North America Ous, affecting the Development and Marketing accounts, and the Infrastructure OU is affecting the Network account.

Figure 2.2: AWS Organizations structure with OUs and SCPs

Policy inheritance in AWS Organizations allows you to define policies at the root level of your organization, and those policies are automatically inherited by all member accounts in the organization. This means that you can create a policy once and have it apply to all accounts in your organization rather than having to manually apply the policy to each individual account. Overall, policy inheritance in AWS Organizations provides a way to centrally manage policies across numerous accounts, creating a continuous set of policies and governance standards across your organization.

There are some critical rules to understand when it comes to policy inheritance, which come down to the following three key concepts:

  • Any policies attached at the root of the organization affect every account and OU in the organization, and this is the total cascading effect of the policies.
  • If you attach a policy to a specific OU, then that OU, any accounts attached to the OU, and any child OUs and their subsequent accounts are affected by that policy. This also applies to future OUs and accounts added to this original OU that have this policy.
  • A policy attached to a specific account only affects that account.

Next, take a look at one of the most powerful features of AWS Organizations, service control policies.