Funzioni dei criteri avanzati

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

Ogni condizione è costituita da una o più variabili predefinite per le quali si specificano i 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, restituisce false e la richiesta non è consentita.

Esistono due tipi di variabili: quelle rilevanti per la richiesta stessa e quelle relative alla risorsa su cui viene eseguita la richiesta, note anche come destinazione. Il nome della variabile viene preceduto di conseguenza da 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'istruzione criteri estesa, ma aggiunge una condizione basata sull'operazione API specifica. Per un esempio, vedere Consenti agli utenti della scrittura di oggetti nei bucket di storage degli elementi.

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 nel linguaggio dei criteri. Quando si scrive un criterio che consente a un gruppo di accedere a un particolare verbo e tipo di risorsa, si concede effettivamente 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 insieme di accesso o un particolare scenario operativo. Le sezioni successive forniscono maggiori dettagli ed esempi.

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

Ad esempio, supponiamo che il gruppo XYZ sia in grado di elencare, ottenere, creare o aggiornare i gruppi (ad esempio, modificarne la descrizione), ma non 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 riportata in Dettagli per verbi + combinazioni di tipi 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 dichiara 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 sarebbe 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, tieni presente che qualsiasi nuova autorizzazione che il servizio potrebbe aggiungere in futuro verrà automaticamente concessa al gruppo XYZ. Verrà omesso solo GROUP_DELETE.

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

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 precedente, tale criterio controllerà già l'accesso del gruppo XYZ alla nuova operazione API.

Tuttavia, è possibile definire ulteriormente l'ambito dell'accesso di un utente a un'autorizzazione specificando anche una condizione basata sull'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 estendere l'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 ulteriori informazioni, 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 come questa sarebbe utile se la tua azienda assumesse appaltatori e si desidera garantire 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 di lavoro (ad esempio, dal lunedì al venerdì dalle 9:00 alle 5:00 PM). Questa restrizione può ridurre il rischio che un cattivo attore faccia cambiamenti quando è più probabile che passino inosservati.

Di seguito sono riportate le variabili che è possibile utilizzare per definire l'ambito dell'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'