Prevenire le violazioni nel SaaS multi-tenant con Penetration Test automatizzati

Gestire una piattaforma SaaS multi-tenant è un po' come gestire un enorme complesso di appartamenti. Fornisci l'infrastruttura, le utenze e la sicurezza per il cancello principale, ma ogni inquilino ha la propria chiave per il proprio appartamento. Lo scenario da incubo non è solo un ladro che irrompe in un appartamento, ma un inquilino che trova un modo per forzare le serrature di tutti gli altri appartamenti dell'edificio. Nel mondo del software, lo chiamiamo "tenant escape" o "cross-tenant data leakage" (perdita di dati tra tenant), ed è l'evento più devastante che possa capitare a un'azienda SaaS.

Il problema è che la maggior parte delle strategie di sicurezza per SaaS sono bloccate nel passato. Probabilmente hai un Penetration Test annuale in cui una società specializzata trascorre due settimane a esaminare la tua app, ti fornisce un PDF di 60 pagine con le vulnerabilità e poi se ne va. Passi tre mesi a correggere le "Criticals" e, quando hai finito, i tuoi sviluppatori hanno rilasciato venti nuovi aggiornamenti delle funzionalità, tre modifiche alla versione dell'API e una nuova configurazione cloud. In sostanza, il tuo report di sicurezza era obsoleto nel momento in cui ti è stato inviato via email.

Se distribuisci codice quotidianamente o settimanalmente, un audit "point-in-time" è solo security theater. Sembra buono su una checklist SOC 2, ma in realtà non impedisce una violazione. Per proteggere veramente un ambiente multi-tenant, devi passare a Penetration Test automatizzati e alla gestione continua dell'esposizione. Non si tratta di sostituire gli hacker umani, ma di garantire che le vulnerabilità più evidenti, le deviazioni di configurazione e i difetti comuni OWASP vengano individuati in tempo reale.

In questa guida, analizzeremo il motivo per cui il SaaS multi-tenant è un bersaglio unico, dove si verificano le perdite più comuni e come il passaggio a un modello automatizzato di On-Demand Security Testing (ODST) come Penetrify può fermare una violazione prima che finisca sui giornali.

Il pericolo unico della multi-tenancy

