В IT практике мы нередко сталкиваемся с неприятными инцидентами при работе с инфраструктурой. Частыми причинами возникновения непредвиденных ситуаций становятся:

• ошибки при обслуживании и поддержке инфраструктуры (удаление или некорректное изменение ресурсов авторизованным персоналом);
• ошибки и недоработки при проектировании приложений (hardcode конфигурации, отсутствие корректной обработки ошибок, проч.);
• взломы приложений и атаки на инфраструктуру.

Довольно часто инциденты происходят одновременно или последовательно – один за другим. Это происходит потому, что людям в стрессовой ситуации сложно что-то менять в инфраструктуре / приложении, одновременно пытаясь отразить атаки и восстановить работоспособность системы. Именно поэтому предельно важно по возможности подготовиться к решению инцидентов заранее, а также выполнить ряд мер для их предотвращения.

В этом посте мы рассмотрим ряд простых правил, которые помогут вам сократить вероятность возникновения инцидентов, а также начать оптимизировать собственную инфраструктуру и процессы её сопровождения.

Один на редкость счастливый день

Начнем мы с примера ситуации, реально возникшей у одной крупной компании.

В один прекрасный солнечный день SysOps инженер, ответственный за проведение обновления backend для мобильных приложений, случайно удалил основную Hosted Zone в Route53. В результате, несколько миллионов мобильных приложений потеряли возможность взаимодействия с собственным backend. TTL для DNS был установлен на 24 часа, обновить конфигурацию приложений было нельзя, так как она зашита в код … занавес? Но не тут-то было.

Новость о проблемах в работе компании быстро распространилась на просторах интернета и привлекла профессиональных хакеров.

В самое короткое время начались атаки на различные ресурсы компании две из которых увенчались успехом.

Одна из атак – классическая SQL Injection была проведена знаменитым в регионе хакером. Факт успешной атаки он незамедлительно опубликовал в своем блоге.

Через некоторое время другой «специалист» по ИБ в поиске ключей доступа смог найти в коде мобильного приложения прямо в виде строковых переменных Access Key и Secret Access Key IAM пользователя с правами администратора. Думаю, излишне говорить, насколько это серьезно. К счастью, команда поддержки уже находилась в режиме постоянной готовности – они смогли зафиксировать взлом и оперативно устранить его последствия. Как результат – мобильное приложение лишилось возможности работать с некоторыми ресурсами backend, так как основной IAM User этого приложения был скомпрометирован.

Довольно естественно, после таких событий коллеги начали оперативно искать алгоритм для максимально быстрого выравнивания ситуации и предотвращения возникновения инцидентов в будущем.

Алгоритм решения проблем

Предложенный алгоритм состоял из шести простых и довольно быстро выполнимых шагов.

1. Проверка и тегирование ресурсов
2. Проверка IAM политик и доступа к ресурсам AWS
3. Включение логирования и мониторинга
4. Выполнение сканирования безопасности
5. Проверка текущего состояния баз данных
6. Покомпонентная проверка DR

Выполнение этого алгоритма позволило коллегам достаточно быстро нормализовать ситуацию, корректно распределить ответственность и снять давление с разработчиков и SysOps команды.

Далее мы детально рассмотрим каждый шаг описанного нами алгоритма.

Шаг 1: Проверка и тегирование ресурсов

Вам наверняка интересно, почему проверка и тегирование ресурсов была поставлена на первое место в такой сложной ситуации. Дело в том, что у коллег не существовало вменяемой схемы маркировки ресурсов и документации. Например, существовали ресурсы с именованием наподобие PLEASE_DO_NOT_DELETE_UNTIL_28/09.

Не зная, какие ресурсы к чему относятся, зачем они нужны и насколько их существование критично, невозможно ни установить приоритеты устранения уязвимостей, ни корректно определить права на ресурсы, ни определить порядок решения инцидентов. Да и читать логи становится крайне затруднительно.

Для начала мы определили простую схему тегирования ресурсов:

• Наименование ресурса в формате uid:function:system
• Владелец ресурса (подразделение или специалист)
• Среда, к которой относится тот или иной ресурс
• Критичность данного ресурса для работоспособности основных систем
• Возможности DR для конкретного ресурса (backup / replication / auto-scaling и проч.)

После определения схемы ресурсов необходимо было выполнить собственно процедуру тегирования. Технически выполнить это не сложно, однако, некоторое время ушло на разбор – какие ресурсы кому принадлежат и для чего они нужны.

Применение тегов для различных групп ресурсов выполняется по-разному. Более подробную информацию можно найти тут:

После того, как схема тегов применена и все ресурсы промаркированы можно выполнить реверс генерацию архитектурной диаграммы c использованием различных инструментов, таких как VisualOps, Hava, Lucidchart и других.

