Organizational Policies

Effective governance in a multi-account AWS environment requires robust policy controls. The Nuvibit Terraform Collection (NTC) provides a strategic approach to implementing AWS Organizations policies through well-defined templates and infrastructure as code.

What are AWS Organizations Policies?

AWS Organizations policies are a set of controls that you can apply to groups of AWS accounts within your organization. These policies help you enforce security guardrails, compliance requirements, and resource management standards across your entire AWS environment.

AWS Organizations supports several policy types:

• Service Control Policies (SCPs): Define maximum permissions for IAM users, roles, and AWS services
• Resource Control Policies (RCPs): Control access to specific AWS resources
• Tag Policies: Ensure consistent tagging across resources
• Backup Policies: Standardize backup procedures
• AI Services Opt-out Policies: Control AI service data usage

NTC Organizations supports all types of policies.

SCPs and RCPs are the most important policies (in general) as these policies define your guardrails across the entire AWS Organization.

NTC Guardrail Templates provides best practice pre-configured guardrail policies which can be deployed via NTC Organizations.

Service Control Policies (SCPs)

Service Control Policies (SCPs) are a type of Organizations policy that helps you centrally control the maximum available permissions for all accounts in your organization. SCPs define guardrails that restrict what services can be used and what actions the users, groups, and roles in your accounts can perform.

Important: SCPs alone do not grant any permissions. They function exclusively as guardrails that define the maximum available permissions. The administrator must still attach identity-based or resource-based policies to IAM users, roles, or resources to actually grant permissions.

⚠️ WARNING: Do not apply guardrail policies like SCPs and RCPs without extensive testing. You should apply guardrails to non-critical accounts first to evaluate the impact on your workloads. Improperly configured policies can block essential services and result in significant operational disruptions across your AWS organization.

⚠️ NOTE: SCPs have no effect on the management account. This means users and roles in the management account are not restricted by SCPs, even if the SCPs are attached directly to the management account. For proper security, limit access to the management account and use it only for tasks that can only be performed from the management account.

SCP Implementation with NTC

With NTC Organizations, you can implement SCPs using pre-defined templates or custom policies:

module "ntc_organizations" {
  source = "github.com/nuvibit-terraform-collection/terraform-aws-ntc-organizations?ref=X.X.X"

  # Other configuration...

  organization_policies = [
    # Reference a policy from guardrail templates
    module.ntc_guardrail_templates.service_control_policies["scp_root_ou"],

    # Or define a custom policy
    {
      policy_name        = "custom_scp_policy"
      policy_type        = "SERVICE_CONTROL_POLICY"
      target_ou_paths    = ["/root/workloads"]
      target_account_ids = []
      policy_json        = jsonencode({
        Version = "2012-10-17"
        Statement = [
          {
            Sid       = "DenyUnencryptedObjectUploads"
            Effect    = "Deny"
            Action    = "s3:PutObject"
            Resource  = "*"
            Condition = {
              StringNotEquals = {
                "s3:x-amz-server-side-encryption" = "AES256"
              }
            }
          }
        ]
      })
    }
  ]
}

Key Characteristics of SCPs

• Applied at the organization root, organizational unit (OU), or account level
• Define maximum available permissions for AWS services and actions (deny permissions model)
• Do not grant any permissions themselves (IAM policies still required)
• Don't affect users or roles in the management account
• Evaluated before IAM policies
• Affect all users and roles in attached accounts, including the root user
• Do not affect service-linked roles
• If both a permissions boundary (an advanced IAM feature) and an SCP are present, then the boundary, the SCP, and the identity-based policy must all allow the action

Common SCP Use Cases

SCPs are versatile and can be used to implement various security controls:

1. Region Restriction: Restrict AWS operations to specific regions
2. Service Restriction: Prevent the use of specific AWS services entirely
3. Resource Type Protection: Block creation or modification of critical resource types
4. Root User Protection: Limit or prevent actions using the root user
5. Data Protection: Prevent public exposure of critical data
6. Prevent Organization Exit: Stop accounts from leaving the organization
7. Environment Segregation: Apply different controls to production vs. non-production environments

Resource Control Policies (RCPs)

Resource Control Policies (RCPs) are a powerful policy type that allows you to control access to specific AWS resources within your organization, regardless of IAM permissions. Unlike SCPs which restrict IAM permissions, RCPs provide guardrails at the resource level.

RCPs are a newer policy type in AWS Organizations, enabling more granular control over resource access patterns and addressing security concerns that cannot be solved with identity-based policies alone.

Important: Similar to SCPs, RCPs alone are not sufficient in granting permissions to the resources in your organization. No permissions are granted by an RCP. An RCP defines a permissions guardrail, or sets limits, on the actions that identities can take on resources in your organization.

