Программа и методика приёмочных испытаний функций информационной безопасности rest-proxy

Реквизит

Значение

Обозначение документа

___ (заготовка, напр. «ИЭП-1.ИБ.ОП1.ПМ.01.М»)

Шифр темы

___

Отчётный период

___

Листов

___

Термин / Сокращение

Определение

rest-proxy

Сервис-прокси REST API к распределённому реестру (Hyperledger Fabric)

НФТ

Нефункциональное требование — требование ТЗ по ИБ

ТЗ по ИБ

Приложение № 3 к Соглашению о соблюдении требований информационной безопасности («Требования по информационной безопасности при разработке программного обеспечения»)

Описание решений по ИБ

Документ, содержащий перечень реализованных функций информационной безопасности rest-proxy и принятых решений по задачам

CSRF

Cross-Site Request Forgery — межсайтовая подделка запроса

HPP

HTTP Parameter Pollution — атака «загрязнения» параметров HTTP

CORS

Cross-Origin Resource Sharing — механизм совместного использования ресурсов между источниками

JSON Lines

Текстовый формат хранения: по одному JSON-объекту в каждой строке

middleware

Промежуточный слой обработки HTTP-запросов

чейнкод (chaincode)

Программа, исполняющая бизнес-логику в распределённом реестре

SIEM

Система сбора и корреляции событий безопасности

X-Forwarded-For

Заголовок HTTP, содержащий исходный IP-адрес клиента при прохождении запроса через прокси

UUID

Универсальный уникальный идентификатор

«Служебная» проверка

Проверка функции, не оценивающей соответствие НФТ напрямую (документация, фиксация N/A, внутренняя инфраструктура); результат фиксируется в протоколе как факт выполнения

«Служебный» шаг

Шаг сценария, обеспечивающий подготовку условий и фиксацию состояния, не оценивающий соответствие НФТ

№ НФТ

Содержание (кратко)

1.1

Процесс разработки с учётом документов (ГОСТ Р 56939-2024, ГОСТ Р 58412-2019, ГОСТ Р 71207-2024, ГОСТ Р ИСО/МЭК 12207-2010, Метод. рекомендации, протокол Президиума Правительственной комиссии от 28.12.2022 № 60)

1.2

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

1.3

Условия использования компонентов третьих лиц

1.4

Меры при разработке исходного кода (регистрация изменений, минимальный доступ к репозиторию, ревизия прав)

1.5

Инструментальные исследования исходного кода по ГОСТ Р 56939 (статический анализ, экспертиза заимствованных компонентов, динамический анализ, фаззинг-тестирование)

1.6

Анализ защищённости каждого релиза; к приёмке — ПО без уязвимостей либо с компенсирующими мерами

1.7

Предоставление отчётных документов по результатам анализа уязвимостей

1.8

Отсутствие скрытых функциональных возможностей («программных закладок»)

1.9

Отсутствие вирусов, троянов, самоликвидирующихся механизмов

1.10

Меры защиты информации на АРМ (идентификация/аутентификация, управление доступом, регистрация событий, антивирусная защита, защита мобильных устройств, защита от утечек, защита каналов)

1.11

Подключение к инфраструктуре разработки с использованием СКЗИ

2.1

Поддержка ОС и СУБД российского производства, сертифицированных по требованиям ФСТЭК России

2.2

Технологические учётные записи — с минимально необходимыми полномочиями

2.3

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

2.4

Единый утверждённый механизм аутентификации (допускается дополнение строгой аутентификацией)

2.5

Исключение интерфейсов отладки и администрирования в обход штатной аутентификации

2.6

Контроли безопасности — только на серверной стороне

2.7

Запрет хранения ключей и секретов в коде, конфигурациях, переменных окружения; секреты — в специализированных решениях

2.8

Хранение паролей в хэшированном виде (PBKDF2 и аналоги с уникальной «солью»)

2.9

TLS-аутентификация сервисов: взаимная; проверка издателя (УЦ), валидности, субъекта сертификата

2.10

Удаление/блокировка встроенных учётных записей во всех компонентах

2.11

