Configura accesso basato sulle risorse per gli endpoint REST mediante OCI API Gateway

Il controllo dell'accesso basato sulle risorse consente di gestire l'accesso alle risorse in base agli attributi e alle caratteristiche dell'utente. Differisce dal controllo dell'accesso basato sul ruolo in cui l'accesso alle risorse viene concesso in base al ruolo. Grazie al controllo dell'accesso basato sulle risorse, le autorizzazioni per le raccolte delle API REST (distribuzioni) possono essere assegnate in modo granulare ai singoli consumer.

Ecco alcuni vantaggi dell'implementazione del controllo dell'accesso basato sulle risorse per gli endpoint delle API REST:

  • Implementa un controllo dettagliato per gli endpoint API in hosting Oracle SaaS e Oracle Cloud Infrastructure (OCI).
  • Evitare di esporre le credenziali API backend agli utenti finali e alle applicazioni.
  • Applica l'accesso basato sulle risorse per le API esposte attraverso vari servizi OCI, come Oracle Cloud Infrastructure Kubernetes Engine e OCI Functions.

OCI API Gateway abilita funzionalità aggiuntive di gestione delle API durante l'implementazione del controllo dell'accesso basato sulle risorse per gli endpoint REST:

  • Aiuta a monetizzare le API aziendali utilizzando i piani di utilizzo.
  • Controlla l'uso dell'API con limiti di frequenza e quote.
  • Utilizza i dashboard per monitorare l'uso consolidato delle API basate su sottoscrittori.

Architettura

Questa architettura delinea il controllo dell'accesso basato sulle risorse per gli endpoint REST ospitati su OCI. Gli utenti e le richieste di applicazioni provenienti dalla gestione del capitale umano (HCM) e dalla supply chain e dalla produzione (SCM) possono accedere solo alle rispettive risorse. Gli endpoint REST vengono ospitati ed esposti tramite applicazioni Oracle SaaS e servizi Oracle come OCI Functions, Oracle Integration Cloud Service e OCI Kubernetes Engine.

Le distribuzioni HCM e SCM vengono create nel gateway API OCI. Gli endpoint REST vengono configurati nelle rispettive distribuzioni come servizi backend. Le applicazioni riservate di OCI Identity and Access Management vengono utilizzate per i domini HCM e SCM. L'ambito e i dettagli di audience delle applicazioni riservate client devono corrispondere alla configurazione di convalida JWT delle distribuzioni OCI API Gateway. I consumer HCM e SCM devono disporre dell'accesso all'URL del token di accesso dell'applicazione riservata, all'ID client, al segreto client e all'ambito per la generazione del token. Condividi gli endpoint di distribuzione HCM e SCM di OCI API Gateway con i consumer.

Esegui il provisioning del gateway API OCI in una subnet pubblica per intercettare tutto il traffico Internet. Le funzioni OCI e Oracle Integration Cloud Service sono servizi OCI nativi che espongono le API REST configurate come distribuzioni del gateway API OCI backend. Il gateway API OCI comunica con queste API REST tramite gateway di servizi. I servizi container OCI Kubernetes Engine possono essere ospitati in subnet private e gli endpoint REST esposti tramite i cluster OCI Kubernetes Engine. La comunicazione tra i cluster OCI API Gateway e OCI Kubernetes Engine può essere abilitata tramite liste di sicurezza e regole di instradamento.

Il seguente diagramma illustra questa architettura di riferimento.



resource-based-access-rest-api-arch.zip

Il seguente diagramma illustra il flusso di dati:



Il flusso di dati per gli utenti HCM e SCM è simile al seguente:

  1. (a,b) Configura l'applicazione client riservata e l'applicazione risorsa con ambito e audience.
  2. (a,b) Configura la distribuzione del gateway API OCI con endpoint REST, ambito e audience.
  3. (a,b) L'applicazione utente genera un token JWT utilizzando l'applicazione riservata client. Il token contiene l'ambito e l'audience codificati.
  4. (a,b) Un utente attiva la distribuzione di un endpoint OCI API Gateway utilizzando il relativo token.
  5. (a,b) Il gateway API OCI convalida il token in base all'ambito e all'audience configurati nella distribuzione.
  6. (a,b) Se la convalida riesce, il rispettivo accesso API viene concesso in base alla configurazione di instradamento.
  7. (a,b) Se la convalida non riesce, viene restituito un errore 401 non autorizzato.