⚠️ WARNING: RCPs require careful planning and testing before deployment. Since RCPs operate at the resource level, they can impact cross-account access patterns in ways that might not be immediately obvious. Always validate RCP configurations in a test environment before applying them to production resources to avoid blocking legitimate access patterns.

⚠️ NOTE: RCPs have no effect on resources in the management account. This means that resources in the management account are not protected by RCPs, even if the RCPs are attached directly to the management account. Keep sensitive resources outside the management account where they can be protected by RCPs.

RCP Implementation with NTC

NTC Organizations supports implementing RCPs through guardrail templates:

module "ntc_organizations" {
  source = "github.com/nuvibit-terraform-collection/terraform-aws-ntc-organizations?ref=X.X.X"

  # Other configuration...

  organization_policies = [
    # Reference RCP policies from guardrail templates
    module.ntc_guardrail_templates.resource_control_policies["rcp_enforce_confused_deputy_protection"],
    module.ntc_guardrail_templates.resource_control_policies["rcp_enforce_secure_transport"],

    # Or define a custom RCP
    {
      policy_name        = "custom_rcp_policy"
      policy_type        = "RESOURCE_CONTROL_POLICY"
      target_ou_paths    = ["/root"]
      target_account_ids = []
      policy_json        = jsonencode({
        Version = "2012-10-17"
        Statement = [
          {
            Sid       = "EnforceS3Encryption"
            Effect    = "Deny"
            Action    = "s3:PutObject"
            Resource  = "*"
            Condition = {
              StringNotEquals = {
                "s3:x-amz-server-side-encryption" = "aws:kms"
              }
            }
          }
        ]
      })
    }
  ]
}

Key Characteristics of RCPs

• Applied at the organization root, organizational unit (OU), or account level
• Control access to resources regardless of IAM permissions
• Can enforce specific security controls across resources
• Work alongside SCPs to provide comprehensive protection
• Only apply to specifically supported services and actions
• Impact the effective permissions of principals trying to access resources in a member account with an applicable RCP, regardless of whether the principals belong to the same organization or not
• Do not affect resources in the management account
• Do not impact the effective permissions of any service-linked role

Supported Services for RCPs

As of the latest update, RCPs support the following services:

• Amazon S3
• AWS Key Management Service (KMS)
• AWS Secrets Manager
• Amazon SQS
• AWS Security Token Service (STS)

Note that RCPs do not apply to AWS managed keys for AWS Key Management Service, and some specific API actions like kms:RetireGrant.

Common RCP Use Cases

RCPs excel at implementing resource-level controls:

1. Enforce Encryption: Require resources to use specific encryption mechanisms (e.g., server-side encryption with KMS for S3 objects)
2. Prevent Confused Deputy: Implement protections against confused deputy attacks across services
3. Restrict Access to Organization: Ensure resources can only be accessed from within your organization
4. Enforce Secure Transport: Require secure TLS connections for resource access (e.g., require HTTPS/TLS 1.2+)
5. Enforce Minimum Security Standards: Mandate minimum security requirements for resources (e.g., S3 bucket policies)

NTC Guardrail Templates

The NTC Guardrail Templates building block provides a set of pre-configured policy templates for both SCPs and RCPs. These templates encapsulate best practices for AWS security and governance, making it easier to implement consistent controls across your organization.

Based on Nuvibit's experience implementing AWS Organizations for enterprises with diverse needs and compliance requirements, these templates offer a proven foundation for your organization's security posture.

For detailed information on the available templates and implementation examples, see the NTC Guardrail Templates documentation.

Service Control Policy Templates

NTC includes several SCP templates for common use cases:

Template Name	Description
deny_leaving_organizations	Prevents accounts from leaving the AWS organization
deny_actions_as_root	Prevents the use of the root user for most operations
deny_actions_as_root_except_centralized_root	Prevents root user actions except those needed for central root management
deny_all	Denies all actions (useful for suspended accounts)
deny_outside_allowed_regions	Restricts operations to specific AWS regions
deny_inside_allowed_regions	Restricts operations within specified regions
deny_iam_modification	Prevents modifications to specified IAM roles

Resource Control Policy Templates

NTC also provides RCP templates for resource-level protection:

Template Name	Description
enforce_confused_deputy_protection	Implements protections against confused deputy attacks by ensuring AWS service principals accessing your resources only do so on behalf of requests from your organization
enforce_principal_access_from_organization	Ensures resources are only accessed from within your organization by preventing AWS principals outside your organization from accessing resources
enforce_secure_transport	Requires secure TLS connections for resource access by ensuring access to resources only occurs on encrypted connections over HTTPS
enforce_s3_kms_encryption	Requires S3 objects to use KMS encryption for server-side encryption
enforce_s3_tls_version	Enforces minimum TLS version for S3 bucket access (configurable, e.g., TLS 1.2+)

