Джин Ким - Руководство по DevOps

Сервис AWS Cloud.govодобрен для использования всеми правительственными системами всех типов, в том числе требующими высокого уровня конфиденциальности, целостности и доступности. К тому времени, когда вы будете читать эту книгу, скорее всего, сервис Cloud.govбудет одобрен для всех систем, требующих среднего уровня конфиденциальности, целостности и доступности [168].

Кроме того, команда Cloud.govразрабатывает платформу для автоматического создания планов безопасности систем (system security plan, SSP), «полных описаний архитектуры системы, ее компонентов и общих средств обеспечения безопасности… обычно очень сложных и занимающих несколько сотен страниц». Они разработали прототип инструмента, названного Compliance Masonry, чтобы данные SSP можно было хранить в машиночитаемом формате YAML и автоматически преобразовывать в GitBooks- или PDF-документы.

Группа 18F исповедует принципы открытой работы и выкладывает всю свою работу в свободный доступ. Вы можете найти Compliance Masonry и компоненты Cloud.govв репозиториях GitHub команды 18F, вы даже можете запустить свой инстанс Cloud.gov. Работа по созданию документации для SSP ведется в тесном сотрудничестве с сообществом OpenControl.

Маркус Сакс, один из исследователей утечек данных компании Verizon, отмечал: «На протяжении многих лет организации только месяцы спустя обнаруживали утечку данных о владельцах карт. Что еще хуже, утечка обнаруживалась не внутренними инструментами контроля, а чаще всего людьми, не работающими в компании. Обычно это был или бизнес-партнер, или клиент, заметивший мошеннические операции с картой. Одна из главных причин заключалась в том, что никто регулярно не просматривал логи».

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

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

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

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

Распространяя сведения о том, как наши сервисы ведут себя при внешней атаке, мы напоминаем всем о необходимости иметь в виду риски безопасности и разрабатывать соответствующие контрмеры в ходе ежедневной работы.

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

Примерами показателей могут быть:

• успешные и неуспешные входы в систему;

• смена паролей пользователей;

• изменение адреса электронной почты;

• изменения данных кредитной карты.

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

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

Мы должны следить и при необходимости получать оповещения о следующих событиях:

• изменения в операционной системе (например, в эксплуатации, в инфраструктуре разработки);

• изменение групп безопасности;

• изменения конфигураций (например, OSSEC, Puppet, Chef, Tripwire);

• изменения облачной инфраструктуры (например, VPC, группы безопасности, пользовательские привилегии);

• попытки XXS (cross-site scripting attacks, межсайтовый скриптинг);

• попытки SQLi (SQL-инъекций);

• ошибки серверов (например, ошибки 4XX и 5XX).

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

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

Для обеспечения защиты данных Галбрет не стал создавать отдельную систему контроля фрод-мошенничеств или новый отдел информационной безопасности. Вместо этого он встроил эти задачи в весь поток ценности DevOps.

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

• Некорректное завершение программы в эксплуатации (например, ошибки сегментации, ошибки дампов памяти и так далее):«Особенно интересно было, почему некоторые процессы, запускаемые с одного из IP-адресов, снова и снова приводили к падению всей нашей среды эксплуатации. Такими же интересными были и эти “ошибки 500: внутренняя ошибка сервера”. Это были сигналы о том, что кто-то использовал уязвимое место, чтобы получить неавторизованный доступ к нашим системам, и эту дыру надо срочно заделать».