Автономная буровая установка для "цифрового рудника" как система с конструктивной информационной безопасностью
▎Цифровой рудник
Цифровой рудник (ЦР) — это интегрированная киберфизическая система управления горным предприятием, где техника, люди, инфраструктура, датчики, связь, диспетчеризация, геомодели и производственные процессы объединены в единую цифровую среду для планирования, мониторинга, оптимизации и частичной/полной автоматизации работ.
▎АБУ — автономная буровая установка
АБУ — это подсистема цифрового рудника, выполняющая бурение по заданию без постоянного участия оператора. Она использует навигацию, датчики, бортовой контроллер, связь с диспетчерской системой и алгоритмы автоматического выполнения операций: позиционирование, бурение, контроль параметров, остановка при отклонениях.
▎Свойства безопасности цифрового рудника как надсистемы
Поскольку цифровой рудник — это надсистема, для него важны свойства не только функциональная, но и информационная безопасность, а также отказоустойчивость:
• Целостность данных и команд управления. • Доступность критических сервисов: связь, диспетчеризация, позиционирование, телеметрия. • Конфиденциальность технологических и производственных данных. • Аутентификация и разграничение доступа для людей, машин и сервисов. • Отказоустойчивость и живучесть при сбоях, потере связи, отказе узлов. • Сегментация сети и изоляция критических контуров управления. • Наблюдаемость и трассируемость: журналирование, мониторинг событий, аудит. • Безопасная интеграция подсистем, чтобы компрометация одной не приводила к аварии всей системы. • Управляемый переход в безопасное состояние при инцидентах. • Координация промышленной безопасности: исключение конфликтов между людьми, техникой и автоматикой.
▎Свойства безопасности АБУ как подсистемы
Для АБУ ключевы свойства безопасного автономного поведения:
• Функциональная безопасность: недопущение опасных действий при отказах. • Безопасное состояние по умолчанию: остановка/блокировка при потере связи, навигации или критических датчиков. • Локальная автономная защита: АБУ должна быть безопасной даже без внешней системы. • Контроль зоны работ: геозоны, запретные зоны, предотвращение столкновений с людьми и техникой. • Целостность управляющих команд и ПО. • Достоверность сенсорных данных и диагностика их отказов. • Резервирование критичных датчиков и каналов. • Аварийный останов и ручной перехват управления. • Предсказуемость поведения и ограниченность режимов работы. • Киберзащита бортовой сети, контроллера, каналов связи и обновлений ПО.
▎Кратко в виде отношения надсистема–подсистема
• Цифровой рудник отвечает за системную безопасность, координацию, защищённый обмен и устойчивость всей экосистемы. • АБУ отвечает за безопасное выполнение конкретной операции и безопасное поведение даже при частичной деградации надсистемы.
В первой версии ЦР был сделан акцент на функционале системы. Однако по требованиям Регулятора с 2026 года все системы должны быть реализованы в соответствии с рекомендациями ГОСТ Р 72118-2025. Должны быть определены цели и предположения безопасности, определена и минимизирована доверенная вычислительная база (всё, что критично для целей безопасности системы), ДВБ должна быть покрыта тестами.
Кроме того, разработчикам АБУ следует воспользоваться рекомендациями стандарта ISO/SAE 21434-2021.
Регулятор ввёл процедуру сертификации, через которую должны проходить будущие АБУ. Комплект артефактов для сертификации включает
- описание системы (архитектура), обоснование разделения доменов безопасности и контроля взаимодействия
- цели и предположения безопасности
- SBOM с разделением на SBOM для доверенного и недоверенного кода
- исходный код
- тесты
Регулятор выполняет тесты и проверяет, что ДВБ покрыта тестами не менее чем на 80%, а искажения в недоверенном коде не нарушают цели безопасности. В случае успешного тестирования конкретная версия АБУ получает сертификат. Стоимость сертификации зависит от размера и сложности ДВБ.
Примечание: в коде ЦПБ сокращать как SGA - security goals and assumptions.
Производители АБУ могут сами выбирать цели и предположения безопасности для своих систем. Однако конкретные ЦР отбирают те АБУ, которые подходят под требуемые ЦБ и учитывают ЦБ ЦР как свои предположения безопасности.
Цели безопасности (security goals) в сертификате представляются двумя полями:
- идентификатор ЦБ, имеет формат SG_<Код системы><Тип цели><Вариатор>
- полная формулировка ЦБ
Предположения безопасности (security assumptions) описываются аналогично
- идентификатор ПБ, формат SA_<Код системы><Тип предположения><Вариатор>
- ADS - autonomous drilling system - АБУ
- DM - digital mine - ЦР
- REG - регулятор
-
Полная формулировка: При любых обстоятельствах выполняются только авторизованные критичные команды Идентификатор: SG_ADS_Authorized_critical_commands
-
Полная формулировка: При любых обстоятельствах соблюдаются критичные ограничения Идентификатор: SG_ADS_Controlled_operations
-
Полная формулировка: При любых обстоятельствах сохраняются события безопасности Идентификатор: SG_ADS_Security_events_store
- Полная формулировка: авторизованные сотрудники ЦР являются благонадёжными Идентификатор: SA_ADS_Trustrworthy_authorized_operators
TARA (Threat Analysis and Risk Assessment) в контексте ISO/SAE 21434 — это систематический цикл: выделить активы (что защищаем), идентифицировать угрозы и сценарии атак, оценить риск (связь вероятности и ущерба damage), выбрать меры и согласовать их с целями безопасности (SG) и предположениями (SA) в SGA.
В учебном прототипе достаточно упрощённой модели: 1–2 пути атаки, явно указанные активы и ущерб, связь с конкретной SG (например SG_ADS_Authorized_critical_commands).
- Зафиксировать SGA для своей версии АБУ (или доработать исходные формулировки из docs/context.md).
- Построить модель границ: контроллер, связь с ЦР, зависимости Python, места вызова критичных решений (лимиты глубины/оборотов, аварийный стоп).
- Для каждой значимой зависимости и подсистемы задать вопрос: «если этот компонент скомпрометирован, нарушаются ли SG?» — ответ связывается с ДВБ и с тестами безопасности.
- Оформить путь атаки (текстовая цепочка или диаграмма PlantUML), как в docs/diagrams/tara_attack_numpy.puml.
В этой задаче ДВБ — это совокупность всего кода, компрометация которого критична для поставленных целей безопасности (SG из SGA и связанных с ними проверок и поведения системы). Код вне ДВБ по определению не должен иметь возможности нарушить эти цели при произвольном поведении (в пределах модели угроз).
Если границы ДВБ явно не описаны и не сужены архитектурой, в прототипе весь код поставки в пакете считается ДВБ при расчёте покрытия и стоимости сертификации и последующей эксплуатации.
Нужно проанализировать все подсистемы и зависимости АБУ (включая библиотеки из requirements.txt, модули псевдо-ИИ, журнал, HTTP-слой), чтобы:
- определить минимальный состав ДВБ и отразить его в SBOM_TCB / SBOM_OTHER;
- обосновать перенос проверок в ДВБ и покрытие тестами безопасности;
- согласовать выводы с Регулятором (стоимость, тяжёлые зависимости в ДВБ, например numpy).
| Элемент | Описание |
|---|---|
| Актив | Целостность критичных команд и режимов бурения (SG_ADS_Authorized_critical_commands); корректность расчётов в контуре миссии. |
| Компонент | Библиотека numpy в ДВБ (как в заготовке numpy_workflow) — исполняется в том же процессе, что и логика безопасности. |
| Угроза | Компрометация цепочки поставок: вредоносный артефакт в репозитории пакетов / зеркале / кэше сборки; подмена версии зависимости в SBOM или в окружении. |
| Путь атаки | Злоумышленник внедряет код в пакет numpy (или в транзитивную зависимость) → при установке пакет попадает в поставку АБУ → при выполнении миссии искажаются вычисления (сглаживание вибрации, пороги) → нарушается логика принятия решений → возможны неавторизованные или опасные команды, обход ограничений. |
| Ущерб (damage) | Нарушение безопасности на объекте: превышение глубины/оборотов, ложное «нормальное» состояние при аварийных сенсорах, блокировка аварийного стопа — в зависимости от внедрённой логики. |
| Меры | Сужение ДВБ, проверка целостности, воспроизводимые сборки, разделение: numpy вне ДВБ с чётким контрактом данных, усиление тестов безопасности и SBOM. |
Этот пример согласован с диаграммой пути атаки в docs/tara_abu.md.