Sicurezza
Nessuno sviluppatore deve ricordarsi di filtrare una query per organizzazione. Ci pensa automaticamente uno scope globale, su ogni modello che ne ha bisogno, così un id vecchio o indovinato per i dati di qualcun altro non porta a una fuga di dati: porta a niente.
Ognuno chiude un modo diverso in cui una piattaforma multi-tenant di solito perde dati, in silenzio, finché qualcuno non va a cercare.
Uno scope globale filtra ogni query per organizzazione nel momento in cui un modello si avvia, senza nulla da ricordare per lo sviluppatore e senza una sola query che possa dimenticarlo, inclusi i link diretti alle pagine.
L'accesso da amministratore viene verificato a ogni richiesta, non solo al login, quindi sospendere un'organizzazione blocca il suo team già al clic successivo. I suoi prodotti smettono di essere raggiungibili pubblicamente nello stesso momento.
Invalidare un biglietto o annullare un ordine richiede il permesso specifico riverificato esattamente nel momento dell'azione, indipendentemente dal permesso che aveva fatto arrivare qualcuno a quella schermata.
Costo e margine non vengono mai scritti in una risposta rivolta al pubblico o a una scansione al varco. Non è nascosto dietro un flag che potrebbe essere configurato male in seguito: il campo, semplicemente, non esiste in quello che viene restituito.
Come regge
Cinque meccanismi, ognuno chiude un modo diverso in cui l'isolamento di solito si rompe nell'uso reale.
Uno scope globale aggiunge il filtro per organizzazione a ogni query eseguita su un modello che lo prevede, applicato nel momento in cui il modello si avvia, senza filtri da ricordare e senza modo per una singola query di saltarlo.
I link diretti si affidano allo stesso scope, quindi un link a un record di un'altra organizzazione restituisce un semplice 404 prima ancora che parta qualsiasi codice, mai un errore di permesso che confermerebbe l'esistenza del record.
Lo scope da solo protegge letture e cancellazioni, ma non una scrittura alla cieca verso un id esterno, quindi un id destinato a una tabella pivot o a una foreign key viene prima riverificato tramite la query con scope della sua stessa destinazione.
Ogni azione sensibile riesegue un controllo dei permessi dal vivo contro il database nel momento esatto in cui accade, non una volta sola al caricamento della pagina, così un permesso revocato a metà sessione smette di funzionare già al clic successivo, non al prossimo login.
Eliminare un prodotto, un'opzione o una categoria di biglietti con vendite reali viene rifiutato due volte: il livello applicativo spiega il motivo prima ancora di provarci, e la foreign key del database stesso è dichiarata per bloccare quella stessa cancellazione, così anche un percorso che saltasse il controllo fallirebbe comunque.
Il dettaglio, così com'è
La risposta vista dallo scanner è un elenco scritto a mano di esattamente ciò di cui il personale al varco ha bisogno. Costo, prezzo netto e margine non ci sono mai stati aggiunti, quindi non c'è nulla da esporre per errore in seguito.
{
"returned_to_gate_staff": {
"ticket_code": "AB12CD34EF",
"status": "redeemed",
"product_name": "City Food Tour",
"buyer_name": "Jane Buyer",
"position": 2,
"quantity": 3
},
"never_included": [
"cost_amount",
"net_amount",
"margin"
]
}Il dettaglio che quasi nessuno spiega
Un audit ha trovato otto modelli raggiungibili indovinando un id di un'altra organizzazione: sei che regolano prezzi e disponibilità, due che regolano l'assegnazione delle tasse. Nessuno portava un proprio filtro per organizzazione: ognuno lo ereditava da una relazione superiore che una ricerca diretta con un id fornito dal client saltava del tutto. Ognuno di essi ora porta il proprio id di organizzazione, chiudendo quella precisa categoria di falla per sempre, e una suite di test dedicata la mantiene chiusa tentando esattamente quell'id indovinato, su tutti e otto i modelli, ogni volta che la suite viene eseguita.
No. Ogni modello che ne ha bisogno porta uno scope globale che filtra automaticamente per organizzazione, il che protegge anche i link diretti: un id vecchio o indovinato per il record di un'altra organizzazione restituisce un 404, mai un errore di permesso che confermerebbe l'esistenza del record.
Il suo team amministrativo perde l'accesso al pannello già alla richiesta successiva, non solo al prossimo login, e i suoi prodotti smettono di essere raggiungibili tramite l'API pubblica nello stesso momento. La sospensione viene applicata, non solo registrata.
Sì. Ogni azione sensibile riverifica il permesso dal vivo contro il database nel momento in cui viene eseguita, non un ruolo salvato al primo caricamento della pagina. Il clic immediatamente successivo alla revoca viene bloccato.
No, due volte. Il livello applicativo rifiuta la cancellazione con una spiegazione chiara prima ancora di tentarla, e la foreign key del database stesso è dichiarata per impedire quella stessa cancellazione, così anche un percorso che aggirasse il controllo applicativo fallirebbe comunque.
No. Quelle risposte sono scritte a mano per includere solo ciò di cui il destinatario ha davvero bisogno. Il campo non viene mai scritto nella risposta fin dall'inizio, non nascosto dietro un flag che potrebbe essere configurato male.
Tiqory mantiene disponibilità, prezzi, pagamenti e accessi allineati mentre la tua operazione cresce. Dicci dove vuoi arrivare: ti mostriamo come farlo senza ricominciare da zero.