Policy Evaluation Logic

Understanding how AWS evaluates policies is crucial for effective implementation:

SCP Evaluation

• SCPs follow an explicit deny model
• If any applicable SCP denies an action, it is denied
• SCPs do not grant permissions - they only restrict what permissions can be granted
• SCPs are evaluated before IAM policies
• The management account is not restricted by SCPs

SCP Implementation Approaches

In our experience at Nuvibit, we've found two primary approaches for implementing SCPs effectively:

Restrictive Policies with Allow Statements: This approach starts with highly restrictive permissions and gradually adds explicit Allow statements for necessary services and actions. When using this approach, permissions must be explicitly allowed at each level of the organization hierarchy (root, OUs, and accounts) to be effective. The default FullAWSAccess policy that AWS automatically attaches enables this pattern, but we recommend replacing it with more targeted allow statements as you mature your governance model.

Targeted Deny Statements: This approach is typically more practical for organizations transitioning to a multi-account strategy. It starts with broad permissions and uses specific Deny statements to restrict problematic or high-risk services and actions. A single Deny statement anywhere in the hierarchy blocks that permission, making this approach powerful for enforcing security controls.

At Nuvibit, we typically recommend a blend of these approaches, with a focus on targeted deny statements for most organizations. This provides a balance of security and flexibility while minimizing disruption. As your governance model matures, you can gradually move toward a more restrictive model with explicit allows.

RCP Evaluation

• RCPs are evaluated during resource access, not during IAM authorization
• RCPs can deny access even if IAM permissions allow it
• RCPs are evaluated for both cross-account and same-account access
• RCPs are evaluated for each supported API action individually
• RCPs do not affect resources in the management account
• RCPs do not impact the effective permissions of any service-linked role
• The effective permissions are the logical intersection between what is allowed by RCPs, SCPs, and what is allowed by identity-based and resource-based policies

Monitoring and Testing Policy Controls

Effective governance in a multi-account environment requires ongoing monitoring and systematic testing of your policy controls:

1. Use AWS CloudTrail: Monitor policy-related events in CloudTrail to identify policy changes, application, and potential violations
2. Implement Automated Testing: Regularly test that policies are working as expected through automated scripts or workflows
3. Use AWS IAM Access Analyzer: Validate policies before implementation to identify potential security issues or unintended consequences
4. Create Testing Accounts: Maintain dedicated accounts for policy testing to safely evaluate the impact of new or modified policies
5. Document Policy Decisions: Keep comprehensive records of policy decisions and changes for compliance and audit purposes

Strategic Policy Testing Approach

At Nuvibit, we recommend implementing guardrail policies through a staged rollout approach:

1. Begin with individual test accounts or the Sandbox OU: Apply policies to low-impact environments first
2. Collect and incorporate feedback: Wait for user feedback before proceeding to the next stage
3. Roll out to non-production workload accounts: Apply to dev/test environments once validated
4. Finally deploy to production accounts: Only after thorough testing and validation

It allows you to verify policy effects in real environments with minimal business impact before applying them more broadly.

The guardrail policies provided by Nuvibit are battle-tested and validated through automated testing processes to ensure they work as expected. However, even with these pre-configured templates, we still recommend the staged approach to account for the unique aspects of your environment.

When evaluating policy impacts, collect feedback from account users about any disruption to workflows.

Conclusion

A well-designed policy framework is the cornerstone of effective AWS governance, security, and compliance. By implementing the Nuvibit recommended policy controls through NTC Organizations and Guardrail Templates, you'll create a scalable, secure, and easily manageable multi-account AWS environment that aligns with both Nuvibit best practices and AWS recommendations.

The combination of SCPs and RCPs creates a comprehensive defense-in-depth strategy:

• SCPs control permissions at the identity level (IAM users and roles)
• RCPs control access at the resource level regardless of identity permissions

This layered approach provides robust protection, helping you meet security and compliance requirements with confidence while still enabling innovation within secure boundaries. Through careful policy design and testing, you can create a secure foundation for your AWS environment that supports your organization's growth and operational needs.

This policy framework not only helps with day-to-day governance (how you manage and control your AWS environment) but also enhances compliance readiness (your ability to meet industry regulations and standards).

While governance focuses on operational control and decision-making, compliance ensures adherence to external requirements such as HIPAA, PCI DSS, ISO 27001, and other regulatory frameworks. The consistent policy application across your organization significantly reduces the effort required to demonstrate compliance during audits while maintaining the security posture necessary to protect your AWS resources.