Как достичь безопасной работы онлайн-сервисов

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

Но сначала я включу режим Капитана Очевидности и акцентирую внимание на некоторых общеизвестных постулатах:

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

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

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

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

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

Эффективны ли они? Да.

Используются они повсеместно? Нет.

Что может мешать применять эти практики? Ответ — лень и оптимизм.

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

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

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

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

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

В этом году мы запустили платформу TuchaKube, которая обеспечивает целый ряд функций. Зачастую самостоятельное внедрение таких функций требует длительной и кропотливой работы, осмысления множества принципиально новых понятий, а также мучительных поисков ответа на вопрос: «А зачем мне это нужно?». И эти функции касаются не только безопасности. Платформа обеспечивает такие вещи, как:

• мониторинг огромного количества метрик;
• автоматическое горизонтальное масштабирование (путём создания на различных вычислительных узлах нужного количества одинаковых контейнеров с учётом текущей нагрузки);
• автоматический выпуск сертификатов для TLS-соединений;
• автоматизацию функций DevOps.

Ещё с прошлого года, благодаря пожеланиям некоторых партнёров нашей компании, мы столкнулись с необходимостью решить задачи по обеспечению автоматизации CI/CD-процессов. Это привело нас к плотному использования Docker-контейнеров, а затем — и к использованию системы оркестрации Kubernetes. Накопив достаточное количество практического опыта, мы решили этот опыт систематизировать и извлечь из него дополнительную пользу для всех: именно так и появилась революционная платформа TuchaKube.