Опубликовано: 03.10.2026 | Источник: SecurityLab (RSS)

Доступ к коммерческим спутниковым данным в ВКР: разграничение прав, Zero Trust и метрики защиты

26 марта 2026 года SecurityLab сообщил: частные спутниковые операторы свернули доступ СМИ к свежим снимкам, а приоритет отдали заказчикам из Пентагона. Геопространственная аналитика по Ближнему Востоку окончательно стала платной подпиской. Для выпускника ИТ это не «новость про политику», а прямой сигнал: открытых данных становится меньше, а значит каждый проект, который их потребляет, обязан доказывать право доступа. Если ваша работа касается ГИС, BI-платформ, облачных хранилищ или импортозамещённых сервисов — тема разграничения прав превращается из «приятного бонуса» в ядро исследования. Ниже — как превратить этот кейс в защищаемую ВКР, какие стандарты подтянуть и какие метрики посчитать, чтобы комиссия увидела инженера, а не пересказчика новостей.

Где брать данные, если реальные снимки закрыты и стоят денег?

Не нужны закрытые сцены. Берите открытые архивы: Sentinel-2 (ESA, Copernicus), Landsat 8/9 (USGS), OSM для векторных слоёв, STAC-каталоги для метаданных. Для ВКР важен не «шпионский» снимок, а воспроизводимый конвейер: получение → нормализация метаданных → проверка лицензии → выдача по токену. Синтетику для нагрузочных тестов генерируйте сами — комиссия это принимает, если описана методика генерации.

Что выбрать: писать свой IAM или взять Keycloak?

Свой IAM — это минус три месяца жизни и плюс три главы вместо двух. Возьмите Keycloak или Ory как поставщика идентичности, а научную новизну стройте на политике доступа: ABAC-правила, привязка к региону, классификации и сроку лицензии. Тогда в главе 2 у вас архитектура, а не самодельный JWT-велосипед.

Как оценить эффективность защиты, если реальных атак нет?

Считайте не «число отражённых атак», а операционные метрики: долю отказов в доступе по политике, среднее время реакции на инцидент (MTTA/MTTR), задержку проверки авторизации (p95), покрытие событий аудитом. Плюс экономику: TCO решения против ручного согласования заявок. Методику опишите в главе 3, а исходные значения — в приложении.

Обязателен ли ГОСТ 34 или можно обойтись ISO?

Смотрите требования кафедры. Классическая связка: ГОСТ 34.601 для стадий создания системы и ГОСТ 19.701 для схем, а ISO/IEC 25010 — для нефункциональных требований (безопасность, производительность, сопровождаемость). Не выдумывайте «ГОСТ 34.2024» — таких документов нет, и нормоконтролёр это заметит.

Три темы ВКР, которые вырастают из этой новости

• 1. Разграничение доступа к геопространственным данным на базе ABAC и OPA

  Актуальность: операторы спутников ограничивают выдачу по корпоративным подпискам, значит ролевой модели «админ/пользователь» уже мало — нужны атрибуты региона, уровня допуска и срока лицензии.

  Цель: спроектировать и оценить сервис авторизации доступа к тайловому ГИС-серверу.

  Задачи: обзор моделей RBAC/ABAC; формализация политик в Rego; интеграция с Keycloak; нагрузочное тестирование и метрики задержки.

  Структура: Глава 1 — анализ моделей доступа и стандартов; Глава 2 — архитектура (C4 + диаграмма последовательности UML); Глава 3 — тестирование, p95 задержки, покрытие политик тестами.

• 2. Подписочная модель доступа к спутниковым продуктам: лицензии, биллинг, аудит

  Актуальность: данные продают по подписке, а значит нужен учёт лицензий и журнал выдачи — иначе спор с поставщиком не выиграть.

  Цель: построить сервис управления лицензиями с неизменяемым аудитом.

  Задачи: модель лицензий и квот; протокол выдачи токенов; журнал событий с защитой от подмены; расчёт TCO.

  Структура: Глава 1 — рынок коммерческих данных и требования; Глава 2 — проектирование (BPMN процесса заявки); Глава 3 — оценка эффективности и стоимость владения.