Новый токен при каждой аутентификации; старый становится недействительным

2.12

Хранение сессионных токенов в браузере — в защищённых cookie или хранилище сессий HTML5

2.13

Генерация сессионных токенов — надёжными криптографическими алгоритмами

2.14

Конечный срок действия токенов; недействительность по истечении и при выходе из системы

2.15

Защита от CSRF-атак

2.16

Отключение просмотра каталогов; запрет раскрытия метаданных (Thumbs.db, .DS_Store, .git, .svn)

2.17

Защита от атак «загрязнения» параметров HTTP (HPP)

2.18

Форматно-логический контроль всех поступающих данных по «белому» списку (типы, значения, параметры, заголовки, запросы, методы, cookie)

2.19

Строгая типизация структурированных данных и проверка по схеме (символы, длина, шаблон)

2.20

Нейтрализация недоверенного HTML (санитизация)

2.21

Исключение eval() и динамического исполнения кода

2.22

Нейтрализация контента на языках сценариев/шаблонов (Markdown, CSS, XSL, BBCode)

2.23

Отсутствие недокументированной или неиспользуемой функциональности

2.24

Отделение среды разработки/тестирования от продуктивной

2.25

Запрет продуктивных данных в средах разработки и тестирования

2.26

Запрет разработки и тестирования изменений на продуктивном экземпляре

2.27

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

3.1

Регистрация событий безопасности (состав, содержание, объём — по ГОСТ 59548-2022). Категории: 3.1.1 аутентификация и авторизация пользователей; 3.1.2 управление пользователями и конфигурациями; 3.1.3 управление событиями безопасности

3.2.1–3.2.21

Типы событий: 3.2.1 успешные/неуспешные аутентификации; 3.2.2 выход пользователя из ПО; 3.2.3 создание, удаление учётной записи; 3.2.4 изменение наименования учётной записи; 3.2.5 изменение пароля; 3.2.6 блокирование (отключение) учётной записи; 3.2.7 разблокировка (активация); 3.2.8 назначение, исключение, изменение прав на объект; 3.2.9 создание, удаление группы (роли); 3.2.10 изменение прав группы (роли); 3.2.11 исключение пользователя из группы (роли); 3.2.12 занесение пользователя в группу (роль); 3.2.13 ошибка обработки запроса пользователя (некорректный запрос); 3.2.14 очистка журнала аудита; 3.2.15 отключение журналирования событий информационной безопасности; 3.2.16 изменение настроек аудита (включение/отключение, уровень логирования); 3.2.17 успешное/неуспешное изменение конфигурации системы или её компонентов; 3.2.18 включение и отключение компонентов, модулей и служб ПО; 3.2.19 экспорт и импорт данных; 3.2.20 создание, удаление, изменение объектов, составляющих ПО; 3.2.21 запуск (завершение) программ и процессов (заданий, задач)

3.3

Допускается регистрация дополнительных событий безопасности

3.4.1–3.4.11

Основная информация события: 3.4.1 название и идентификатор события; 3.4.2 информация о выполненной операции (создание, изменение, удаление, просмотр); 3.4.3 точное время возникновения события; 3.4.4 информация об объекте и субъекте операции; 3.4.5 уникальный идентификатор и имя пользователя; 3.4.6 уникальный идентификатор сессии; 3.4.7 статус операции (успех/отказ); 3.4.8 описание причины неуспешности; 3.4.9 IP-адрес и имя источника информации о событии; 3.4.10 IP-адрес и имя хоста, выполнившего операцию; 3.4.11 IP-адрес и имя хоста, на котором зафиксирована операция

3.5.1–3.5.4

Дополнительная информация: 3.5.1 user-agent; 3.5.2 старые и новые значения изменённых свойств; 3.5.3 названия и идентификаторы процессов, служб, файлов, компонентов; 3.5.4 NAT IP-адрес хоста, выполнившего операцию

3.6

Хранение событий: 3.6.1 в базе данных; 3.6.2 в структурированном текстовом файле: 3.6.2.1 KeyValue; 3.6.2.2 JSON; 3.6.2.3 XML; 3.6.2.4 CSV (с любым разделителем); 3.6.2.5 CEF; 3.6.2.6 LEEF; 3.6.2.7 Windows Event Log

