SCF / Документация / Карта

База знаний SCF

Версия: 0.1

1. Назначение

База знаний SCF — поддерживаемый корпус знаний для построения, выпуска, сопровождения и вывода из эксплуатации операционных систем. Она охватывает настольные и серверные системы общего назначения, программно-аппаратные комплексы, киоски, периферийные и встраиваемые устройства, носители восстановления и установки, защищённые рабочие станции, виртуальные и облачные образы, базовые образы контейнеров и white-label-производные.

Это не каталог инструментов сборки. SCF разделяет:

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

2. Архитектура знаний

Слой A — Основания

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

Слой B — Универсальный контракт

Конституция построения;
безопасные и приватные настройки по умолчанию;
человеческая агентность над машиной: право проверить, отключить, перенести и удалить данные;
доступность и интерфейсные обязательства, наследуемые от HIF;
нормативный словарь и порядок исключений.

Слой C — Переносимая модель построения

спецификация, разрешение входов, фиксация входов (lock), сборка, артефакт, выпуск, канал;
канонический конвейер построения и контракты его этапов;
контракт адаптера для семейства платформ;
отображение сущностей между deb, rpm, apk, BSD pkg, IPS, деревьями портов и системами, собираемыми из исходного кода;
требования к привилегиям, изоляции и герметичности каждого этапа;
кэширование, зеркалирование и фиксация среза архива.

Слой D — Свойства системы

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

Слой E — Данные и люди

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

Слой F — Профили

настольная система общего назначения; серверная система общего назначения;
программно-аппаратный комплекс и встраиваемое устройство; киоск и одноцелевой терминал;
рабочая станция безопасности и криминалистического анализа;
неизменяемая система с атомарным обновлением;
изолированное от сети и регулируемое развёртывание;
установочные, live- и восстановительные носители;
виртуальные, облачные и базовые контейнерные образы;
white-label-производная.

Слой G — Доказательства

лестница доказательств и то, что каждая её ступень может и не может доказать;
корпус проверок: проверки, выполняемые офлайн над образом, проверки, требующие виртуальной машины с прошивкой и TPM, и проверки, требующие эталонного оборудования;
воспроизводимость и проверка повторной сборкой;
уровни соответствия и контрольный этап выпуска;
эксплуатационные сигналы после выпуска.

Слой H — Жизненный цикл и профессиональная практика

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

Слой I — Право и управление

регулирование безопасности продукции и оценка соответствия;
лицензионные обязательства каждого включённого произведения, включая доступность исходного кода;
товарные знаки upstream-проектов и производителя;
условия использования прошивок и несвободных компонентов;
экспортный контроль и санкции;
записи, декларации и сроки хранения.

3. Политика источников

Источник SCF MUST быть прослеживаем до первичного текста. Приоритет:

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

Вторичная статья, перевод, блог поставщика или чек-лист без источников MAY помочь найти первоисточник, но MUST NOT служить доказательной основой нормативного требования.

Каждое утверждение о платформе MUST нести свою область: какая система, какая версия, какая архитектура, какая дата. Поведение платформ меняется; утверждение без версии и даты непригодно к использованию.

4. Классы утверждений

Класс	Значение	Необходимая опора
Нормативное	Обязательство SCF	Конституция, применимый профиль и метод проверки
Регуляторное	Обязательство, налагаемое правом	Опубликованный текст, статья и дата начала применения
Платформенное	Ограничение экосистемы или прошивки	Актуальная официальная документация с версией и датой
Измеренное	Наблюдаемое значение	Метод, среда, дата и исходный результат
Паттерн	Повторяемое решение проблемы	Контекст, силы и известные ограничения
Эвристика	Вопрос экспертной проверки	Происхождение и валидация в контексте продукта
Гипотеза	Непроверенное предположение	Критерии успеха и опровержения
Решение	Выбранный компромисс	Ответственный, обоснование, доказательства и дата пересмотра

Числа MUST NOT объявляться универсальными порогами, если стандарт не определяет их для заявленной области. Время сборки, размеры образов и объёмы зеркал являются измеренными утверждениями и MUST нести условия своего измерения.

5. Навигация по корпусу

Начните с Конституции. Выберите профиль продукта. Опишите систему как спецификацию и отобразите её на семейство платформ с помощью переносимой модели сборки. Планируйте проверку до реализации по документу Оценка и соответствие и поддерживайте трассировку от обязательства к доказательству.

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

6. Поддержка

Каждый документ MUST указывать версию или наследовать версию корпуса. Существенное изменение требует:

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

Не реже раза в год и перед любыми связанными работами MUST пересматриваться:

регулирование безопасности продукции и даты начала его применения;
политика центра подписи и срок действия сертификатов;
сроки поддержки upstream и даты окончания поддержки;
базовые конфигурации усиления защиты и их текущие редакции;
политика алгоритмов и объявленные устаревшими решения;
условия использования товарных знаков и лицензий upstream.