Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Logica della valutazione
L'obiettivo al momento della valutazione consiste nel decidere se una determinata richiesta deve essere autorizzata o rifiutata. La logica della valutazione segue diverse regole di base:
-
Di default, tutte le richieste per utilizzare la tua risorsa che provengono da chiunque eccetto te, vengono rifiutate
-
Un consenso sovrascrive tutti i rifiuti per default
-
Un rifiuto esplicito sovrascrive tutti i consensi
-
L'ordine in cui vengono valutate le policy non è importante
Il seguente diagramma di flusso e la discussione descrivono in modo più dettagliato come viene presa la decisione.
1 |
La decisione inizia con un rifiuto per default. |
2 |
Il codice di applicazione quindi valuta tutte le policy applicabili alla richiesta (in base alla risorsa, al principale, all'operazione e alle condizioni). L'ordine in cui il codice di attuazione valuta le policy non è importante. |
3 |
In tutte queste policy, il codice di applicazione cerca un'istruzione di rifiuto esplicito che applicherebbe alla richiesta. Se ne trova anche uno, il codice di applicazione restituisce una decisione di "rifiuto" e il processo è finito (questo è un rifiuto esplicito; per ulteriori informazioni, vedi Rifiuto esplicito). |
4 |
Se non viene trovato un rifiuto esplicito, il codice di applicazione cerca un'istruzione di "consenso" da applicare alla richiesta. Se ne trova anche uno, il codice di applicazione restituisce una decisione di "consenso" e il processo è completato (il servizio continua a elaborare la richiesta). |
5 |
Se non viene trovato alcun consenso, la decisione finale è il "rifiuto" e dal momento che non è stato trovato un rifiuto esplicito o un consenso, questo viene considerato un rifiuto per default (per ulteriori informazioni, vedi Rifiuto per default). |
L'interazione tra rifiuti espliciti e per default
Una policy restituisce un rifiuto per default se non si applica direttamente alla richiesta. Ad esempio, se un utente richiede di utilizzare AmazonSNS, ma la politica sull'argomento non si riferisce Account AWS affatto a quella dell'utente, tale politica comporta una negazione predefinita.
Una policy restituisce un rifiuto per default anche quando una condizione in una dichiarazione non viene soddisfatta. Se tutte le condizioni nella dichiarazione sono soddisfatte, la policy restituisce un consenso o un rifiuto esplicito, a secondo del valore dell'elemento Effetto nella policy. Le policy non specificano cosa fare se una condizione non viene soddisfatta e quindi il risultato di default in quel caso è un rifiuto per default.
Ad esempio, supponiamo che tu voglia impedire le richieste provenienti dall'Antartide. Scrivi una policy (chiamata Policy A1) che consente una richiesta solo se non proviene dall'Antartide. Il diagramma seguente illustra la policy.
Se qualcuno invia una richiesta dagli Stati Uniti, la condizione è soddisfatta (la richiesta non proviene dall'Antartide). Pertanto, la richiesta è consentita. Tuttavia, se qualcuno invia una richiesta dall'Antartide, la condizione non viene soddisfatta e il risultato della policy è quindi un rifiuto per default.
Puoi trasformare il risultato in un rifiuto esplicito riscrivendo la policy (denominata Policy A2) come nel diagramma seguente. In questo caso, la policy rifiuta esplicitamente una richiesta se proviene dall'Antartide.
Se qualcuno invia una richiesta dall'Antartide, la condizione viene soddisfatta e il risultato della policy è quindi un rifiuto esplicito.
La differenza tra un rifiuto per default e un rifiuto esplicito è importante perché un rifiuto per default può essere sovrascritto da un consenso, mentre un rifiuto esplicito no. Ad esempio, supponiamo che ci sia un'altra policy che consente le richieste se arrivano il 1° giugno 2010. In che modo questa policy influisce sul risultato complessivo se abbinata alla policy che limita l'accesso dall'Antartide? Confronteremo il risultato complessivo quando abbiniamo la policy basata sulla data (che chiameremo policy B) con le precedenti policy A1 e A2. Lo scenario 1 abbina la policy A1 con la policy B e lo scenario 2 abbina la policy A2 con la policy B. La seguente figura e la discussione mostrano i risultati quando arriva una richiesta dall'Antartide il 1 giugno 2010.
Nello scenario 1, la policy A1 restituisce un rifiuto per default, come descritto in precedenza in questa sezione. La policy B restituisce un consenso perché la policy (per definizione) consente le richieste che arrivano il 1 giugno 2010. Il consenso dalla policy B sovrascrive il rifiuto per default dalla policy A1 e pertanto la richiesta è consentita.
Nello scenario 2, la policy A2 restituisce un rifiuto esplicito, come descritto in precedenza in questa sezione. Anche in questo caso, la policy B restituisce un consenso. Il rifiuto esplicito dalla policy A2 sovrascrive il consenso dalla policy B e pertanto la richiesta viene rifiutata.