L'architettura presenta i seguenti componenti:

  • Area

    Un'area geografica Oracle Cloud Infrastructure è un'area geografica localizzata che contiene uno o più data center, denominati domini di disponibilità. Le regioni sono indipendenti da altre regioni e grandi distanze possono separarle (tra paesi o addirittura continenti).

  • Domini di disponibilità

    I domini di disponibilità sono data center standalone e indipendenti all'interno di un'area geografica. Le risorse fisiche in ciascun dominio di disponibilità sono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono l'infrastruttura, ad esempio alimentazione o raffreddamento, o la rete interna del dominio di disponibilità. Pertanto, un errore in un dominio di disponibilità non dovrebbe influire sugli altri domini di disponibilità nell'area.

  • Domini di errore

    Un dominio di errore consiste in un gruppo di hardware e infrastruttura all'interno di un dominio di disponibilità. Ogni dominio di disponibilità dispone di tre domini di errore con alimentazione e hardware indipendenti. Quando distribuisci le risorse su più domini di errore, le tue applicazioni possono tollerare errori fisici del server, manutenzione del sistema e errori di alimentazione all'interno di un dominio di errore.

  • Rete cloud virtuale (VCN) e subnet

    Una VCN è una rete personalizzabile e definita dal software configurata in un'area Oracle Cloud Infrastructure. Come le tradizionali reti di data center, le reti VCN consentono di controllare l'ambiente di rete. Una VCN può avere più blocchi CIDR non sovrapposti che è possibile modificare dopo aver creato la VCN. Puoi segmentare una VCN in subnet, che possono essere definite in un'area o in un dominio di disponibilità. Ogni subnet è costituita da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet nella VCN. È possibile modificare le dimensioni di una subnet dopo la creazione. Una subnet può essere pubblica o privata.

  • Motore Kubernetes OCI

    Oracle Cloud Infrastructure Kubernetes Engine (Kubernetes Engine o OKE) è un servizio completamente gestito, scalabile e ad alta disponibilità che puoi utilizzare per distribuire le tue applicazioni containerizzate nel cloud. Puoi specificare le risorse di computazione richieste dalle tue applicazioni e Kubernetes Engine le esegue sul Oracle Cloud Infrastructure in una tenancy esistente. OKE utilizza Kubernetes per automatizzare l'implementazione, la scalabilità e la gestione di applicazioni containerizzate tra cluster di host.

  • Gateway API

    Oracle API Gateway ti consente di pubblicare le API con endpoint privati accessibili dall'interno della tua rete e che, se necessario, puoi esporre alla rete Internet pubblica. Gli endpoint supportano la convalida delle API, la trasformazione delle richieste e delle risposte, il CORS, l'autenticazione e l'autorizzazione e la limitazione delle richieste.

  • Funzioni

    Oracle Cloud Infrastructure Functions è una piattaforma completamente gestita, multi-tenant, altamente scalabile, on-demand e Functions-as-a-Service (FaaS). È alimentato dal motore open source Fn Project. Le funzioni consentono di distribuire il codice e di chiamarlo direttamente o di attivarlo in risposta agli eventi. Oracle Functions utilizza i container Docker ospitati in Oracle Cloud Infrastructure Registry.

  • Integrazione

    Oracle Integration è un servizio completamente gestito che consente di integrare le applicazioni, automatizzare i processi, ottenere insight sui processi aziendali e creare applicazioni visive.

  • Identity and Access Management (IAM)

    Oracle Cloud Infrastructure Identity and Access Management (IAM) è il piano di controllo dell'accesso per Oracle Cloud Infrastructure (OCI) e Oracle Cloud Applications. L'API IAM e l'interfaccia utente consentono di gestire i domini di Identity e le risorse all'interno del dominio di Identity. Ogni dominio di Identity IAM OCI rappresenta una soluzione standalone per la gestione delle identità e degli accessi o una popolazione di utenti diversa.

Suggerimenti

Utilizzare i seguenti suggerimenti come punto di partenza. I tuoi requisiti potrebbero essere diversi dall'architettura descritta qui.
  • Ambienti di produzione e non di produzione

    Crea più domini di Identity e istanze separate di OCI API Gateway per la produzione e la non produzione per un migliore controllo dell'accesso e dell'isolamento degli utenti.

  • Sicurezza

    Memorizzare le credenziali backend in OCI Vault per una maggiore sicurezza. Se il segreto client è stato compromesso, rigenerarlo.

Considerazioni

Quando si implementa questa architettura di riferimento, tenere presente quanto riportato di seguito.

  • Prestazioni

    In OCI API Gateway sono disponibili funzioni per la limitazione di frequenza e la quota che consentono di ottimizzare le prestazioni e ridurre la latenza. Ecco alcuni dei vantaggi:

    • Mantieni alta disponibilità e uso corretto delle risorse proteggendo il tuo backend dalla sovrascrittura di troppe richieste.
    • Previeni gli attacchi di tipo servizio negato.
    • Vincolare i costi del consumo delle risorse.
    • Limita l'uso delle API da parte degli utenti dei tuoi clienti per monetizzare le API.
  • Sicurezza

    Stabilisci processi di governance per gestire le credenziali dei clienti e i consumatori.

  • Disponibilità

    Crea gateway API nelle subnet regionali (non nelle subnet specifiche del dominio di disponibilità) per garantire alta disponibilità.

  • Costo

    OCI API Gateway è un'opzione conveniente con un modello di prezzo equo.

conferme

  • Autore: Subburam Mathuraiveeran
  • Collaboratori: Wei Han, Robert Wunderlich