Effect Of Service Control Policy on Delegated Administrator Account

Hi! Good question. Service Control Policies will apply to member accounts, but will not affect users or roles in the management account. With your "Delegated Admin," that will count as a member account. If the policy is attached to the "root", this will be inherited by all the member accounts.

For more about SCP inheritance, check out this AWS Guide: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_inheritance_auth.html

If you are using a deny structure, keep in mind that explicit denies will override any explicit allows. Thus, if you have an explicit deny on GuardDuty, that will get inherited, it could block the ability of your delegated admin account to administer GuardDuty.

A couple options:

• Conditions - You can use conditions to exclude the account to be able to manage GuardDuty. This can be done with aws:PrincipalAccount Principal and NotPrincipal are not supported in SCPs.

• Re-structure the Organization so that the delegated admin account is not affected by the broad Deny/SCP. This could be useful if you plan on using the delegated admin account for other purposes or solely as a management or security account.

• Using an allowlist structure for IAM. By using an Allowlist, you can have more granularity on child accounts/OUs. However, this would require not having an Allow * * at the root level. This may require a restructuring of your SCPs as well.

If you attach the SCP to all account including the Delegated Admin Account, the Delegated Admin Account will access get denied when making a change on GuardDuty because you explicitly deny the action in the policy. Delegating administrator account for GuardDuty does NOT mean that the delegated admin account will have permission of "*" action in GuardDuty regardless of SCP but just mean that the delegated admin account can collect GuardDuty findings from member account and propagate configuration to member accounts. In order for the delegated admin account to manage GuardDuty configuration in your organization, you must exclude the delegated admin account.

Thanks

Eunsu

That's correct, Eunsu. I understand that I have to exclude that "Delegated Admin Account" when creating SCP from AWS master account in AWS organizations. I have checked the AWS documentation but I didn't find any global condition context key to add it to the condition in SCP policy in order to exclude that account.

Here is the doc link:

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid

Let me know If you have any idea.

SCPs are effective against Member Accounts (AWS Accounts) within an AWS Org, and not the Administrative/Root AWS Account (previously referred to as the 'Master Account'). So with this in-mind, if you have a flat AWS Org structure (no drill-down levels of OUs), then applying an SCP at the Root-level of the AWS Org will mean that the restrictive statements of the SCP will be applied to your AWS GuardDuty delegated admin account.

Now, how to get around this? You could go down the route of adding in Condition blocks within your SCP, but you're missing out on a perfect opportunity to organise your AWS Org structure, and to really get the most out of your SCPs. You should look into crafting an OU structure within AWS Organizations which enables you to apply your SCPs to Member accounts, but not have any detrimental effect on more 'sensitive' accounts, such as the delegate admin account for AWS GuardDuty within your AWS Org.

If you're looking for examples of OU structure, there's always that of the AWS Landing Zone solution, here.