La configurazione di Amazon Databricks S3 ha appena eliminato 140 righe di policy IAM
La connettività di Amazon Databricks è cambiata il 23 luglio 2026, quando Databricks ha introdotto una configurazione automatizzata di S3 basata su autorizzazioni AWS temporanee. Secondo l’azienda, il nuovo flusso sostituisce attività che in precedenza richiedevano una trust policy di 140 righe, autorizzazioni per bucket, CloudFormation e ripetuti passaggi tra console.
Potrebbe sembrare un normale miglioramento della configurazione. È più rilevante perché il processo precedente si collocava direttamente tra i dati archiviati e quasi tutti i carichi di lavoro utili di Databricks. Ingestion, analytics, governance e le più recenti architetture transazionali dipendono tutti dalla corretta connessione dello storage.
Il confronto non è quindi tra Databricks e un’altra piattaforma dati. È tra provisioning automatizzato e il modello di controllo manuale di cui molti team di sicurezza continuano a fidarsi. Databricks deve dimostrare che meno passaggi di configurazione non significano revisioni più deboli, accessi più ampi o un’infrastruttura meno visibile.
AWS fornisce il meccanismo alla base di questa argomentazione. La sua funzionalità di delega temporanea consente ai partner qualificati di richiedere autorizzazioni limitate e con scadenza per azioni di configurazione definite. L’autorizzazione scade, ma un ruolo IAM approvato può rimanere attivo per la connessione S3 continuativa.
Il risultato sposta il lavoro più complesso dell’onboarding di Amazon Databricks dalla scrittura delle policy alla revisione delle autorizzazioni. È un cambiamento utile, ma non elimina le decisioni di sicurezza. Le concentra in una finestra di approvazione più breve, nella quale identità, ambito del bucket, crittografia e accesso continuativo richiedono comunque grande attenzione.
Cosa è cambiato nella connessione Amazon Databricks S3
Databricks ha trasformato un’attività infrastrutturale che richiedeva più console in un flusso guidato dalle approvazioni all’interno del proprio workspace.
Una connessione S3 inizia con un external location, un oggetto Unity Catalog che associa un percorso di cloud storage a credenziali. Unity Catalog è il livello di governance di Databricks per dati e altre risorse distribuite tra i workspace.
Il percorso precedente richiedeva modifiche coordinate in due sistemi amministrativi. Un utente o amministratore cloud doveva creare un ruolo IAM, definirne le autorizzazioni e configurare la trust cross-account. Doveva inoltre concedere il corretto accesso al bucket e registrare gli oggetti corrispondenti in Databricks.
Ogni componente rappresentava un’opportunità distinta di errore. Un Amazon Resource Name errato poteva puntare alla risorsa sbagliata. Un’azione sul bucket mancante poteva interrompere un job in seguito. Una trust policy poteva consentire il principal sbagliato o impedire a Databricks di assumere il ruolo.
Databricks afferma che il nuovo flusso di connessione S3 riduce questa sequenza a poche azioni guidate. Un utente seleziona un bucket S3 e un livello di accesso, quindi accede ad AWS per verificare le autorizzazioni.
Se l’utente dispone di autorità sufficiente, può approvare una richiesta di delega con durata limitata. Chi non dispone di tale autorità può inviare la richiesta a un amministratore AWS dallo stesso flusso.
Databricks esegue quindi il provisioning delle risorse richieste. Secondo l’azienda, crea un ruolo IAM con autorizzazioni a privilegio minimo e configura la trust policy cross-account. Crea inoltre la storage credential e registra un external location associato al bucket selezionato.
Auto Loader e File Events vengono abilitati automaticamente. Auto Loader elabora in modo incrementale i nuovi file cloud in arrivo, mentre File Events fornisce notifiche che possono ridurre le operazioni ripetute di elenco delle directory.
La distinzione tra accesso temporaneo per la configurazione e accesso continuativo ai dati è importante. Databricks afferma che l’autorizzazione temporanea scade dopo il provisioning. Il ruolo IAM creato per il normale funzionamento rimane, perché Databricks necessita comunque di un’identità approvata per leggere o scrivere dati S3 selezionati.
Questo design segue il modello AWS documentato. La delega temporanea può autorizzare un partner a configurare risorse per un periodo limitato. AWS fissa a 12 ore la durata massima dell’accesso delegato.
AWS richiede inoltre un permission boundary per un ruolo IAM creato tramite questo meccanismo. Un permission boundary stabilisce le autorizzazioni massime che una policy basata sull’identità può concedere. Non concede accesso in modo indipendente.
Questo boundary fornisce una protezione utile, ma non sostituisce la revisione della policy del ruolo. Gli amministratori devono comunque confermare che le azioni e le risorse richieste corrispondano al percorso del bucket previsto.
La nuova esperienza è disponibile in Catalog Explorer, nella sezione External Locations. La documentazione Databricks identifica la configurazione automatizzata come metodo preferito per la maggior parte delle implementazioni, mantenendo al contempo alternative manuali e programmatiche.
Si tratta di una scelta di prodotto importante. Databricks non ha eliminato i percorsi SQL, a riga di comando, Terraform o tramite console manuale. Ha aggiunto un’impostazione predefinita che privilegia il provisioning guidato, lasciando ai team infrastrutturali un percorso per una gestione ripetibile basata sul codice.
Il cambiamento immediato è quindi circoscritto e concreto. Databricks ora gestisce la generazione delle policy e la registrazione delle risorse dopo che un’identità AWS ha approvato una richiesta delimitata. La questione più ampia è se le aziende considereranno questa automazione una standardizzazione più sicura o un’astrazione indesiderata.
Perché una connettività S3 più semplice ha un’importanza sproporzionata
La connettività dello storage non è un’integrazione periferica, perché determina se Databricks può governare, elaborare ed esporre i dati esistenti di un’organizzazione.
Molte organizzazioni conservano già record operativi, log applicativi, contenuti multimediali, dati di addestramento e dataset analitici in Amazon S3. Spostare questi oggetti esclusivamente per iniziare a utilizzare un’altra piattaforma introdurrebbe costi, duplicazioni e problemi di ciclo di vita.
Un external location consente a Databricks di lavorare con un percorso S3 definito, mentre l’organizzazione continua a gestire lo storage sottostante. La connessione fornisce a Unity Catalog una credenziale approvata e un confine governato per quel percorso.
Il pertinente modello Unity Catalog utilizza due oggetti securable. Una storage credential rappresenta il meccanismo di autenticazione, come un ruolo AWS IAM. Un external location combina tale credenziale con un percorso di storage.
Databricks può quindi concedere o revocare privilegi sull’external location. Questi controlli regolano chi può creare tabelle esterne, volumi esterni o posizioni di storage gestito rispetto a quel percorso.
Questa separazione aiuta i team dati a evitare di distribuire credenziali AWS ai singoli utenti. Analisti e ingegneri possono lavorare tramite le autorizzazioni Databricks invece di ricevere accesso diretto al bucket.
L’accesso diretto può creare una lacuna di governance. Databricks avverte che le identità che raggiungono lo storage gestito al di fuori di Unity Catalog possono aggirarne i controlli di accesso. Tali azioni possono inoltre sfuggire ai registri di audit e di lineage di Databricks.
La nuova configurazione riduce una barriera all’uso di questo percorso governato. Prima del cambiamento, i team potevano comprendere l’architettura di destinazione ma rimanere bloccati dal coordinamento tra data engineer, responsabili della piattaforma e amministratori AWS.
Questo coordinamento è particolarmente costoso quando le responsabilità sono suddivise. Un data engineer conosce il bucket e il carico di lavoro desiderato. Un amministratore cloud controlla IAM. Un responsabile della governance decide se la posizione debba consentire letture, scritture o ulteriore creazione di oggetti.
Un lungo documento di policy può trasformare questa divisione in un lento scambio di ticket. L’ingegnere fornisce un ARN, l’amministratore crea un ruolo e l’ingegnere lo testa. Una convalida fallita rimanda il lavoro indietro senza identificare chiaramente quale livello abbia causato il problema.
Il provisioning automatizzato cambia l’unità di collaborazione. Invece di chiedere a un amministratore di assemblare la connessione, un utente può inviare una richiesta di delega specifica per la revisione. Il sistema applica quindi la configurazione approvata in modo coerente.
Questo cambiamento spinge i team interni di piattaforma a riconsiderare i propri standard di onboarding. Una policy scritta manualmente non è automaticamente più sicura di una generata. Il lavoro manuale può preservare l’intento, ma può anche riprodurre errori tra account e ambienti.
Allo stesso tempo, un’infrastruttura generata non è automaticamente corretta per ogni azienda. Le organizzazioni spesso aggiungono regole di naming, requisiti di tagging, chiavi di crittografia gestite dal cliente, service control policy e standard di monitoraggio oltre il percorso predefinito di un prodotto.
Il caso d’uso più solido è quindi un’implementazione comune con un ambito del bucket chiaro e normali requisiti di governance. I team possono eliminare l’assemblaggio ripetitivo delle policy mantenendo un passaggio esplicito di approvazione AWS.
Il valore diventa più evidente su larga scala. Una connessione può giustificare un attento lavoro manuale. Decine di account, ambienti e percorsi di bucket possono trasformare piccole differenze di configurazione in costi persistenti di supporto e audit.
Databricks collega inoltre il cambiamento a LTAP, ovvero Lake Transactional/Analytical Processing. LTAP descrive un’architettura che mantiene carichi di lavoro transazionali e analitici su una base condivisa e governata, riducendo repliche e pipeline separate.
Questa visione più ampia dipende dalla facilità di collegare lo storage senza renderlo incontrollato. Un external location semplificato non è sufficiente a realizzare LTAP, ma una configurazione dello storage difficile comprometterebbe l’architettura prima che le applicazioni raggiungano la produzione.
L’integrazione di Amazon Databricks è quindi importante perché porta la governance più avanti nel percorso di adozione. La prima connessione può ora stabilire un confine Unity Catalog invece di incoraggiare una soluzione temporanea che in seguito diventa permanente.
Il provisioning automatizzato mette in discussione il modello predefinito del controllo manuale
Il compromesso centrale è stabilire se un’automazione sottoposta a revisione produca controlli più affidabili delle policy assemblate manualmente.
La configurazione IAM manuale offre visibilità. Un cloud engineer esperto può esaminare ogni azione, principal, schema di risorsa e condizione prima dell’implementazione. L’infrastruttura come codice può inoltre conservare tale configurazione nel controllo di versione.
Questi vantaggi rimangono rilevanti per ambienti regolamentati e strutture di account complesse. Un’azienda potrebbe richiedere la revisione tramite pull request, il controllo automatizzato delle policy o il deployment attraverso un repository centrale della piattaforma cloud.
Il flusso guidato di Databricks affronta un diverso modello di errore. Molte connessioni S3 sono strutturalmente simili, eppure ciascuna richiede un coordinamento preciso tra policy di trust e autorizzazione. Ripetere manualmente questo lavoro non crea necessariamente ulteriore valore di sicurezza.
L’accesso cross-account AWS si basa normalmente su un ruolo nell’account del cliente. La relativa trust policy identifica quale principal esterno può assumerlo, mentre la sua permission policy definisce ciò che quel ruolo può fare.
AWS spiega che i ruoli cross-account delegano autorizzazioni specifiche a un altro account. Il sistema esterno chiama quindi AWS Security Token Service per ottenere credenziali temporanee per il ruolo.
La relazione di trust e l’ambito delle autorizzazioni risolvono problemi diversi. Una trust policy corretta con diritti S3 eccessivi rimane rischiosa. Anche una permission policy ristretta con un principal attendibile errato può creare esposizione.
Databricks afferma che la sua automazione genera sia il ruolo IAM sia la relativa configurazione di trust cross-account. Questo può ridurre errori di sintassi e identificatori non corrispondenti, in particolare per i team che collegano S3 per la prima volta.
Il processo mantiene inoltre l’approvazione AWS del cliente nel ciclo. Il provider avvia una richiesta, ma il cliente valuta se approvarla, rifiutarla o inoltrarla. Un utente non può delegare autorizzazioni che non possiede.
CloudTrail registra l’attività svolta tramite l’autorizzazione delegata. CloudTrail è il servizio AWS che registra l’attività dell’account e le operazioni API. Questi record possono supportare indagini e monitoraggio della conformità.
Questo modello è più difendibile rispetto al concedere a un fornitore un accesso amministrativo permanente. Databricks afferma di non mantenere un accesso permanente all’account dopo la configurazione. L’autorizzazione temporanea al provisioning scade automaticamente.
Tuttavia, “nessun accesso permanente all’account” non va confuso con “nessun accesso continuativo”. Il ruolo IAM creato persiste perché i carichi di lavoro Databricks in corso devono raggiungere le risorse S3 approvate.
Quel ruolo persistente diventa l’oggetto centrale dell’audit. Dopo il deployment, i team di sicurezza dovrebbero esaminarne la policy di trust, il permission boundary, la policy delle identità, le condizioni di sessione e l’effettivo utilizzo di CloudTrail.
Dovrebbero inoltre distinguere il record della delega temporanea dall’infrastruttura risultante. Una richiesta scaduta limita ulteriori attività di configurazione, ma non rimuove un ruolo creato intenzionalmente per il normale funzionamento del servizio.
Il confronto tra automazione e configurazione manuale non ha quindi un vincitore universale. La configurazione automatizzata offre coerenza e minori costi di configurazione. Il deployment gestito come codice offre una personalizzazione più profonda e una traccia di change control familiare.
Databricks preserva entrambi i percorsi nelle sue opzioni per external location. La configurazione automatizzata è consigliata per la maggior parte dei deployment. Restano disponibili i metodi manuali tramite Catalog Explorer, SQL, CLI e Terraform.
Questa coesistenza è importante per l’adozione aziendale. Un team orientato al prodotto può iniziare con il flusso di approvazione, mentre un gruppo centrale di piattaforma può mantenere il provisioning programmatico per ambienti standardizzati.
La pressione ricadrà sui flussi di lavoro manuali che esistono solo perché non era disponibile un’automazione più sicura. Gli amministratori dovranno spiegare quale requisito di policy richieda davvero un deployment personalizzato e quale passaggio rifletta invece soltanto un processo ereditato.
Per i team dati, il vantaggio è un feedback più rapido. Una richiesta non riuscita può far emergere l’autorità mancante prima che qualcuno scriva e distribuisca diverse policy collegate. Una richiesta approvata può creare risorse AWS e Databricks corrispondenti in un’unica sessione.
Per i team di sicurezza, il vantaggio dipende dalle evidenze. Servono contenuti chiari delle richieste, ambiti delle risorse, record CloudTrail e un modo stabile per confrontare i ruoli generati tra account.
La vera misura non è il numero di clic eliminati. È se i ruoli risultanti siano più circoscritti, più coerenti e più facili da esaminare rispetto ai loro predecessori creati manualmente.
Meno passaggi IAM non eliminano le questioni di sicurezza
La nuova configurazione Amazon Databricks riduce il rischio di configurazione, ma i rischi relativi ad autorizzazione, ambito dei dati e ciclo di vita restano a carico del cliente.
La prima domanda è chi possa approvare una richiesta di delega. AWS consente agli utenti di gestire le richieste tramite azioni IAM specifiche, tra cui visualizzare, inoltrare, accettare, rifiutare e rilasciare token di delega.
Le organizzazioni non dovrebbero concedere queste azioni in modo esteso. Un utente che può avviare una connessione non dovrebbe ricevere automaticamente l’autorità di approvare ogni autorizzazione richiesta per ogni account.
AWS supporta l’inoltro di una richiesta a un amministratore quando l’utente originario non dispone delle autorizzazioni richieste. Questo flusso si adatta alle policy di separazione dei compiti, ma solo se gli amministratori verificano la richiesta anziché trattarla come un ticket di routine.
La seconda domanda riguarda l’ambito delle risorse. Una richiesta destinata a un bucket o prefisso non dovrebbe autorizzare storage non correlato. I team devono controllare risorse con wildcard, autorizzazioni di elenco, azioni di scrittura, diritti di eliminazione e accesso alle chiavi di crittografia.
Le autorizzazioni S3 possono essere ingannevolmente granulari. Leggere un oggetto, elencare un bucket, scrivere nuovi dati, eliminare oggetti e lavorare con upload multipart richiedono azioni diverse. Un carico di lavoro potrebbe richiederne diverse, ma raramente necessita di ogni azione S3.
La crittografia aggiunge un ulteriore livello. I dati protetti con una chiave AWS Key Management Service possono richiedere autorizzazioni KMS oltre all’accesso S3. Anche la policy della chiave deve riconoscere il ruolo pertinente.
La terza domanda riguarda il confine di trust. Gli amministratori dovrebbero confermare il principal AWS che può assumere il ruolo risultante e rivedere eventuali ID esterni o restrizioni di sessione.
AWS raccomanda gli ID esterni per l’accesso di terze parti multi-tenant. Un ID esterno aiuta a impedire che un cliente induca un provider a usare il ruolo di un altro cliente, uno scenario noto come problema del deputy confuso.
La quarta domanda riguarda la responsabilità dopo la creazione. Qualcuno deve monitorare il ruolo IAM persistente, aggiornarlo quando cambia il percorso del bucket e rimuoverlo quando l’external location viene ritirata.
L’automazione può creare infrastruttura più velocemente di quanto le organizzazioni riescano a documentarne la responsabilità. Senza controlli sul ciclo di vita, ruoli inutilizzati possono rimanere dopo una proof of concept, una riorganizzazione del team o una migrazione.
La quinta domanda riguarda il drift. Un amministratore potrebbe modificare direttamente il ruolo dopo che Databricks lo ha creato. Un successivo aggiornamento del prodotto potrebbe aspettarsi una struttura di policy diversa, oppure una policy del bucket potrebbe cambiare in modo indipendente.
L’annuncio di Databricks non stabilisce come verrà rilevata o corretta ogni forma di drift. I clienti dovrebbero testare le modifiche in un account controllato e determinare quale sistema possieda la configurazione finale.
La sesta domanda riguarda la compatibilità con i controlli preventivi. Le service control policy di AWS Organizations possono limitare azioni anche quando un ruolo IAM sembra consentirle. Permission boundary e policy delle risorse possono imporre limiti aggiuntivi.
Questo modello a livelli è auspicabile, ma può rendere più difficile la risoluzione dei problemi. Un ruolo generato può apparire corretto mentre un’altra policy impedisce l’accesso. I team hanno comunque bisogno di competenze cloud quando il percorso guidato incontra un’organizzazione complessa.
La registrazione CloudTrail migliora la tracciabilità, ma i log da soli non producono un monitoraggio efficace. I team di sicurezza devono instradare gli eventi rilevanti, definire avvisi, conservare i record e collegare l’attività a una modifica approvata.
Anche le policy di least privilege generate meritano una revisione empirica. Databricks afferma che i ruoli seguono principi di least privilege, ma i clienti dovrebbero confrontare le autorizzazioni richieste con il comportamento effettivo dei carichi di lavoro.
Un pilot utile dovrebbe includere scenari di sola lettura e di lettura-scrittura. Dovrebbe testare un prefisso di bucket, oggetti crittografati, azioni negate, assunzione del ruolo, ingestione degli eventi e rimozione dell’external location.
I team dovrebbero anche confermare che i privilegi di Unity Catalog corrispondano alle autorizzazioni AWS. Un ruolo IAM con ambito ristretto non aiuta se Databricks concede a un gruppo un accesso eccessivamente ampio alla corrispondente external location.
Vale anche il contrario. Grant precisi di Unity Catalog non possono compensare gli utenti che mantengono un accesso S3 diretto al di fuori del percorso governato. Tale percorso può aggirare i controlli Databricks e lasciare una lineage incompleta.
Per questo l’annuncio non dovrebbe essere interpretato come “IAM è risolto”. Databricks ha automatizzato un modello di configurazione noto. Il cliente continua a definire l’autorità accettabile, rivedere la richiesta e gestire la connessione risultante.
Per le organizzazioni con rigidi obblighi di infrastructure as code, il flusso guidato può fungere da implementazione di riferimento anziché da percorso di deployment per la produzione. I team possono ispezionarne l’output e riprodurre i controlli approvati tramite Terraform.
Per i team più piccoli, il flusso automatizzato può diventare l’impostazione predefinita più sicura. La generazione coerente e l’accesso al provisioning circoscritto possono ridurre la probabilità che un utente sotto pressione copi una policy eccessivamente ampia da un esempio obsoleto.
L’esito in termini di sicurezza dipende dal comportamento che l’automazione sostituisce. Sostituire codice revisionato e testato può offrire un valore limitato. Sostituire un lavoro improvvisato nella console può migliorare materialmente la coerenza.
Tre segnali mostreranno se il nuovo flusso funziona
Il prossimo test è l’evidenza dell’adozione, non un’altra affermazione sulla riduzione dei clic.
Il primo segnale è la struttura delle policy IAM generate nei reali account aziendali. I team di sicurezza dovrebbero confrontare gli ambiti delle risorse, le azioni consentite, i permission boundary e le condizioni di trust tra diverse connessioni.
Ruoli coerenti con accesso ristretto ai bucket rafforzerebbero la tesi di Databricks. Frequenti modifiche manuali suggerirebbero che l’impostazione predefinita non si adatta ai comuni controlli aziendali.
Questo segnale è importante perché la generazione delle policy è la promessa centrale del prodotto. L’interfaccia può sembrare semplice pur producendo un’infrastruttura che richiede un’ampia revisione dopo la creazione.
Il secondo segnale è se i clienti standardizzano il flusso di approvazione. Un’implementazione sana dovrebbe instradare le richieste verso amministratori definiti, preservare le evidenze della revisione e associare ogni ruolo a un proprietario.
Se i team continuano a scambiarsi screenshot, ARN e ticket ad hoc, l’automazione ha eliminato la digitazione senza risolvere il coordinamento. Se le richieste diventano un punto di controllo ripetibile, il nuovo modello ha trasformato più sostanzialmente l’onboarding.
Il terzo segnale è l’affidabilità operativa dopo la configurazione. Le organizzazioni dovrebbero monitorare assunzioni di ruolo non riuscite, azioni S3 negate, anomalie CloudTrail, problemi di consegna degli eventi e external location abbandonate.
Bassi tassi di errore sosterrebbero l’argomento secondo cui un provisioning coordinato riduce gli errori di configurazione. Problemi persistenti indicherebbero che policy dei bucket, crittografia, controlli organizzativi e autorizzazioni sui dati creano ancora troppe dipendenze nascoste.
Databricks dovrebbe anche chiarire come gli amministratori possano ispezionare, esportare, convalidare e riprodurre le risorse generate. Queste capacità determineranno se i team cloud centrali considereranno la funzionalità un percorso di deployment approvato.
Le opzioni manuali e Terraform mantenute creano un percorso di migrazione pratico. Un team può testare la configurazione automatizzata, esaminare il ruolo risultante e decidere se le connessioni future debbano rientrare in un template gestito come codice.
Questa valutazione dovrebbe restare specifica per il carico di lavoro. Un dataset analitico di sola lettura ha esigenze diverse da una destinazione di ingestione che riceve scritture continue ed eventi di file.
I team dovrebbero iniziare con un prefisso di bucket limitato e un carico di lavoro non critico. Possono quindi confermare l’accesso, rivedere i log, testare la revoca e documentare quale gruppo possiede la connessione.
Il risultato più importante è una divisione più chiara delle responsabilità. Databricks può generare risorse compatibili, AWS può applicare un’approvazione circoscritta e il cliente può mantenere il controllo sulle identità e sull’ambito dei dati.
Questa divisione supporta un onboarding più rapido senza fingere che la governance cloud sia scomparsa. Rende più visibile la decisione di approvazione perché il lavoro di configurazione circostante diventa standardizzato.
Il cambiamento offre inoltre alle piattaforme dati concorrenti un benchmark più chiaro. Un connettore di storage ora richiede più della sola documentazione e di frammenti di policy. Gli acquirenti si aspetteranno sempre più autorizzazione guidata, diritti di configurazione a scadenza, azioni verificabili e accesso continuativo governato.
Per sviluppatori e team di piattaforma, la lezione va oltre un singolo prodotto. Un buon onboarding cloud dovrebbe richiedere l’autorità temporanea minima necessaria per creare un’identità operativa esplicita e duratura.
I team che documentano questa valutazione possono conservare policy, decisioni architetturali e risultati dei test in una knowledge base ingegneristica ricercabile. Questo record diventa utile quando i ruoli cambiano o gli auditor riesaminano l’approvazione originale.
La configurazione S3 di Amazon Databricks è ora più semplice, ma il vantaggio significativo non è soltanto la comodità. Il nuovo flusso offre alle organizzazioni l’opportunità di sostituire una composizione manuale fragile con un’automazione verificabile e circoscritta.
Il passo successivo è semplice: testare una connessione rappresentativa, esaminare ogni autorizzazione generata e verificare il ruolo persistente dopo la scadenza della delega. Il risultato riduce sia i tempi di configurazione sia le eccezioni di sicurezza, oppure soltanto il numero visibile di passaggi?
