[PYTHON] Invoke tagging discipline across organization in AWS --3

This is a continuation of Last time. This time, we will implement a notification function that extracts information that is non-compliant with required-tags from the information Aggregate and sends it to Slack channel.

Up to the last time, we have introduced two solutions, Tag policies and required-tags, and have reached the point where we can get a bird's-eye view on the management console. However, the human resources of the audit team are limited, and if you open the management console and keep an eye on it, the problem of increasing the operational load will arise. Ideally, he would only notify Slack when a breach occurs.

Since they are two different services, each solution is required, but the first is reqired-tags. Tag policies will be done at a later date

design

As I mentioned at the end of the last article, our Compliance account already has a Chatbot configured for Security Hub running. The first thing I came up with was if I could piggyback on this. It looks like Aggregator-> sns-> Chatbot-> Slack.

However, I did not find any implementation examples by searching. Apparently, as of December 2020, such a configuration would be difficult.

In conclusion, I decided to give up the event trigger and compromise with the regular execution of the Lambda function. It is a configuration that extracts non-compliant information from the Lambda function that started on time with Advanced Query, shapes it, and sends it to Slack.

I don't think the periodical self-made Lambda function is very elegant, but I give priority to Conciseness, which limits the dependency to Config Aggregator. The startup cycle is assumed to be about once a day to several days, but this is acceptable. It's just that compliance isn't tagged. I think it's also a matter of fighting for a minute and a second to make a wrinkle (for now).

Implementation

During the above research and examination process, the essential API of Aggregator was Knowledge, and the basic specifications of the Lambda function were finalized. Let's write it quickly Yes, I'm done (laughs). If you sam deploy this guy, it will look like this:

In this image, I get a message that one Source account ap-northeast-1 and two us-east-1 EC2 instances are non-compliant.

Mass post suppression function

In the example of the above image, since it is a verification environment, only a few notifications are received, but in turn, we will consider the case where a large number of resources are deployed in the production environment in operation.

That's because the larger the number of noncompliant resources, the more notifications will be posted to Slack Channel (that's the specification). No matter how much you want to report non-compliance, if you receive too many notifications, you will be overlooked because you are a human being, and you will not be willing to deal with it. This is the end of the story. Also, with the schedule-based specifications created this time, I thought that it was necessary to pay attention to the restrictions due to the timeout of the Lambda Function. It's trying to cover all Source accounts non-compliance information (albeit limited to required-tags) in a single launch. Therefore, we set a threshold and omitted individual messages when the number of noncompliant resources exceeds that threshold. When this deterrent function is activated, only Summary will be displayed as shown below.

• • Dummy data is embedded and executed to intentionally activate the suppression function * In this case, I will go straight to the Aggregated View for individual details.

Other

This time I tried to develop it with sam, but it's easy and nice. Advanced Query is also pretty good

Next time, I'm going to do a notification system for Tag policies