On-premise или облако для AppSec-инструментов: критерии выбора для банков и госсектора

Для банков и государственных организаций Центральной Азии по умолчанию безопаснее и проще согласовать установку AppSec-инструментов в собственном контуре (on-premise): исходный код и данные об уязвимостях не покидают периметр. Облако выигрывает в скорости запуска и затратах на эксплуатацию и подходит там, где нет жёстких требований к размещению кода и данных. Решение принимают не по моде, а по набору критериев, которые разобраны ниже.

Что именно уходит в инструмент безопасности

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

• SAST анализирует исходный или бинарный код — это самый чувствительный актив разработки: логика бизнес-процессов, интеграции, иногда непреднамеренно оставленные в коде секреты;
• SCA работает в основном с перечнем зависимостей (манифесты, SBOM), что значительно менее чувствительно, но тоже раскрывает состав и версии ПО;
• DAST обращается к работающим приложениям и обрабатывает ответы и параметры запросов;
• результаты сканирования сами по себе — карта уязвимостей организации, которую нельзя оставлять в открытом доступе.

Поэтому один и тот же банк может спокойно использовать облачный сервис для SCA и требовать локальной установки для SAST. Классы инструментов описаны в статье «SAST, DAST, SCA и MAST».

Критерии выбора

1. Регуляторные и внутренние требования к размещению данных

В странах региона действуют требования к хранению персональных данных, отраслевые правила регуляторов финансового сектора и внутренние политики информационной безопасности банков и госорганов. Например, закон Республики Казахстан «О персональных данных и их защите» предусматривает хранение персональных данных в базах, находящихся на территории страны (в публикациях это связывают со статьёй 12 закона — точную редакцию проверяйте на adilet.zan.kz). Если исходный код или результаты сканирования содержат такие данные либо политика банка запрещает вывод кода за периметр, вариант с зарубежным облаком снимается сразу. Требования в каждой стране свои — сверяйтесь с действующими актами и консультируйтесь с юристами. Мы не даём здесь юридических заключений: это общий ориентир для обсуждения.

2. Чувствительность кода и модель угроз

Спросите себя: что случится, если исходный код или карта уязвимостей окажутся у третьих лиц? Для платёжных систем, процессинга и систем с персональными данными граждан ответ обычно «неприемлемо». Для маркетингового сайта или внутреннего прототипа — допустимо. Облачный сервис может быть надёжно защищён, но вы добавляете в цепочку ещё одну организацию с доступом к активам.

3. Изоляция сети и работа без интернета

Многие критичные контуры работают в сегментах без доступа в интернет. Для них нужна возможность полностью автономной работы, включая получение обновлений баз правил и уязвимостей по контролируемому каналу. Например, Sonatype указывает, что Nexus Repository можно использовать как управляемый облачный сервис, как самостоятельно развёрнутое решение в дата-центре или облаке либо в режиме для изолированных (air-gapped) сред. Платформа DerScanner поставляется в варианте on-premise. Подробности лицензирования и условий обновлений уточняйте у нас.

4. Требования аудиторов и регуляторов к контролю

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

5. Скорость запуска

Облако запускается быстрее: нет закупки серверов, согласования инфраструктуры, развёртывания и настройки. Для пилота это серьёзное преимущество. Но если для облака потребуется месяцы согласований с ИБ и юристами, выигрыш во времени исчезает.

6. Эксплуатация и нагрузка на команду

On-premise требует серверов, администрирования, обновлений, резервного копирования, мониторинга и квалифицированных людей. В облаке эти работы выполняет вендор. Если в банке уже есть зрелая команда эксплуатации и инфраструктура, дополнительная нагрузка небольшая; если нет — это реальная статья расходов.

7. Стоимость

Облако переводит затраты в операционные (подписка) и убирает капитальные вложения в инфраструктуру. On-premise требует вложений в оборудование и людей, но может быть выгоднее на больших объёмах и длительном горизонте. Сравнивайте полную стоимость владения, а не только цену лицензии (см. структуру бюджета DevSecOps).

8. Масштабируемость и доступность

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

Сравнение в одном списке

• Контроль над кодом и данными: on-premise — полный; облако — ограничен договором и мерами вендора.
• Работа в изолированном контуре: on-premise — возможна; облако — нет.
• Скорость запуска: on-premise — дольше; облако — быстрее.
• Нагрузка на эксплуатацию: on-premise — на вас; облако — на вендоре.
• Затраты: on-premise — оборудование и люди; облако — подписка.
• Прохождение согласований ИБ: on-premise — обычно проще для банков и госсектора; облако — требует отдельной оценки поставщика.

Гибридный подход

На практике многие организации не выбирают что-то одно. Типичная схема: SAST и репозиторий артефактов — в собственном контуре, потому что они работают с исходным кодом и артефактами сборки; облачные сервисы — для некритичных проектов, пилотов и внешнего DAST-сканирования периметра. Главное — зафиксировать правило: какие классы систем разрешено обрабатывать в облаке, а какие нет.

Как принять решение: короткий алгоритм

1. Классифицируйте системы по критичности и типам обрабатываемых данных.
2. Выпишите обязательные требования: закон, регулятор, внутренняя политика, договоры.
3. Для систем с жёсткими ограничениями выберите on-premise, для остальных рассмотрите облако.
4. Проверьте у поставщика поддержку нужной модели размещения и порядок обновлений в закрытом контуре.
5. Проведите пилот в той модели, в которой будете работать в промышленной эксплуатации (с чего начать).

Вопросы вендору перед выбором модели

Независимо от выбранной модели, задайте поставщику конкретные вопросы и зафиксируйте ответы письменно:

• Какие данные передаются на сторону вендора при каждом режиме работы и можно ли это отключить?
• Как доставляются обновления баз правил и уязвимостей в закрытом контуре и с какой периодичностью?
• Какие требования к серверам, СУБД и ОС для установки у вас, как масштабируется решение?
• Как организована техническая поддержка для закрытых сред — удалённый доступ невозможен, как решаются инциденты?
• Что будет с данными при расторжении договора: сроки хранения и удаления?
• Какой путь миграции между облаком и локальной установкой, если требования изменятся?

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

Особенности региона

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

Частые вопросы

Источники

• Sonatype: Nexus Repository — варианты развёртывания
• Digital Business: Как МСБ сэкономить на ИТ и защитить данные (о локализации данных в Казахстане)