Глава 8

Обеспечение безопасности современных систем и приложений

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

• API и микросервисов;

• онлайн-хранилищ;

• контейнеров и оркестровки;

• бессерверных приложений;

• инфраструктуры как кода;

• безопасности как кода;

• платформы как безопасности;

• инфраструктуры как безопасности;

• конвейера CI/CD;

• DevSecOps;

• облака;

• облачного потока.

В этой главе рассматриваются новейшие инструменты обеспечения безопасности приложений, а также современные тактики выполнения программы безопасности приложений.

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

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

API и микросервисы

API означает программный интерфейс приложения. Однако название не очень точно отражает его суть: из него можно сделать вывод, что API – это программное обеспечение (интерфейс), которое используется для написания кода приложения (программы), но на самом деле это определение интегрированной среды разработки (IDE), а не API.

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

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

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

Под «микросервисами» часто имеется в виду «микросервисная архитектура», то есть приложение, построенное из множества небольших сервисов, вызываемых из одного интерфейса. Она показана на рис. 8.1 в упрощенном виде. Наличие набора из нескольких сервисов, работающих независимо друг от друга, означает, что если один из них выйдет из строя, то остальная часть приложения все равно (в основном) будет работать. Сервисы, как и API, не имеют графического интерфейса.

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

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

Рис. 8.1. Упрощенная архитектура микросервиса

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

Отличным инструментом для защиты микросервисов является сервисная сетка. Сервисная сетка (англ. service mesh) – это слой инфраструктуры, который помогает микросервисам быстро и надежно взаимодействовать друг с другом. Сервисная сетка нужна только в облаке и микросервисных архитектурах. Представьте себе тысячу различных сервисов для приложения, а затем сотни экземпляров каждого сервиса, работающих одновременно. Такая сложная структура требует организованности, скорости и надежности. Именно для этого и нужна сервисная сетка.

Рис. 8.2. Архитектура микросервиса с API-шлюзом

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

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

Еще один метод защиты API – обеспечить максимально строгое следование протоколу и определению API (проверка через тест). Таким образом можно избежать двусмысленности вызовов API и его переходов в неизвестное состояние из-за способа вызова.

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

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

Наконец, еще один пункт, который применим ко всем приложениям, – следует разрешить вызывать только используемые приложением HTTP-методы, а остальные заблокировать.