Filosofia self-service: le operazioni ricorrenti non devono passare da un ticket nostro. Ogni servizio ha un backend web con dashboard operativa, gestione utenti e ruoli, notifiche, audit log immutabile. Accesso solo con 2FA obbligatoria (TOTP o WebAuthn, a scelta dell'utente). Ruoli granulari (admin, operatore, readonly). Conforme a GDPR (registro trattamenti, diritti interessati) e NIS2 (audit log immutabile, gestione incidenti). API REST disponibili per automazione e integrazione con i vostri sistemi.
01La filosofia self-service
Prima delle feature, il principio. Un fornitore IT che costringe a aprire un ticket per creare un utente, resettare una password, aggiungere un inoltro mail, provisionare una VM di test o stampare un report di audit non sta fornendo un servizio: sta vendendo la propria attesa. Noi lavoriamo nel settore da quarant'anni e abbiamo visto cosa succede quando il cliente non ha autonomia operativa — il ticket diventa un imbuto, la tempistica diventa politica, e il fornitore finisce per essere odiato anche quando lavora bene.
Per questo separiamo in modo netto routine da operazioni straordinarie. Tutto ciò che è ricorrente, reversibile, e non richiede competenza sistemistica sta nel backend del servizio e lo fate voi, quando serve, senza passare da noi. Le operazioni straordinarie — migrazioni, cambi di architettura, interventi su incidenti, analisi forensi — restano il nostro mestiere, con ticket, on-call, SLA scritti. È una divisione di responsabilità, non uno scarico.
Conseguenza pratica: un cliente medio apre con noi un ordine di grandezza in meno di ticket rispetto a un fornitore tradizionale a ticket-per-tutto. E le cose che passano da noi sono quelle che richiedono davvero il nostro intervento.
02Cosa copre il backend di ciascun servizio
La struttura di base è identica su ogni servizio che consegniamo, con le specificità del dominio. Quattro aree sempre presenti:
- Dashboard operativa: stato del servizio in tempo reale, metriche rilevanti (uptime, consumi, quote), eventi recenti, allarmi attivi. Pensata per un operatore, non per un dashboard-lover.
- Utenti e ruoli: creare, modificare, sospendere, eliminare account. Assegnare ruoli. Forzare reset 2FA. Invitare nuovi utenti via email con link di onboarding.
- Notifiche configurabili: email, webhook, Slack — per eventi significativi (login sospetti, soglie superate, incidenti). Destinatari modificabili per ruolo o per utente.
- Audit log consultabile: chi ha fatto cosa, quando, da quale IP. Filtri per utente, data, tipo di azione. Esportabile in CSV/JSON per analisi esterne.
| Area | Cosa fate voi (self-service) | Cosa facciamo noi (ticket / on-call) |
|---|---|---|
| Utenti | Creare, sospendere, reset password, 2FA | Federazione SSO, integrazione LDAP/AD |
| Posta | Alias, inoltri, quote, filtri antispam per utente | Record DNS, DKIM, deliverability tuning |
| Virtualizzazione | Start/stop/snapshot VM, consumi, utenti | Cluster, storage, HA, migrazioni live |
| VPN | Provisioning profili, revoca, MFA | Routing, firewall, tunnel site-to-site |
| DR / Backup | Consultare job, ripristini file-level, retention | Ripristino bare-metal, DR geografico |
| Incidenti | Visualizzare, commentare, aprire ticket | Risoluzione, RCA, post-mortem, notifica autorità |
032FA obbligatoria
Nessun utente può accedere a un backend senza secondo fattore. Nessun bypass, nessun workaround, nessun "solo per oggi". Alla prima login l'utente sceglie il metodo:
- TOTP (codice a 6 cifre che ruota ogni 30 secondi): Google Authenticator, 1Password, Authy, Bitwarden, qualsiasi app compatibile RFC 6238.
- WebAuthn / FIDO2: YubiKey fisiche, passkey su iPhone/Android/macOS/Windows. Lo standard moderno, immune a phishing per costruzione crittografica.
Alla prima configurazione viene generato un set di recovery code monouso, da conservare offline. Se l'utente perde il secondo fattore e i recovery code, un admin del cliente può forzare il reset 2FA dal backend — non noi, voi. È un punto importante: la sovranità sull'accesso resta in casa vostra.
Per chi ha esigenze più stringenti (compliance settoriale, ruoli privilegiati) imponiamo WebAuthn-only a livello di policy, escludendo TOTP. Configurabile per ruolo.
04Audit log immutabile
Ogni azione sul backend genera una riga di audit: timestamp, utente, IP, azione, oggetto, esito. Lo storage è append-only — nessun utente, compresi gli admin del cliente e compresi noi, può modificare o cancellare le righe già scritte. Retention minima 13 mesi (per coprire un ciclo di audit annuale con margine), estendibile a 5 anni per settori regolamentati.
Il log è consultabile dal backend con filtri e ricerche, ed esportabile in CSV/JSON/NDJSON per integrazione con SIEM esterni. È pensato per superare un audit di terze parti senza riaprire database sul server: NIS2, ISO 27001, certificazioni settoriali. Chi ha fatto cosa, quando, lo dimostrate con un export.
05Ruoli e permessi granulari
Tre ruoli standard su ogni backend:
- Admin: tutto — utenti, configurazioni strutturali, integrazioni, cancellazione dati.
- Operatore: operazioni quotidiane senza cambi strutturali — gestisce utenti, esegue job, consulta log, ma non può alterare la configurazione del servizio né promuovere altri admin.
- Readonly: solo consultazione — utile per auditor interni, DPO, responsabili compliance, personale in formazione.
Per grandi organizzazioni con deleghe articolate definiamo ruoli custom: matrici di permessi su singole azioni, scope per reparto o per perimetro di risorse. Non è un feature da spot commerciale, è un lavoro di configurazione iniziale che facciamo noi con voi in una sessione dedicata.
06Conformità alle normative
I backend non sono "belli da vedere", sono strumenti di compliance operativa. Coprono tre fronti normativi principali:
- GDPR: registro dei trattamenti generabile dal backend, gestione dei diritti degli interessati (accesso, rettifica, cancellazione, portabilità) con workflow tracciato, log di consenso, DPA pre-configurato sul servizio.
- NIS2: audit log immutabile già citato, workflow di notifica incidenti con timestamping, segregazione dei ruoli, tracciamento degli accessi privilegiati. Chi ricade nel perimetro NIS2 trova già le chiavi che gli servono.
- ISO 27001: allineamento ai controlli A.5-A.8 e A.9 sulla gestione accessi e logging. Non siamo certificati noi, lo siete voi — ma il servizio non vi mette i bastoni tra le ruote, anzi facilita l'evidence collection per il vostro auditor.
07API REST per automazione
Ogni backend ha API REST documentata con specifica OpenAPI 3.0 scaricabile. Questo significa che potete automatizzare qualsiasi operazione fate a mano dal pannello: script interni, integrazioni col vostro ITSM (Jira, ServiceNow), orchestrazione con Ansible/Terraform, webhook verso i vostri sistemi di monitoring.
Gli accessi API usano service account dedicati, separati dagli utenti umani, con token a scadenza configurabile e rate limit per proteggere il backend da automazioni impazzite. I webhook verso endpoint del cliente consegnano eventi significativi in push (login sospetti, job completati, soglie superate), firmati con HMAC per verifica integrità.
Se state costruendo un portale interno o un bot Slack per le operazioni più ricorrenti, l'API è il punto da cui partire — non chiedeteci di "esporre qualcosa": è già esposto.
08Roadmap: pagine dedicate per ogni pannello
Questa pagina descrive il modello comune. Ogni pannello specifico — posta, VPN, virtualizzazione, DR, reti — ha poi particolarità di interfaccia, metriche esposte, workflow specifici del dominio. Descriverli in astratto qui significherebbe perdere in precisione.
Per questo nei prossimi mesi pubblicheremo pagine dedicate a ciascun servizio, con screenshot reali e walkthrough delle operazioni più frequenti. Se nel frattempo volete vedere un pannello specifico in funzione, la strada più rapida è una demo di 30 minuti in videocall — la facciamo sull'ambiente reale, non su una slide.