Блог Amazon Web Services
Базовые меры по предотвращению инцидентов при работе с AWS
Андрей Зайчиков, Архитектор AWS
В IT практике мы нередко сталкиваемся с неприятными инцидентами при работе с инфраструктурой. Частыми причинами возникновения непредвиденных ситуаций становятся:
- ошибки при обслуживании и поддержке инфраструктуры (удаление или некорректное изменение ресурсов авторизованным персоналом);
- ошибки и недоработки при проектировании приложений (hardcode конфигурации, отсутствие корректной обработки ошибок, проч.);
- взломы приложений и атаки на инфраструктуру.
Довольно часто инциденты происходят одновременно или последовательно – один за другим. Это происходит потому, что людям в стрессовой ситуации сложно что-то менять в инфраструктуре / приложении, одновременно пытаясь отразить атаки и восстановить работоспособность системы. Именно поэтому предельно важно по возможности подготовиться к решению инцидентов заранее, а также выполнить ряд мер для их предотвращения.
В этом посте мы рассмотрим ряд простых правил, которые помогут вам сократить вероятность возникновения инцидентов, а также начать оптимизировать собственную инфраструктуру и процессы её сопровождения.
Один на редкость счастливый день
Начнем мы с примера ситуации, реально возникшей у одной крупной компании.
В один прекрасный солнечный день SysOps инженер, ответственный за проведение обновления backend для мобильных приложений, случайно удалил основную Hosted Zone в Route53. В результате, несколько миллионов мобильных приложений потеряли возможность взаимодействия с собственным backend. TTL для DNS был установлен на 24 часа, обновить конфигурацию приложений было нельзя, так как она зашита в код … занавес? Но не тут-то было.
Новость о проблемах в работе компании быстро распространилась на просторах интернета и привлекла профессиональных хакеров.
В самое короткое время начались атаки на различные ресурсы компании две из которых увенчались успехом.
Одна из атак — классическая SQL Injection была проведена знаменитым в регионе хакером. Факт успешной атаки он незамедлительно опубликовал в своем блоге.
Через некоторое время другой «специалист» по ИБ в поиске ключей доступа смог найти в коде мобильного приложения прямо в виде строковых переменных Access Key и Secret Access Key IAM пользователя с правами администратора. Думаю, излишне говорить, насколько это серьезно. К счастью, команда поддержки уже находилась в режиме постоянной готовности — они смогли зафиксировать взлом и оперативно устранить его последствия. Как результат — мобильное приложение лишилось возможности работать с некоторыми ресурсами backend, так как основной IAM User этого приложения был скомпрометирован.
Довольно естественно, после таких событий коллеги начали оперативно искать алгоритм для максимально быстрого выравнивания ситуации и предотвращения возникновения инцидентов в будущем.
Алгоритм решения проблем
Предложенный алгоритм состоял из шести простых и довольно быстро выполнимых шагов.
- Проверка и тегирование ресурсов
- Проверка IAM политик и доступа к ресурсам AWS
- Включение логирования и мониторинга
- Выполнение сканирования безопасности
- Проверка текущего состояния баз данных
- Покомпонентная проверка DR
Выполнение этого алгоритма позволило коллегам достаточно быстро нормализовать ситуацию, корректно распределить ответственность и снять давление с разработчиков и SysOps команды.
Далее мы детально рассмотрим каждый шаг описанного нами алгоритма.
Шаг 1: Проверка и тегирование ресурсов
Вам наверняка интересно, почему проверка и тегирование ресурсов была поставлена на первое место в такой сложной ситуации. Дело в том, что у коллег не существовало вменяемой схемы маркировки ресурсов и документации. Например, существовали ресурсы с именованием наподобие PLEASE_DO_NOT_DELETE_UNTIL_28/09.
Не зная, какие ресурсы к чему относятся, зачем они нужны и насколько их существование критично, невозможно ни установить приоритеты устранения уязвимостей, ни корректно определить права на ресурсы, ни определить порядок решения инцидентов. Да и читать логи становится крайне затруднительно.
Для начала мы определили простую схему тегирования ресурсов:
- Наименование ресурса в формате uid:function:system
- Владелец ресурса (подразделение или специалист)
- Среда, к которой относится тот или иной ресурс
- Критичность данного ресурса для работоспособности основных систем
- Возможности DR для конкретного ресурса (backup / replication / auto-scaling и проч.)
После определения схемы ресурсов необходимо было выполнить собственно процедуру тегирования. Технически выполнить это не сложно, однако, некоторое время ушло на разбор — какие ресурсы кому принадлежат и для чего они нужны.
Применение тегов для различных групп ресурсов выполняется по-разному. Более подробную информацию можно найти тут:
- Для сред Elastic Beanstalk;
- Для Auto Scaling групп;
- Для различных ресурсов с помощью Management Console.
После того, как схема тегов применена и все ресурсы промаркированы можно выполнить реверс генерацию архитектурной диаграммы c использованием различных инструментов, таких как VisualOps, Hava, Lucidchart и других.
Шаг 2: Проверка IAM политик и доступа
Проверка IAM политик и способов организации доступа к ресурсам AWS – один из наиболее критичных процессов с точки зрения сокращения вероятности возникновения инцидентов.
- Средства аутентификации пользовательских приложений;
- Средства аутентификации администраторов;
- Средства аутентификации backend приложений;
- Политики прав доступа пользовательских ролей;
- Политики прав доступа администраторов и их ролей;
- Политики прав доступа приложений.
Важность проверки и корректировки политик доступа сложно переоценить. В ситуации, когда первый инцидент случился по вине конкретного инженера, а данные о ресурсах и их назначении восстановлены по памяти, отсутствие вменяемых и контролируемых политик разграничения прав доступа дополнительно давит на специалистов и увеличивает риск нарушения работы системы вследствие ошибок обслуживающего персонала. Естественно, когда пользователи с административными правами «зашиты» в код приложения, это также усложняет жизнь разработчикам.
Для проверки и корректировки политик доступа к ресурсам мы предложили следующий простой алгоритм.
- Основываясь на результатах тегирования ресурсов и с помощью архитектурных диаграмм / других артефактов идентифицируется список критически важных ресурсов.
- Для каждого типа критически важных ресурсов идентифицируется список потенциально опасных действий (Actions). К таким действиям может относиться:
- Удаление вычислительных ресурсов (EC2, RDS, ElasticCache, RedShift);
- Удаление прочих ресурсов (DynamoDB tables, DynamoDB streams, S3 buckets, SQS queues, SNS topics, SES mailing lists, Lambda functions, VPN Gateways, Internet Gateways, VPC Routes)
- Модицификация политик (IAM Policies, Bucket policies, Security Groups Ingress/Egress rules, nACL Ingress/Egress rules).
- Для комбинации потенциально опасных действий над критически важными ресурсами создаются и тестируются отдельные политики, при этом список ресурсов может быть ограничен условиями (Condition: Tag). Дополнительно, можно добавить необходимость ввода MFA кода для выполнения опасных действий.
- Для выполнения потенциально опасных действий создаются специальные роли, при этом лучше не объединять все действия в одну политику / роль. Для пользователей / групп пользователей создается Assume Role Policy, которая позволяет применять роль к IAM пользователю (позволяет пользователю потреблять роль).
- После того, как роли созданы и политики назначены, а также после тестирования возможности применения данных ролей, необходимо переопределить политики административного доступа, в которых нужно запретить выполнять потенциально опасные действия с критически важными ресурсами.
Более подробную информацию можно найти тут:
- IAM roles for EC2;
- Secure Token Service для ротации Credentials приложениями;
- AWS Cognito для аутентификации и авторизации пользователей мобильных приложений (с функцией ротации Credentials);
- MFA protected API access.
Шаг 3: Включение логирования и мониторинга
После того, как все ресурсы известны и права на них корректно распределены и ограничены можно приступить к корректной настройке логирования и мониторинга. Оба эти процесса играют ключевую роль для любого SysOps специалиста и на сегодняшний момент существует огромное количество средств и инструментов, обеспечивающих сбор метрик, логов, их корректное представление и анализ. В некоторой мере, настройка этих инструментов постепенно превращается в искусство.
Этой теме посвящено большое количество различных постов и даже книг, поэтому, здесь мы ограничимся кратким обзором того, что можно сделать с использованием уже существующих платформенных сервисов логирования и мониторинга.
Логирование
В AWS существует значительное количество инструментов для сбора самых разнообразных логов.
В первую очередь необходимо обратить внимание на логирование доступа пользователей и приложений / скриптов к API AWS. Для этого используется сервис под названием Amazon CloudTrail. Этот сервис рекомендуется применять всегда и хранить его логи в течение продолжительного времени (например, в течение одного года). Данные полученные с использованием AWS CloudTrail можно использовать не только в качестве отличного материала для анализа работы пользователей и приложений с инфраструктурой AWS, но и для обоснования финансовых запросов в AWS.
Включить CloudTrail очень просто.
Для анализа логов CloudTrail можно использовать различные инструменты. В первую очередь это Cloud Watch Logs. Кроме того, существует большое количество сторонних приложений, предназначенных в том числе для анализа логов CloudTrail. Список этих инструментов приведен здесь.
Кроме перечисленных сервисов, полезными источниками логов могут быть:
- VPC Flow Logs (в основном используются в критичной инфраструктуре / для поиска проблем на сетевом уровне)
- ELB Logs;
- ALB Logs;
- CloudFront Logs;
- S3 Bucket Logs.
Для сбора и анализа всех логов в качестве базового инструмента можно использовать уже упомянутый выше функционал Amazon CloudWatch – CloudWatch Logs. Он предоставляет базовую функциональность сбора и просмотра логов, однако для анализа логов потребуется применять регулярные выражения. В качестве еще одной удобной функции можно упомянуть интеграцию с SNS и возможность генерировать и отправлять alert’ы при появлении определенных ошибок.
Другим популярным вариантом инструментов для сбора и анализа логов является комбинация ELK (ElasticSearch + Logstash + Kibana) или её вариации, в том числе с заменой Logstash на CloudWatch Logs и использованием сервиса Amazon Elasticsearch. Такая схема позволяет существенно кастомизировать процессы анализа логов и при этом не фокусироваться на выделении ресурсов и управлении ими.
Мониторинг
Основным сервисом мониторинга на платформе AWS является Amazon CloudWatch. Этот сервис предоставляет достаточно широкие возможности по организации мониторинга сервисов AWS, а также решений, размещенных на платформе.
Amazon CloudWatch предоставляет значительное количество предопределенных метрик (список можно посмотреть здесь), которые позволяют быстро и эффективно настраивать мониторинг ресурсов. При этом, интеграция CloudWatch с другими сервисами AWS уже выполнена.
Кроме того, CloudWatch позволяет создавать и использовать кастомизированные метрики для унификации процесса мониторинга приложений / специфических особенностей инфраструктуры. Также для организации мониторинга можно использовать сторонние приложения / системы партнеров AWS.
Шаг 4: Выполнение сканирования безопасности
Сканирование безопасности – важный шаг, который, по опыту, лучше всего выполнять после того, как все ресурсы известны, доступ обеспечен в необходимом объеме, а также все средства мониторинга и логирования настроены и позволят контролировать результаты сканирования и выявлять конкретные особенности работы приложений и инфраструктуры.
При организации сканирования ИБ необходимо уведомлять AWS о проведении процедур сканирования с использованием следующей формы. При этом, если для сканирования применяются средства, прошедшие проверку со стороны AWS и получившие разрешение на использование для сканирования, уведомление посылать не нужно.
Проверка ИБ может состоять из нескольких основных шагов:
- ASV сканирование периметра вычислительной сети (VPC и собственной сети) – можно использовать ASV провайдеров сертифицированных PCI Council;
- Сканирование уязвимостей с помощью Amazon Inspector или сторонних инструментов;
- Penetration тестирование (в случае необходимости / требований регуляторов, например, по требованиям PCI\DSS).
На основании проверки результатов сканирования ИБ необходимо принять меры по устранению выявленных рисков и проблем. В числе подобных мер могут быть:
- Откорректировать правила фильтрации трафика Security Groups и Network Access Control Lists;
- Реализовать Web Application Firewall и интегрировать его с собственными приложениями;
- Обновить программное обеспечение и операционные системы;
- Изменить парольные политики / пароли используемые для доступа к стороннему ПО (базы данных, сервера приложений, сервлет контейнеры и проч.);
- Изменить средства аутентификации и авторизации (например, перейти на использование одноразовых токенов вместо использования IAM User Credentials);
- Обеспечить контроль целостности на уровне операционных систем, конфигурационных файлов, сторонних приложений и проч. (например, с использованием OSSEC);
Естественно, перечисленные выше шаги – это только малая часть того объема мер, которые возможно и, нередко, необходимо применять. Хорошей практикой является встраивание проверок ИБ в релизный цикл и реализация данных процедур на периодической основе.
Шаг 5: Проверка текущего состояния баз данных
Большинство информационных систем, с которыми мы работаем, хранит структурированную и полу-структурированную информацию в базах данных. Соответственно, одним из важнейших аспектов сокращения вероятности серьезного инцидента и повышения шансов устранить последствия инцидента без существенных потерь является обеспечение disaster recovery на уровне баз данных.
При этом, естественно, необходимо помнить о таких параметрах восстановления баз данных, как Recovery Point Objective и Recovery Time Objective. Кроме того, нельзя забывать, что наличие репликации и различных high availability опций для БД не отменяет необходимость создания бекапов. Это релевантно не только для RDBMS, но также и для различных NoSQL БД.
Итак, с точки зрения проверки состояния БД желательно:
- Проверить наличие бекапов и процедур их автоматического создания в рамках, определенных RPO;
- Проверить специфику использования баз данных – не хранится ли важная информация в БД кеша (Redis, Memcached, etc.) / поисковом движке (Solr, ElasticSearch) в единственном экземпляре, не запускаются ли ETL процедуры на мастер-базе и проч.;
- Проверить специфику установки БД и определить потоки данных (в том числе с использованием ETL процедур, специализированных приложений, MQ систем), определить необходимость / наличие реализации HA & DR процедур для этих компонент;
- По возможности обеспечить выполнение процедур ротации параметров доступа к БД со стороны приложений / пользователей;
- Обеспечить специфическое для конкретной БД покрытие средствами мониторинга / логирование.
Шаг 6: Покомпонентная проверка DR
В качестве последнего шага мы рекомендуем выполнить покомпонентную проверку DR вашей системы. Первую итерацию такой проверки лучше проводить на тестовой среде и переносить результаты проверки на продуктивную систему (проверять наличие процедур, настройки и проч.).
Среди тех вещей, которые необходимо проверять, можно отметить:
- Проверка бекапов:
- Конфигурационных файлов Infrastructure-as-a-Code (CloudFormation, Elastic Beanstalk, Terraform, etc.);
- Эталонных EBS snapshot’ов и образов AMI;
- Баз данных / файловых хранилищ;
- Конфигураций приложений и сервисов;
- Кодовой базы.
- Проверка HA функций
- Схема IP адресации (private / public / static & IP failover);
- Схема внутренней и внешней DNS адресации;
- Представление схемы адресации в приложениях + failover схемы адресации на уровне приложений;
- Поведение приложений при инвалидации кешей / перезапуске процедуры построения индекса;
- Failover баз данных (переключение на slave / выбор нового мастера / другие процедуры) + переключение приложений;
- DNS based routing & health checks
- ELB based routing &workspaces health checks
Сервисы AWS по обеспечению информационной безопасности
В дополнение ко всему сказанному выше, хотелось бы подчеркнуть, что AWS имеет большое портфолио сервисов по обеспечению информационной безопасности и каждому из них можно посвятить не один пост.
Вместо заключения: Well Architected Framework
На этом на сегодня, пожалуй, все. В этом посте перечислен набор простых и быстро выполнимых действий, которые помогут вам существенно сократить влияние инцидентов на вашу инфраструктуру и сон. Однако, на этом наши рекомендации не исчерпываются. Тем, кто действительно заботится о безопасности и устойчивости инфраструктуры на AWS мы настоятельно советуем прислушаться к рекомендациям, собранным специалистами AWS в Well-Architected Framework.
Всем спасибо. До скорого!