Безопасность PROD-уровня. Масштабная, но захватывающая воображение задача

BIS Journal №1(44)/2022

3 марта, 2022

Безопасность PROD-уровня. Масштабная, но захватывающая воображение задача

Цифровая трансформация делает классические не ИТ-компании провайдерами цифровых услуг для правительства, клиентов и сотрудников. Это значит, что компаниям придётся внедрить практики управления приложениями, что позволит оказывать таковые услуги с заданным уровнем сервиса – будь то классическая доступность, время генерации счёта, время формирования квоты или любой другой важный для цифрового потребителя параметр.

Одной из фундаментальных практик управления приложениями является разделение ИТ-ландшафта на среды. Выросшие из классических инфраструктурных задач подразделения информационной безопасности обычно знают три таких среды – PROD/TEST/DEV. Однако для по-настоящему крупных цифровых сервисов с миллионами клиентов онлайн три среды недостаточно, и необходимо внедрять дополнительные.

 

ДОПОЛНИТЕЛЬНЫЕ СРЕДЫ ДЛЯ УПРАВЛЕНИЯ ПРИЛОЖЕНИЯМИ

Mirror-среда. Дублирует PROD, как и PROD, содержит клиентские данные, позволяет воссоздать инцидент недоступности сервиса или его компонента контролируемым образом. Требует применений тех же контролей безопасности и с такой же частотой, что и PROD.

Pre-prod-среда. Максимально близка к prod, но не содержит клиентских данных. Между pre-prod и PROD разумно организовать ворота безопасности (security gate), например, сканируя конфигурации и образы Docker на наличие уязвимостей и соответствие требованиям безопасности. Тут же оптимально проводить тесты на проникновение и сканирование на уязвимости.

Obfuscation-среда. Позволяет провести обфускацию клиентских данных для передачи обфусцированных данных вне контура с клиентскими данными.

DR-среды. Дублируют PROD и готовы подхватить задачи PROD в случае значительных проблем.

 

МЕХАНИЗМЫ СИНХРОНИЗАЦИИ КИБЕРБЕЗОПАСНОСТИ С УПРАВЛЕНИЕМ ПРИЛОЖЕНИЯМИ

Change Advisory Board. Комитет по согласованию изменений, рекомендуется ITIL, в случае наличия изменений, драйвером которых выступает служба ИБ, приглашает представителя службы ИБ. В случае отказа в согласовании такого изменения служба ИБ запускает процесс риск-менеджмента, дабы документировать отказ и бизнес-причины для него и проверить наличие спонсора принятия риска, например представителя высшего руководства.

Promotion. Постепенное тестирование всех вносимых изменений на каждой из сред, пока изменение не будет внесено в PROD.

Production Schedule. Расписание внесений изменений в PROD. Важно планировать окна обслуживания для применения фиксов безопасности наперёд.

Verification. Проверка исполнения изменения, например, фикса log4j путём сканирования Qualys/Nessus.

Passive/Active Security Gates. Пассивный (мониторинговый) режим работы ворот безопасности и активный. В пассивном режиме повышение фикса не блокируется в случае наличия критических проблем с безопасностью. А в активном режиме – блокируется.

Proactive Security. Подход проверки безопасности, например, безопасности кода (SAST, SCA) на ранних средах, с изменением режима работы ворот безопасности по мере приближения к PROD.

Security Patching timelines. Формальные обязательства службы управления приложения перед службой ИБ по применению фиксов в случае наличия уязвимостей различного уровня. Например, High/Critical CVSS – 14 календарных дней.

Ticket. Заявка в используемой службой поддержки системе HelpDesk позволяет отслеживать количество запросов ИБ и одновременно оперативность их обработки службой управления приложениями.

Security Officer. Отвечающий за безопасность крупного приложения (ERP, BSS, core banking system) специалист координирует работу различных служб по обеспечению безопасности. Может быть специалистом по ИБ, в случае отсутствия такового эта функция так или иначе оказывается на директоре по управлению приложениями.

 

ТИПОВЫЕ МЕРЫ БЕЗОПАСНОСТИ ДЛЯ КРУПНЫХ ПРИЛОЖЕНИЙ

Мониторинг безопасности. Применение известных HIDS/EDR, SIEM и Vulnerability Scanning, Penetration Testing для мониторинга серверов крупных приложений.

Application Security. Применение классических SAST, SCA и обучения разработчиков, постепенное включение крупных приложений в процессы Application Security.

Container Security. Набор практик по обеспечению безопасности контейнеризованных приложений, в том числе управляемых с помощью Kubernetes/OpenShift. Традиционно включает сканирование образов контейнеров, мониторинг активности контейнеров (runtime security), харденинг кластеров Kubernetes/OpenShift, управление привилегиями ролей внутри кластеров Kubernetes/OpenShift, сканирование конфигурации Kubernetes/OpenShift на предмет проблем безопасности (IaaC Security).

Cloud Security. Набор практик по обеспечению безопасности используемых облачных провайдеров (AWS/Azure/GCP/Alibaba). Включает в себя мониторинг безопасности облака (встроенные Defender/GuardDuty/Security Hub, отдельные средства CSPM), управление секретами/API ключами (Secrets Management – Vaults, Hashicorp Vault), IaaC Security, Cloud IAM.

 

ЗАКЛЮЧЕНИЕ

Обеспечение безопасности крупного приложения – масштабная, но захватывающая воображение задача. Возможно, главное – беспощадная приоритизация подзадач и построение продуктивных рабочих взаимоотношений со службами потребителями безопасности (бизнес, юристы) и службами поставщиками тех или иных сервисов безопасности – AppSec, SOC, DevOps, administrators.

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

01.03.2024
Банки будут строже следить за криптотранзакциями, связанными с дропперами
01.03.2024
Холода прошли, но голос берегите — скамеры усиленно собирают слепки
01.03.2024
Лишение банковской лицензии — это ещё не всё
01.03.2024
«Они подобны смартфонам на колёсах». В США проверят «умные» авто из Китая
01.03.2024
Набиуллина: Дважды «красные» клиенты будут исключаться из реестра
01.03.2024
Банк России усовершенствует платформу цифрового рубля
01.03.2024
Организации здравоохранения США стали жертвами массовых кибератак
29.02.2024
«ИнфоТеКС» — о проблемах стандартизации ИБ
29.02.2024
Почему нормативные акты выполняются формально
29.02.2024
Почему затянулся переход на российские решения

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных