SICUREZZA SVIZZERA & POSTURA DEI DATI

Il controllo del cliente, spiegato con precisione.

La sicurezza inizia dal sapere quali dati un workflow può leggere, quali azioni può eseguire e chi è responsabile quando qualcosa va storto.

Pratiche, non una dichiarazione di certificazione

I principi di implementazione riportati di seguito sono impegni di consegna da concordare nell’ambito di un cliente. Non costituiscono prova di una certificazione di sicurezza né di un audit del cliente completato. La sezione «Cosa fa oggi questo sito web» descrive il comportamento di aifab.ch stesso.

I vostri account. L’accesso minimo.

Le implementazioni in produzione sono progettate per account di proprietà del cliente e credenziali controllate dal cliente. Concordiamo quali identità possono leggere, redigere, approvare ed eseguire; un accesso amministrativo ampio non è lo standard.

Permessi di integrazione, condizioni dei fornitori e requisiti di localizzazione dei dati vengono verificati nella definizione dell’ambito. Il nome di una piattaforma su questo sito non garantisce la compatibilità con ogni politica del tenant o abbonamento.

  • Identità di connessione approvata e un responsabile designato presso il cliente
  • Permessi delimitati per origini e destinazioni
  • Segreti lato server, senza credenziali nei prompt o nel codice client pubblico
  • Responsabilità di revoca e di consegna documentate

Fonti approvate, percorsi dati espliciti.

Confini nidificati di distribuzione e dati sotto il controllo del cliente, comprendenti archiviazione, esecuzione del workflow e approvazione.
Solo confine di riferimento. Hosting, accessi e ripartizione delle responsabilità devono essere documentati per ogni incarico.

L’ambito del workflow stabilisce quali dati sono necessari, quali sistemi li ricevono e quali fornitori li elaborano. Conservazione, registrazione e requisiti transfrontalieri sono decisioni specifiche del cliente, non ipotesi basate sulla sede svizzera di AIFAB.

I permessi delle fonti devono continuare a valere quando le informazioni vengono recuperate e presentate. Dati sensibili, decisioni regolamentate o requisiti settoriali richiedono una verifica esplicita prima dell’implementazione.

Valutare un’implementazione ospitata in Svizzera.

Una sede svizzera non dimostra da sola la residenza dei dati. Un’implementazione proposta sotto il controllo del cliente richiede evidenze sull’intero percorso di trattamento prima di poter essere offerta come opzione validata.

Un percorso di riferimento con pesi aperti ospitato in Svizzera resta non validato. La valutazione deve coprire:

  • Hosting svizzero verificato e titolarità dell'account
  • Archiviazione, log, backup, telemetria e accesso di supporto documentati
  • Evidenza di rete che non vi sia alcuna uscita non approvata verso fornitori di modelli
  • Controlli equivalenti di approvazione, ripiego e accettazione
  • Verifica legale e sulla privacy dei fornitori e delle responsabilità effettivi

L'approvazione concede un'azione definita.

Una revisione dovrebbe mostrare le evidenze, la modifica proposta e ciò che accadrà dopo. Invio, spese, accettazione e modifiche sensibili ai sistemi richiedono l’autorità concordata per quella specifica azione.

Approvare la revisione di un documento o una guida di processo non approva un contratto, un acquisto o una concessione di accesso. Ripetizioni e input modificati non devono ereditare l’approvazione da un risultato non correlato.

Prepararsi agli errori prima del rilascio.

L’accettazione copre input non validi, ambiguità, fonti mancanti e integrazioni non disponibili. La registrazione deve rendere diagnosticabile un errore senza copiare inutilmente dati sensibili.

Prima della produzione si concordano monitoraggio, escalation, ripristino e ritorno a una versione precedente. Ripetere una richiesta non deve duplicare un’azione con conseguenze. Un rollback non può annullare automaticamente un’e-mail già inviata o un altro effetto esterno irreversibile.

  • Configurazione e istruzioni versionate
  • Un percorso di ripristino testato e un responsabile degli incidenti designato
  • Copertura di supporto definita piuttosto che una promessa implicita 24/7
  • Aggiornamenti delle dipendenze e controlli di regressione prima del rilascio

Il Red Button: una pausa in mano al cliente con un percorso manuale.

Responsabile del workflow illustrato mentre verifica il lavoro completato, la gestione delle eccezioni e un passaggio visibile dalla pausa al percorso manuale.
Una pausa arresta i nuovi effetti automatizzati dopo la conferma; le azioni già completate non possono essere richiamate.

AIFAB progetta un controllo assegnato al cliente che trattiene i nuovi effetti automatizzati dopo la conferma della pausa. Il lavoro in coda mantiene il suo stato e i nuovi casi seguono il percorso manuale documentato finché una persona autorizzata non ripristina il funzionamento controllato.

Le cinque dimostrazioni locali espongono questo controllo e mostrano che ripetizione, cambi di scenario e cambio di workflow non lo annullano silenziosamente. Un’implementazione per un cliente richiede comunque evidenze di accettazione specifiche dei sistemi: una pausa non può richiamare un’e-mail o un’altra azione esterna già completata.

  • Autorità di pausa assegnata dal cliente
  • Nuovi effetti automatizzati trattenuti al confine di controllo concordato
  • Gestione manuale, responsabilità e stato in coda preservati
  • Ripristino esplicitamente autorizzato
  • Eventi di controllo delimitati senza dati aziendali

Cosa fa oggi questo sito web.

Le cinque dimostrazioni pubbliche funzionano localmente con set di dati sintetici. Non ci sono caricamenti di documenti, chiamate a modelli in tempo reale, connessioni a sistemi dei clienti né azioni operative.

L’applicazione serve i font localmente. La preferenza di visualizzazione usa lo storage locale. Il Workflow Fit Checker e il ROI Calculator funzionano localmente; la consegna strutturata facoltativa di un risultato e le informazioni di attribuzione delimitate usano lo storage di sessione della scheda per un massimo di 30 minuti. Nessuna descrizione dell’attività in testo libero e nessun dato di contatto vengono salvati lì.

Gli endpoint per il contatto e l’invio dei risultati validano gli input e si chiudono in sicurezza quando la consegna o la protezione condivisa contro gli abusi non è disponibile. Resend gestisce l’invio e-mail richiesto e una risorsa Upstash Redis applica la protezione condivisa contro gli abusi. L’applicazione non tiene un database delle richieste. I servizi di analisi facoltativi non sono attivi al lancio.

Il sito è servito tramite HTTPS con HSTS, una Content Security Policy che blocca script remoti, frame ed eval, una protezione contro il MIME sniffing e una politica restrittiva sul referrer. Script e stili inline restano consentiti per il rendering statico.

Segnalare un problema di sicurezza.

Utilizzate l'opzione Segnalazione di sicurezza nel modulo di contatto protetto, indicando una descrizione concisa, la pagina o il servizio interessato e un modo sicuro per contattarvi. Nel primo messaggio non includete password, token di accesso, dati dei clienti o codice exploit.

AIFAB confermerà la ricezione della segnalazione, concorderà se necessario un canale sicuro e coordinerà la verifica e la correzione. Non eseguite test sui sistemi dei clienti e non accedete a dati che non vi appartengono.

ULTERIORI INFORMAZIONI

Guida IFPDT sulla sicurezza dell’informazione

Linee guida ufficiali e informazioni dei fornitori pertinenti alla presente informativa.

IL PROSSIMO PASSO UTILE

Capire come è costruito il workflow.

Leggete l’architettura di riferimento, i confini delle decisioni umane e i casi di accettazione alla base di un’implementazione delimitata.