Анализ форка systemd без birthDate для ВКР: приватность как архитектурное требование

В марте 2026 года вокруг systemd развернулась показательная история: в upstream добавили в userdb поле birthDate, а в homectl — опцию --birth-date. Ответом стал форк, вычистивший эту функциональность и обещающий синхронизироваться с веткой main. Отдельно GrapheneOS отказался встраивать верификацию возраста. Для выпускника ИТ это не новость «из мира Linux», а готовый кейс для ВКР по защите информации и системному программированию: здесь есть конфликт «функциональность против приватности», архитектурное решение, юридические требования и измеримые метрики. Ниже — как превратить этот сюжет в диплом, который не стыдно защищать.

Частые вопросы до старта работы

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

• «Минимизация персональных данных в подсистеме идентификации Linux: анализ userdb systemd»
  Актуальность — прямое следствие статьи: добавление birthDate в userdb повышает объём PII в системе.
  Цель — спроектировать модель userdb без избыточных идентификационных полей.
  Задачи: разобрать схему userdb, построить STRIDE-модель угроз, описать политику минимизации, сравнить форк и upstream по метрикам.
  Главы: 1) анализ стандартов и нормативки (152-ФЗ, ISO/IEC 25010), 2) проектирование схемы без birthDate (C4 + UML class diagram), 3) тестирование и оценка сокращения PII.
• «Форк как метод управления техническим долгом и приватностью ПО»
  Актуальность — форк синхронизируется с main, значит, встаёт классическая задача сопровождения diverged-ветки.
  Цель — оценить стоимость поддержки форка с точки зрения релизного цикла.
  Задачи: измерить объём патчей, построить диаграмму процесса sync, посчитать частоту конфликтов слияния, оценить трудозатраты.
  Главы: 1) теоретическая база (MBSE, ГОСТ 34), 2) реализация процесса синхронизации, 3) метрики (lead time, MTTR конфликтов).
• «Верификация возраста в операционных системах: архитектурный конфликт и его последствия»
  Актуальность — отказ GrapheneOS показывает, что технические ограничения неотделимы от политики.
  Цель — построить модель взаимодействия сервисов верификации возраста и локальной ОС без утечки идентификаторов.
  Задачи: анализ регуляторики, проектирование протокола с zero-knowledge подходом, оценка угроз, нагрузочное тестирование сценария.
  Главы: 1) анализ предметной области и OWASP-риски, 2) проектирование архитектуры (диаграммы последовательностей), 3) верификация модели угроз и метрики latency.

Как встроить кейс в главы ВКР

Глава 1. Аналитическая часть

Начните с разбора коммитов: где именно в userdb появилось поле birthDate, какие модули его читают, кто является потребителем. Затем — нормативная база: 152-ФЗ (ст. 5, минимизация), GDPR Art. 5, ISO/IEC 25010 (quality model, характеристика security с подхарактеристикой confidentiality). Соберите таблицу «требование → техническое решение → метрика проверки». Именно здесь уместна ссылка на новость как на первичный источник.

Глава 2. Проектирование и реализация

Постройте C4-диаграмму контейнеров: ядро Linux, systemd-userdbd, homectl, приложения-клиенты. Обозначьте точки, где PII проходит через границы доверия. Затем — диаграмму классов userdb до и после форка. Реализация форка проста в понимании, если показать патч:

--- a/src/userdb/userrecord.c
+++ b/src/userdb/userrecord.c
@@
-        if (birth_date) {
-                r = json_variant_set_field(&v, "birthDate", birth_date);
-                if (r < 0)
-                        return r;
-        }
+        /* Поле birthDate удалено: минимизация PII.
+         * См. политику обработки персональных данных. */

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

Глава 3. Тестирование и оценка

Метрики поддомена ИБ: сокращение числа полей PII (штук), сокращение поверхности атаки (количество функций, читающих идентификацию), MTTR синхронизации форка с upstream, покрытие тестами изменённых модулей. Схема замеров: baseline (upstream) vs target (форк). Используйте OpenTelemetry для сбора событий обращения к userdb — это даст фактическую статистику, а не гипотезу.

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

• Строить threat model по STRIDE и привязывать её к архитектуре ОС.
• Оформлять требования приватности как измеримые характеристики по ISO/IEC 25010.
• Читать и анализировать патчи C-кода и отличать интерфейсные изменения от логических.
• Проектировать диаграммы C4 и UML так, чтобы нормоконтроль их принял.
• Считать метрики сопровождения форка: lead time, MTTR, частота конфликтов.

Источник: Создан форк systemd без хранения возраста. GrapheneOS отказался верифицировать возраст (опубликовано 2026-03-24)