Синхронизация времени и контроль часов

СТАНДАРТНАЯ ОПЕРАЦИОННАЯ ПРОЦЕДУРА

Синхронизация времени и контроль часов\ в компьютерной системе «n-tst.ru»

Номер СОП: СОП-КС-18

Версия: 1.0

Дата эффективности: 01.11.2026

Планируемая дата пересмотра СОП: 01.11.2028

           ФИО   Должность                                 Подпись   Дата

Утвердил Генеральный директор
Разработал Специалист по клиническим исследованиям

История изменений документа

Версия Дата эффективности Изменения Необходимость тренинга

СОП-КС-18, версия 1.0 01.11.2026 Первоначальный документ. Да

  1. НАЗНАЧЕНИЕ ПРОЦЕДУРЫ

Настоящая Стандартная операционная процедура (СОП) устанавливает порядок настройки, синхронизации и контроля системного времени на серверах и в компьютерной системе «n-tst.ru» (далее --- Система). Процедура обеспечивает точность и неизменность временных меток в журналах аудита, электронных подписях и клинических данных в соответствии с требованиями GCP и 21 CFR Part 11.

  1. ОБЛАСТЬ ПРИМЕНЕНИЯ

Процедура распространяется на:

  • серверы Production и Staging;

  • СУБД PostgreSQL (irk_db, irk_db_stage);

  • Node.js-приложение (server.js);

  • браузеры пользователей (в части отображения времени).

  • НОРМАТИВНО-ПРАВОВАЯ БАЗА

  • 21 CFR Part 11: Electronic Records; Electronic Signatures (США), п. 11.10(e) (временные метки), 11.70 (связь подписи с записью).

  • ICH E6 (R2) Good Clinical Practice: Section 4.9 (Records and Reports).

  • ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems.

  • ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ

Термин Определение

NTP (Network Time Protocol) Протокол синхронизации времени между серверами. UTC Coordinated Universal Time (Всемирное координированное время). Временная метка (timestamp) Значение даты и времени, фиксируемое в БД (например, created_at, signed_at). Часовой пояс (timezone) Локальное смещение относительно UTC (для РФ --- MSK, UTC+3).

  1. ОБЯЗАННОСТИ

  2. Администратор Системы --- настраивает NTP-синхронизацию, проверяет точность часов, ограничивает права на изменение системного времени.

  3. QA --- периодически проверяет корректность временных меток в журналах аудита и подписях.

  4. Разработчик --- обеспечивает, чтобы все timestamp в БД и API создавались в UTC (или MSK с явным указанием часового пояса) и не подменялись на стороне клиента.

  5. ОПИСАНИЕ ПРОЦЕДУРЫ

6.1. Единый стандарт времени

  1. Все временные метки в БД (created_at, updated_at, signed_at, published_at, invalidated_at и др.) хранятся в UTC (тип timestamp with time zone или timestamp without time zone с явным соглашением).

  2. Отображение времени пользователю в браузере --- в локальном часовом поясе (для РФ --- MSK, UTC+3), с явным указанием пояса, если это критично.

  3. В печатных формах (сертифицированные копии, отчёты мониторинга) время указывается либо в UTC с пометкой «UTC», либо в MSK с пометкой «MSK». Смешивать форматы в одном документе запрещается.

6.2. Настройка NTP-синхронизации

  1. На серверах Production и Staging настраивается автоматическая синхронизация времени через systemd-timesyncd (или chrony/ntpd) с надёжными NTP-источниками (например, pool.ntp.org, ntp1.vniiftri.ru).

  2. Проверка статуса синхронизации:

bash

timedatectl status

  1. В выводе должно быть System clock synchronized: yes и корректный NTP service: active.

  2. Администратор обязан проверить синхронизацию после установки сервера, после перезагрузки и после изменений в сетевой инфраструктуре.

6.3. Ограничение прав на изменение времени

  1. Права на изменение системного времени (timedatectl set-time, изменение /etc/timezone) имеют только root и Администратор Системы.

  2. Ручное изменение времени допускается только в исключительных случаях (например, при сбое NTP) и только с фиксацией в Журнале ручных изменений времени (Приложение 1).

  3. В Системе (Node.js) запрещено использовать клиентское время для критичных меток. Все signed_at, created_at и др. должны формироваться на сервере (NOW() в PostgreSQL или new Date() на сервере с проверкой синхронизации).

6.4. Использование времени в электронных подписях

  1. При подписании визита/карты время signed_at формируется на сервере (не в браузере) и записывается в БД.

  2. В подписи фиксируется:

    • signed_at (UTC),

    • IP-адрес,

    • часовой пояс сервера.

  3. Если клиент присылает своё время, сервер его игнорирует и использует своё. Это защищает от подмены времени на стороне пользователя.

6.5. Мониторинг и периодические проверки

  1. Администратор ежемесячно проверяет статус NTP на всех серверах (timedatectl status).

  2. QA при периодическом обзоре Audit Trail (СОП-КС-ЭД-11) проверяет:

    • нет ли записей с временем, «уехавшим» в будущее или в прошлое;

    • нет ли разрывов во временных метках (например, резкий скачок времени на несколько часов);

    • соответствуют ли временные метки подписей времени в первичной документации.

  3. При выявлении расхождений QA инициирует инцидент (СОП-КС-РП-10) и оценку влияния на данные.

6.6. Действия при сбое синхронизации

  1. Если NTP-синхронизация недоступна:

    • Администратор фиксирует инцидент;

    • проверяет, не «уехало» ли время на сервере;

    • при необходимости временно настраивает альтернативный NTP-источник;

    • после восстановления проверяет, не появились ли в БД записи с некорректными метками.

  2. Если время всё же было изменено вручную, все записи, сделанные в этот период, помечаются в Журнале ручных изменений времени и проверяются QA.

<!-- -->
7. ПЕРЕЧЕНЬ ПРИЛОЖЕНИЙ

  • Приложение 1. Журнал ручных изменений системного времени.

Приложение 1. Журнал ручных изменений системного времени.

Приложение 1 к СОП-КС-ЭД-18. Журнал ручных изменений системного времени

№ Дата изменения Сервер (IP) Было (UTC) Стало (UTC) Причина изменения Кто изменил (ФИО) Подпись QA

1 *12.11.2026* (пример) *94.154.11.5* *12:00* *15:00* Сбой NTP, восстановление синхронизации Админ
...

*Подписи:\ Разработал (QA): ___________ / _______________________ / «___» ___ 20__ г.\

Утвердил (Руководитель): ______________ / _____________ / «» _____ 20__ г.