3.7

Срок хранения событий — не менее 14 дней

3.8

Передача событий (хотя бы одним способом): 3.8.1 Syslog; 3.8.2 Windows RPC (для Windows-ориентированных систем); 3.8.3 выгрузка из базы данных; 3.8.4 выгрузка из текстового файла; 3.8.5 через API (REST, SOAP); 3.8.6 регистрация в брокерах сообщений (Kafka, RabbitMQ)

Номер пункта методики

Функции (задачи Описания решений по ИБ)

Проверяемые НФТ

А.1.1

Задача 1 «Задокументировать архитектурное решение об отсутствии CSRF-токена»

Служебная (контекст: п. 2.15)

А.1.2

Задача 2 «Ограничить CORS AllowOrigins»

п. 2.15

А.1.3

Задача 3 «Добавить middleware проверки Origin/Referer»

п. 2.15

А.1.4

Задача 4 «Предупреждение при обнаружении cookie в запросах»

п. 2.15

А.2.1

«Задокументировать политику обработки дублирующихся параметров»

Служебная (контекст: п. 2.17)

А.2.2

«Защита от HTTP Parameter Pollution» — архитектурное исключение «исходящие вызовы» (N/A)

Служебная (фиксация N/A)

А.2.3

«Client-side HPP» (N/A)

Служебная (фиксация N/A)

А.2.4

«Валидация критичных query-параметров»

пп. 2.17, 2.18, 2.19

А.2.5

«Добавить валидацию дублирующихся ключей JSON-тела»

пп. 2.17, 2.19

А.2.6

«Создать HPP Middleware», «Зарегистрировать HPP middleware в handler/api.go»

п. 2.17

А.3.1

«Добавить событие для POST /registry/set»

пп. 3.1.2, 3.2.13, 3.2.17, 3.2.20

А.3.2

«Добавить события управления событиями безопасности (жизненный цикл)»

пп. 3.1.3, 3.2.14, 3.2.15, 3.2.16, 3.2.21

А.3.3

«Расширить auth middleware: логировать»

пп. 3.1.1, 3.2.1, 3.2.13

А.3.4

«Реализовать мониторинг потерянных событий»

п. 3.1.3

А.3.5

«Создать SecurityLoggingMiddleware для регистрации каждого запроса»

п. 3.1

А.3.6

«Создать пакет pkg/seclog — ядро журнала событий безопасности»

Служебная (инфраструктура)

А.4.1

«Создать pkg/seclog/event.go — тип SecurityEvent с 18 обязательными полями»

пп. 3.4.1–3.4.11

А.4.2

«Инициализировать actor_ip, actor_hostname, target_ip, target_hostname»

пп. 3.4.9–3.4.11

А.4.3

«Создать pkg/seclog/ip.go — корректное извлечение source_ip»

пп. 3.4.9, 3.5.4

А.4.4

«Создать pkg/seclog/writer.go — структурированная запись с корректным timestamp»

п. 3.4.3

А.5.1

«Хранение событий безопасности», «Перевести хранилище событий на JSON Lines»

пп. 3.6, 3.7, 3.8

Средство

Назначение

Тестовый стенд rest-proxy + тестовая сеть Hyperledger Fabric (или эмулятор)

Объект испытаний

curl / Postman

Выполнение HTTP-запросов к REST API

Репозиторий исходного кода rest-proxy

Проверка конфигурации, middleware, документации (README)

Средства просмотра и парсинга журналов (jq и аналог)

Анализ записей событий безопасности

SIEM/коллектор (при наличии)

Проверка передачи событий (НФТ п. 3.8)

№

Шаг

Ожидаемый результат

Ссылка

1

Открыть файл rest-proxy/README.md

Файл содержит секцию с описанием решения о защите от CSRF, в которой зафиксировано: аутентификация REST API выполняется исключительно через HTTP-заголовки (Authorization: Bearer, X-Api-Key); cookie-аутентификация не используется и не планируется; синхронизированный CSRF-токен не требуется, так как браузер не добавляет произвольные заголовки автоматически

