Версия: 2.0 (WIP)

Контроль целостности

Обзор архитектуры контроля целостности

Контроль целостности Памир реализован на двух уровнях и охватывает весь жизненный цикл ПО:

Уровень	Компонент	Когда выполняется
Установка / обновление	`pamir-installer`	При каждом запуске `install`
Эксплуатация	`pamirctl`	При каждом `start` и `restart`, по запросу (`sums`), а также периодически в режиме демона

Алгоритм контрольного суммирования во всех случаях — SHA-256.

Эталонные контрольные суммы встраиваются в исполняемые бинарники на этапе сборки CI/CD (//go:embed) и не могут быть изменены без пересборки бинарника.

Контроль целостности модулей ПО с использованием контрольного суммирования

§ 3.3.1

Как реализовано:

Модули прикладного ПО Памир поставляются в виде образов контейнеров. Каждый образ криптографически идентифицируется через SHA256(config_blob) — так называемый ImageID в Docker Engine. config_blob — JSON-файл, содержащий цепочку хешей всех слоёв образа (diff_ids = [SHA256(распакованный_слой), ...]), поэтому одно значение ImageID однозначно и полностью покрывает всё содержимое образа: бинарники, библиотеки, скрипты, конфигурации по умолчанию.

Схема формирования и использования эталонных сумм:

В CI/CD (pamir-iso, generate_artifacts.sh) при каждой сборке релиза: из каждого tar-архива образа извлекается manifest.json, из него — поле Config (config_id); результат записывается в digests.json
digests.json помещается в pamirctl/internal/verifier/ и встраивается в бинарник pamirctl через //go:embed при сборке
Аналогично sums.json встраивается в pamir-installer при сборке
При каждом вызове pamirctl start и pamirctl restart функция verifier.Verify() запрашивает у Docker Engine ImageID каждого образа и сравнивает с эталоном
При установке/обновлении pamir-installer сравнивает config_id, извлечённый из tar-архива на носителе, с эталонным значением из встроенного sums.json
Если хотя бы один образ отсутствует или его сумма не совпадает — операция блокируется

Формат digests.json:

{
  "pamir.io/auth:2.0.0":     "sha256:cc464c......",
  "pamir.io/postgres:15.13": "sha256:2f3b2a......",
  "pamir.io/frontend:2.0.0": "sha256:a1b2c3......"
}

Как проверить:

# 1. Просмотреть эталонные суммы, встроенные в бинарник
pamirctl sums

# 2. Получить суммы в JSON-формате (без цветового вывода, пригодно для скриптов)
pamirctl sums -o /tmp/embedded-digests.json

# 3. Проверить фактический ImageID загруженного образа
docker inspect --format '{{.Id}}' pamir.io/auth:2.0.0

# 4. Убедиться что суммы совпадают (start должен пройти)
pamirctl start

# 5. Симулировать подмену образа — загрузить другой образ под тем же тегом
docker tag ubuntu:latest pamir.io/auth:2.0.0
# Теперь start должен завершиться ошибкой несоответствия контрольной суммы
pamirctl start
# Ожидается: ошибка "image digest mismatch" и ненулевой код возврата

Контроль целостности настроек прикладного ПО с использованием сверки с эталонными значениями

§ 3.3.2

Как реализовано:

Настройки Памир — это конфигурационные файлы в директории install/: .env-файлы, docker-compose-файлы, инициализационные скрипты баз данных, сертификаты и прочие ресурсы установки. При каждой сборке CI/CD скрипт generate_artifacts.sh рекурсивно обходит директорию конфигурации, вычисляет SHA-256 для каждого файла и формирует configs.json:

{
  ".env":                           "sha256:3b4c5d......",
  ".auth.autogen":                  "sha256:9f1a2b......",
  "init/database/init-database.sh": "sha256:7e8f9a......"
}

configs.json встраивается в pamirctl и pamir-installer через //go:embed. При каждом запуске:

pamirctl start / pamirctl restart: функция verifier.VerifyConfigs() вычисляет актуальный SHA-256 каждого конфигурационного файла в app_path и сравнивает с эталоном
pamir-installer install: аналогичная проверка конфигурационных файлов на носителе перед копированием

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

Дополнительно: в files.sha256 (поставляется на ISO и в Nexus) включены SHA-256 всех конфигурационных файлов дистрибутива, что позволяет проверить целостность носителя до установки:

cd /media/cdrom0 && sha256sum --check --ignore-missing files.sha256

примечание

Флаг --ignore-missing пропускает проверку файлов, интегрированных в бинарник инсталлятора (docker-compose.*.yml), поскольку проверить их средствами sha256sum нельзя.

Как проверить:

# 1. Просмотреть эталонные суммы конфигурационных файлов, встроенные в бинарник
pamirctl sums --show-config

# 2. Запустить приложение — в аудит-логе будут зафиксированы результаты проверки конфигурации
pamirctl start

# 3. Просмотреть аудит-лог (путь зависит от пользователя):
#    - root:        /var/log/pamirctl-audit-YYYY-MM-DD-HH-MM-SS.log
#    - обычный пользователь: ~/.pamirctl-audit-YYYY-MM-DD-HH-MM-SS.log
cat ~/.pamirctl-audit-2025-01-15-10-30-00.log

# 4. Симулировать несанкционированное изменение конфигурации
echo "EXTRA_VAR=malicious" >> ~/.pamir/.env
pamirctl start
# Ожидается: в аудит-логе строка WARN: config checksum mismatch для .env

# 5. Проверить целостность конфигурационных файлов дистрибутива на ISO
cd /media/cdrom0 && sha256sum --check --ignore-missing files.sha256

Контроль целостности при запуске ПО и по запросу пользователя (администратора)

§ 3.3.3

Как реализовано:

Контроль целостности выполняется в двух режимах:

При запуске (автоматически):

pamirctl start — перед запуском контейнеров автоматически вызываются verifier.Verify() (образы) и verifier.VerifyConfigs() (конфигурационные файлы). При несоответствии образов запуск блокируется.
pamirctl restart — аналогично, проверка выполняется перед перезапуском сервисов.
pamir-installer install — при установке и обновлении проверяется целостность образов и конфигурационных файлов на носителе.

По запросу администратора:

pamirctl sums — выводит эталонные суммы, встроенные в бинарник (образы + конфигурационные файлы по флагу --show-config). Позволяет сверить значения вручную или выгрузить для передачи в СЗИ.
pamirctl sums -o <file> — выгружает суммы в JSON-файл.
sha256sum --check --ignore-missing /media/cdrom0/files.sha256 — ручная проверка целостности дистрибутива на носителе.

примечание

Как проверить:

# При запуске — проверка выполняется автоматически, результат фиксируется в аудит-лог
pamirctl start

# По запросу — просмотр встроенных эталонных сумм без запуска сервисов
pamirctl sums
pamirctl sums --show-config

# По запросу — сохранить суммы в файл (для передачи в СЗИ или архивации)
pamirctl sums -o /tmp/reference-sums-$(date +%Y%m%d).json

# По запросу — проверить целостность дистрибутива на носителе
sha256sum --check --ignore-missing /media/cdrom0/files.sha256

Периодический контроль целостности модулей ПО в процессе функционирования

§ 3.3.4

Как реализовано:

Периодический контроль целостности работающих контейнеров реализован в режиме демона утилиты pamirctl. Демон запускается как пользовательский сервис systemd (pamirctl.service) и непрерывно выполняет циклические проверки через Docker API.

Принцип работы:

Сразу после запуска, а затем через каждые 15 секунд (интервал задаётся переменной окружения PAMIRCTL_DAEMON_INTERVAL, по умолчанию 15s) демон выполняет цикл проверки:

Получает список запущенных контейнеров Compose-проекта (фильтр по лейблу com.docker.compose.project).
Для каждого контейнера последовательно выполняет три проверки через Docker Inspect:

№	Проверка	Реакция при нарушении
1	Имя образа контейнера (`Config.Image`) присутствует в эталонном `digests.json`	Контейнер останавливается
2	Реальный `ImageID` контейнера совпадает с эталонной суммой из `digests.json`	Контейнер останавливается
3	Корневая ФС контейнера смонтирована в режиме `readonly`	Контейнер останавливается

Остановленный контейнер заносится в список блокировок. При попытке повторного запуска демон перехватывает событие через Docker Events API и немедленно останавливает заблокированный контейнер.

Лог аудита демона:

Демон ведёт отдельный постоянный лог аудита, открываемый в режиме дополнения (история не теряется между перезапусками):

Режим запуска	Путь к файлу
Суперпользователь	`/var/log/pamirctl-audit-daemon.log`
Обычный пользователь	`~/.pamirctl-audit-daemon.log`

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

Пример записей:

2026-04-10 00:00:01 [INFO ] Демон контроля целостности запущен  project: pamir  interval: 15s
2026-04-10 00:00:01 [INFO ] Запуск цикла проверки контрольных сумм
2026-04-10 00:00:01 [INFO ] Контейнер прошёл проверку целостности  container: /pamir-auth-1  image: pamir.io/auth:2.1.0
2026-04-10 00:00:02 [WARN ] Нарушение целостности: контейнер будет остановлен  container: /pamir-srm-1  id: a1b2c3d4e5f6  reason: ImageID контейнера не соответствует эталонной контрольной сумме  image: pamir.io/srm:2.1.0  expected: sha256:<hex>  actual: sha256:<hex>
2026-04-10 00:00:02 [INFO ] Контейнер остановлен по причине нарушения целостности  container: /pamir-srm-1  id: a1b2c3d4e5f6
2026-04-10 00:00:15 [WARN ] Попытка повторного запуска заблокированного контейнера — остановка  container: /pamir-srm-1  id: a1b2c3d4e5f6  reason: ImageID контейнера не соответствует эталонной контрольной сумме

Просмотр сервиса systemd:

# Проверка состояния
systemctl --user status pamirctl.service

# Просмотр журнала через systemd
journalctl --user -u pamirctl -f

# Или просмотр файла аудита напрямую
tail -f ~/.pamirctl-audit-daemon.log

Как проверить:

# 1. Убедиться что периодические проверки выполняются
tail -f ~/.pamirctl-audit-daemon.log
# Ожидается: строки "Запуск цикла проверки контрольных сумм" с интервалом ~15 секунд

# 2. Симулировать подмену образа и убедиться что демон остановил нарушителя
docker tag ubuntu:latest pamir.io/auth:2.0.0
# Через один цикл (≤15 секунд) контейнер с поддельным образом должен быть остановлен
grep "Нарушение целостности" ~/.pamirctl-audit-daemon.log | tail -5
# Ожидается: запись с reason=ImageID... и фактическим значением суммы

# 3. Убедиться что повторный запуск заблокированного контейнера перехватывается
grep "Попытка повторного запуска заблокированного контейнера" ~/.pamirctl-audit-daemon.log | tail -5

Хранение эталонных контрольных сумм в защищённом виде

§ 3.3.5

Как реализовано:

Эталонные контрольные суммы хранятся в двух формах:

1. Встроенные в исполняемый бинарник (основной механизм):

Файлы digests.json и configs.json встраиваются в бинарники pamirctl и pamir-installer на этапе сборки CI/CD через директиву //go:embed. После сборки эти данные являются частью исполняемого файла и:

не могут быть изменены без пересборки бинарника (требует доступа к исходному коду и CI/CD-среде)
защищены целостностью самого бинарника (SHA-256 бинарника включается в files.sha256)
доступны только для чтения в runtime

2. На дистрибутивном носителе (ISO) и в Nexus:

Файлы images.sha256 и files.sha256 размещаются на ISO (файловая система ISO 9660 — read-only по природе носителя) и в Nexus-репозитории. Nexus требует аутентификации для загрузки и имеет разграничение доступа на запись.

Таким образом, несанкционированная модификация эталонных сумм без физического перезаписи носителя или несанкционированного доступа к CI/CD-системе и репозиторию исходного кода невозможна.

Как проверить:

# 1. Убедиться что суммы встроены в бинарник (не читаются из внешнего файла)
# Удалить файл digests.json если он присутствует рядом с бинарником
rm -f ~/.pamir/digests.json
# Команда sums должна по-прежнему работать — данные берутся из бинарника
pamirctl sums

# 2. Убедиться что ISO-образ монтируется в режиме read-only
mount | grep cdrom
# Ожидается: iso9660 ... ro,relatime

# 3. Проверить целостность самого бинарника pamirctl
sha256sum ~/.local/bin/pamirctl
# Сравнить с записью в files.sha256 дистрибутива
grep pamirctl /media/cdrom0/files.sha256

Блокировка загрузки ПО при несоответствии эталонным значениям контрольных сумм

§ 3.3.6

Как реализовано:

При обнаружении несоответствия контрольной суммы образа контейнера (как при установке, так и при запуске) операция немедленно прерывается:

pamirctl start / pamirctl restart: при любом несоответствии ImageID функция verifier.Verify() возвращает ошибку → команда запуска/перезапуска не выполняется → приложение не запускается → процесс завершается с ненулевым кодом возврата.
pamir-installer install: при несоответствии суммы образа на носителе загрузка образов в Docker Engine не выполняется → установка/обновление прерывается.

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

Как проверить:

# Симуляция подмены образа в Docker Engine
docker tag ubuntu:latest pamir.io/auth:2.0.0

# Попытка запуска — должна завершиться ошибкой
pamirctl start
# Ожидается: сообщение об ошибке несоответствия суммы, ненулевой код возврата
echo $?  # → ненулевое значение (например, 1)

# Убедиться что контейнеры NOT запущены
docker ps | grep pamir
# Ожидается: нет запущенных контейнеров pamir

# Просмотреть детали ошибки в аудит-логе
tail -20 ~/.pamirctl-audit-*.log

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

§ 3.3.7

Как реализовано:

При каждой сборке релиза в пайплайне pamir-iso (задания task:iso:server, task:iso:probe) автоматически формируются следующие файлы с эталонными суммами:

Файл	Содержимое	Формат	Назначение
`digests.json`	`ImageID` каждого образа контейнера	JSON (`{"image:tag": "sha256:..."}`)	Встраивается в `pamirctl`, используется `verifier.Verify()`
`sums.json`	SHA-256 tar-архивов образов по категориям	JSON (`{"server": {"auth": "..."}}`)	Встраивается в `pamir-installer`
`configs.json`	SHA-256 конфигурационных файлов	JSON (`{"path": "sha256:..."}`)	Встраивается в оба бинарника
`images.sha256`	Те же ImageID в виде `<hash> <image:tag>`	Стандарт `sha256sum`	Поставляется на ISO и в Nexus для ручной и внешней проверки
`files.sha256`	Суммы всех файлов дистрибутива	Стандарт `sha256sum`	Поставляется на ISO и в Nexus

Шаги формирования в CI (task.gitlab-ci.yml):

generate_artifacts.sh обходит tar-архивы образов, извлекает config_id из manifest.json → формирует digests.json
digests.json копируется в pamirctl/internal/verifier/ → pamirctl собирается с embedded суммами
images.sha256 формируется из digests.json через jq в формате sha256sum
Все файлы укладываются в ISO и загружаются в Nexus — при каждом обновлении новые суммы гарантированно поставляются вместе с дистрибутивом

Таким образом, при выходе любого обновления ПО эталонные суммы автоматически обновляются и поставляются в двух форматах (JSON и стандарт sha256sum), оба из которых пригодны для использования механизмами контроля целостности.

Как проверить:

# 1. На ISO релиза убедиться что файлы с суммами присутствуют
ls /media/cdrom0/
# → files.sha256  images.sha256  pamir-installer  install/  server/  deps/

# 2. Убедиться что суммы нового релиза отличаются от предыдущего
#    (подтверждает, что суммы обновляются при каждом обновлении ПО)
diff pamir-2.0.0.images.sha256 pamir-2.0.0.images.sha256

# 3. Убедиться что embedded суммы в бинарнике совпадают с images.sha256 на ISO
pamirctl sums -o /tmp/embedded.json
jq -r 'to_entries[] | (.value | ltrimstr("sha256:")) + "  " + .key' /tmp/embedded.json \
  | sort > /tmp/embedded.sha256
sort /media/cdrom0/images.sha256 > /tmp/iso.sha256
diff /tmp/embedded.sha256 /tmp/iso.sha256
# Ожидается: нет различий

Регистрация изменения перечня модулей и их эталонных контрольных сумм

§ 3.3.12

Как реализовано:

При обновлении ПО (pamir-installer install на системе с уже установленным Памир) инсталлятор обнаруживает изменение образов и конфигурационных файлов и регистрирует в логе:

time=2026-03-23T22:39:09.304+03:00 level=INFO msg="Образ контейнера заменён" user=pamir image=pamir.io/auth:2.0.0 old_image_id=sha256:abc123... new_image_id=sha256:cc464c...
time=2026-03-23T22:41:20.307+03:00 level=INFO msg="Конфигурационный файл заменён" user=pamir path=/home/pamir/.pamir/.env old_sha256=099cec... new_sha256=213aea...

Для каждого изменённого объекта регистрируются:

Логин пользователя (учётная запись, от имени которой запущен инсталлятор)
Идентификатор модуля/файла (имя образа с тегом, путь конфигурационного файла)
Старое значение контрольной суммы
Новое значение контрольной суммы

Регистрация изменений в pamirctl происходит косвенно: при каждом запуске сравниваются значения из встроенного digests.json (эталон текущей версии бинарника) с фактическими ImageID в Docker Engine. Если суммы не совпадают (образ заменён без обновления pamirctl), это фиксируется как нарушение целостности в аудит-лог с указанием ожидаемого и фактического значений.

Как проверить:

# Симуляция обновления: запустить pamir-installer install с обновлённым дистрибутивом
# В логе установки должны появиться записи об обновлённых образах и файлах
cat ~/.pamir-installer-*.log | grep -E "заменён" | head -20

# Убедиться что записываются старое и новое значения сумм
cat ~/.pamir-installer-*.log | grep -E "old_image_id=|old_sha256=" | head -20

# Убедиться что регистрируется пользователь, выполняющий изменение
cat ~/.pamir-installer-*.log | grep "user=" | head -3

Регистрация запуска и завершения процедуры контроля целостности

§ 3.3.13

Как реализовано:

При каждом запуске pamirctl start и pamirctl restart в аудит-лог записываются события начала и окончания каждой процедуры контроля целостности:

2026-03-24 12:48:25 [INFO ] Сеанс аудита открыт  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  log_file: /home/pamir/.pamirctl-audit-2026-03-24-12-48-25.log
2026-03-24 12:48:25 [INFO ] Команда запуска сервисов ПАМИР  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir
2026-03-24 12:48:25 [INFO ] Начало проверки контрольных сумм образов  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  count: 36
2026-03-24 12:48:25 [INFO ] Все контрольные суммы образов соответствуют эталонным  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  count: 36
2026-03-24 12:48:25 [INFO ] Начало проверки целостности конфигурации  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  count: 33  path: /home/pamir/.pamir
2026-03-24 12:48:25 [WARN ] Несоответствие контрольной суммы файла конфигурации  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  path: .license.env  expected: sha256:af0358...  actual: sha256:69d8a8...
2026-03-24 12:48:25 [WARN ] Несоответствие контрольной суммы файла конфигурации  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  path: docker-compose.deps.yml  expected: sha256:7e1592...  actual: sha256:dd74a5...
2026-03-24 12:48:25 [WARN ] Несоответствие контрольной суммы файла конфигурации  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  path: .task-tool.env  expected: sha256:31d599...  actual: sha256:348c19...
2026-03-24 12:48:25 [WARN ] Несоответствие контрольной суммы файла конфигурации  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  path: .celery.env  expected: sha256:e6b92d...  actual: sha256:7b0ef6...
2026-03-24 12:48:25 [WARN ] Несоответствие контрольной суммы файла конфигурации  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  path: .env  expected: sha256:213aea...  actual: sha256:099cec...
2026-03-24 12:48:25 [WARN ] Несоответствие контрольной суммы файла конфигурации  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  path: .notification.env  expected: sha256:1dcb78...  actual: sha256:0f3156...
2026-03-24 12:48:25 [WARN ] Несоответствие контрольной суммы файла конфигурации  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  path: .auth.env  expected: sha256:c268aa...  actual: sha256:cf1553...
2026-03-24 12:48:25 [WARN ] Несоответствие контрольной суммы файла конфигурации  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  path: .docker-tool.env  expected: sha256:1dffb0...  actual: sha256:8ecdf6...
2026-03-24 12:48:25 [WARN ] Несоответствие контрольной суммы файла конфигурации  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  path: .srm.env  expected: sha256:0cd598...  actual: sha256:5346d4...
2026-03-24 12:48:25 [WARN ] Несоответствие контрольной суммы файла конфигурации  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  path: .frontend.env  expected: sha256:69f4d6...  actual: sha256:ffbb26...
2026-03-24 12:48:25 [WARN ] Несоответствие контрольной суммы файла конфигурации  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  path: .monitoring.env  expected: sha256:ded8d4...  actual: sha256:0701d2...
2026-03-24 12:48:25 [WARN ] Проверка целостности конфигурации выявила нарушения  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir  violations: 11
2026-03-24 12:48:27 [INFO ] Запуск сервисов ПАМИР выполнен успешно  user: pamir  host: e2e-v2-0-0  workdir: /home/pamir

Дополнительно к запуску и завершению регистрируются:

Сведения об учётной записи: имя пользователя (user=), имя хоста (host=), рабочая директория (workdir=)
Результаты выполнения: количество проверенных объектов (ok=), количество нарушений (failed= / violations=), детали каждого нарушения

Как проверить:

# Запустить приложение и проверить наличие событий начала/окончания проверки
pamirctl start
grep -E "Начало проверки|сумм образов завершилась с ошибками|сумм образов успешно пройдена|целостности конфигурации выявила нарушения|конфигурации соответствуют эталонным значениям" ~/.pamirctl-audit-*.log

# Убедиться что присутствуют сведения о пользователе
grep "user=" ~/.pamirctl-audit-*.log | head -3

Расчёт контрольных сумм для файлов программного обеспечения

§ 4.3.1

Как реализовано:

Расчёт контрольных сумм выполняется на двух этапах:

На этапе сборки (CI/CD):

Скрипт generate_artifacts.sh (pamir-iso/tools/):

Для образов контейнеров: извлекает config_id из manifest.json tar-архива образа. config_id = SHA-256 от config_blob образа, что эквивалентно ImageID в Docker Engine.
Для конфигурационных файлов: вычисляет SHA-256 с помощью sha256sum для каждого файла в директории конфигурации (рекурсивно, с исключениями).
Для файлов дистрибутива: формирует files.sha256 через sha256sum для всех файлов в корне дистрибутива.

На этапе эксплуатации:

pamirctl при каждом start/restart вычисляет SHA-256 конфигурационных файлов в app_path и запрашивает ImageID у Docker Engine для загруженных образов.
pamir-installer при install вычисляет SHA-256 конфигурационных файлов на носителе и извлекает config_id из tar-архивов образов.

Как проверить:

# Воспроизвести расчёт суммы конфигурационного файла
sha256sum ~/.pamir/.env
# Сравнить с выводом
pamirctl sums --show-config | grep '"\.env"'

# Воспроизвести расчёт ImageID
docker inspect --format '{{.Id}}' pamir.io/auth:2.0.0
# Сравнить с выводом
pamirctl sums | grep '"pamir.io/auth'

Регистрация информации и её локальное хранение

§ 4.3.2

Как реализовано:

Результаты контроля целостности регистрируются и хранятся локально в структурированных текстовых файлах (plain-text с метаданными). Формат записи — ориентированный на человека и машинную обработку журнал с временными метками, уровнями логирования и структурированными полями.

Аудит-лог создаётся при каждом запуске pamirctl.

Лог инсталлятора создается при запуске процесса установки: pamir-installer install.

Компонент	Расположение (root)	Расположение (обычный пользователь)
`pamirctl`	`/var/log/pamirctl-audit-YYYY-MM-DD-HH-MM-SS.log`	`~/.pamirctl-audit-YYYY-MM-DD-HH-MM-SS.log`
`pamir-installer`	`/var/log/pamir-installer-YYYY-MM-DD-HH-MM-SS.log`	`~/.pamir-installer-YYYY-MM-DD-HH-MM-SS.log`

Каждый лог-файл содержит:

Временную метку каждого события
Уровень события (INFO, WARN, ERROR)
Сведения о сессии: имя пользователя (все), имя хоста и рабочая директория (pamirctl)
Начало и окончание проверки целостности образов
Начало и окончание проверки целостности конфигурационных файлов
При нарушении: имя образа/файла, ожидаемое значение суммы, фактическое значение

Формат соответствует требованию «структурированный текстовый файл» (п. 4.3.2).

Как проверить:

# Просмотреть аудит-лог после запуска
pamirctl start
cat ~/.pamirctl-audit-*.log | head -40

# Убедиться что лог создаётся с уникальным именем при каждом запуске
ls -la ~/.pamirctl-audit-*.log

# При нарушении целостности просмотреть детали в логе
docker tag ubuntu:latest pamir.io/auth:2.0.0
pamirctl start 2>&1 || true
grep -E "WARN|ERROR|Несоответствие" ~/.pamirctl-audit-*.log | tail -10

Описание формата сведений, передаваемых в наложенные средства защиты

§ 4.3.3

Как реализовано:

Команда pamirctl sums выводит эталонные контрольные суммы в JSON-формате, пригодном для передачи в наложенные СЗИ.

Формат digests.json (образы контейнеров):

{
  "<image_name>:<tag>": "sha256:<64 hex-символа>"
}

Пример:

{
  "pamir.io/auth:2.0.0":       "sha256:cc464c...",
  "pamir.io/postgres:15.13":   "sha256:2f3b2a...",
  "pamir.io/frontend:2.0.0":   "sha256:a1b2c3..."
}

Поля:

Ключ (string): полное имя образа контейнера, включая имя реестра, имя образа и тег
Значение (string): SHA-256 от config_blob образа (ImageID в Docker Engine) с префиксом sha256:

Формат configs.json (конфигурационные файлы):

{
  "<relative_path>": "sha256:<64 hex-символа>"
}

Пример:

{
  ".env":                           "sha256:3b4c5d...",
  ".auth.autogen":                  "sha256:9f1a2b...",
  "init/database/init-database.sh": "sha256:7e8f9a..."
}

Поля:

Ключ (string): путь к файлу относительно корневой директории приложения (app_path)
Значение (string): SHA-256 от содержимого файла с префиксом sha256:

Формат аудит-лога:

Текстовый журнал с разделителями-пробелами. Каждая строка содержит:

<YYYY-MM-DDTHH:MM:SS+TZ> [<УРОВЕНЬ>] <сообщение>  [поле=значение  ...]

Формат лога инсталлятора:

Текстовый журнал с разделителями-пробелами. Каждая строка содержит:

time=<YYYY-MM-DDTHH:MM:SS+TZ> level=<УРОВЕНЬ> msg="<сообщение>" [поле=значение ...]

Как проверить:

# Получить суммы в машиночитаемом JSON
pamirctl sums -o /tmp/digests.json
cat /tmp/digests.json | jq .

# Получить суммы конфигурационных файлов
pamirctl sums --show-config -o /tmp/configs.json
cat /tmp/configs.json | jq .

# Проверить структуру полей
jq 'keys[0]' /tmp/digests.json          # → "pamir.io/auth:2.0.0"
jq '.[keys[0]]' /tmp/digests.json       # → "sha256:cc464c......"
jq '.[keys[0]] | startswith("sha256:")' /tmp/digests.json  # → true

Протоколы передачи информации на сервер информационной безопасности

§ 4.3.4

Как реализовано:

Передача контрольных сумм и аудит-логов в наложенные СЗИ обеспечивается стандартными средствами ОС. В документации предоставлены примеры для следующих протоколов:

SSH/SFTP/SCP (рекомендуется как защищённый протокол):

# Выгрузить актуальные эталонные суммы на сервер ИБ по SCP
pamirctl sums -o /tmp/sums-$(date +%Y%m%d).json
scp /tmp/sums-$(date +%Y%m%d).json security-server:/opt/integrity/pamir/

# Выгрузить аудит-логи по SFTP
sftp security-server <<EOF
put ~/.pamirctl-audit-*.log /opt/logs/pamir/
EOF

# Выгрузить через SSH-туннель (для сред с ограниченным доступом)
cat ~/.pamirctl-audit-*.log | ssh security-server "cat >> /opt/logs/pamir/audit.log"

REST (HTTP/HTTPS):

# Отправить суммы на HTTP-сервер ИБ
pamirctl sums -o - | curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${SIB_TOKEN}" \
  --data-binary @- \
  https://sib-server/api/integrity/update

# Отправить аудит-лог
curl -X POST \
  -H "Content-Type: text/plain" \
  --data-binary @~/.pamirctl-audit-$(date +%Y-%m-%d)*.log \
  https://sib-server/api/logs/pamir

Приоритет отдаётся защищённым протоколам (SSH, SFTP, SCP, HTTPS). При невозможности применения защищённых протоколов в качестве компенсирующей меры рекомендуется использование шифрования на уровне сети (VPN, IPsec).

Как проверить:

# Убедиться что pamirctl sums поддерживает вывод без цветового форматирования
pamirctl sums -o /dev/stdout | head -5
# Ожидается: валидный JSON без ANSI escape-последовательностей

# Проверить доступность аудит-логов для чтения системными агентами
ls -la ~/.pamirctl-audit-*.log
# Ожидается: файлы доступны для чтения от имени пользователя, запустившего pamirctl

Описание параметров и настроек, подлежащих контролю, в эксплуатационной документации

§ 4.3.5

Как реализовано:

В эксплуатационной документации (раздел «Установка», installation.md) описаны:

Контролируемые объекты:

Объект	Тип	Механизм контроля
Образы контейнеров (все сервисы приложения и зависимости)	Бинарные модули	`ImageID` (SHA-256 config_blob), `verifier.Verify()`
`.env` — основные параметры сервисов (порты, пароли, URL)	Конфигурация	SHA-256 файла, `verifier.VerifyConfigs()`
`.*.autogen` — автогенерируемые переменные окружения	Конфигурация	SHA-256 файла
`docker-compose*.yml` — топология и параметры запуска сервисов	Конфигурация	SHA-256 файла; также встроены в `pamir-installer`
`init/database/*.sh` — скрипты инициализации БД	Скрипты	SHA-256 файла
`pamirctl` — исполняемый файл утилиты управления	Бинарный модуль	SHA-256 файла (в `files.sha256`)
`pamir-installer` — исполняемый файл инсталлятора	Бинарный модуль	SHA-256 файла (в `files.sha256`)

Как проверить:

# Убедиться что все контролируемые файлы представлены в configs.json
pamirctl sums --show-config | jq 'keys'

# Убедиться что исполняемые файлы присутствуют в files.sha256 на ISO
grep -E "pamirctl|pamir-installer" /media/cdrom0/files.sha256

Итоговая таблица соответствия

Требование	§	Статус	Реализация
Контрольное суммирование модулей	3.3.1	Выполнено	SHA-256 ImageID образов, `verifier.Verify()` в `pamirctl` и `pamir-installer`
Контроль целостности настроек	3.3.2	Выполнено	SHA-256 конфигурационных файлов, `verifier.VerifyConfigs()` + `files.sha256` на ISO
Контроль при запуске и по запросу	3.3.3	Выполнено	Автоматически при `start`/`restart`; `pamirctl sums` и `sha256sum --check` по запросу
Периодический контроль в процессе функционирования	3.3.4	Выполнено	Режим демона `pamirctl --daemon`: периодическая проверка ImageID, readonly ФС; блокировка нарушителей через Docker Events API; интеграция с systemd
Защищённое хранение эталонных значений	3.3.5	Выполнено	Встраивание в бинарник (`//go:embed`); ISO (read-only); Nexus с авторизацией
Блокировка при несоответствии сумм образов	3.3.6	Выполнено	`verifier.Verify()` блокирует `start`/`restart`/`install` при несоответствии ImageID
Эталонные суммы от разработчика при обновлении	3.3.7	Выполнено	Автоматическая генерация `digests.json`, `images.sha256`, `files.sha256` в CI/CD при каждой сборке
Регистрация изменений контролируемых объектов	3.5.12	Выполнено	Лог инсталлятора: имя файла/образа, старое и новое значения суммы, пользователь
Регистрация запуска и завершения КЦ	3.5.13	Выполнено	Аудит-лог: события start/end + учётная запись + результаты
Расчёт контрольных сумм для файлов ПО	4.3.1	Выполнено	SHA-256 в CI/CD (`generate_artifacts.sh`) и в runtime (`pamirctl`, `pamir-installer`)
Регистрация и локальное хранение в допустимом формате	4.3.2	Выполнено	Структурированный текстовый файл с разделителями; JSON-формат (`digests.json`, `configs.json`)
Описание формата передаваемых сведений	4.3.3	Выполнено	Описано в документации (см. п. 4.3.3 настоящего документа)
Протоколы передачи на сервер ИБ	4.3.4	Выполнено (документация)	Примеры для SCP, SFTP, SSH, HTTPS в документации
Описание параметров и настроек в документации	4.3.5	Выполнено	Перечень контролируемых объектов в `installation.md` и настоящем документе

Обзор архитектуры контроля целостности​

Контроль целостности модулей ПО с использованием контрольного суммирования​

Контроль целостности настроек прикладного ПО с использованием сверки с эталонными значениями​

Контроль целостности при запуске ПО и по запросу пользователя (администратора)​

Периодический контроль целостности модулей ПО в процессе функционирования​

Хранение эталонных контрольных сумм в защищённом виде​

Блокировка загрузки ПО при несоответствии эталонным значениям контрольных сумм​

Эталонные суммы предоставляются разработчиком, в том числе при обновлении, в формате, пригодном для механизмов контроля​

Регистрация изменения перечня модулей и их эталонных контрольных сумм​

Регистрация запуска и завершения процедуры контроля целостности​

Расчёт контрольных сумм для файлов программного обеспечения​

Регистрация информации и её локальное хранение​

Описание формата сведений, передаваемых в наложенные средства защиты​

Протоколы передачи информации на сервер информационной безопасности​

Описание параметров и настроек, подлежащих контролю, в эксплуатационной документации​

Итоговая таблица соответствия​

Обзор архитектуры контроля целостности

Контроль целостности модулей ПО с использованием контрольного суммирования

Контроль целостности настроек прикладного ПО с использованием сверки с эталонными значениями

Контроль целостности при запуске ПО и по запросу пользователя (администратора)

Периодический контроль целостности модулей ПО в процессе функционирования

Хранение эталонных контрольных сумм в защищённом виде

Блокировка загрузки ПО при несоответствии эталонным значениям контрольных сумм

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

Регистрация изменения перечня модулей и их эталонных контрольных сумм

Регистрация запуска и завершения процедуры контроля целостности

Расчёт контрольных сумм для файлов программного обеспечения

Регистрация информации и её локальное хранение

Описание формата сведений, передаваемых в наложенные средства защиты

Протоколы передачи информации на сервер информационной безопасности

Описание параметров и настроек, подлежащих контролю, в эксплуатационной документации

Итоговая таблица соответствия