Vai al contenuto

Installazione conforme per la PA

Questa pagina è per l'ufficio IT e il Responsabile per la transizione digitale (RTD). Elenca, norma per norma, cosa fa già il software e cosa resta da fare in fase di installazione e messa in esercizio.

Da validare

La checklist è un supporto tecnico. Classificazione dei dati, valutazioni d'impatto e atti formali vanno confermati con RTD, RPD e Segretario comunale.

Checklist

Ambito Riferimento Cosa fa il software Cosa fa l'IT all'installazione
Riuso e open source CAD artt. 68-69; Linee guida AgID su acquisizione e riuso del software Licenza EUPL-1.2, publiccode.yml Pubblicare il riuso su Developers Italia; valutazione comparativa ex art. 68 nell'atto di adozione
Cloud Regolamento ACN per le infrastrutture e i servizi cloud della PA Container Docker, nessun servizio esterno obbligatorio Ospitare su infrastruttura o servizio cloud qualificato ACN adeguato alla classificazione dei dati
Identità digitale CAD art. 64; regole tecniche SPID e CIE Adapter identity con attributi minimi (CF, nome, cognome, email) Collegare il gateway SPID/CIE del portale o un proxy OIDC certificato, sostituendo MockIdentity
Pagamenti CAD art. 5; Linee guida pagoPA Dovuto con importo e causale esatti, IUV per prenotazione, verifica idempotente Chiedere a Regione Puglia l'accesso MyPay SIL, completare MyPaySILGateway e il job di verifica dei pagamenti
Design Linee guida di design per i servizi digitali della PA Bootstrap Italia 2.18.3 ospitato in locale con verifica sha512 Link dalla sezione Prenota appuntamento del portale
Accessibilità L. 4/2004; Linee guida AgID sull'accessibilità; WCAG 2.1 AA / EN 301 549 Render lato server, funziona senza JavaScript; audit axe-core senza violazioni Test con utenti; aggiornare la dichiarazione di accessibilità su form.agid.gov.it
Protezione dati GDPR artt. 6.1.e, 25, 28, 30, 32 Minimizzazione: telefono facoltativo, CF escluso dagli export; cookie solo tecnico Registro dei trattamenti, nomina del fornitore come responsabile, informativa validata dal RPD, tempi di conservazione
Sicurezza ICT Misure minime di sicurezza ICT per le PA (circolare AgID 2/2017) CSRF, cookie firmati, QR firmati HMAC, anti open-redirect, container non-root, inferenza non esposta HTTPS, segreti robusti, rate limiting, log di audit, backup, aggiornamenti, vulnerability assessment
Interoperabilità Linee guida AgID sull'interoperabilità tecnica API REST documentate in OpenAPI (/api/docs) Valutare la pubblicazione su PDND se le API servono ad altri enti
Intelligenza artificiale AI Act (Reg. UE 2024/1689) art. 50; L. 132/2025; Linee guida AgID per l'IA nella PA Trasparenza in interfaccia, decisione umana, redazione dei dati personali, tracciabilità del motore Valutazione d'impatto prima di attivare un LLM; iscrizione nel registro dei sistemi IA dell'ente

Messa in esercizio passo per passo

1. Infrastruttura

  • Una VM o un servizio container su cloud qualificato ACN, con almeno 1 vCPU e 1 GB di RAM per app e motore a regole. Un LLM locale (--profile llm) richiede almeno 4 vCPU e 8 GB di RAM.
  • Docker Engine e Compose v2, con aggiornamenti di sicurezza automatici del sistema operativo.
  • Database: PostgreSQL 17. Si può usare il container spazio-comune-db del pacchetto oppure, meglio in esercizio, un PostgreSQL gestito sul cloud qualificato (DATABASE_URL con sslmode=require), che offre backup, cifratura a riposo e ripristino a un istante preciso.

2. Rete e HTTPS

Mettere un reverse proxy davanti all'app, con TLS 1.2 o superiore e certificato valido. Pubblicare solo la porta dell'app: il server di inferenza e Ollama restano sulla rete interna di Compose.

server {
  listen 443 ssl http2;
  server_name prenota.comune.example.it;
  ssl_protocols TLSv1.2 TLSv1.3;
  add_header Strict-Transport-Security "max-age=31536000" always;
  limit_req zone=prenota burst=20 nodelay;     # rate limiting

  location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

3. Configurazione e segreti

cp .env.example .env && chmod 600 .env
# BASE_URL=https://prenota.comune.example.it
# SECRET_KEY, UFFICIO_PASSWORD, CUSTODE_PASSWORD, FEED_TOKEN: valori casuali robusti
# COOKIE_SECURE=true
docker compose up --build -d

Il significato di ogni variabile è in Configurazione (.env). In esercizio i segreti vanno in un vault o nei secret della piattaforma, non in chiaro sul disco.

4. Backup e continuità

# backup giornaliero del database PostgreSQL (container spazio-comune-db)
docker exec spazio-comune-db pg_dump -U spazio -Fc spazio_comune > /backup/spazio-comune-$(date +%F).dump

Conservare i backup cifrati su un sito diverso e provare il ripristino almeno una volta prima del pilota.

5. Log, monitoraggio e aggiornamenti

  • Healthcheck: GET /api/v1/health (app) e GET /health (inferenza), già usati dai container.
  • Centralizzare i log (docker logs spazio-comune-app) con una conservazione coerente con l'informativa privacy.
  • Aggiornare con regolarità le immagini e le dipendenze Python, ad esempio con pip-audit e una scansione delle immagini in CI.

6. Prima del pilota

  • HTTPS attivo e COOKIE_SECURE=true
  • Segreti robusti e non versionati
  • Integrazioni MyPay SIL e SPID/CIE collaudate in ambiente di test
  • Backup provato
  • Registro dei trattamenti e informativa approvati dal RPD
  • Dichiarazione di accessibilità aggiornata
  • Valutazione d'impatto IA (se si attiva un LLM)
  • Repository pubblico e publiccode.yml aggiornati