Служебный

2

Проверить наличие оговорки о будущих изменениях

В документации зафиксировано: при введении cookie-аутентификации необходимо реализовать CSRF-токены (Double Submit Cookie или Synchronizer Token Pattern) до выкладки изменений в продуктивную среду

Служебный

№

Шаг

Ожидаемый результат

Ссылка

1

Отправить запрос к API с заголовком Origin, входящим в перечень CORS_ALLOW_ORIGINS

Ответ содержит заголовок Access-Control-Allow-Origin со значением запрошенного Origin; запрос обработан штатно

п. 2.15

2

Отправить запрос с заголовком Origin, не входящим в перечень

Ответ не содержит Access-Control-Allow-Origin (либо запрос отклонён); чтение ответа из браузера с постороннего источника невозможно

п. 2.15

3

Проверить конфигурацию CORS в handler/api.go

Значение AllowOrigins формируется из CORS_ALLOW_ORIGINS; открытое значение * (любой источник) не задано

п. 2.15

4

Проверить настройку AllowCredentials

При открытом перечне источников AllowCredentials: true не установлен

п. 2.15

№

Шаг

Ожидаемый результат

Ссылка

1

Проверить регистрацию middleware в handler/api.go

Middleware проверки Origin/Referer включён в цепочку обработки запросов

Служебный

2

Отправить запрос с заголовком Origin, отличным от разрешённого

Запрос отклонён; факт отклонения зафиксирован в журнале (с логированием)

п. 2.15

3

Отправить server-to-server запрос без заголовка Origin

Запрос пропущен (не блокируется)

п. 2.15

4

Отправить запрос с корректным Origin из перечня

Запрос пропущен

п. 2.15

№

Шаг

Ожидаемый результат

Ссылка

1

Отправить запрос к API с заголовком Cookie

Запрос обработан; в журнале зафиксировано предупреждение об обнаружении cookie в запросе

п. 2.15

2

Отправить запрос без заголовка Cookie

Предупреждение в журнале отсутствует

п. 2.15

3

Проверить ответы API на наличие Set-Cookie

API не устанавливает cookie в ответах (инвариант «cookie не используются» соблюдается)

п. 2.15

№

Шаг

Ожидаемый результат

Ссылка

1

Найти в документации rest-proxy описание политики обработки дублирующихся параметров запроса

Политика задокументирована: определено, какое значение из дублирующихся считается действующим (например, FIRST VALUE) и как регистрируется факт дублирования

Служебный

№

Шаг

Ожидаемый результат

Ссылка

1

Проверить реализацию исходящих вызовов к Hyperledger Fabric (gateway/router.go, gateway/ca.go, gateway/registry.go)

Исходящие вызовы выполняются через Fabric Gateway SDK по gRPC-протоколу; HTTP URL с query-строкой не формируются

Служебный

2

Проверить способ передачи пользовательских данных в транзакции

Пользовательские данные передаются сериализованным JSON в payload транзакции чейнкода (transient-map); инъекция через дублирование URL-параметров на уровне gateway исключена по архитектуре

Служебный

№

Шаг

Ожидаемый результат

Ссылка

1

Проверить наличие клиентской части, формирующей URL с параметрами

Клиентский интерфейс отсутствует (сервис — REST API без клиентской стороны); зафиксировать N/A для client-side HPP

Служебный

№

Шаг

Ожидаемый результат

Ссылка

1

Выполнить GET /ca/{ogrn}/accreditation/by-date с параметром accreditationID в формате UUID и корректным date

Запрос обработан штатно; возвращён результат

п. 2.19

2

Выполнить тот же запрос с accreditationID не в формате UUID

Запрос отклонён с ошибкой валидации формата

пп. 2.17, 2.19

3

Выполнить запрос с параметром date в неверном формате

Запрос отклонён с ошибкой форматно-логического контроля

п. 2.18

4

Передать orgID через query-строку

Параметр не принят из query-строки (значение берётся только из конфигурации сервиса); обход конфигурации невозможен

