Permettere a un utente di conoscere le proprie capacità autorizzate diminuisce la sicurezza?

Come già accennato nella risposta di Lie Ryan, il principio di Kerckhoff si applica qui. Concedere conoscenze, a un utente delle sue risorse su un sistema non dovrebbe aumentare la vulnerabilità di quel sistema. Se pensi che lo faccia, hai alcuni problemi più grandi da considerare prima.

La prima cosa da fare con il tuo sistema: valutare se dare la conoscenza di come funziona quel sistema aumenta il rischio in primo luogo.

Se aumenta i rischi, potresti avere problemi più grossi del semplice se un utente può visualizzare le proprie autorizzazioni e deve bloccare qualsiasi altra conoscenza di quel sistema.

Inoltre, nascondere le autorizzazioni di un utente è una condizione per ridurre la vulnerabilità del sistema? Se è così, ti stai preparando per il fallimento.

Questo perché, in un sistema correttamente disponibile, un utente può facilmente scoprire le sue funzionalità nel tempo, semplicemente utilizzando il sistema in questione e registrando ciò che possono e non possono fare. Questo si applica anche se il sistema è un metodo di distribuzione delle truppe perché, hey , i tuoi utenti dovranno, usarlo .

In effetti, la conoscenza di un utente di ciò che è a sua disposizione è spesso una condizione di disponibilità in primo luogo.

E un sistema non disponibile ha già fallito.

Torna al principio di Kerckhoff, ecco alcune domande per verificare se sei in un tipo di situazione di "sicurezza attraverso l'oscurità":

1. Il codice o le specifiche relativi al tuo sistema sono open-source?

2. Anche altri utenti che utilizzano sistemi simili limitano queste informazioni

3. In caso contrario, ha portato a maggiori rischi per loro?

4. Quali scenari puoi pensare a dove consentire a queste informazioni di rendere tutti gli utenti vulnerabili? E limitare le informazioni riduce effettivamente la vulnerabilità (rispetto alle alternative)?

Ecco un esempio funzionante, utilizzando 2 dei miei strumenti di sicurezza Blue Team di scelta, KeePassXC e HashiCorp Vault:

1. Sì KeePassXC , HashiCorp Vault

2. KeePassXC: no, perché l'autorizzazione è limitata ai DB di KeePassXC a cui si hanno password e chiavi. HashiCorp Vault: No

3. KeePassXC: No. Se non chiami il tuo DB dopo una qualsiasi delle tue password, sei d'oro. HashiCorp Vault: No, purché non nominare il materiale utilizzato nel metodo di autorizzazione (ad esempio i nomi dei negozi KV) per conservare i dati segreti Di nuovo, c'è una responsabilità per l'utente, qui. Se rispettate i limiti e non nominate i vostri DB e KV dopo nomi utente o password, questo non introduce una nuova vulnerabilità.

4. Ecco uno scenario in cui la vulnerabilità è aumentata dalla conoscenza del proprio accesso da parte di un utente:

A. Dove l'utente ha già accesso privilegiato non dovrebbe, e semplicemente non lo saprebbe altrimenti.

In questo caso, sarebbe prudente limitare la conoscenza dell'utente. Ma un'alternativa migliore è semplicemente ridurre i livelli di accesso in primo luogo, piuttosto che limitarsi a limitare la sua conoscenza del proprio accesso, perché potrebbe comunque scoprire le sue risorse disponibili accidentalmente. Se ti trovi in una situazione in cui hai nominato i nomi delle chiavi KV KeePassXC DB o HashiCorp Vault dopo qualcosa di privilegiato, entrambi hanno il modo di spostare tali informazioni più in basso verso il luogo in cui non è esposto al sistema di autorizzazione. Per l'esempio nell'archivio KV di Vault, basta cambiare i nomi delle chiavi in qualcosa di generico e copiare le informazioni privilegiate per proteggere i valori di tali chiavi.

Hai fatto una domanda di alto livello, quindi fornirò una risposta di alto livello.

Non pensare al problema in termini di "riduzione della sicurezza" (che non è definito al meglio), ma pensa in termini di "vulnerabilità" e "pericolo".

• Quali vulnerabilità (debolezze di sistema e di controllo) sono esposte attraverso la divulgazione delle informazioni?
• Quali pericoli (condizioni non sicure che potrebbero causare incidenti) vengono creati attraverso la divulgazione delle informazioni?

Per rispondere a questo, non si crea un modello di minaccia, ma si crea un modello di vulnerabilità. Dov'è il tuo sistema vulnerabile e dove possono essere creati rischi attraverso l'uso o l'uso improprio del sistema?

Se la divulgazione delle informazioni non ha alcun impatto sui punti vulnerabili del tuo sistema e se le informazioni non possono essere utilizzate per creare un pericolo, o se gli impatti e le probabilità sono abbastanza bassi da essere tollerati, allora hai il rischio basato risposta.

Il principio di Kerckhoff si applica qui: non dovrebbe.

In teoria, l'elenco dei privilegi dell'utente dovrebbe corrispondere a ciò che l'utente è autorizzato a fare. In pratica, una certa supervisione può farti concedere all'utente un privilegio maggiore di quello di cui ha realmente bisogno, e divulgare le informazioni di autorizzazione rende solo più semplice per loro capirlo.

L'unico inconveniente qui è se all'utente viene effettivamente concesso più accesso del necessario. Quindi le informazioni sull'autorizzazione possono suggerire all'utente di avere più privilegi di quanto dovrebbero. In definitiva, però, questo non è il problema causato dalla divulgazione delle informazioni di autorizzazione, ma piuttosto il privilegio del token era troppo ampio per cominciare.

Penso che la risposta più accurata dipenda dall'applicazione. L'autorizzazione è una bestia sfumata e il controllo di accesso corretto richiede l'analisi del sistema sottostante.

Detto questo, la mia opinione personale è che, sebbene possa o meno essere la migliore UX o fornire l'interfaccia utente più chiara, esporre le autorizzazioni agli utenti probabilmente * non comprometterà la sicurezza. Se un ruolo utente può fare qualcosa, penso che qualcuno con quel ruolo probabilmente lo capirà alla fine.

* l'avvertenza è importante qui - di nuovo, la risposta effettiva dipende dall'applicazione. Questa è solo speculazione e potrebbe benissimo essere sbagliata (ancora una volta, a seconda della natura della tua applicazione). YMMV, GLHF, ecc. Ecc.