ThothII/docs/operations/psd-dwh-auth-rollout.md

PSD — rollout controllato DWH REST

Questo runbook rispecchia i Task 9–10 del piano. È descrittivo: non autorizza mutazioni ora. Activity 1 PSD resta IN_DISCUSSION fino a due consensi espliciti separati.

Invarianti

• ThothII sul server PSD: postgres_direct read-only, senza chiave dwh-auth.
• Mac PSD e client remoti: rest_api, una chiave per installazione, HTTPS .it verificato.
• dwh-auth è systemd indipendente, non Compose; non fermare o sostituire il vecchio stack ora.
• Sessioni legacy, indici Qdrant e cache Ollama sono dati test: nessuna migrazione o backup per il cutover. Il vecchio stack resta comunque fino a cutover/rollback approvati.
• Usare solo /dwh/rpc/ping, mai risultati clinici o catture Nginx grezze.

Gate A — Task 9, servizio locale senza Nginx pubblico

Richiedere prima autorizzazione per SHA congelato, target, rollback e impatto legacy. Senza consenso, fermarsi e registrare solo IN_DISCUSSION.

1. Verificare in sola lettura architettura, gruppo www-data, nomi liberi, systemd, nginx -t, ping attuale e file legacy regolare root:root 0600; non leggerlo, stamparlo o calcolarne hash.
2. Costruire con bash scripts/build-dwh-auth.sh --output /tmp/dwh-auth-release; registrare solo SHA sorgente e checksum binario.
3. Installare binario/unit/tmpfiles come nella guida server: registry root:dwh-auth 2750, lock/record 0640, socket dwh-auth:www-data 0660.
4. Importare una sola legacy legacy-shared dal file protetto e creare psd-mac-primary in nuovo file 0600 sotto /root/dwh-auth-provision/; mai segreti in argv, ambiente, log o evidenze.
5. Eseguire dwh-auth check, systemd-analyze verify, avviare l'unità e testare sul socket Unix con config curl protette 0600: nuova=204, legacy=204, casuale=401, assente=401.
6. Salvare solo ID pubblici, owner/mode, stato unit/socket, timestamp, checksum binario/config e rollback. Non modificare Nginx in questo gate.

Gate B — Task 10, Nginx e client

Serve un secondo consenso: presentare file, backup, canale consegna Mac, osservazione ed esiti 204/401/503.

1. Creare copie timestampate root:root 0600 di /etc/nginx/sites-available/policlinicosandonato e file coinvolti; non allegare configurazioni Nginx grezze alle evidenze.
2. Aggiungere solo /etc/nginx/conf.d/dwh-auth-rate-limit.conf e route DWH; preservare upstream http://127.0.0.1:3001/, mantenere byte-identiche le location vector e rimuovere la chiave prima di PostgREST.
3. Eseguire checker strutturale, scansione con solo esito, diff limitato e sudo nginx -t. Se uno fallisce, ripristinare backup prima di reload e registrare FAIL sanitizzato.
4. Dopo consenso fare reload, poi HTTPS .it con CA e config curl protette: legacy=204, nuova=204, casuale=401, assente=401 su /dwh/rpc/ping; guasto autenticatore=503, mai accesso permissivo.
5. Consegnare al Mac chiave e CA separatamente, verificare fingerprint fuori banda, configurare vault GUI o API_KEY_FILE, poi Validate workspace e Test connections.
6. Dopo osservazione revocare legacy-shared con ragione shared-credential-rotation; nuova=204, legacy=401 e journal limitato senza chiavi/digest.

Rollback e chiusura

Durante dual-key il rollback ripristina solo route/servizio revisionati, verifica nginx -t e fa reload autorizzato. Non ripristina chiavi revocate, PostgreSQL, dati legacy o stack. Scatta per TLS, risposte inattese, salute degradata o assenza di consenso.

Activity 1 diventa PASS solo con nuova positiva, legacy 401, servizio/Nginx validi, log sanitizzati, rollback leggibile e accettazione owner; poi avanza a Activity 2, con programma ancora SURVEY_NO_GO. Compilare evidenza e collaudo.