DevOps без Security в итоге может обойтись слишком дорого

KOGDATA.RU — Я начинал карьеру как системный администратор. Эта профессия предполагает знание передовых аспектов безопасности. Затем перешел в DevOps, где сначала фокусировался на соответствия выбранного для имплементации решения задачам, которые поставил клиент. Иными словами, моей целью было сделать так, чтобы наше решение работало. Например, если речь идет о деплоймент приложения, моей задачей было сделать так, чтобы компоненты деплоймент-схемы забирали код с репозитория, обрабатывали его и в конечном итоге выдавали обновленный код на сервере. Если эта схема работает идеально, я, будучи специалистом исключительно с DevOps, считал, что задача решена и проект завершен.

Но на момент релиза приложения часто в наш отдел по безопасности или у клиента возникала ряд вопросов, связанных с безопасностью:

ли решение HIPAA compliance (Акт о передаче и защите данных учреждений здравоохранения) или PCI compliance (связано с оплатой в интернете)
или все порты закрыты и т. д.
Если есть проблемы с безопасностью, как бы прекрасно решение не работало, запускать его нельзя. И такое на практике случается, причем часто. Автор: Артем Маслов

Сохраните в соц.сети, ок?

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

Недоработки по безопасности также могут привести к прямым финансовым потерям. У нас был большой проект, в рамках которого клиент не утвердил бюджет на security, что в результате обошлось ему значительно дороже. Мы разработали всю инфраструктуру, описав ее как код: запускаешь один скрипт, и через несколько минут разворачивается много кластеров, все это работает и взаимодействует между собой. Но при UAT-тестирования клиент (для удобства) открыл один из портов в интернет. На работе самого приложения это никак не отразилось, однако хакеры получили возможность сломать кластер, который занимался обработкой большого объема данных, и начать майнить криптовалюту.

Поскольку по умолчанию было настроено автоматическое расширение в случае увеличения нагрузки, процессоры были загнаны по максимуму и инфраструктура расширилась, достигнув лимита облачных ресурсов. Клиент заметил это через 2 дня, когда пришел счет на 10+ тыс. долларов за использование облачной инфраструктуры.

Несет ответственность за подобные кейсы DevOps в чистом виде? Скорее всего нет, поскольку у него нет компетенций, позволяющих качественно проанализировать работу программы с точки зрения безопасности, найти все недостатки и закрыть их. Есть ли смысл каждый готовый проект отдавать на обработку инженерам по безопасности? Тоже, вероятно, нет. Остановимся на этих вопросах, прежде чем переходить к DevSecOps. Разберемся, в каких случаях связка DevOps-Engineer + Security Engineer - необходимое, а когда - неэффективна.

Почему дуэт DevOps + Security - это не всегда эффективно? И в каких случаях без инженера по безопасности не обойтись?

Прежде всего привлечения Security Engineer увеличивает продолжительность работы над проектом. Им нужно в среднем несколько недель, чтобы разобраться, как построена инфраструктура приложения, как компоненты взаимодействуют между собой, и найти пробелы в безопасности. Это увеличивает бюджет проекта, к чему клиент обычно не готов.

Основная задача Security Engineer - закрыть конкретные пробелы. Проектирование программы и сопровождение процесса разработки (в который часто клиент вносит правки и дает новые входные данные) - не его компетенция и сфера ответственности.

Исходя из этого, Security Engineer привлекаются уже после завершения работы над приложением на момент penetration testing, когда есть необходимость дополнительно проверить уязвимость из-за слишком сложную инфраструктуру и повышенные риски. Или если с самого начала не была учтена необходимость обеспечения безопасности. Также они нужны, если на проекте нет DevOps, который разбирается в вопросах безопасности.

Механика такова: если проектная команда сомневается в безопасности разработанного решения, это обсуждается с клиентом. Если у клиента нет внутренних ресурсов для проведения security assessment, согласовываем с ним отдельный бюджет на привлечение Security Team. Для сокращения времени, необходимого Security Engineer, чтобы разобраться в тонкостях работы решения, они проводят сессии с разработчиками, которые рассказывают, как работает приложение, показывают взаимосвязи между компонентами. После этого Security Engineers могут качественно протестировать как веб-, так и мобильное приложение (проверяют отдельно под каждую версию платформы iOS и Android), для выявления OWASP TOP-10 уязвимостей:

Инъекции.
Сломанная аутентификация.
Чувствительные данные воздействия.
Внешние объекты XML (XXE).
Сломанный контроль доступа.
Неправильная настройка безопасности.
Межсайтовый скриптинг (XSS).
Небезопасная десериализация.
Использование компонентов с известными уязвимостями.
Недостаточная регистрация и мониторинг.

Недавно SoftServe приобрела программу, которая анализирует полный спектр уязвимостей: приложения, базы данных, связи между компонентами и т. Д. Грубо говоря, программа натравливает различные уязвимости на компоненты программы и анализирует их реакцию. Если программа обнаружила пробелы в безопасности, Security Team совместно с разработчиками работают над тем, чтобы их закрыть.

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

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