пп. 2.17, 2.18

5

Выполнить запрос с продублированным параметром (например, два значения date)

Обработка выполняется по задокументированной политике (А.2.1); факт дублирования зафиксирован в журнале

п. 2.17

№

Шаг

Ожидаемый результат

Ссылка

1

Выполнить POST /registry/set с JSON-телом, содержащим дублирующийся ключ (например, два ключа status с разными значениями)

Запрос отклонён с ошибкой валидации (дублирующийся ключ JSON-тела недопустим)

пп. 2.17, 2.19

2

Выполнить POST /ca/create с корректным JSON-телом без дубликатов

Запрос обработан штатно

п. 2.19

3

Выполнить POST-запрос с дублирующимся ключом к другому эндпоинту приёма данных (например, /certificate/create)

Запрос отклонён с ошибкой валидации

п. 2.17

№

Шаг

Ожидаемый результат

Ссылка

1

Проверить регистрацию HPP middleware в handler/api.go

Middleware зарегистрирован в цепочке обработки запросов

Служебный

2

Выполнить GET-запрос с продублированным query-параметром

Обработка — по задокументированной политике; факт дублирования параметра зафиксирован в журнале (попытка HPP-атаки не остаётся незамеченной)

п. 2.17

3

Выполнить GET-запрос с одиночными параметрами

Штатная обработка; записей о дублировании в журнале нет

п. 2.17

№

Шаг

Ожидаемый результат

Ссылка

1

Выполнить POST /registry/set (регистрация нового chaincode-маршрута)

Операция выполнена штатно

Служебный

2

Проверить журнал событий безопасности

Зафиксировано событие изменения конфигурации системы: указаны операция, статус, время, объект и субъект операции

пп. 3.2.17, 3.2.20

3

Выполнить POST /registry/set с некорректным запросом

В журнале зафиксировано событие ошибки обработки запроса пользователя

п. 3.2.13

№

Шаг

Ожидаемый результат

Ссылка

1

Изменить настройки аудита (включить/отключить или изменить уровень логирования)

Зафиксировано событие изменения настроек аудита

п. 3.2.16

2

Отключить журналирование событий информационной безопасности

Зафиксировано событие отключения журналирования

п. 3.2.15

3

Очистить журнал аудита

Перед очисткой зафиксировано событие очистки журнала аудита

п. 3.2.14

4

Остановить и запустить сервис (или подсистему журналирования)

Зафиксированы события запуска и завершения

п. 3.2.21

№

Шаг

Ожидаемый результат

Ссылка

1

Выполнить запрос с валидным ключом (успешная аутентификация)

В журнале зафиксировано событие успешной аутентификации (с обязательными полями записи события)

п. 3.2.1

2

Выполнить запрос с невалидным ключом (неуспешная аутентификация)

В журнале зафиксировано событие неуспешной аутентификации (с обязательными полями записи события)

п. 3.2.1

3

Выполнить запрос с некорректными данными

В журнале зафиксировано событие ошибки обработки запроса пользователя

п. 3.2.13

№

Шаг

Ожидаемый результат

Ссылка

1

Имитировать сбой канала логирования (недоступность файла/каталога хранилища)

Система фиксирует потерю событий (предупреждение/счётчик потерянных событий); события не теряются без предупреждения

п. 3.1.3

2

Восстановить канал логирования

Мониторинг фиксирует восстановление; количество потерянных событий учтено

п. 3.1.3

№

Шаг

Ожидаемый результат

Ссылка

1

Выполнить произвольный GET-запрос к API

Для запроса сформирована запись события безопасности

п. 3.1

2

Выполнить произвольный POST-запрос к API

Для запроса сформирована запись события безопасности

п. 3.1

3

Сопоставить количество выполненных запросов с количеством записей журнала

Каждому запросу соответствует запись события безопасности (пропусков нет)

п. 3.1

№

Шаг

Ожидаемый результат

Ссылка

1

Проверить состав пакета pkg/seclog

Пакет содержит компоненты формирования события (event.go), извлечения сетевых реквизитов (ip.go) и записи (writer.go)

