-
|
I deploy the ASEA this past weekend using a mostly default config-lite configuration file provided in the repo. It was generally smooth, however I was surprised to see that both the CloutTrail and AWS Config were going out to all regions globally. I did see in the config file an option to exclude regions from AWS Config, however you would need to specify each one. So 2 questions:
Attached is a sample of the Config billing showing some of the regions evaluating and recording config changes. (it is incredibly expensive as well.)
thanks in advance. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
Hi Mike, In many cases it is just as important or even more important you have security controls, logging and tooling deployed in the unused regions. Should an administrator make a mistake a misconfigure something erroneously opening access, bypass the rules themselves, or should a bad actor somehow get access to an environment, they will often try to do things in a location you won't notice (i.e. a region you don't typically work in) - you need logs and alerting in place to be able to track down and alert on the activity, and to understand what was done and by whom. If their is no activity in a region, the volume of logs or events from those regions will be minimal. Additionally, many Gov't departments are using additional regions (other than Canada) to deploy non-sensitive workloads and or experiment with AWS services not yet in Canada. Your post is timely - we had enabled Security Hub and deployed a tweaked version of the NIST800-53 conformance pack, which resulted in 56 duplicate rules between the conformance pack and the SH rules. I have a GitHub branch (created today) with updated config rules, removing the duplicates - will be merged into the main branch in the next couple of days. This should drop the config rule evaluation costs by 30% (although I believe the majority of the costs are not from rule evaluations, but evaluating and recording the regions config history). I believe having CloudTrail and GuardDuty enabled in all regions is critical. I suppose Config could be debated. In the end, it's up to you, these are the recommendations we've developed working with the GC. When deploying, if you set "supported-regions": ["ca-central-1"], instead of the full list of 17 regions, all the security services will only be enabled/deployed in Canada (or the specified regions). The ultra-lite config file demonstrates this non-best-practice option. (BTW: Changing this value will not uninstall these services after the initial deployment). If you simply wish to prevent the global distribution of config rules, yes, you need to provide the list of "excl-regions": ["ap-northeast-3", "region2", "regionN"] in each and every OU. We assume all regions enabled and allow you to opt specific or the majority of regions out if desired. (BTW: Changing this value should remove the rules from these regions). We do the opposite for SSM documents, for which we only deploy to named regions. Hopefully this answers your questions? |
Beta Was this translation helpful? Give feedback.
-
|
Hi Brian,
Thanks for the quick response. I see your logic regarding possible deployments in non-CND regions, however having worked with the Canadian Gov, specifically with PB content. It is generally incredibly important to ensure all data is kept ( especially at rest ) on domestic soil. So that is worth a conversation, I think?
I’m just starting my deep dive into ASEA, but have tight timelines to deploy a usable environment in the next weeks, so I appreciate the help.
Just as a FYI … deploying the vanilla lite config on a personal new account incurred approx. 140$ in the first 12hrs. 2/3 of that was AWS Config.
Looking forward to working with you.
Cheers
Mike
From: Brian969 ***@***.***>
Sent: April 26, 2021 6:48 PM
To: aws-samples/aws-secure-environment-accelerator ***@***.***>
Cc: Mike ***@***.***>; Author ***@***.***>
Subject: Re: [aws-samples/aws-secure-environment-accelerator] AWS Config and CloudTrail Recording in all Regions (#718)
Hi Mike,
In many cases it is just as important or even more important you have security controls, logging and tooling deployed in the unused regions. Should an administrator make a mistake a misconfigure something erroneously opening access, bypass the rules themselves, or should a bad actor somehow get access to an environment, they will often try to do things in a location you won't notice (i.e. a region you don't typically work in) - you need logs and alerting in place to be able to track down and alert on the activity, and to understand what was done and by whom. If their is no activity in a region, the volume of logs or events from those regions will be minimal.
Additionally, many Gov't departments are using additional regions (other than Canada) to deploy non-sensitive workloads and or experiment with AWS services not yet in Canada.
Your post is timely - we had enabled Security Hub and deployed a tweaked version of the NIST800-53 conformance pack, which resulted in 56 duplicate rules between the conformance pack and the SH rules. I have a GitHub branch (created today) with updated config rules, removing the duplicates - will be merged into the main branch in the next couple of days. This should drop the config rule evaluation costs by 30% (although I believe the majority of the costs are not from rule evaluations, but evaluating and recording the regions config history).
I believe having CloudTrail and GuardDuty enabled in all regions is critical. I suppose Config could be debated. In the end, it's up to you, these are the recommendations we've developed working with the GC.
When deploying, if you set "supported-regions": ["ca-central-1"], instead of the full list of 17 regions, all the security services will only be enabled/deployed in Canada (or the specified regions). The ultra-lite config file demonstrates this non-best-practice option. (BTW: Changing this value will not uninstall these services after the initial deployment).
If you simply wish to prevent the global distribution of config rules, yes, you need to provide the list of "excl-regions": ["ap-northeast-3", "region2", "regionN"] in each and every OU. We assume all regions enabled and allow you to opt specific or the majority of regions out if desired. (BTW: Changing this value should remove the rules from these regions). We do the opposite for SSM documents, for which we only deploy to named regions.
Hopefully this answers your questions?
Brian
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#718 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFTBHHE5HJ4YRUDSJB36G3TKXUSLANCNFSM43THSM7Q> . <https://github.com/notifications/beacon/ACFTBHCEG7GRYYFUUR5LTLTTKXUSLA5CNFSM43THSM72YY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOAAFBULY.gif>
|
Beta Was this translation helpful? Give feedback.
-
The primary reasons are not for the non-Canadian workloads, but for visibility, traceability, and monitoring. Yes, we also have strong preventative controls to keep workloads within Canada, when desired. For your testing purposes - those global config rules are definitely not required. It should be noted that on April 1, 2020, Treasury Board Secretariat did change the data residency policy - something many GC departments are still not aware of (emphasis mine): Old Policy"All sensitive electronic data under government control, that has been categorized as Protected B, Protected C or is Classified, will be stored in a GC-approved computing facility located within the geographic boundaries of Canada or within the premises of a GC department located abroad, such as a diplomatic or consular mission." New Policy"Ensuring computing facilities located within the geographic boundaries of Canada or within the premises of a Government of Canada department located abroad, such as a diplomatic or consular mission, be identified and evaluated as a principal delivery option for all sensitive electronic information and data under government control that has been categorized as Protected B, Protected C or is Classified." - The updated policy can be found in section 4.4.1.10, here. BTW: You have just stood up a highly available and scalable multi-datacenter environment with hyperscale routing and enterprise grade security, something that would cost tens of millions of dollars on premise. The costs of the services you have stood up are generally not aligned with a personal test account (yet typically only represent a very small percentage of a production AWS customers spend). Should it be a concern, a crude, unofficial uninstall script exists in this folder which can be used at your own risk in a non-production environment. Interaction here is great, but, I also recommend you reach out to bmycroft at amazon dot com - I'd love to get you aligned with your AWS account team to ensure you are properly supported through your deployment. Let us know if you need anything else, |
Beta Was this translation helpful? Give feedback.
Hi Mike,
In many cases it is just as important or even more important you have security controls, logging and tooling deployed in the unused regions. Should an administrator make a mistake a misconfigure something erroneously opening access, bypass the rules themselves, or should a bad actor somehow get access to an environment, they will often try to do things in a location you won't notice (i.e. a region you don't typically work in) - you need logs and alerting in place to be able to track down and alert on the activity, and to understand what was done and by whom. If their is no activity in a region, the volume of logs or events from those regions will be minimal.
Additionally, many Go…