Gestire i permessi di un tipo di oggetto sicuro
- Tipo non definito
Questo documento descrive come visualizzare, testare, creare e rinominare i permessi di un tipo di oggetto sicuro.
1. Principio del permesso
Un permesso descrive un'azione testabile su un tipo di oggetto, come visualizzare una mappa, modificare un apparecchiature o amministrare il contenuto di una cartella.
Non offre alcun accesso di per sé. L'accesso effettivo è garantito da diritti assegnati agli utenti o gruppi su specifici oggetti.
| Campo | Ruolo |
|---|---|
| Nome | Etichetta funzionale mostrata agli amministratori. |
| Descrizione | Spiegazione dell'azione protetta. |
Maschera o Flag |
Bit che devono essere presenti in AuthorizedFlags per autorizzare il permesso. |
Maschera rifiutata o DeniedFlag |
Bit cercati in DeniedFlags di negare il permesso. Se è vuoto, il Flag viene usato. |
2. Gestione dei permessi aperti
- Open
/Security/Configurationcon il conto Cerebrate. - Individua il tipo in questione.
- Clicca su Permessi.
La finestra presenta successivamente:
- un promemoria dell'immutabilità delle maschere esistenti;
- il testerista di bandiere;
- permessi esistenti;
- Il modulo per creare un permesso.

3. Capire Flag e DeniedFlag
Un permesso può fornire una maschera di autorizzazione composita e una maschera di rifiuto più mirata.
Esempio con Modify Map :
Flag = 5 = 0101 = lire + modifier
DeniedFlag = 4 = 0100 = modifier
Il permesso non vieta nulla di sé di per sé. La maschera utilizzata dipende dall'azione amministrativa:
| Azione | Maschera sancita dalla legge |
|---|---|
Permette Modify Map |
AuthorizedFlags Riceve Flag, quindi 5. |
Rifiuti Modify Map |
DeniedFlags Riceve DeniedFlag, quindi 4. |
Questa separazione rende possibile rifiutare la modifica mantenendo però qualsiasi permesso di lettura.
Il DeniedFlag, quando popolato, deve essere un sottoinsieme positivo del Flag.
DeniedFlag Non significa che il permesso sia negato di default. Indica solo quale maschera usare quando un amministratore o una regola sceglie esplicitamente l'effetto Rifiuti.
4. Bandiere di prova
Il tester decodifica una coppia di valori come se provenisse da un Right :
AuthorizedFlagscontiene abilità concesse;DeniedFlagscontiene le capacità esplicitamente negate.
Accetta numeri decimali, numeri esadecimali e combinazioni con | :
1
0x3
1 | 5
0x3 | 65
Per ogni permesso, il risultato può essere:
| Risultato | Significato |
|---|---|
Autorisée |
Tutte le parti del Flag sono presenti e non è presente alcun rifiuto applicabile. |
Refusée |
Tutti i pezzi della maschera negata sono presenti in DeniedFlags. |
Refusée (prioritaire) |
Le maschere consentite e rifiutate corrispondono entrambe le cose; il rifiuto vince. |
Non définie |
Non è presente l'autorizzazione completa e non ci sono corrispondenze di diniego complete. |
Il tester non consulta utenti, gruppi o un oggetto sicuro reale. Viene utilizzato solo per comprendere le maschere.

5. Creare un permesso
Il tipo deve essere attivo.
- Inserisci un nome funzionale specifico.
- Aggiungi una descrizione dell'operazione protetta.
- Inserisci una maschera positiva in Maschera.
- Opzionalmente inserisci una sottomaschera positiva in Mask rifiutò.
- Clicca su Aggiungi al carrello.
La forma di creazione attualmente prevede numeri interi decimali. Scritture esadecimali ed espressioni con | sono accettate dal tester, ma non tramite questa forma digitale.
Per lo stesso tipo:
- Il nome deve essere unico;
- Il
Flagdeve essere unico; - Il
DeniedFlag, dove esiste, deve essere contenuto nelFlag; - il nome è limitato a 255 caratteri;
- La descrizione è limitata a 2.048 caratteri.

Creare un permesso non concede l'accesso. Deve quindi essere utilizzato nei diritti manuali, in una regola di autorizzazione automatica e nei controlli del codice aziendale.
6. Modifica un permesso esistente
Il nome e la descrizione possono essere modificati quando il tipo è attivo:
- Modifica il testo direttamente nella riga.
- clicca su Aggiornamento.
Il Flag e il DeniedFlag sono mostrati ma non possono essere modificati.
I diritti salvati contengono direttamente le maschere numeriche. Non mantengono un riferimento al permesso scelto. Modificare la maschera di un permesso esistente cambierebbe quindi retroattivamente il significato dei diritti già assegnati.
Per cambiare una mascherina:
- creare un nuovo permesso;
- Trasferire i diritti interessati alla nuova maschera.
- Adatta regole automatiche e controlli aziendali.
- Verifica gli oggetti esistenti con gli strumenti di audit.
Attualmente l'interfaccia non offre la rimozione dei permessi.
7. Effetto del tipo attivo o inattivo
| Stato del tipo | Consulenza | Tester | Creazione | Cambio del nome o della descrizione |
|---|---|---|---|---|
| Attivo | Sì | Sì | Sì | Sì |
| Inattivi | Sì | Sì | No | Rifiutato dal server |
Disabilitare il tipo non rimuove i suoi permessi né modifica quelli che già utilizzano le loro maschere.
8. Dopo la Creazione
Controlla quanto segue:
- Il controller o il servizio aziendale testano questo permesso con il calcolo centrale.
- i gruppi o gli utenti appropriati ricevono i flag necessari;
- Viene creata una regola automatica se a nuovi oggetti viene concesso questo diritto non appena vengono creati.
- Gli oggetti esistenti vengono auditati e, se necessario, regolarizzati.
9. Regole da ricordare
- Un permesso descrive un'azione ma non concede l'accesso.
Flagviene utilizzato per autorizzare.DeniedFlagviene usato solo quando viene esplicitamente negato.- Un rifiuto applicabile ha la precedenza su un'autorizzazione.
- Le maschere di un permesso esistente sono immutabili.
- Un nuovo permesso deve essere inserito nel codice aziendale per diventare davvero utile.