Служебный

2

Проверить использование пакета в коде

События безопасности формируются через pkg/seclog; отдельные разрозненные вызовы логирования безопасности (вне пакета) отсутствуют

Служебный

№

Шаг

Ожидаемый результат

Ссылка

1

Извлечь запись события из журнала

Запись содержит 18 обязательных полей, раскрывающих 11 групп основной информации: название и идентификатор события; операция; точное время; объект и субъект; идентификатор и имя пользователя; идентификатор сессии; статус (успех/отказ); причина неуспеха (при отказе); IP-адрес и имя источника; IP-адрес и имя хоста, выполнившего операцию; IP-адрес и имя хоста, на котором зафиксирована операция

пп. 3.4.1–3.4.11

2

Проверить запись события неуспешной операции

Поле причины неуспешности заполнено

п. 3.4.8

3

Проверить формат временной метки

Точное время возникновения события представлено в структурированном машиночитаемом виде (RFC 3339, UTC, без долей секунды)

п. 3.4.3

4

Проверить поле статуса операции

Поле принимает значения успех/отказ; фильтрация записей по статусу выполнима

п. 3.4.7

№

Шаг

Ожидаемый результат

Ссылка

1

Выполнить запрос к API и извлечь запись события

Поля actor_ip и actor_hostname (хост, выполнивший операцию) заполнены корректными значениями

п. 3.4.10

2

Проверить целевые реквизиты той же записи

Поля target_ip и target_hostname (хост, на котором зафиксирована операция) заполнены корректными значениями

п. 3.4.11

3

Проверить реквизиты источника

Поле source_ip и имя источника информации о событии заполнены

п. 3.4.9

№

Шаг

Ожидаемый результат

Ссылка

1

Выполнить запрос к API напрямую (без прокси)

source_ip равен IP-адресу клиента

п. 3.4.9

2

Выполнить запрос через доверенный прокси с заголовком X-Forwarded-For

source_ip равен исходному IP-адресу клиента из X-Forwarded-For, а не адресу прокси или балансировщика

п. 3.4.9

3

Выполнить запрос через NAT (при наличии на стенде)

Дополнительно зафиксирован NAT IP-адрес хоста, выполнившего операцию

п. 3.5.4

№

Шаг

Ожидаемый результат

Ссылка

1

Извлечь запись события из хранилища

Запись структурирована (JSON); временная метка представлена структурированным полем, а не строкой внутри текстового сообщения

п. 3.4.3

2

Разобрать запись стандартным JSON-парсером

Запись разбирается без ошибок; временная метка интерпретируется как момент времени

п. 3.4.3

№

Шаг

Ожидаемый результат

Ссылка

1

Открыть файл хранилища событий безопасности

Записи хранятся в текстовом файле в структурированном формате: по одному JSON-объекту в строке (JSON Lines)

п. 3.6.2.2

2

Проверить каждую строку хранилища

Каждая строка — валидный JSON-объект; формат записи не является текстовым форматом logrus TextFormatter

п. 3.6

3

Проверить срок хранения событий

Конфигурация/политика хранилища обеспечивает хранение событий не менее 14 дней

п. 3.7

4

Проверить доступность событий для передачи

События могут быть выгружены из текстового файла (и/или переданы одним из способов: Syslog, API, брокер сообщений)

п. 3.8

Реквизит

Значение

Номер протокола

___

Дата

«» ___________ 20 г.

Объект испытаний

Функциональность информационной безопасности rest-proxy

Документы, на соответствие которым проводились испытания

ТЗ по ИБ (Приложение № 3 к Соглашению); Описание решений по ИБ

Испытания проводились

с «» ___________ 20 г. по «» ___________ 20 г.

Место проведения

___

Состав комиссии

___

Среда испытаний

Тестовый стенд (эмуляторы: ___)

№ проверки (пункт методики)

Результат (соответствует / не соответствует)

Примечание

А.1.1

___

___

…

…

…

А.5.1

___

___

Роль

Подпись

ФИО

Председатель комиссии

Член комиссии

Член комиссии

Роль

Подпись

ФИО