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à.
Raccomandazioni per l'isolamento degli inquilini e la riservatezza dei dati
La sezione precedente ha fornito diversi approcci per l'utilizzo di dati esterni con OPA e Amazon Verified Permissions per facilitare le decisioni di autorizzazione. Ove possibile, consigliamo di utilizzare l'approccio di input in caso di sovraccarico per passare i dati contestuali SaaS a OPA per prendere decisioni di autorizzazione invece di archiviare i dati nella memoria di OPA. Questo caso d'uso non si applica a AWS Cloud Map, perché non supporta l'archiviazione di dati esterni nel servizio.
Nei modelli ibridi di controllo degli accessi basato sui ruoli (RBAC) o RBAC e nei modelli ibridi di controllo degli accessi basato sugli attributi (ABAC), i dati forniti esclusivamente da una richiesta o da una query di autorizzazione potrebbero essere insufficienti, poiché è necessario fare riferimento a ruoli e autorizzazioni per prendere decisioni di autorizzazione. Per mantenere l'isolamento degli inquilini e la riservatezza della mappatura dei ruoli, questi dati non devono risiedere all'interno dell'OPA. I dati RBAC devono risiedere in una fonte di dati esterna come un database o devono essere trasmessi come parte dei claim in un JWT da un IdP. In Verified Permissions, i dati RBAC possono essere gestiti come parte delle politiche e dello schema nel modello di archivio delle politiche per tenant, poiché ogni tenant ha il proprio archivio delle politiche separato logicamente. Tuttavia, nel modello di policy store multi-tenant condiviso, i dati di mappatura dei ruoli non devono risiedere nelle autorizzazioni verificate per mantenere l'isolamento dei tenant.
Inoltre, OPA e Verified Permissions non devono essere utilizzati per mappare ruoli predefiniti a permessi specifici, poiché ciò rende difficile per gli inquilini definire i propri ruoli e le proprie autorizzazioni. Inoltre, rende la logica di autorizzazione rigida e necessita di un aggiornamento costante. L'eccezione a questa linea guida è il modello di archivio delle politiche per tenant in Verified Permissions, poiché questo modello consente a ciascun tenant di disporre di proprie politiche che possono essere valutate indipendentemente su base individuale.
Autorizzazioni verificate da Amazon
L'unico posto in cui Verified Permissions può archiviare dati RBAC potenzialmente privati è nello schema. Ciò è accettabile nel modello di archivio delle politiche per tenant, poiché ogni tenant dispone di un proprio archivio di politiche separato logicamente. Tuttavia, potrebbe compromettere l'isolamento dei tenant nell'unico modello di archivio delle politiche multi-tenant condiviso. Nei casi in cui questi dati siano necessari per prendere una decisione di autorizzazione, devono essere recuperati da una fonte esterna come DynamoDB o Amazon RDS e incorporati nella richiesta di autorizzazione Verified Permissions.
OPA
Gli approcci sicuri con OPA per il mantenimento della privacy e l'isolamento dei tenant dei dati RBAC includono l'utilizzo del recupero o della replica dinamica dei dati per ottenere dati esterni. Questo perché è possibile utilizzare il servizio di autorizzazione illustrato nel diagramma precedente per fornire solo dati esterni specifici del tenant o dell'utente per prendere una decisione di autorizzazione. Ad esempio, è possibile utilizzare un replicatore per fornire dati RBAC o una matrice di autorizzazioni alla cache OPA quando un utente accede e fare in modo che i dati vengano referenziati in base a un utente fornito nei dati di input. È possibile utilizzare un approccio simile con i dati estratti dinamicamente per recuperare solo i dati pertinenti per prendere decisioni di autorizzazione. Inoltre, nell'approccio al recupero dinamico dei dati, questi dati non devono essere memorizzati nella cache in OPA. L'approccio di raggruppamento non è efficace quanto l'approccio di recupero dinamico nel mantenere l'isolamento dei tenant, perché aggiorna tutto ciò che si trova nella cache OPA e non è in grado di elaborare aggiornamenti precisi. Il modello di raggruppamento è ancora un buon approccio per l'aggiornamento delle politiche OPA e dei dati non RBAC.
