BLP Struttura reticolare con livelli superiori e inferiori mancanti

Sembra che tu abbia frainteso il modo in cui funziona questo modello di reticolo, e il diagramma che hai dato non aiuta molto. È pensato per essere una struttura 3D.

In questo modello, abbiamo:

• Entità : queste sono le cose a cui puoi avere accesso. Nel tuo diagramma, questi sono crypto e nuclear .
• Livelli di privilegi : si tratta di livelli generici di privilegio che possono essere applicati a qualsiasi entità. Ogni privilegio superiore eredita il privilegio sottostante. Nel tuo diagramma, questi sono secret e top secret .
• Privilegi delle entità : si tratta dei livelli di privilegio associati a una singola entità. Ad esempio, potresti avere (Top Secret {nuclear}) o (Secret {crypto}) .
• Percorsi di escalation : questi sono i modi per aumentare i privilegi di una persona. Nota che ogni riga sul reticolo aumenta un tipo di privilegio, ad es. non è possibile passare direttamente da (Secret {nuclear}) a (Top Secret {nuclear, crypto}) . Ciò consente procedure di escalation dei privilegi strongmente definite e percorsi di controllo appropriati.

Il modello reticolare mette essenzialmente tutte le possibili combinazioni di accesso all'entità su ciascun livello di privilegio. In quanto tale, un individuo può essere solo in un punto del reticolo.

I privilegi delle entità in questo modello non consentono i casi in cui un individuo può avere un privilegio più elevato su un'entità rispetto a un altro. Hai lo stesso privilegio per tutte le entità a cui hai accesso, ma potresti non avere accesso ad alcune entità. Questo è spesso una buona cosa nei classici sistemi di applicazione della legge e di governo, ma non si presta bene ai moderni sistemi informatici aziendali.

Alterare questo modello per avere livelli di privilegi mancanti o strati mancanti non ha alcun senso. Dal punto di vista della progettazione del software, l'amministratore mantiene il più alto livello di privilegio per tutte le entità, mentre un utente non autenticato non ha privilegi su alcuna entità. I singoli utenti sarebbero in qualsiasi punto nel mezzo. La rimozione di questi privilegi di entità rende i percorsi di escalation più tortuosi e rende inutile il lavoro di convalida.

Se stai cercando un modello di controllo degli accessi più flessibile, prova ad accedere agli elenchi di controllo con ereditarietà. In tale modello, gli utenti possono essere organizzati in gruppi e sottogruppi, ognuno dei quali ha un livello di privilegio di base che eredita dal suo genitore. I singoli utenti possono essere inoltrati oltre il livello base, ma non al di sotto. Ciò consente di creare complessi gruppi di privilegi con un lavoro minimo, in modo intuitivo che rispecchia l'infrastruttura fisica.

BLP presuppone che il reticolo sia, beh, un reticolo. La definizione matematica di un reticolo dice che deve avere una cima e un fondo. Se non hai una cima e un fondo, non è un reticolato.

Se stai chiedendo se puoi far funzionare Bell-Lapadula con un ordine parziale che non è un reticolo, la risposta è che dipende. Se non si dispone di un reticolo, le cose potrebbero andare in pezzi inaspettatamente se nel proprio sistema c'è qualcosa che aggiorna le etichette su oggetti o oggetti. Ad esempio, se non è un reticolo e se aggiorni le etichette soggetto al volo, potresti imbatterti in situazioni in cui non sarai in grado di aggiornare l'etichetta di un soggetto come richiesto dalle regole, perché non avrai alcun reticolo adatto punto che soddisfa tutti i requisiti.

Questo non ha nulla a che fare con la sicurezza che posso vedere; ha a che fare con la garanzia di disporre di un insieme coerente di regole che possono essere effettivamente eseguite, senza rimanere bloccati.

Caveat: il modello Bell-Lapadula ha molti problemi ed è (secondo me) una scelta sbagliata per la maggior parte dei nuovi sistemi, quindi dovresti cercare con attenzione se è davvero la scelta giusta per te.