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à.
Modelli di progettazione per OPA
Utilizzo di un PDP centralizzato con on PEPs APIs
Il punto decisionale centralizzato (PDP) con punti di applicazione delle politiche (PEPs) sul APIs modello segue le migliori pratiche del settore per creare un sistema efficace e di facile manutenzione per il controllo e l'autorizzazione degli accessi alle API. Questo approccio supporta diversi principi chiave:
-
L'autorizzazione e il controllo dell'accesso alle API vengono applicati in più punti dell'applicazione.
-
La logica di autorizzazione è indipendente dall'applicazione.
-
Le decisioni sul controllo degli accessi sono centralizzate.
Questo modello utilizza un PDP centralizzato per prendere decisioni di autorizzazione. PEPs vengono implementati interamente APIs per effettuare richieste di autorizzazione al PDP. Il diagramma seguente mostra come implementare questo modello in un'ipotetica applicazione SaaS multi-tenant.
Flusso dell'applicazione (illustrato con callout numerati in blu nel diagramma):
-
Un utente autenticato con un JWT genera una richiesta HTTP ad Amazon. CloudFront
-
CloudFront inoltra la richiesta ad Amazon API Gateway, che è configurato come CloudFront origine.
-
Viene chiamato un autorizzatore personalizzato API Gateway per verificare il JWT.
-
I microservizi rispondono alla richiesta.
Flusso di autorizzazione e controllo dell'accesso alle API (illustrato con callout numerati in rosso nel diagramma):
-
Il PEP chiama il servizio di autorizzazione e trasmette i dati della richiesta, compresi quelli. JWTs
-
Il servizio di autorizzazione (PDP) prende i dati della richiesta e interroga un'API REST dell'agente OPA, che viene eseguita come sidecar. I dati della richiesta servono come input per la query.
-
L'OPA valuta l'input in base alle politiche pertinenti specificate dalla query. I dati vengono importati per prendere una decisione di autorizzazione, se necessario.
-
L'OPA restituisce una decisione al servizio di autorizzazione.
-
La decisione di autorizzazione viene restituita al PEP e valutata.
In questa architettura, PEPs richiedi le decisioni di autorizzazione sugli endpoint del servizio per Amazon CloudFront e Amazon API Gateway e per ogni microservizio. La decisione di autorizzazione viene presa da un servizio di autorizzazione (il PDP) con un sidecar OPA. È possibile utilizzare questo servizio di autorizzazione come contenitore o come istanza di server tradizionale. Il sidecar OPA espone la propria RESTful API localmente in modo che l'API sia accessibile solo al servizio di autorizzazione. Il servizio di autorizzazione espone un'API separata disponibile per. PEPs Il fatto che il servizio di autorizzazione funga da intermediario tra OPA PEPs e OPA consente l'inserimento di qualsiasi logica di trasformazione tra OPA PEPs e OPA che possa essere necessaria, ad esempio quando la richiesta di autorizzazione di un PEP non è conforme all'input di query previsto dall'OPA.
È inoltre possibile utilizzare questa architettura con motori di policy personalizzati. Tuttavia, tutti i vantaggi ottenuti dall'OPA devono essere sostituiti con la logica fornita dal motore di policy personalizzato.
Un PDP centralizzato con PEPs acceso APIs offre un'opzione semplice per creare un solido sistema di autorizzazione per. APIs È semplice da implementare e fornisce anche un' easy-to-useinterfaccia ripetibile per prendere decisioni di autorizzazione per microservizi APIs, livelli di Backend for Frontend (BFF) o altri componenti applicativi. Tuttavia, questo approccio potrebbe creare troppa latenza nell'applicazione, poiché le decisioni di autorizzazione richiedono la chiamata di un'API separata. Se la latenza di rete è un problema, potreste prendere in considerazione un PDP distribuito.
Utilizzo di un PDP distribuito con attivo PEPs APIs
Il APIs modello PDP (Distributed Policy Decision Point) con Policy Enforcement Points (PEPs) segue le best practice del settore per creare un sistema efficace per il controllo e l'autorizzazione degli accessi alle API. Analogamente al PDP centralizzato con un PEPs APIs modello, questo approccio supporta i seguenti principi chiave:
-
L'autorizzazione e il controllo dell'accesso alle API vengono applicati in più punti dell'applicazione.
-
La logica di autorizzazione è indipendente dall'applicazione.
-
Le decisioni sul controllo degli accessi sono centralizzate.
Potresti chiederti perché le decisioni sul controllo degli accessi sono centralizzate quando il PDP viene distribuito. Sebbene il PDP possa esistere in più punti di un'applicazione, deve utilizzare la stessa logica di autorizzazione per prendere decisioni sul controllo degli accessi. Tutti PDPs forniscono le stesse decisioni di controllo degli accessi e forniscono gli stessi input. PEPs sono completamente implementati APIs per effettuare richieste di autorizzazione al PDP. La figura seguente mostra come questo modello distribuito può essere implementato in un'ipotetica applicazione SaaS multi-tenant.
In questo approccio, PDPs vengono implementati in più punti dell'applicazione. Per i componenti applicativi che dispongono di funzionalità di elaborazione integrate in grado di eseguire OPA e supportare un PDP, come un servizio containerizzato con un sidecar o un'istanza Amazon Elastic Compute Cloud (Amazon EC2), le decisioni PDP possono essere integrate direttamente nel componente dell'applicazione senza dover effettuare una chiamata API a un servizio PDP centralizzato. RESTful Ciò ha il vantaggio di ridurre la latenza che si potrebbe riscontrare nel modello PDP centralizzato, poiché non tutti i componenti dell'applicazione devono effettuare chiamate API aggiuntive per ottenere decisioni di autorizzazione. Tuttavia, in questo modello è ancora necessario un PDP centralizzato per i componenti applicativi che non dispongono di funzionalità di elaborazione integrate che consentano l'integrazione diretta di un PDP, come il servizio Amazon o Amazon CloudFront API Gateway.
Il diagramma seguente mostra come questa combinazione di un PDP centralizzato e un PDP distribuito può essere implementata in un'ipotetica applicazione SaaS multi-tenant.
Flusso dell'applicazione (illustrato con callout numerati in blu nel diagramma):
-
Un utente autenticato con un JWT genera una richiesta HTTP ad Amazon. CloudFront
-
CloudFront inoltra la richiesta ad Amazon API Gateway, che è configurato come CloudFront origine.
-
Viene chiamato un autorizzatore personalizzato API Gateway per verificare il JWT.
-
I microservizi rispondono alla richiesta.
Flusso di autorizzazione e controllo dell'accesso alle API (illustrato con callout numerati in rosso nel diagramma):
-
Il PEP chiama il servizio di autorizzazione e trasmette i dati della richiesta, compresi quelli. JWTs
-
Il servizio di autorizzazione (PDP) prende i dati della richiesta e interroga un'API REST dell'agente OPA, che viene eseguita come sidecar. I dati della richiesta servono come input per la query.
-
L'OPA valuta l'input in base alle politiche pertinenti specificate dalla query. I dati vengono importati per prendere una decisione di autorizzazione, se necessario.
-
L'OPA restituisce una decisione al servizio di autorizzazione.
-
La decisione di autorizzazione viene restituita al PEP e valutata.
In questa architettura, PEPs richiedi le decisioni di autorizzazione agli endpoint di servizio per CloudFront un API Gateway e per ogni microservizio. La decisione di autorizzazione per i microservizi viene presa da un servizio di autorizzazione (il PDP) che funge da complemento al componente dell'applicazione. Questo modello è possibile per microservizi (o servizi) eseguiti su contenitori o istanze Amazon Elastic Compute Cloud EC2 (Amazon). Le decisioni di autorizzazione per servizi come API Gateway richiedono CloudFront comunque il contatto con un servizio di autorizzazione esterno. Indipendentemente da ciò, il servizio di autorizzazione espone un'API disponibile per PEPs. Il fatto che il servizio di autorizzazione funga da intermediario tra OPA PEPs e OPA consente l'inserimento di qualsiasi logica di trasformazione tra OPA PEPs e OPA che potrebbe essere necessaria, ad esempio quando la richiesta di autorizzazione di un PEP non è conforme all'input di query previsto dall'OPA.
È inoltre possibile utilizzare questa architettura con motori di policy personalizzati. Tuttavia, tutti i vantaggi ottenuti dall'OPA devono essere sostituiti con la logica fornita dal motore di policy personalizzato.
Un PDP distribuito con PEPs acceso APIs offre la possibilità di creare un solido sistema di autorizzazione per. APIs È semplice da implementare e fornisce un' easy-to-useinterfaccia ripetibile per prendere decisioni di autorizzazione per microservizi APIs, livelli di Backend for Frontend (BFF) o altri componenti applicativi. Questo approccio ha anche il vantaggio di ridurre la latenza che si potrebbe riscontrare nel modello PDP centralizzato.
Utilizzo di un PDP distribuito come libreria
È inoltre possibile richiedere decisioni di autorizzazione a un PDP reso disponibile come libreria o pacchetto da utilizzare all'interno di un'applicazione. OPA può essere utilizzata come libreria Go di terze parti. Per altri linguaggi di programmazione, l'adozione di questo modello in genere significa che è necessario creare un motore di policy personalizzato.
