Содержание статьи
В былые времена после каждого «дефейса» герои хацкеры винили неких «сисадминов»: мол, если он такой ламер, что не смог обновить или настроить систему, то и поделом ему. Прошло уже немало времени, и хакерские приемы поиска и эксплуатации уязвимостей развиваются семимильными шагами, методы безопасной разработки приложений также совершенствуются, не говоря уже про механизмы ОС. А что же со старыми добрыми «сисадминами»? Эволюционировали и эти ребята. Сегодня мы поговорим об одном довольном модном концепте — DevOps, и, конечно же, говорить мы будем с точки зрения безопасности!
DevOps
Раньше были некие разработчики, они писали какой-то код; были сисадмины, они настраивали и ставили серверы, потом на эти серверы накатывали приложения, написанные разработчиками. Так люди и жили, пока не возникла потребность в гибком управлении всем этим делом и увеличении темпов выкладки билдов и релизов. Теперь уже надо накатывать приложения несколько раз в день, и при этом на разных серверах с разной конфигурацией. Сложность задач росла, а время решения надо было сокращать, при этом не сильно повышая стоимость решения. Для этого отношения между разработчиками, тестировщиками и админами нужно унифицировать и «упростить» (читай: автоматизировать). В итоге сообщество профессионалов представило новый концепт — DevOps. Как видно из названия, это «разработка и операции» в одном флаконе. То есть админские ИТ-задачи, связанные с развертыванием, конфигурированием и прочим, ложатся в новую парадигму отношений разработчик — админ — тестировщик — кто-угодно-еще. Если сказать другими словами, то задачи развертывания и настройки платформы управляются командой разработчиков через некий унифицированный «интерфейс». То есть это методология разработки и развертывания как единого процесса. Вся это идея в том числе поддерживается такими простыми и понятными вещами, как автоматизация развертывания, стандартизация конфигураций, описание инфраструктуры кодом. Все эти темы существовали и раньше, но, разумеется, их можно и нужно использовать как инструменты для реализации DevOps. Таким образом, ИТ-решение в виде сервера, виртуалки, ОС, пакетов и конфигов — это часть финального продукта, который «разрабатывается» командой, а не настраивается какими-то админами, хотя все это довольно спорно и зависит от точки обзора. Тем не менее раз это «разрабатывается», то, значит, и тестируется, и тут мы говорим про интеграционные и непрерывные тесты и уже в контексте всего продукта, вместе с платформой, а не только кода приложения. Очевидно, что это плюс, в том числе и для ИБ!
DevOps и ИБ
Важно понять, что DevOps — это не какие-то «технические» решения, а идеология управления развертывания и выпуска. Вся это автоматизация, виртуализация, контроль конфигураций существовали и раньше, это просто инструменты, которые помогают поддерживать процесс, не более. Если говорить про DevOps как идею, то в некотором смысле это продолжение Agile, только в контексте платформы. В прошлом выпуске я рассуждал, что в Agile вопросы безопасности кода переходят на сторону команды. Абсолютно такая же ситуация и тут — вопросы безопасной настройки, конфигурации и ИТ-поддержки переходят на сторону команды. Так вот, что может сделать инженер ИБ, так это реализовать требования, гайды и прочее по правильной настройке компонентов, правильному деплою и так далее. Более того, мы можем делать тулзы, различные автоматизированные решения, системы мониторинга и прочие плюшки, которые не позволят командам DevOps совершить ошибку, даже если они что-то проморгали в гайдах. Таким образом, основным инструментом для нас станет всевозможная автоматизация вопросов ИБ.
Автоматизация
Реализовать хороший DevOps-процесс без хорошей автоматизации — нереальная задача, поэтому большая часть проблем решается автоматизацией. Нам нужно развертывание серверов (виртуалка), накатка нужных пакетов, их конфигурация и потом уже тестирование. Чтобы автоматизировать такие штуки, мы должны иметь унифицированный подход, что, с одной стороны, ограничивает нашу гибкость, но с другой — повышает производительность. Хотя все это опять же вопрос архитектуры DevOps-системы. Тем не менее это означает и плюсы — идентичность конфигураций, то есть стандартизация в хорошем смысле этого слова! Таким образом, мы подготавливаем стандарты конфигурации для пакетов, даем инструмент управления этими конфигурациями, если нужна гибкость (а она нужна), автоматизируем задачи развертывания и тестирования. В результате у нас будет нечто вроде фреймворка для создания продукта. Для разработчиков конкретного приложения это может быть удобным инструментом, он может не знать детали — ему просто нужен Апач, но то, что этот Апач будет сконфигурирован нужным и эффективным способом, уже решит ряд вопросов при тестировании, в том числе и безопасности.
1. Стандарты
Уже было сказано, но повторим еще раз: иметь темплейты и стандарты конфигурации для используемых вещей — это круто, молодежно и безопасно. Мы знаем, как правильно настраивать SSHd, Apache, php.ini или Tomcat, — отлично, пользуемся этими темплейтами как стандартами и автоматизируем их использование. Главное — предоставить механизм для гибкости, API и/или расширенную возможность конфигурации, ведь конфиг, скажем того же Апача, дело уникальное, и на разные проекты может требоваться разная конфигурация. Кроме того, мы можем и должны предоставлять конфигурацию ОС, типа маски доступа к файлам, владельцев + noexec на /tmp /dev/shm/tmp и так далее. При автоматизации все это довольно круто улучшит положение дел, особенно если сюда добавить SELinux/AppArmor.
2. Безопасность из коробки
Нам нужен мониторинг за событиями, HIDS, WAF и конфигурация этого дела для контроля за ИБ сервера? Так интегрируй эти решения, в чем вопрос! Например, почему бы нам не расставлять rkhunter на все серверы и настраивать его по крону на проверки раз в сутки, а кроме того, и какой-нибудь скрипт для контроля целостности. В общем, эту идею можно развивать до бесконечности, главное, что мы хотим иметь контроль и механизмы оповещения о нарушениях и можем автоматизировать развертывание и настройку этого дела, и для команды разработчика эти требования будут выполняться «автоматически» и прозрачно.
3. Тестирование
Включение security-тестов в процесс интеграционного и непрерывного тестирования. При таком раскладе, грубо говоря, на каждый новый билд мы будем запускать сканер и/или скрипт проверки безопасности из коробки, да что удобно — как лучше тестировать, так и тестируешь! Главное, что мы не «забыли» и контролируем этот процесс. Один из примеров — деплоим новый виртуальный сервер на AWS и сразу же добавляем его DNS-имя в сканер безопасности, который просканит его и будет держать в листе для сканирования, пока сервер есть. Кроме того, тестировать можно и изнутри. Например, у нас есть скрипт, который проверяет, что все настройки на сервере соответствуют требованиям ИБ, и, как только сервер разворачивается для тестирования, этот скрипт пробегает детально по всем пунктам, и если он что-то определил, то это возвращается в тест-результатах.
4. Автоматизируй все, что можно
Как бы ни любили пентестеры и ресерчеры говорить о том, что ручная работа бесценна, но с точки зрения инженерии автоматизация — более ценная вещь. Главное — понимать покрытие и глубину своей автоматизации, чтобы знать, что мы можем пропустить. Предыдущие пункты уже описывают и тестирование, и автоконфигурацию, но мы ничем не ограничены — любая свобода творчества с пользой абсолютно допустима.
Вместо тысячи слов
Как уже ясно, с точки зрения организации ИБ DevOps очень похож по идеологии с Agile. Только если там мы говорили про разработку кода, то тут про разработку конфигурации. Мы переносим ответственность за конфигурации с команды системных инженеров на команду разработчика, но при этом нам надо иметь и контроль и уверенность в том, что команда все будет делать правильно. Доверяй, но проверяй — главный принцип ИБ в DevOps/Agile. Все проблемы те же и решаются очень похоже: гайды, треннинг, автоматизация... Вообще, движение в эту сторону, что DevOps, что Agile, говорит о потребностях в быстрой и эффективной разработке и такой же быстрой и эффективной выкатке билдов и сервисов, поэтому вопросы ИБ будут касаться не только финального продукта и процесса, но и сервисов и процедур, которые поддерживают этот ваш DevOps. Ведь если мы совершим ошибку или наша автоматизация будет иметь слабое покрытие и малую глубину — то подвержены этой проблеме будут все «выпущенные» сервисы! Так что, кроме очевидных плюсов, имеются и очевидные минусы. Веселого тебе DevOps’а и да пребудет с тобой Сила!