digitc1 / AWSLandingZone

Repository for AWSLandingZone module developed by DIGIT.C.1
Apache License 2.0
1 stars 0 forks source link

Enforcement of region restrictions at OU Level #32

Open stmag opened 4 years ago

stmag commented 4 years ago

New feature request - can we enforce SCPs at the EC OU level to prevent certain regions from being used. This could help alleviate costs of deploying GuardDuty in all regions as we would consider this unnecessary if region restrictions were in place.

eg i would never see us using Africa, Middle East, South America regions for example (unless there are edge cases we are not aware of within EC). Some key services (like IAM/DNS operate globally from US regions, so we could not restrict these)

tec-goblin commented 4 years ago

Does GuardDuty cost if there're no associated logs?

tec-goblin commented 4 years ago

To be also verified if FPI (they have delegations) is considered in the end as Commission (it could be solved by not putting them in EC's OU). CloudFront also is in multiple regions, isn't it? (some of our services do need global outreach)

stmag commented 4 years ago

Does GuardDuty cost if there're no associated logs?

In theory it should be very little if there is not much activity within a given region - if we can get it on all regions then would be happy - i guess then the question changes around data residency and if this is an issue or not - guess that question would have to be solved by the customer doing a risk assessment

chouma commented 4 years ago

The alternative is to “deactivate” not allowed regions entirely, and force GD for all allowed regions, but it’s probably better for now to force GD in all regions

But you can’t deactivate US East as you all know.

On 22 Sep 2020, at 14.53, S McGowan notifications@github.com wrote:

 Does GuardDuty cost if there're no associated logs?

In theory it should be very little if there is not much activity within a given region - if we can get it on all regions then would be happy - i guess then the question changes around data residency and if this is an issue or not - guess that question would have to be solved by the customer doing a risk assessment

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

neisije commented 3 years ago

Possible Action Plan to implement this change request:

  1. Define the list of AWS regions that can be DISABLED by the SCP (i.e. allowed regions could be restricted to EU regions / North Virginia)
  2. Define the corresponding SCP implementing the DENY for this list of AWS regions
  3. Create a specific OU in our Test organization with this SCP enabled
  4. Develop a specific release of the LZ that will allow its deployment on the allowed AWS regions
  5. Develop a script that will un-deploy the LZ in the DISABLED regions
  6. Develop a script that will check for existing services in the DISABLED regions (use CUR file or iCoco ?)
  7. Check for existing services in the DISABLED regions in test accounts
  8. Run the script to un-deploy the LZ in the DISABLED regions in the test accounts configured with the LZ
  9. Move test accounts to the specific OU in the test organization
  10. Create the SCP and the OU in the production organization
  11. Document the procedure
  12. Share the procedure with customers who wants to reduce their costs
  13. Ask the customers who wants to reduce their costs to execute the procedure
chouma commented 3 years ago

@austindimmer here's the plan for the deployment of this ticket.