Шаг 2: Проверка IAM политик и доступа

Проверка IAM политик и способов организации доступа к ресурсам AWS – один из наиболее критичных процессов с точки зрения сокращения вероятности возникновения инцидентов.

• Средства аутентификации пользовательских приложений;
• Средства аутентификации администраторов;
• Средства аутентификации backend приложений;
• Политики прав доступа пользовательских ролей;
• Политики прав доступа администраторов и их ролей;
• Политики прав доступа приложений.

Важность проверки и корректировки политик доступа сложно переоценить. В ситуации, когда первый инцидент случился по вине конкретного инженера, а данные о ресурсах и их назначении восстановлены по памяти, отсутствие вменяемых и контролируемых политик разграничения прав доступа дополнительно давит на специалистов и увеличивает риск нарушения работы системы вследствие ошибок обслуживающего персонала. Естественно, когда пользователи с административными правами «зашиты» в код приложения, это также усложняет жизнь разработчикам.

Для проверки и корректировки политик доступа к ресурсам мы предложили следующий простой алгоритм.

1. Основываясь на результатах тегирования ресурсов и с помощью архитектурных диаграмм / других артефактов идентифицируется список критически важных ресурсов.
2. Для каждого типа критически важных ресурсов идентифицируется список потенциально опасных действий (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).
3. Для комбинации потенциально опасных действий над критически важными ресурсами создаются и тестируются отдельные политики, при этом список ресурсов может быть ограничен условиями (Condition: Tag). Дополнительно, можно добавить необходимость ввода MFA кода для выполнения опасных действий.
4. Для выполнения потенциально опасных действий создаются специальные роли, при этом лучше не объединять все действия в одну политику / роль. Для пользователей / групп пользователей создается Assume Role Policy, которая позволяет применять роль к IAM пользователю (позволяет пользователю потреблять роль).
5. После того, как роли созданы и политики назначены, а также после тестирования возможности применения данных ролей, необходимо переопределить политики административного доступа, в которых нужно запретить выполнять потенциально опасные действия с критически важными ресурсами.

Более подробную информацию можно найти тут:

• Secure Token Service для ротации Credentials приложениями;
• AWS Cognito для аутентификации и авторизации пользователей мобильных приложений (с функцией ротации Credentials);

Шаг 3: Включение логирования и мониторинга

После того, как все ресурсы известны и права на них корректно распределены и ограничены можно приступить к корректной настройке логирования и мониторинга. Оба эти процесса играют ключевую роль для любого SysOps специалиста и на сегодняшний момент существует огромное количество средств и инструментов, обеспечивающих сбор метрик, логов, их корректное представление и анализ. В некоторой мере, настройка этих инструментов постепенно превращается в искусство.

Этой теме посвящено большое количество различных постов и даже книг, поэтому, здесь мы ограничимся кратким обзором того, что можно сделать с использованием уже существующих платформенных сервисов логирования и мониторинга.

Логирование

В AWS существует значительное количество инструментов для сбора самых разнообразных логов.

В первую очередь необходимо обратить внимание на логирование доступа пользователей и приложений / скриптов к API AWS. Для этого используется сервис под названием Amazon CloudTrail. Этот сервис рекомендуется применять всегда и хранить его логи в течение продолжительного времени (например, в течение одного года). Данные полученные с использованием AWS CloudTrail можно использовать не только в качестве отличного материала для анализа работы пользователей и приложений с инфраструктурой AWS, но и для обоснования финансовых запросов в AWS.

Включить CloudTrail очень просто.

Для анализа логов CloudTrail можно использовать различные инструменты. В первую очередь это Cloud Watch Logs. Кроме того, существует большое количество сторонних приложений, предназначенных в том числе для анализа логов CloudTrail. Список этих инструментов приведен здесь.

Кроме перечисленных сервисов, полезными источниками логов могут быть:

• VPC Flow 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;
• 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 имеет большое портфолио сервисов по обеспечению информационной безопасности и каждому из них можно посвятить не один пост. Однако для вашего удобства здесь я опубликую диаграмму со всеми актуальными на сегодняшний день сервисами в области ИБ. Крупное изображение доступно здесь.

Полный перечень сервисов по обеспечению ИБ в AWS (на 23 ноября 2017 года)

Вместо заключения: Well Architected Framework

На этом на сегодня, пожалуй, все. В этом посте перечислен набор простых и быстро выполнимых действий, которые помогут вам существенно сократить влияние инцидентов на вашу инфраструктуру и сон. Однако, на этом наши рекомендации не исчерпываются. Тем, кто действительно заботится о безопасности и устойчивости инфраструктуры на AWS мы настоятельно советуем прислушаться к рекомендациям, собранным специалистами AWS в Well-Architected Framework.

Всем спасибо. До скорого!