2 Нормативная база и требования к серверной части платформы

2.1 Заинтересованные стороны и сценарии использования

Для корректной постановки требований проведён анализ ролей пользователей и их целей. Выделены четыре основные роли:

• Студент — получает назначенные его группе материалы и лабораторные среды, выполняет задания в отведённое время;
• Преподаватель — формирует структуру дисциплины и банк вопросов, назначает задания группам, отслеживает успеваемость;
• Модератор — сопровождает учебный процесс в рамках закреплённых групп: проверяет работы и модерирует материалы, но не управляет системными настройками платформы;
• Администратор — управляет учётными записями, глобальными правами и состоянием инфраструктуры.

Интересы ролей частично конфликтуют: удобство (быстрый запуск среды, минимум ограничений) противопоставлено контролю (строгая изоляция, проверяемость действий, минимум привилегий). Задача проектирования состоит в том, чтобы разрешить этот конфликт архитектурно, а не организационными мерами.

Типовые сценарии использования по ролям:

Студент:

• доступ только к материалам, официально назначенным его группе;
• запуск лабораторной среды «в один клик»;
• получение обратной связи о состоянии ресурсов и результатах тестов.

Преподаватель:

• формирование структуры курса и управление банком вопросов;
• мониторинг активности студентов и автоматизированное формирование отчётности по успеваемости;
• управление параметрами сложности лабораторных работ.

Администратор:

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

Связь основных сущностей платформы и ролей представлена на рисунке 2.1.

%%{init: {"theme": "neutral", "themeVariables": {"fontFamily": "Times New Roman, serif"}}}%%
flowchart TD
    User[Пользователь] -->|"входит в"| Group[Учебная группа]
    Group -->|"назначена"| Topic[Учебная дисциплина]
    Topic -->|"содержит"| Section[Раздел и материалы]
    Section -->|"включает"| Test[Тест]
    User -->|"имеет"| Role[Роль]
    Role -->|"через группу доступа даёт"| Capability[Полномочие]
    Capability -->|"проверяется при доступе к"| Resource[Учебный ресурс]
    Topic -.->|"запуск (проектируемое)"| Lab[Лабораторная среда]

Рисунок 2.1 — Схема логических связей объектов платформы

2.2 Нормативная база

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

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

Состав организационных и технических мер защиты задаётся требованиями ФСТЭК России. Приказ № 17 6, устанавливающий требования к защите информации, не составляющей государственную тайну, используется как методическая основа выбора и систематизации мер защиты. Из предусмотренных групп мер для серверной части наиболее существенны идентификация и аутентификация субъектов доступа, управление доступом (разграничение прав), регистрация событий безопасности (аудит) и обеспечение целостности информации.

При создании автоматизированной системы в защищённом исполнении учитываются положения ГОСТ Р 51583 3; организация процессов управления информационной безопасностью опирается на ГОСТ Р ИСО/МЭК 27001 4; поскольку разрабатывается программное обеспечение, обрабатывающее защищаемую информацию, применимы рекомендации ГОСТ Р 58412 по разработке безопасного ПО 5. Перечисленные нормативные положения далее конкретизируются в функциональных и нефункциональных требованиях к серверной части.

2.3 Функциональные требования

На основании анализа ролей и сценариев использования (подраздел 2.1), а также нормативных требований (подраздел 2.2) сформулированы ключевые функциональные требования (ФТ) к серверной части. Требования формулируются применительно к серверной части: операции с вычислительной инфраструктурой рассматриваются в той части, которую серверная часть инициирует и контролирует, тогда как их низкоуровневое исполнение относится к инфраструктурному контуру.

• ФТ-1. Аутентификация пользователей через внешнего поставщика аутентификации и авторизация по ролям «студент», «преподаватель», «модератор», «администратор».
• ФТ-2. Управление учебными сущностями: курсами, темами (дисциплинами), банком вопросов и назначением материалов учебным группам.
• ФТ-3. Постановка серверной частью задач на запуск и остановку изолированных лабораторных сред по запросу пользователя с последующим контролем их статуса.
• ФТ-4. Передача инфраструктурному слою параметров изоляции лабораторной сессии (выделенное пространство имён, сетевые политики) и фиксация результата на стороне серверной части.
• ФТ-5. Разграничение доступа к ресурсам на основе ролей и атрибутов (сочетание моделей RBAC и ABAC).
• ФТ-6. Централизованный аудит операций управления и доступа с фиксацией субъекта, времени и типа действия.
• ФТ-7. Предоставление клиентской части программного интерфейса (API) и набора эффективных прав пользователя для управления отображением элементов.