Более того, из моей практики, могу сказать, что сам клиент редко задумывается о безопасности, пока не столкнется с какой-то ситуацией.
Решением этой проблемы является развитие компетенции DevSecOps, что сейчас является мировым трендом.

SecDevOps против DevSecOps

SecDevOps-подход предусматривает имплементацию элементов безопасности при разработке проекта. С моей точки зрения, это неэффективно по той же причине, почему нет смысла привлекать Security Team: в конце может получиться совсем не то, что планировалось изначально.

Конечно, бывают проекты, когда все очевидно с самого начала и еще до старта работы можно продумать безопасность. Например, это разработка программы, когда у тебя есть сервер, база данных, пользователи, которые логинятся на веб-приложения, и это приложение работает с этой базой данных. Тебе с самого начала все данные известны, то есть клиент уверен, что ничего нового добавляться не будет. В таких ситуациях необходимо просто Continuous Integration & Continuous Delivery процесс, чтобы запушить код в GitHub или любую другую Cloud Management System, и он обновит сервер.

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

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

Как-то мы разрабатывали веб-приложение, которое запускался на большом кластере. Клиент-за отсутствия документации, сам не до конца понимал, как оно работало. Там использовались базы данных, Big Data cluster и код, который это все запускал и разворачивал. Причем клиент предоставил исходный код. В течение нескольких недель мы разбирались с кодом и пытались воссоздать рабочий приложение, параллельно убирая баги в коде в виде прописанных паролей к базе данных в явном виде.

За несколько недель мы столкнулись с блокером, и ничего не оставалось, кроме как прийти к клиенту и сказать, что запустить код невозможно, что бы мы не делали. Оказалось, что нам просто не сообщили, что нужен еще дополнительный компонент, чтобы все заработало - analytics engine for big data processing. В таких ситуациях ты понимаешь, что потратил время зря. Теперь нужно думать, как его интегрировать. Причем сам клиент не знает, как это сделать, поскольку код писало два человека, которые ушли из компании, и проконсультироваться с ними возможности нет. Здесь явно проблема в самой разработке программы, то есть в DevOps.

А представьте, если бы на каждом этапе нужно было подключать Security Engineer? Например, он скажет, что тот же Big Data cluster или analytics engine for big data processing не покрывается решением, которое выбрали изначально. И здесь нужно думать, каким дополнительным компонентом можно закрыть этот пробел, чтобы работа инфраструктуры была в безопасности. Вы можете сначала выбрать неправильный инструмент для обеспечения безопасности, что может привести к дополнительным проблемам и усложнения инфраструктуры.

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

Как работает DevSecOps

Я с DevOps переквалифицировался в DevSecOps. Для этого начал посещать внутренние тренинги, которые организуют наши Security Engineers, изучать дополнительную информацию, чтобы понимать, какие бывают уязвимости, как они могут закрываться, на что нужно обращать внимание, если клиент работает с медицинскими данными или платежными карточками.

На этапе pre-sale в разговоре с клиентами я улавливаю моменты, которые могут быть не очевидны Architecture, Sales Manager, Project Manager.
На этапе разработки и деплоймента проекта я работаю как стандартный DevOps Engineer, анализируя связи между компонентами. Далее, в зависимости от масштабов проекта, я или сам имплементируем решения, необходимые для обеспечения полной безопасности проекта, или работаю в связке с Security Team. Рассмотрим на примерах.

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

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

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

В этом случае не было необходимости изучать, каким образом была гарантирована безопасность старого решение, поскольку я разработал полностью новую схему. Когда я это делаю сам, шаг за шагом, впоследствии можно легко проанализировать безопасность конечного продукта, выявить риски и закрыть их. В этом конкретном случае я понимал, что самое главное - закрыть доступ к системе и устранить риски взлома. Поэтому оставил возможность подключаться к серверам только из офиса клиента и офиса SoftServe. Департамент по безопасности клиента проверил новое решение на уязвимости и слабых мест не обнаружил.

Этот проект я смог сделать полностью самостоятельно, поскольку инфраструктура состояла лишь из нескольких серверов. Если разрабатывается система, которая состоит из множества серверов, баз данных, взаимодействующих между собой, необходима поддержка Security Team. Во-первых, у одного человека это займет очень много времени, во-вторых, DevSecOps-Engineer не работает ежедневно с программами для тестирования системы. В таких случаях моя роль - помочь команде по безопасности сделать работу быстрее и проще, объяснив им структуру программы и взаимосвязь между ее компонентами. Это занимает около 3 дней, после чего через несколько недель они смогут качественно ее протестировать. Если они работают самостоятельно с незнакомым проектом, это занимает больше месяца.

Выводы

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

Категория: Новости о онлайн-медиа и IT-корпорациях Ваш IP записан: 18.191.216.163 (06.06.19)