Vai al contenuto

Modello di Sicurezza

Panoramica

SGV GE.CO gestisce dati personali e amministrativi soggetti a GDPR e normativa italiana sulla privacy. Il sistema implementa autenticazione e autorizzazione a livello di modulo, con meccanismi diversi per ogni componente.

Autenticazione per Modulo

graph LR
    subgraph "Spring Security 3.2"
        GA["GeCo.Alfa"]
        GS["GecoService"]
    end

    subgraph "BASIC Auth"
        MFA["MobileFineAdapter"]
    end

    subgraph "X-Realm Multi-Tenant"
        REST["REST (Quarkus)"]
    end

    subgraph "WildFly Realm"
        ELB["ElaborazioneService"]
        CONN["ConnessioneService"]
        OTT["OtticoService"]
        VPN["VpnMctcService"]
    end

    KC["Keycloak SSO"] -.->|"pianificato"| GA
    AR["ApplicationRealm<br/>(WildFly)"] --> GA
    AR --> MFA
    TR["SGVTenantResolver"] --> REST
Modulo Meccanismo Dettagli
GeCo.Alfa Spring Security 3.2 + ApplicationRealm MAutenticationManager, MSecurityImpl, LoginPresenter, LoginDao. Configurato in spring-security.xml
GecoService Spring Security 3.2 Condivide configurazione con GeCo.Alfa
MobileFineAdapterServer Spring Boot Security + BASIC SecurityConfig class, autenticazione BASIC con ApplicationRealm
REST (Quarkus) Multi-tenant via header Header X-Realm per routing tenant, SGVTenantResolver per isolamento DB
ElaborazioneService WildFly ApplicationRealm Autenticazione a livello container
ConnessioneService WildFly ApplicationRealm Autenticazione a livello container
OtticoService WildFly ApplicationRealm Autenticazione a livello container
VpnMctcService WildFly ApplicationRealm Autenticazione a livello container

Multi-Tenancy

Il modulo REST (Quarkus) implementa multi-tenancy a livello DATABASE:

  1. Ogni richiesta HTTP deve includere l'header X-Realm: <tenant-name>
  2. SGVTenantResolver risolve il tenant dall'header
  3. Hibernate ORM indirizza la connessione al database corretto
  4. Isolamento completo dei dati tra tenant

Errore comune: 500 - No tenant identifier specified indica header X-Realm mancante o invalido.

Sicurezza Integrazioni PA

Tutte le integrazioni con i servizi della Pubblica Amministrazione usano:

Servizio Protocollo Autenticazione
ANPR REST/HTTPS Mutual TLS + certificati client + PDND
PND SOAP/REST HTTPS Mutual TLS + API key
INAD REST/HTTPS OAuth2 + certificati
PagoPA SOAP/HTTPS Mutual TLS + firma richiesta
MCTC FTP over VPN VPN tunnel + credenziali FTP
DocFly SOAP/HTTPS Mutual TLS

Le credenziali di integrazione sono archiviate nel vault cifrato di ConnessioneService (file .properties cifrati sul filesystem WildFly).

Classificazione Dati (GDPR)

Categoria Esempi Livello
Dati personali Nome, cognome, CF, residenza, patente Alto
Dati amministrativi Verbali, sanzioni, ricorsi, punti patente Alto
Dati finanziari Pagamenti PagoPA, importi, rateizzazioni Alto
Dati giudiziari Contenziosi, ricorsi GdP, sentenze Molto alto
Dati di configurazione Template, parametri, contatori Basso
Dati di riferimento Comuni, province, codici violazione Pubblico

Regole di Logging

Cosa Permesso Note
Password, token, chiavi API MAI Nessuna eccezione
Codice fiscale completo MAI Al massimo ultimi 4 caratteri
Dati di pagamento MAI
Azioni utente su verbali/ricorsi SEMPRE Audit trail obbligatorio
Risultati chiamate API (successo/errore) SEMPRE
Eventi autenticazione (login/logout) SEMPRE

Il sistema usa MLogger2 come framework di logging. Livello TRACE per PII deve essere evitato in produzione.

File Protetti

I seguenti file non devono mai essere modificati direttamente:

  • persistence.xml - Configurazione JPA con credenziali datasource
  • *.properties in config/ o resources/ - Possono contenere password DB, API key
  • quartz.properties - Configurazione scheduler
  • keycloak.json / web.xml security constraints
  • Certificati (.key, .pem, .p12) - Mai commitare in Git

Approfondimenti