• 3. Мониторинг аномалий доступа к ГИС-сервису через OpenTelemetry

  Актуальность: утечка геоданных — это утечка разведданных; аномальные скачивания нужно ловить в реальном времени, а не в квартальном отчёте.

  Цель: собрать наблюдаемость по трассировкам и метрикам, детектировать нетипичный доступ.

  Задачи: инструментирование сервиса; правила детекции (пороговые и статистические); дашборды; оценка точности детектора (precision/recall).

  Структура: Глава 1 — анализ угроз и ISO/IEC 27001; Глава 2 — схема телеметрии и хранилище; Глава 3 — эксперимент и матрица ошибок.

Как встроить кейс в главу 1: не пересказ, а постановка задачи

Новость из SecurityLab — это ваш «повод», а не содержание. В аналитической главе она занимает один абзац и превращается в ограничения: доступ к свежим сценам — по контракту, распространение — по лицензии, часть территорий закрыта. Дальше идёт теория: модели доступа (DAC, MAC, RBAC, ABAC), принцип наименьших привилегий, Zero Trust с его «никогда не доверяй, всегда проверяй». Обязательно свяжите это с требованиями ISO/IEC 25010 — безопасность и сопровождаемость там описаны как измеримые характеристики, а не как лозунги. И зафиксируйте перечень угроз: несанкционированная выгрузка тайлов, повторное использование токена, обход лицензионного ограничения по региону.

Полезный приём для защиты: постройте матрицу «угроза → мера → метрика проверки». Комиссия любит, когда каждая мера имеет числовой критерий.

Глава 2: архитектура и политики доступа

Схемы, которые стоит нарисовать

Минимум три диаграммы: контекстная C4 (кто снаружи обращается к сервису), диаграмма последовательности UML для сценария «СМИ запрашивает снимок», и схема развёртывания (Keycloak, PDP-сервис на политиках, тайловый сервер, объектное хранилище, сборщик телеметрии). Схемы оформляйте по ГОСТ 19.701 — единый стиль рамок и подписей, нумерация, перечень элементов.

# Упрощённая архитектура (ASCII)

[Клиент/СМИ] --HTTPS--> [API Gateway] --JWT--> [PDP: OPA + Rego]
                              |                      |
                              |                      +--> [Keycloak: identity & roles]
                              v
                       [Tile Service] --RBAC/ABAC check--> [Geo Store (S3-совместимый)]
                              |
                              +--> [OTel Collector] --> [Metrics/Traces/Loki]

Политика доступа: пример, который можно защитить

Пишите политику декларативно: логика отделена от кода, её видно эксперту и её можно протестировать юнит-тестами. Это ровно тот аргумент, который отличает инженерную ВКР от «сделал форму логина».

package geo.authz

default allow = false

allow {
  input.user.tier == "press"
  input.asset.classification == "public"
  not input.asset.region in input.user.blocked_regions
}

allow {
  input.user.clearance >= input.asset.required_clearance
  input.license.expires_at > time.now_ns()
  input.license.scope contains input.asset.sensor_id
}

# Отказ должен логироваться так же подробно, как разрешение
reason = "license_expired" {
  input.license.expires_at < time.now_ns()
}

Обратите внимание на последний блок: отказ — тоже событие аудита. В работе по ИБ это ценится выше, чем красивая схема.

Глава 3: метрики, эксперимент, экономика

Здесь чаще всего проваливаются. Студент пишет «система эффективна», а цифр нет. Возьмите набор метрик и посчитайте их на своём стенде — хотя бы на виртуальной машине с генератором нагрузки.

Для оценки экономики не нужно считать «миллионы корпорации». Сравните два сценария: ручное согласование заявок на доступ (часы аналитика) и автоматическая выдача по политике. Разница в человеко-часах за год — это и есть ваш измеримый эффект.

Чему вы научитесь на этой теме

• Формализовывать требования безопасности по ISO/IEC 25010, а не «на словах».
• Проектировать разграничение доступа на атрибутах и описывать политики отдельно от кода.
• Строить наблюдаемость через OpenTelemetry и превращать логи в метрики.
• Считать TCO и защищать экономическую часть без фантазий.
• Оформлять схемы и ТЗ по ГОСТ 34.601 и ГОСТ 19.701 так, чтобы нормоконтроль прошёл с первого раза.

Источник: Космос наш, но по платной подписке. Правду о Ближнем Востоке теперь покупают у корпораций (опубликовано 2026-03-26)