Viewable by the world

Service Control Policies

Service Control Policies (SCPs) offer central control over the maximum available permissions for IAM users and IAM roles in an organization.

The overall LBNL AWS Organization structure contains Organizational Units (OUs) as a hierarchical parent-child structure. SCPs can be attached to individual accounts or entire OUs, or to the organization as a whole using the Root OU. Only 5 SCPs can be enabled on the Root OU at one time. This requires us to apply multiple rules within each SCP. 

Standard LBL AWS accounts are in the Non-SSO Accounts OU, and can be moved into other OUs with different applied policies using the organization management accounts.

Active

allow-leave-organization

    • Users in the LBNL AWS organization are prevented from leaving (via deny-account-actions) to ensure the security of their accounts. If a user has been approved to leave the organization, applying this policy to their account will enable them to do so. 


deny-ability-to-delete-or-change-roles

    • This grants Wiz access to all accounts in the LBNL AWS Organization, and also prevents users from editing organization-wide roles, currently Wiz and stacksets-exec. The stacksets-exec role itself is exempt from this policy to allow Wiz StackSets to be installed properly.
    • StackSets create a template out of an existing stack, allowing for easy deployment across multiple AWS accounts or regions.
    • More roles can be added to or excluded from this policy as-needed.

deny-account-actions

    • This is the main policy for blanket denial of account level permissions across the organization, additional actions may be added to this policy as-needed.
    • It prevents any account in the LBNL AWS organization from leaving, which ensures all accounts are being monitored for security and compliance.
    • It also prevents users from enabling any non-default regions as determined by AWS, which limits unexpected resource usage and data transfer costs, reducing the attack surface of the organization.


deny-root-actions-without-mfa

    • Multi-Factor Authentication must be enabled for all AWS root accounts, and is also strongly recommended for IAM accounts. This policy denies all actions from any root account without MFA. Upon request, user accounts can be placed into the Special Function OU called “Move account in here to allow root user to add MFA”. After that, they will be able to enable MFA and regain root account functionality. 
    • In the future, deny-root-user-access-key and other root account-based denials may be added to this policy.


deny-root-user-access-key

    • Access keys should not be used by the root user, they should be associated with IAM accounts only with the necessary user permissions. This policy prevents root accounts from creating access keys.


FullAWSAccess

    • This policy allows all actions by default, so actions are denied specifically when they meet the criteria of the other policies. It is managed by AWS itself, and is applied by default to all accounts to give them necessary account functionality.








  • No labels