Funzioni avanzate dei criteri

Nell'ambito di un'istruzione criterio, è possibile specificare una o più condizioni che devono essere soddisfatte affinché l'accesso possa essere concesso.

Ogni condizione è costituita da una o più variabili predefinite per le quali si specificano valori nell'istruzione dei criteri. In seguito, quando un utente richiede l'accesso alla risorsa in questione, se la condizione nel criterio viene soddisfatta, restituisce true e la richiesta è consentita. Se la condizione non viene soddisfatta, viene restituito false e la richiesta non è consentita.

Esistono due tipi di variabili: quelle rilevanti per la richiesta stessa e quelle rilevanti per la risorsa su cui si sta eseguendo l'azione nella richiesta, nota anche come destinazione. Il nome della variabile viene preceduto dal prefisso request o target seguito da un punto. Ad esempio, esiste una variabile di richiesta denominata request.operation per rappresentare l'operazione API richiesta. Questa variabile consente di scrivere un'ampia istruzione dei criteri, ma di aggiungere una condizione in base all'operazione API specifica. Per un esempio, vedere Consenti agli utenti di scrivere oggetti nei bucket di storage degli oggetti.

Le autorizzazioni sono le unità atomiche di autorizzazione che controllano la capacità di un utente di eseguire operazioni sulle risorse. Oracle definisce tutte le autorizzazioni nella lingua dei criteri. Quando si scrive un criterio che consente a un gruppo di accedere a un determinato verbo e a un determinato tipo di risorsa, in realtà si concede a tale gruppo l'accesso a una o più autorizzazioni predefinite. Lo scopo dei verbi è quello di semplificare il processo di concessione di più autorizzazioni correlate che coprono un ampio set di accesso o un particolare scenario operativo. Nelle sezioni successive vengono forniti maggiori dettagli ed esempi.

In un'istruzione criterio è possibile utilizzare le condizioni combinate con le autorizzazioni o le operazioni API per ridurre l'ambito di accesso concesso da un verbo specifico.

Si supponga, ad esempio, di voler consentire al gruppo XYZ di elencare, ottenere, creare o aggiornare i gruppi (ad esempio, modificarne la descrizione), ma non di eliminarli. Per elencare, ottenere, creare e aggiornare i gruppi, è necessario un criterio con manage groups come verbo e tipo di risorsa. In base alla tabella in Dettagli per combinazioni Verbi + Tipo di risorsa, le autorizzazioni coperte sono le seguenti:

• GROUP_INSPECT
• GROUP_UPDATE
• GROUP_CREATE
• GROUP_DELETE

Per limitare l'accesso solo alle autorizzazioni desiderate, è possibile aggiungere una condizione che dichiari in modo esplicito le autorizzazioni che si desidera consentire:

Allow group XYZ to manage groups in tenancy

 where any {request.permission='GROUP_INSPECT',
            request.permission='GROUP_CREATE',
            request.permission='GROUP_UPDATE'}

Un'alternativa è un criterio che consente tutte le autorizzazioni ad eccezione di GROUP_DELETE:

Allow group XYZ to manage groups in tenancy where request.permission != 'GROUP_DELETE'

Tuttavia, con questo approccio, tenere presente che tutte le nuove autorizzazioni che il servizio potrebbe aggiungere in futuro verranno automaticamente concesse al gruppo XYZ. Verrà omesso solo GROUP_DELETE.

Un'altra alternativa sarebbe quella di scrivere una condizione in base alle operazioni API specifiche. Si noti che, in base alla tabella in Autorizzazioni richieste per ogni operazione API, sia ListGroups che GetGroup richiedono solo l'autorizzazione GROUP_INSPECT. Ecco la politica:

Allow group XYZ to manage groups in tenancy

 where any {request.operation='ListGroups',  
            request.operation='GetGroup',
            request.operation='CreateGroup',
            request.operation='UpdateGroup'}

Può essere utile utilizzare le autorizzazioni anziché le operazioni API nelle condizioni. In futuro, se viene aggiunta una nuova operazione API che richiede una delle autorizzazioni elencate nel criterio basato sulle autorizzazioni sopra riportato, tale criterio controllerà già l'accesso del gruppo XYZ a tale nuova operazione API.

Tuttavia, è possibile definire ulteriormente l'ambito dell'accesso di un utente a un'autorizzazione specificando anche una condizione in base all'operazione API. Ad esempio, è possibile concedere a un utente l'accesso a GROUP_INSPECT, ma solo a ListGroups.

Allow group XYZ to manage groups in tenancy

 where all {request.permission='GROUP_INSPECT',  
            request.operation='ListGroups'}

È possibile definire l'ambito dell'accesso solo a un set di indirizzi IP consentiti. Ad esempio, puoi scrivere un criterio per consentire solo alle richieste provenienti da un determinato intervallo di IP pubblici di accedere a un bucket di storage degli oggetti specifico oppure puoi consentire solo a subnet specifiche di una VCN specifica di effettuare richieste tramite un gateway di servizi.

Per limitare l'accesso a un set di indirizzi IP, effettuare le operazioni riportate di seguito.

1. Creare un oggetto di origine di rete che specifichi gli indirizzi IP consentiti. Per i dettagli, vedere Gestione delle origini di rete.
2. Scrivere un criterio che utilizza l'oggetto di origine di rete in una condizione.

Utilizzare la variabile seguente nel criterio:

request.networkSource.name='<network_source_name>'

Ad esempio:

allow group GroupA to manage object-family in tenancy where request.networkSource.name='corpnet'

È possibile utilizzare variabili basate sul tempo nei criteri per limitare l'accesso concesso nel criterio solo a determinati intervalli di tempo. Questa funzione consente di limitare le azioni sulle risorse a orari specifici. Ad esempio, è possibile creare un criterio che consenta l'accesso solo fino a una data specificata. Una politica di questo tipo sarebbe utile se l'azienda assume collaboratori e si desidera assicurarsi che l'accesso non sia consentito oltre la data di fine del contratto. In alternativa, è possibile consentire l'accesso alle risorse solo durante l'orario lavorativo (ad esempio, lunedì-venerdì 9:00 - 5:00 PM). Questa restrizione può ridurre il rischio che un cattivo attore apporti modifiche quando è più probabile che passino inosservati.

Di seguito sono riportate le variabili che è possibile utilizzare per definire l'accesso in base al tempo.

L'uso di queste variabili è descritto in modo più dettagliato nelle sezioni seguenti.

Allow group Contractors to manage instance-family in tenancy where request.utc-timestamp before '2022-01-01T00:00Z'

Allow group SummerInterns to manage instance-family in tenancy where ANY {request.utc-timestamp.month-of-year in ('6', '7', '8')}

Allow group ComplianceAuditors to read all-resources in tenancy where request.utc-timestamp.day-of-month = '1'

Allow group WorkWeek to manage instance-family where ANY {request.utc-timestamp.day-of-week in ('monday', 'tuesday', 'wednesday', 'thursday', 'friday')}

Allow group DayShift to manage instance-family where request.utc-timestamp.time-of-day between '17:00:00Z' and '01:00:00Z'

Allow group NightShift to manage instance-family where request.utc-timestamp.time-of-day between '01:00:00Z' and '17:00:00Z'