🤔 WSO2 InfoSec Reco

Салют, давай в догонку, с тобой, ко вчерашнему посту, посмотрим на требования ИБ, которые помогут нам при интеграциях.

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

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

• Учитывать стандарты безопасности Открытых API

— СТО БР ФАПИ.СЕК‑1.6‑2024 (безопасность OpenID API)

— СТО БР ФАПИ.ПАОК‑1.0‑2024 (аутентификация по отдельному каналу)

• ГОСТ 57580.1 и процессы

— Для фин информации и ПДн применять состав мер ГОСТ 57580.1: защита каналов, контроль доступа, регистрация событий, управление уязвимостями, обеспечение целостности и актуальности ПО

— Логи WSO2 и бэкенд‑сервисов по API должны попадать в централизованный журнал

— Для каждого API, обрабатывающего ПДн, должна быть проведена оценка рисков ИБ в рамках 57580.1 и внутренних политик по 152‑ФЗ

• Требования по персональным данным

— Факт передачи ПДн через WSO2 должен быть отражён в договорных документах и в перечне информационных систем ПДн, и трансграничных передач

— Внутренние документы должны описывать порядок уведомления Роскомнадзора об инцидентах с ПДн (72 часа на расследование и отчёт) и ответственность ролей

— Для API, где минимально возможен объём ПДн, следует применять минимизацию, маскировку и обезличивание: передавать только необходимый набор атрибутов, а также, где можно, использовать токены/ псевдонимы вместо прямых идентификаторов клиента

• Архитектурные требования

— Настроить WSO2 с использованием HTTPS/ TLS 1.2+ с Forward Secrecy для всех публичных endpoint’ов, включить проверку клиентских сертификатов, если используется mutual TLS

— Использовать OAuth 2.0 + OpenID Connect как основной механизм аутентификации клиентов API (в соответствии с ФАПИ.СЕК), ограничивать доступ по scope/ role и, при необходимости, по IP/ ASN

— Обеспечить защиту от типичных атак на API: rate limiting, throttling, защита от replay‑атак, CSRF, injection, а также валидацию схемы JSON/ REST

• Дополнение

— Для каждого интеграционного кейса должна быть выполнена модель угроз и оценка рисков с фиксацией мер защиты в архитектуре

— Необходим отдельный регламент «Управление внешними интеграциями», описывающий: жизненный цикл API, ответственность Integration Layer, порядок ревью ИБ и архитекторов, требования к логированию и мониторингу

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

— Доступ с BYOD во внутренний контур должен быть ограничен путем контроля привелегированных пользователей путем Segregation-of-Duties

— Необходимо реализовать отсутствие прав доступа во внутренним системам

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

— Все файлы, которые передаются (также для последующих случаев - в обе стороны, если будут использоваться) должны быть зашифрованы и проходить через песочницу

— Доступ к данным по id из внешнего периметра должен исключать инкрементальный id

— При проектировании API через WSO2 ориентироваться на профили безопасности OpenID/ OAuth2: обязательно TLS, защищённое хранение и передача токенов, защита от подмены запросов/ ответов

#reco #devsecops #pmicases #specialty #techsolution #compliance #paper