La multi-tenancy è il motore della scalabilità SaaS. Condividendo una singola istanza del software e un singolo database (o un set di database in cluster) tra più clienti, si mantengono bassi i costi e si semplificano gli aggiornamenti. Ma dal punto di vista della sicurezza, hai creato un enorme "blast radius" (raggio d'esplosione).

In un'architettura single-tenant, se un hacker entra nell'ambiente del Cliente A, ha accesso solo ai dati del Cliente A. In un ambiente multi-tenant, l'unica cosa che separa i dati del Cliente A da quelli del Cliente B è il tuo codice, in particolare la tua logica di autorizzazione.

Il problema della "Broken Object Level Authorization" (BOLA)

Se si guarda alla OWASP Top 10 per le API, BOLA (precedentemente noto come IDOR) è quasi sempre in cima. In un contesto SaaS, BOLA è il principale veicolo per le violazioni multi-tenant.

Immagina un URL come questo: app.saas.com/api/invoice/12345. Un utente legittimo della Società A ha effettuato l'accesso e vede la propria fattura (ID 12345). Poi, diventa curioso. Cambia l'URL in app.saas.com/api/invoice/12346. Se il tuo sistema controlla solo se l'utente ha effettuato l'accesso, ma non controlla se l'utente possiede effettivamente la fattura 12346, hai appena divulgato i dati della Società B.

Questo non è un "hack" complesso. È un semplice errore di logica. Tuttavia, in una piattaforma con migliaia di endpoint, questi errori sono inevitabili. Testare manualmente ogni singolo endpoint API per BOLA ogni volta che uno sviluppatore modifica una riga di codice è impossibile. È qui che i Penetration Test automatizzati diventano una necessità piuttosto che un lusso.

Contesa di risorse condivise e attacchi Side-Channel

Oltre alla perdita di dati, c'è il rischio di esaurimento delle risorse. In un cloud multi-tenant, un "noisy neighbor" (vicino rumoroso), che sia un attore malintenzionato o semplicemente un cliente con uno script scritto male, può monopolizzare tutta la CPU o la memoria, causando di fatto un Denial of Service (DoS) per tutti gli altri tenant di quel cluster. Mentre i provider di cloud come AWS o Azure gestiscono parte di questo a livello di infrastruttura, la logica della tua applicazione potrebbe comunque essere vulnerabile agli attacchi di "algorithmic complexity" (complessità algoritmica) che possono mandare in crash il tuo pod e mettere fuori uso più clienti contemporaneamente.

Perché il Penetration Testing tradizionale fallisce nel SaaS

Per anni, lo standard del settore è stato il Penetration Test professionale annuale. Assumi un'azienda, che trascorre alcune settimane nel tuo ambiente di staging e ottieni un report. Sebbene questi test siano ottimi per trovare difetti architetturali profondi e complessi che un bot potrebbe perdere, sono fondamentalmente imperfetti per il moderno ciclo di vita CI/CD.

Il divario di vulnerabilità

Pensa alla timeline. Hai il tuo test annuale a gennaio. A febbraio, il tuo team lancia una nuova integrazione con un CRM di terze parti. A marzo, aggiorni il tuo flusso di autenticazione per supportare SAML. Ad aprile, viene scoperta una nuova vulnerabilità Zero Day in una libreria Java che usi per la generazione di PDF.

Tra gennaio e il test successivo del gennaio successivo, hai un enorme "blind spot" (punto cieco). Qualsiasi vulnerabilità introdotta a febbraio è attiva e sfruttabile per dieci mesi. Per un'azienda SaaS, questa finestra di rischio è inaccettabile.

L'attrito degli audit manuali

I Penetration Test manuali creano "security friction" (attrito di sicurezza). Gli sviluppatori li odiano perché di solito si traducono in un enorme scarico di ticket alla fine di un trimestre, che interrompe la roadmap del prodotto. Diventa un confronto: la sicurezza dice: "Hai 50 bug" e il prodotto dice: "Abbiamo una scadenza per la nuova dashboard".

Quando la sicurezza è un "evento" piuttosto che un "processo", perde sempre contro la roadmap del prodotto.

La barriera dei costi per le PMI

Le società di sicurezza specializzate di fascia alta sono costose. Per un'azienda SaaS di medie dimensioni, spendere tra $ 30.000 e $ 50.000 per un test una tantum è un colpo significativo. A causa del costo, le PMI spesso riducono l'ambito del test, dicendo ai tester di ignorare determinati moduli "a basso rischio". Ma come sappiamo, gli aggressori non seguono il tuo ambito; trovano l'unico modulo ignorato e lo usano come punto di partenza per entrare nel resto del sistema.

Passare a Continuous Threat Exposure Management (CTEM)

L'alternativa al modello "una volta all'anno" è il Continuous Threat Exposure Management (CTEM). Invece di considerare la sicurezza come un'istantanea, il CTEM la tratta come un flusso continuo. È qui che entra in gioco il concetto di Penetration Testing as a Service (PTaaS).

Automated Attack Surface Mapping

La tua superficie di attacco non è statica. Potresti avviare un nuovo bucket S3 per una campagna di marketing, aprire una porta temporanea per un'integrazione con un partner o dimenticare di disattivare una versione beta della tua API. La maggior parte delle aziende non conosce nemmeno la propria superficie di attacco completa.

Piattaforme automatizzate, come Penetrify, mappano continuamente la tua impronta esterna. Non si limitano a scansionare ciò che gli dici di scansionare; scoprono ciò che è effettivamente esposto a Internet. Se uno sviluppatore carica accidentalmente un file .env in una directory pubblica, un sistema automatizzato lo rileva in pochi minuti, non in mesi.

Integrating Security into the CI/CD Pipeline (DevSecOps)

L'obiettivo è spostare la sicurezza "a sinistra". Ciò significa spostare la fase di test all'inizio del processo di sviluppo. Quando automatizzi il Penetration Testing, puoi attivare le scansioni ogni volta che il codice viene unito in un ambiente di staging.

Invece di un PDF di 60 pagine, lo sviluppatore riceve un ticket Jira o un avviso Slack: "Ehi, il nuovo endpoint /api/user/profile è vulnerabile a BOLA. Risolvilo prima che arrivi in produzione." Questo trasforma la sicurezza in un ciclo di feedback in tempo reale, riducendo il Mean Time to Remediation (MTTR) da mesi a ore.

The Role of Breach and Attack Simulation (BAS)

Mentre la scansione delle vulnerabilità trova "buchi" (come una libreria obsoleta), il Breach and Attack Simulation (BAS) testa i "percorsi". Simula il modo in cui un aggressore si muoverebbe effettivamente attraverso il tuo sistema.

Per un SaaS multi-tenant, BAS può simulare uno scenario di "tenant compromesso". Si chiede: "Se ho un token valido per l'Azienda A, posso usarlo per accedere alle funzioni amministrative della piattaforma globale?" Simulando continuamente questi percorsi, puoi trovare i difetti logici che i semplici scanner non rilevano.

Common Vulnerabilities in Multi-Tenant SaaS (and How to Automate the Search)

Per capire come gli automated Penetration Test aiutano, dobbiamo esaminare i guasti tecnici specifici che portano alle violazioni SaaS.

1. Insecure Direct Object References (IDOR/BOLA)

Come accennato, questo è il "sacro graal" per gli aggressori SaaS.

• The Flaw: L'app utilizza un identificatore (come un UUID o un intero) per recuperare una risorsa ma non verifica il permesso dell'utente di accedere a quello specifico ID.
• How Automation Catches It: Gli strumenti automatizzati possono eseguire "parameter fuzzing" e "cross-account testing". Utilizzando due diversi set di token di autenticazione (Tenant A e Tenant B), lo strumento tenta di accedere alle risorse del Tenant A utilizzando il token del Tenant B. Se ha successo, segnala una violazione di alta gravità.

2. JWT and Session Management Failures

Molte app SaaS utilizzano JSON Web Tokens (JWT) per l'autenticazione stateless.

• The Flaw: Utilizzo di chiavi di firma deboli, mancata convalida della firma o autorizzazione dell'attacco alg: none. Se un aggressore può falsificare un JWT, può essenzialmente "diventare" qualsiasi utente o anche un Super Admin.
• How Automation Catches It: I test automatizzati possono tentare exploit JWT comuni: provare a modificare l'algoritmo, forzare con la forza bruta segreti deboli o testare i bypass della scadenza del token, ogni volta che il modulo di autenticazione viene aggiornato.

3. Mass Assignment Vulnerabilities

Le app SaaS spesso prendono un oggetto JSON da una richiesta e lo salvano direttamente in un record di database.

• The Flaw: Un utente invia {"username": "bob", "email": "bob@example.com"} per aggiornare il proprio profilo. Ma aggiungono un campo nascosto: {"username": "bob", "email": "bob@example.com", "is_admin": true}. Se il backend salva ciecamente questo, Bob si è appena promosso ad amministratore.
• How Automation Catches It: Gli strumenti automatizzati possono sondare gli endpoint API iniettando campi amministrativi comuni (is_admin, role, permissions, account_level) nelle richieste per vedere se il server li accetta.

4. SSRF (Server-Side Request Forgery)

Le piattaforme SaaS spesso consentono agli utenti di fornire URL (ad esempio, per webhook o immagini del profilo).

• The Flaw: Se il server non convalida l'URL, un aggressore può dire al server di effettuare una richiesta alla propria rete interna. In un ambiente cloud, questo spesso significa colpire il Metadata Service (come 169.254.169.254 in AWS) per rubare ruoli e credenziali IAM.
• How Automation Catches It: Gli scanner automatizzati testano tutti i campi di input URL con token "canary" (come quelli di Burp Collaborator o strumenti interni simili) per vedere se il server effettua una richiesta in uscita verso una destinazione non autorizzata.

A Step-by-Step Guide to Implementing Automated Pentesting

Se attualmente ti affidi a test annuali, non puoi semplicemente premere un interruttore ed essere "sicuro". Hai bisogno di un piano di transizione.

Step 1: Audit Your Current Inventory

Non puoi proteggere ciò che non sai che esiste. Inizia elencando:

• Tutte le API pubbliche (incluse quelle versionate come /v1/ e /v2/).
• Tutti i sottodomini e gli ambienti di staging.
• Tutte le integrazioni di terze parti che hanno accesso ai tuoi dati.
• Quali servizi cloud (S3, Azure Blobs, ecc.) interagiscono con i dati degli utenti.

Step 2: Establish a Baseline

Esegui una scansione completa iniziale utilizzando uno strumento come Penetrify. Questo ti darà un rapporto sullo "Stato Attuale". Non farti prendere dal panico quando vedi un elenco di 100 vulnerabilità; questo è normale. Categorizzale per gravità:

• Critico: BOLA, Remote Code Execution (RCE), SQL Injection. (Correggere immediatamente).
• Alto: Broken Auth, esposizione di dati sensibili. (Correggere entro 2 settimane).
• Medio/Basso: Mancanza di header di sicurezza, versioni obsolete di librerie non critiche. (Pianificare nel prossimo sprint).

Passo 3: Integrare nella Pipeline

Una volta che la baseline è pulita, connetti il tuo security testing al tuo flusso di deployment.

• CI/CD Trigger: Imposta un webhook in modo che ogni volta che il codice viene inviato al branch develop o staging, venga attivata una scansione automatizzata.
• Alerting: Connetti i risultati a Slack o Microsoft Teams. Invece di un PDF, il team riceve una notifica: "Trovata vulnerabilità critica nel Branch 'Feature-X'. Deployment bloccato."

Passo 4: Definisci il Tuo "Budget di Sicurezza"

Non puoi correggere tutto. Definisci cosa è un "rischio accettabile". Ad esempio, potresti decidere che nessun bug "Alto" o "Critico" può esistere in produzione, ma i "Medi" possono rimanere per 30 giorni. Questo impedisce alla sicurezza di diventare un collo di bottiglia che blocca tutto lo sviluppo del prodotto.

Passo 5: Monitoraggio Continuo

La parte "continua" di CTEM significa che le scansioni non si fermano quando il codice viene distribuito. Imposta "sanity scan" giornalieri o settimanali per intercettare nuovi Zero Day o deviazioni di configurazione (come una porta aperta in un Security Group per errore).

Confronto tra i Tre Livelli di Security Testing

Per rendere più facile la visualizzazione, confrontiamo i tre modi principali in cui le aziende SaaS gestiscono la sicurezza.

Funzionalità	Semplice Vulnerability Scanner	Penetration Test Manuale Tradizionale	Penetration Test Automatizzato (Penetrify)
Frequenza	Continua/Pianificata	Una volta all'anno / Una volta al trimestre	Continua / On-Demand
Profondità	Livello superficiale (principalmente versioni)	Profonda (logica, architettura)	Medio-Profonda (logica + superficie)
Costo	Basso	Molto Alto	Moderato / Prevedibile
Ciclo di Feedback	Rumoroso, molti False Positives	Lento (settimane per un report)	Veloce (avvisi quasi in tempo reale)
Logic Testing	Quasi nullo	Eccellente	Forte (tramite test BAS & BOLA)
Compliance	Debole	Forte	Forte (fornisce audit trail)
Integrazione Dev	Base (API)	Nessuna (Manuale)	Alta (integrazione DevSecOps)

La maggior parte delle aziende SaaS si rende conto di aver bisogno di un mix. Potresti ancora volere un "Deep Dive" manuale una volta all'anno per un audit SOC 2, ma hai bisogno di Penetrify per i 364 giorni intermedi.

Il Ruolo di Penetrify nell'Ecosistema SaaS

È qui che Penetrify si inserisce. Non abbiamo creato Penetrify per essere solo un altro "scanner" che ti dice che la tua versione di Nginx è vecchia. L'abbiamo creato per essere un ponte tra la superficialità degli scanner di base e il costo proibitivo delle aziende boutique.

Penetrify si concentra sull'aspetto "cloud" del SaaS. Poiché siamo cloud-native, possiamo scalare i nostri test su AWS, Azure e GCP senza problemi. Non cerchiamo solo bug; mappiamo la tua superficie di attacco e simuliamo i percorsi reali che un hacker intraprenderebbe per passare da un account ospite al tuo database.

Automatizzando le fasi di ricognizione e scansione, Penetrify elimina il vincolo delle risorse umane. Non devi aspettare la disponibilità di un consulente. Basta attivare un test. Questo riduce l'"attrito di sicurezza" perché il feedback viene fornito in un linguaggio che gli sviluppatori comprendono: guida alla correzione concreta e attuabile piuttosto che vaghe "osservazioni di sicurezza".

Errori Comuni che le Aziende SaaS Commettono con la Sicurezza

Anche con gli strumenti giusti, è facile sbagliare l'implementazione. Ecco alcune insidie da evitare.

Errore 1: Testare in Produzione Senza un Piano

Alcuni team hanno paura di testare in staging perché "lo staging non è esattamente come la produzione". Sebbene il testing in produzione fornisca i risultati più accurati, è pericoloso se i tuoi strumenti automatizzati sono troppo aggressivi.

• La Soluzione: Utilizza token di "sola lettura" per le scansioni iniziali e introduci lentamente i test di "scrittura". Assicurati che i tuoi strumenti automatizzati siano configurati per evitare di attivare le funzioni "Elimina Tutto" o "Reimposta Password".

Errore 2: Ignorare i Risultati di Gravità "Bassa"

Un risultato di gravità "Bassa" - come un header X-Content-Type-Options mancante - sembra innocuo. Ma gli aggressori spesso "concatenano" le vulnerabilità. Una perdita di informazioni di bassa gravità potrebbe fornire loro il nome del server interno, che poi utilizzano per eseguire un SSRF di gravità media, che alla fine porta a una violazione dei dati di gravità critica.

• La Soluzione: Non ignorare i bassi; dai loro solo la priorità. Utilizza un sistema di backlog per garantire che i "bassi" vengano ripuliti durante gli "sprint di manutenzione".

Errore 3: Eccessiva Dipendenza dagli Strumenti

Nessuno strumento è perfetto. I Penetration Testing automatizzati sono incredibili per intercettare la OWASP Top 10 e gli errori di configurazione, ma hanno difficoltà con la logica di business complessa (ad esempio, "Un utente può bypassare il gateway di pagamento manipolando la quantità del carrello a un numero negativo?").

• La Soluzione: Utilizza un approccio ibrido. Automatizza il 90% del lavoro con Penetrify e spendi il tuo budget limitato per un esperto umano per fare un "Logic Audit" una volta all'anno.

Errore 4: Considerare la sicurezza un problema esclusivo del "Team di sicurezza"

Se gli sviluppatori pensano che la sicurezza sia compito di qualcun altro, continueranno a scrivere codice non sicuro.

• La soluzione: Democratizzare la sicurezza. Fornite ai vostri sviluppatori principali l'accesso alla dashboard di Penetrify. Permettete loro di vedere le vulnerabilità non appena compaiono. Quando uno sviluppatore si assume la responsabilità della sicurezza della propria funzionalità, la qualità del codice migliora.

Uno scenario di esempio: La violazione dovuta alla "corsa alla funzionalità"

Analizziamo uno scenario fittizio ma realistico per vedere come i Penetration Test automatizzati cambiano il risultato.

L'azienda: "CloudDocs", un SaaS di collaborazione su documenti multi-tenant. La situazione: Il team di marketing richiede una nuova funzionalità di "Condivisione pubblica". Questa consente agli utenti di generare un link pubblico in modo che qualcuno al di fuori della loro organizzazione possa visualizzare un documento. La scadenza: Venerdì.

Scenario A: Il modello tradizionale (La violazione) Gli sviluppatori si affrettano a realizzare la funzionalità. Creano un nuovo endpoint API: /api/docs/public/{doc_id}. Nella fretta, si dimenticano di verificare se il doc_id è effettivamente contrassegnato come "pubblico" nel database. Controllano solo se il doc_id esiste. La funzionalità viene lanciata venerdì. Lunedì, un malintenzionato nota il pattern dell'URL. Scrive un semplice script per scorrere i numeri doc_id. Nel giro di tre ore, ha estratto 50.000 documenti privati da 200 aziende diverse. CloudDocs lo scopre due settimane dopo, quando un cliente si lamenta che i suoi dati privati sono su un forum pubblico. Il Penetration Test annuale è previsto tra sei mesi.

Scenario B: Il modello Penetrify (Il salvataggio) Gli sviluppatori si affrettano a realizzare la stessa funzionalità e la inviano all'ambiente di staging mercoledì. Il merge attiva una scansione automatizzata di Penetrify. Lo strumento identifica il nuovo endpoint /api/docs/public/. Esegue immediatamente un test per BOLA tentando di accedere a un doc_id che non è contrassegnato come pubblico. La scansione fallisce. Un avviso "Critico" viene inviato al canale Slack #dev-alerts: "Vulnerability Found: BOLA on /api/docs/public/{doc_id}. Unauthorized access possible." Lo sviluppatore vede l'avviso, si rende conto dell'errore e aggiunge il controllo is_public == true alla query SQL. La funzionalità viene lanciata venerdì, sicura e stabile.

La differenza non è che gli sviluppatori erano "migliori" nello Scenario B, ma che avevano una rete di sicurezza che operava alla velocità del loro sviluppo.

FAQ: Penetration Testing automatizzato per SaaS

D: Il pentesting automatizzato sostituisce la necessità di un hacker umano? No. Gli esseri umani sono ancora più bravi nel pensiero "creativo" e nell'individuazione di falle complesse nella logica aziendale. Tuttavia, gli esseri umani sono lenti e costosi. L'automazione gestisce le cose "noiose" - la scansione di migliaia di endpoint per la OWASP Top 10 - il che consente agli esperti umani di concentrarsi sui problemi architetturali veramente difficili.

D: Le scansioni automatizzate rallenteranno la mia applicazione o bloccheranno il mio server? Se configurato correttamente, no. Gli strumenti moderni come Penetrify consentono di limitare la frequenza delle richieste e specificare gli endpoint "out-of-scope". È sempre consigliabile eseguire test pesanti in un ambiente di staging che rispecchi la produzione prima di eseguire una scansione di "sanity" più leggera nell'ambiente live.

D: In che modo questo aiuta con la conformità SOC 2 o HIPAA? Gli auditor di conformità amano la documentazione. I Penetration Test tradizionali forniscono un report all'anno. Penetrify fornisce un audit trail continuo. Potete mostrare a un auditor: "Ecco la nostra posizione di sicurezza ogni singolo giorno dell'ultimo anno, ed ecco la prova che ogni bug critico è stato corretto entro 48 ore." Questo è molto più impressionante di un singolo PDF annuale.

D: È difficile da configurare? Non proprio. La maggior parte delle piattaforme moderne utilizza una connessione "cloud-to-cloud". Voi fornite gli URL o la documentazione API (come un file Swagger/OpenAPI) e la piattaforma inizia la mappatura. L'integrazione in CI/CD di solito comporta una semplice API key o una GitHub Action.

D: Cosa succede se ci sono troppi False Positives? I False Positives sono la rovina degli strumenti di sicurezza. La chiave è utilizzare uno strumento che sfrutti l'"analisi intelligente" piuttosto che la semplice corrispondenza di pattern. Penetrify mira a ridurre il rumore simulando il percorso di attacco effettivo: se lo strumento non può effettivamente "provare" la vulnerabilità accedendo a dati a cui non dovrebbe accedere, non urla "Critico".

Azioni concrete per fondatori e CTO di SaaS

Se vi sentite sopraffatti dai requisiti di sicurezza della vostra piattaforma multi-tenant, iniziate con questi tre passaggi:

1. Smettete di fare affidamento sull'"Audit annuale" come unica difesa. È una polizza assicurativa, non una strategia di sicurezza.
2. Controllate il vostro rischio BOLA. Andate ai vostri endpoint API più importanti. Provate ad accedere a una risorsa appartenente a un altro tenant utilizzando il token di un utente diverso. Se funziona, avete un'emergenza critica.
3. Implementate un approccio "Continuo". Passate a un modello in cui la sicurezza viene testata ogni volta che il codice viene modificato. Che iniziate con strumenti open-source o con una piattaforma professionale come Penetrify, l'obiettivo è ridurre il divario tra "bug introdotto" e "bug corretto".

Il costo di una violazione in un ambiente multi-tenant non è solo la multa o la perdita di dati, ma la perdita di fiducia. Nel SaaS, la fiducia è l'unica valuta che conta davvero. Una volta che i vostri clienti credono che i loro dati siano accessibili ai loro concorrenti, nessun numero di aggiornamenti delle funzionalità li riporterà indietro.

Proteggete i vostri tenant automatizzando la vostra difesa. È ora di abbandonare la sicurezza puntuale e abbracciare un modello che si adatti alla velocità della vostra infrastruttura cloud. Se siete pronti a smettere di indovinare la vostra posizione di sicurezza, scoprite come Penetrify può automatizzare il vostro pentesting e mantenere bloccato il vostro ambiente multi-tenant.