Безопасность

Полевой терминал может оказаться в чужих руках. Рабочая станция может получить заражённый файл. Удалённый объект может потерять связь с инфраструктурой управления.

Условия различаются, но вопросы остаются конкретными: что необходимо защитить, какие действия разрешены и как сохранить контроль при нарушении штатной работы.

В RUS OS мы рассматриваем безопасность как часть архитектуры и всего жизненного цикла системы. От выбора компонентов и подготовки образа до обслуживания, восстановления и вывода устройства из эксплуатации.

Защита должна соответствовать назначению системы.

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

Мы начинаем с определения защищаемых данных, критических функций, возможных нарушителей и последствий их действий.

Модель угроз задаёт требования к архитектуре, настройкам и испытаниям. Она должна пересматриваться при изменении оборудования, функций и условий эксплуатации.

Доверие к системе начинается с того, какой код получает управление.

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

Возможности такой проверки зависят от аппаратной платформы. Поэтому необходимо определять границы доверия, порядок управления ключами и действия при обнаружении изменений.

Режим восстановления также должен быть спроектирован заранее: кто может его запустить, какие операции доступны и как подтверждается возвращение устройства в рабочее состояние.

Оператору, администратору, сервису и приложению нужны разные права.

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

Важно учитывать и обслуживание на месте. Специалисту может потребоваться диагностика или замена компонента без доступа к рабочим данным пользователя.

Мы рассматриваем разграничение полномочий как основу повседневной работы системы.

Ошибка или компрометация одного компонента может затронуть связанные с ним службы.

Границы между компонентами должны ограничивать это влияние. Для каждого взаимодействия необходимо определить доступные операции, передаваемые данные и условия отказа.

Средства изоляции выбираются с учётом оборудования и нагрузки. Их свойства нужно проверять вместе с реальными настройками и зависимостями приложений.

Цель - сохранять управляемость системы и ограничивать область нарушения.

Накопители, журналы, резервные копии и временные файлы могут содержать чувствительную информацию.

Для каждой категории данных необходимо определить место хранения, срок сохранения и круг доступа. Шифрование требует продуманного управления ключами, включая запуск без сети, обслуживание и восстановление.

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

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

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

Для каждого интерфейса нужно определить назначение, допустимые подключения и доступные операции. Неиспользуемые возможности должны отключаться в соответствии с конфигурацией устройства.

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

Система собирается из компонентов, у каждого из которых есть источник, версия и зависимости.

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

Обновления требуют проверки подлинности и целостности, испытаний и определённого порядка установки.

Отдельно необходимо управлять возвратом к предыдущей версии: восстановление работоспособности должно учитывать риск повторного появления уже устранённых уязвимостей.

Защита должна учитывать автономную эксплуатацию.

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

После восстановления связи системе необходимо согласовать изменения и передать накопленные события.

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

Для расследования нужны достоверные события: кто вошёл в систему, изменил настройки, подключил устройство или выполнил значимую операцию.

Журналирование требует собственной защиты, управления доступом и контроля объёма. Состав записей должен учитывать конфиденциальность данных.

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

Заранее определённые процедуры помогают действовать последовательно даже при ограниченной связи и отсутствии разработчика на объекте.

Возможность анализировать данные и право выполнять действия требуют разных полномочий.

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

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

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

Свойства защиты зависят от реализации, конфигурации и условий эксплуатации.

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

Для каждого решения важно фиксировать подтверждённые свойства, ограничения и условия применения.

Мы строим подход к безопасности RUS OS вокруг проверяемости: понимать угрозы, обосновывать механизмы защиты и сохранять контроль на протяжении всего срока службы системы.