Чи є спосіб відстежувати зміни, які ми вносимо в систему AWS?
Наприклад, зміни в налаштуваннях підмережі, від використання nat до iwg - вони відображають повідомлення, а потім зникають.
Чи є спосіб отримати AWS для створення журналу, щоб можна було відслідковувати, які зміни були внесені до чого і коли?
Найближче, що ми маємо зараз, - це події ElasticBeanstalk - але навіть це говорить лише про те, що зробив AWS, а не які зміни були змінені для подій.
Відповіді:
AWS має послугу CloudTrail, яка відстежує більшість викликів API, здійснених у вашому обліковому записі. Потім зберігає їх у файлах у вказаному відрізку S3.
https://aws.amazon.com/cloudtrail/
Використовуючи CloudTrail, ви можете побачити, хто чи яку службу викликав, яку зміну - у багатьох випадках також, які аргументи були використані.
На жаль, на даний момент він не підтримує ВСІХ послуг.
Існує кілька сервісів AWS, які можуть допомогти у цьому, і це дійсно залежить від ваших точних потреб, які саме вам підходять найкраще. Для кожного застосовуються різні функції (та витрати).
Про CloudTrail згадувалося, але перший варіант, який мені спадає на думку, враховуючи ваше запитання (і це згадується в коментарі до відповіді @ Євгена ) - це служба AWS Config . Він зберігає "знімки" вашої конфігурації AWS в моменти часу (у відрі S3), але корисно також надсилає будь-які зміни до теми SNS. Потім ви можете займатися цим, скільки завгодно. Наприклад, на рахунку з низьким трафіком у мене вони потрапляють прямо в Slack; на великому рахунку трафіку я відстежую NumberOfMessagesPublishedпоказник на цю тему SNS, щоб помітити, чи вноситься більша кількість змін, ніж зазвичай.
AWS Config також пропонує послугу «правила»; вони трохи дорожчі, ніж я б очікував, що вони будуть, але залежно від ваших потреб вони можуть бути корисними. Тільки не активуйте їх усі одразу, як я, коли я грав, ... стягнення плати за кожне правило застосовується відразу. ;) (Але ви можете використовувати Config без використання правил - це я зараз роблю).
Є також Trusted Advisor , який не робить того, про що ви просили, але може бути корисним для проведення певних перевірок на те, як інженери налаштовують вашу інфраструктуру, наприклад, чи залишилися у когось відрі S3 відкритими. Це найкорисніше з планом підтримки на рівні бізнесу або вище, оскільки багато його перевірок заблоковані в іншому випадку.
Потім є сторонні інструменти, такі як CloudCheckr , які поєднують в собі аспекти AWS Cost Explorer, Trusted Advisor, Config, CloudTrail, CloudWatch, Inspector та GuardDuty. Корисно, якщо ви хочете зайнятися по-справжньому глибоким, але заощадите час, налаштувавши все самостійно.
Крім того , можна управляти інфраструктурою з допомогою такого інструменту, як терраформіровать або CloudFormation і наказує , що всі зміни повинні бути зроблені через них. Потім ви можете зафіксувати свої конфігураційні файли / шаблони для управління джерелом і навіть перевірити їх проти живої інфраструктури в CI і не вдатися до збірки, якщо хтось вніс невідстежувані зміни. Таким чином, історія ваших зобов'язань стає журналом аудиту - але це вимагає від ваших інженерів дисциплінованості!