В продолжение темы по работе с AWS TrustedAdvisor – рассмотрим настройку отправки уведомлений и обновление данных в Trusted Advisor.

Начало – AWS: Trusted Advisor, часть 1 – обзор возможностей.

Что бы настроить уведомления – используем метрики Trusted Advisor, которые он шлёт в CloudWatch, см. список на странице Trusted Advisor metrics and dimensions.

Далее, CloudWatch будет слать алерты в SNS, оттуда – в Opsgenie, а тот уже будет пересылать их в Slack.

Идея заключается в том, что бы получать уведомления, если кто-то создаст, к примеру, AWS Security Group с открытойым в мир ~~задницей~~ доступом. Настроим сами алерты, их отправку в Slack, и обновление данных в TrustedAdvisor, что бы уведомления получать каждый день (или каждый час – up to you, как говорится, но см. ниже – Trusted Advisor refresh checks – периодичность обновления).

Содержание

Настройка Opsgenie

Создадим отдельную CloudWatch интеграцию в Opsgenie – находим CloudWatch:

Назовём интеграцию “TrustedAdvisor-Security“:

Сохраняем – вернёмся сюда позже, что бы настроить сообщение в Slack.

Настройка AWS Simple Notification Service

AWS SNS настраиваем в регионе us-east-1, N. Virginia, так как часть метрик доступна только в нём, как в самом первом регионе AWS. Тут же потом будем настраивать и CloudWatch Alarms.

Переходим в SNS, создаём топик с типом Standart, назовём его opsgenie-trustedadvisor-security-us-east-1-sns – вроде неплохая идея включать в название сервис/назначение топика и его регион:

После создания – добавляем Subscription:

Копируем URL из Opsgenie:

Возвращаемся к SNS Subscription, указываем Protocol == HTTPS, вставляем URL из Opsgenie:

Сохраняем, переходим к CloudWatch.

Что будем мониторить?

В данном примере будем делать алерт по проверке Security Groups – Specific Ports Unrestricted, но что в целом?

Переходим на AWS Trusted Advisor check reference, смотрим список и выбираем.

К примеру мне пока понравились такие проверки:

Cost optimization:

Amazon RDS Idle DB Instances
Idle Load Balancers
Low Utilization Amazon EC2 Instances
Unassociated Elastic IP Addresses

Performance:

High Utilization Amazon EC2 Instances
Amazon EC2 to EBS Throughput Optimization

Security:

Security Groups – Specific Ports Unrestricted
Security Groups – Unrestricted Access
Amazon S3 Bucket Permissions
Amazon RDS Security Group Access Risk
ELB Security Groups
Exposed Access Keys

При этом у каждой из них есть Green, Yellow и Red уровни важности.

Для Security Groups – Specific Ports Unrestricted важность определяется по следующим критериям (нашёл только в Trusted Advisor Dashboard, почему было не включить в докeментацию?):

Green: Access to port 80, 25, 443, or 465 is unrestricted.
Red: Access to port 20, 21, 1433, 1434, 3306, 3389, 4333, 5432, or 5500 is unrestricted.
Yellow: Access to any other port is unrestricted.

Настроим отправку алерта при срабатывании на Red.

Настройка CloudWatch Alarms

Переходим в CloudWatch Alarms, создаём новый алерт:

Кликаем Select metrics:

Находим нужную метрику Trusted Advisor, в данном случае – Security Groups – Specific Ports Unrestricted – RedResources:

Настраиваем условия срабатывания алерта – в Statistic используем Simple Count, и период 5 минут:

В Conditions выбираем Greater/Equal и than 1, а в Additional configuration указываем Treat missing data as good:

Настраиваем Actions – отправлять уведомление через SNS-топик, который создали выше:

Задаём имя, опционально добавляем описание:

Проверяем – создаём любую SecurityGroup, в ней разрешаем доступ из 0.0.0.0/0 к порту 3306, что бы затриггерить Red Resources:

Сохраняем новый алерт и, казалось бы – всё, жди алерта? Но нет – “Нельзя просто так взять, и затриггерить TrustedAdvisor“.

Trusted Advisor refresh checks – периодичность обновления

Причина – периодичность обновления данных в Trusted Advisor: некоторые проверки обновляются периодически сами, некоторые – при работе с dashboard или с помощью API или AWS CLI.

Открываем документацию по Security Groups – Specific Ports Unrestricted, и читаем:

Тут про refresh не сказано ничего. Зато есть Check ID – сейчас он нам пригодится, что бы выполнить обновление вручную.

А вот проверка на Amazon RDS Public Snapshots выполняется автоматически несколько раз в день, и ручное обновление недоступно:

Trusted Advisor – ручное обновление

Для ручного обновления можно:

просто открыть дашборду TrustedAdvisor, и развернуть проверку Security Groups – Specific Ports Unrestricted
использовать API-вызов RefreshTrustedAdvisorCheck
либо AWS CLI и refresh-trusted-advisor-check

Используем CLI – вызываем команду, передаём регион us-east-1 (N. Virginia, где мы делали алерт), и через --check-id передаёт ID проверки, который видели в документации (также его можно получить через CLI вызов aws support describe-trusted-advisor-checks):

[simterm]

$ aws --region us-east-1 support refresh-trusted-advisor-check --check-id HCP4007jGY
{
    "status": {
        "checkId": "HCP4007jGY",
        "status": "enqueued",
        "millisUntilNextRefreshable": 3599991
    }
}

[/simterm]

Статус enqueued значит, что обновление запущено, можно ждать результат – через несколько минут прилетит алерт.

Если в status значение “success” – значит, проверка недавно выполнялась, и необходимо подождать, пока не истечёт millisUntilNextRefreshable (3599990 мс == 60 минут).

Получаем алерт в Opsgenie: