Смяна на оперативните данни за достъп

LOSPOR Hospital има поддържана двуетапна процедура на сървъра за обикновените данни за достъп. Не е необходимо операторът да редактира ръчно .env, файлове на Status, SQLite или PostgreSQL.

Изпълнявайте процедурата само от конзолата на системата като root:

sudo sh /opt/lospor-hospital/current/scripts/rotate-operational-secrets.sh prepare ordinary
sudo sh /opt/lospor-hospital/current/scripts/rotate-operational-secrets.sh state
sudo sh /opt/lospor-hospital/current/scripts/rotate-operational-secrets.sh commit

Обобщенията и грешките за оператора следват LOSPOR_DEFAULT_LOCALE (по подразбиране български). Външен техник може да постави LOSPOR_DEFAULT_LOCALE=en пред една команда, за да я прочете на английски. Означенията за действия, обхвати, етапи, променливи на средата, роли и файлове остават еднакви на двата езика, за да няма неяснота в процедурите и одита.

prepare създава чакаща транзакция с права 0600 в secrets/rotation/ и не променя работеща услуга. Прегледайте показаните обхват и поколение, след което изпълнете commit. С rollback отхвърлете или отменете подготвената транзакция. При неуспешно прилагане командата автоматично опитва да върне и провери предишното състояние. Ако това не може да бъде доказано, транзакцията остава в ROLLBACK_REQUIRED; не отгатвайте състоянието, не премахвайте файлове и не започвайте друга смяна.

След проверката инструментът първо отбелязва транзакцията като COMMITTED, а после премахва защитеното копие на старите стойности. Затова грешка при почистването на файловете никога не може да отмени вече проверена смяна. В този тесен случай state показва проблема. Поправете посочените собственост или права и изпълнете:

sudo sh /opt/lospor-hospital/current/scripts/rotate-operational-secrets.sh cleanup

cleanup приема само защитена транзакция, чийто идентификатор и метаданни заедно доказват, че тя е достигнала COMMITTED. Командата никога не променя работещи данни за достъп.

Командата използва общото заключване .data/io-mutation.lock заедно с архивирането, възстановяването и активирането на версия. Затова смяна на данни за достъп не може да съвпадне с архив или обновяване. Всеки етап се добавя в .data/security/secret-rotations.v1.jsonl само с идентификатор на транзакцията, обхват, поколение, време и фиксиран етап. Тайните стойности никога не се записват в този одит, аргументи, изхода на конзолата или журналите на контейнерите.

Поддържани обхвати

Обхват	Какво се сменя	Очакван резултат
sessions	LOSPOR_AUTH_SECRET	Всички сесии на Web/PWA/мобилното приложение и връзки за печат се обезсилват умишлено. Потребителите влизат отново. Старият ключ за сесии не се приема.
workers	данните за достъп за доставка, научен износ, срока за съхранение/планираните задачи и снимката на справочните опции	API първо приема текущата и предишната стойност, работните услуги преминават към новата, изпълнява се проверка, след което старата стойност се премахва и се доказва, че е отказана.
status-tokens	токените за снимката на състоянието, акаунтите/управлението, събитията от API и паролата на PostgreSQL ролята само за проверка	Status и API временно приемат двете поколения. Доказателството за самоличността на оператора се обвързва с точния токен на заявката. Паролата на ролята за проверка се сменя в същата транзакция с възможност за отмяна. Сесиите и MFA на Status не се променят.
database	паролите на ролята собственик lospor и API ролята lospor_app	Двете роли, .env, PostgreSQL, миграторът, API, архивирането и зависимите услуги преминават заедно в една транзакция за поддръжка. За всяка роля приемането на новата парола и отказът на старата се проверяват през адреса на услугата, където паролите се изискват.
ordinary	четирите обхвата по-горе	Едно поколение и една транзакция за поддръжка. Това е обичайната планирана смяна.

Поредното поколение се пази като HOSPITAL_OPERATIONAL_SECRET_GENERATION. При смяна на работните услуги временните променливи *_PREVIOUS съществуват само по време на застъпването. Успешният commit ги премахва и пресъздава засегнатите услуги, преди да запише COMMITTED.

Независимата парола на системния оператор използва съществуващата транзакция между клиничната база и Status и има собствен жизнен цикъл на MFA. Сменете я отделно:

sudo sh /opt/lospor-hospital/current/scripts/appliance-operator.sh rotate
sudo sh /opt/lospor-hospital/current/scripts/appliance-operator.sh verify

Умишлено извън тази команда

Не използвайте обикновената смяна за HMAC/криптографските ключове на пациентите, ключовете за псевдоними при износ, удостоверяването на манифестите за архив, криптографските ключове за MFA на администраторите или Status, ключа за запечатване на външния ИИ, доверието за подписване на версии или самоличността с mTLS/подписване между Hospital и Central. Тези стойности защитават записан шифротекст, стабилно свързване, настроени приложения за удостоверяване, архиви или самоличност в отдалечен протокол. Пряката им замяна прави данните нечетими или нарушава поредността и оттеглянията към Central.

Смяната на самоличността Hospital ↔ Central изисква изричен протокол, който запазва същия сайт и история на поредността, докато Central разрешава новите отпечатъци на сертификата и ключа за подписване. Докато такъв протокол не е наличен, спрете доставката, запазете опашката/потвържденията, отменете сайта в Central и следвайте процедурата при инцидент. Никога не презаписвайте файловете с твърдението, че това е смяна.

Приемателно упражнение

На временна Linux система подгответе и приложете всеки отделен обхват и ordinary, след което проверете:

1. API, Status, PostgreSQL, Web/PWA, Browser, архивирането и работната услуга за доставка стават работоспособни в документирания прозорец за поддръжка;
2. старите данни за достъп на работните услуги, Status и базата се отказват след застъпването;
3. след sessions старите сесии се отказват, а нов вход е успешен;
4. входът и MFA на системния оператор в Status продължават да работят след status-tokens;
5. архив след смяната се удостоверява и се възстановява изолирано; и
6. одитът съдържа етапите, но нито една стара или нова тайна стойност.

Договорният тест под Windows доказва двуетапната работа с файловете, почистването след непубликувано подготвяне, премахването на застъпването, автоматичната отмяна, границата между прилагане и почистване, отказа на твърди връзки и липсата на тайни в одита. Истинското упражнение с контейнери, PostgreSQL и измерена недостъпност остава задължителна проверка за версията под Linux.