Перечисленные требования определяют состав серверных модулей: модуль аутентификации и сессий (ФТ-1, ФТ-7), модуль управления учебными материалами (ФТ-2), контроллер постановки инфраструктурных задач (ФТ-3, ФТ-4), подсистему разграничения доступа (ФТ-5) и подсистему аудита (ФТ-6). Проектирование этих модулей рассматривается в главе 3.

2.4 Нефункциональные требования

Нефункциональные требования (НФТ) сформулированы в измеримой форме как проектные критерии приёмки серверной части.

• НФТ-1 (производительность). Медианное время ответа API при штатной нагрузке не превышает 250 мс; накладные расходы серверной части на постановку инфраструктурной задачи — не более 150 мс.
• НФТ-2 (масштабируемость). Поддержка не менее 100 одновременных пользователей на один экземпляр управления без отказов; архитектура допускает горизонтальное масштабирование сервисов.
• НФТ-3 (изоляция и безопасность). Проверка прав доступа выполняется на стороне сервера для каждого вызова API (конструктивная безопасность); серверная часть не допускает обращений к ресурсам в обход подсистемы разграничения доступа.
• НФТ-4 (отказоустойчивость). Сбой отдельного сервиса (например, модуля тестирования) не приводит к потере управляемости платформой и не останавливает уже запущенные лабораторные среды.
• НФТ-5 (наблюдаемость и аудит). Все критичные действия фиксируются в журнале с указанием субъекта, времени и типа операции; доступны метрики для выявления аномального поведения.
• НФТ-6 (соответствие требованиям защиты). Реализация мер идентификации, разграничения доступа и регистрации событий согласуется с требованиями ФСТЭК 6; при проектировании контейнерной среды учитываются рекомендации NIST SP 800-190 15 и SP 800-204 16.

2.5 Модель угроз

Специфика лабораторного комплекса по ИБ заключается в том, что система сознательно провоцирует пользователя на агрессивные действия в рамках выполнения заданий, поэтому граница между «учебным действием» и «атакой на платформу» оказывается размытой. Моделирование угроз выполнено в соответствии с Методикой оценки угроз безопасности информации ФСТЭК России 7. В соответствии с методикой определены негативные последствия (нарушение конфиденциальности заданий и эталонных ответов, целостности оценок и учебных материалов, доступности платформы), объекты воздействия со стороны серверной части (программный интерфейс, серверные сессии и токены, база данных, подсистема разграничения доступа, очередь задач) и источники угроз — нарушители.

В качестве актуальных рассматриваются внутренние нарушители с низким потенциалом — обучающиеся, обладающие легитимным доступом к платформе и к инструментам лабораторных работ. Внешние нарушители с высоким потенциалом в базовой модели не рассматриваются, поскольку платформа развёртывается в контролируемом контуре образовательной организации. Перечень актуальных угроз серверной части сформирован с опорой на Банк данных угроз безопасности информации ФСТЭК России (БДУ) 8 и приведён в таблице 2.1.

Таблица 2.1 — Актуальные угрозы безопасности серверной части и контрмеры

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

2.6 Критерии выбора архитектуры

Выбор архитектуры серверной части не является исключительно технической задачей: он определяется сформулированными выше требованиями (подразделы 2.3, 2.4). Из них вытекают ключевые критерии оценки рассмотренных в подразделе 1.3 архитектурных подходов:

• Контролируемость границ доверия (НФТ-3) — чёткое определение прав и зоны ответственности каждого компонента, возможность локализовать компрометацию.
• Масштабируемость фоновых операций (НФТ-2) — вынос создания лабораторных сред в асинхронный контур без деградации интерфейса.
• Независимость развития подсистем (НФТ-4) — обновление модулей без остановки всей платформы и без влияния на запущенные среды.
• Прозрачность контрактов API (ФТ-7) — строгое соответствие между клиентской и серверной частями.

2.7 Сравнение подходов и выбор

Сравнение архитектурных подходов по выделенным критериям приведено в таблице 2.2.

Таблица 2.2 — Сравнительный анализ архитектурных подходов

Как показывает сравнение, требованиям к изоляции (НФТ-3), масштабируемости (НФТ-2) и независимости развития подсистем (НФТ-4) в наибольшей степени отвечает микросервисная архитектура, которая и принята в качестве целевой для серверной части платформы.

Во второй главе на основе анализа заинтересованных сторон и нормативной базы (Федеральный закон № 149-ФЗ, требования ФСТЭК, ГОСТ) сформулированы функциональные и измеримые нефункциональные требования к серверной части, а угрозы безопасности систематизированы по Методике оценки угроз ФСТЭК России с акцентом на серверные объекты воздействия. На основе требований обоснован выбор микросервисной архитектуры как наиболее отвечающей условиям изоляции, масштабируемости и независимости развития подсистем. Полученные требования, модель угроз и обоснованная архитектура образуют исходные данные для проектирования серверной части в третьей главе.