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à.
Domande frequenti
Questa sezione fornisce le risposte alle domande più frequenti sull'implementazione del controllo e dell'autorizzazione degli accessi alle API nelle applicazioni SaaS multi-tenant.
D: Qual è la differenza tra autorizzazione e autenticazione?
R. L'autenticazione è il processo di verifica dell'identità di un utente. L'autorizzazione concede agli utenti le autorizzazioni per accedere a una risorsa specifica.
D: Qual è la differenza tra l'autorizzazione e l'isolamento dei tenant in un'applicazione SaaS?
R. L'isolamento dei tenant si riferisce a meccanismi espliciti utilizzati in un sistema SaaS per garantire che le risorse di ciascun tenant, anche quando operano su un'infrastruttura condivisa, siano isolate. L'autorizzazione multi-tenant si riferisce all'autorizzazione delle azioni in entrata e alla prevenzione che vengano implementate sul tenant sbagliato. Un utente ipotetico potrebbe essere autenticato e autorizzato, ma potrebbe comunque essere in grado di accedere alle risorse di un altro tenant. Nulla di ciò che riguarda l'autenticazione e l'autorizzazione blocca necessariamente questo accesso, ma l'isolamento dei tenant è necessario per raggiungere questo obiettivo. Per ulteriori informazioni su questi due concetti, consulta la discussione sull'isolamento dei tenant nel white paper AWS SaaS Architecture Fundamentals.
D: Perché devo prendere in considerazione l'isolamento dei tenant per la mia applicazione SaaS?
R. Le applicazioni SaaS hanno più tenant. Un tenant può essere un'organizzazione cliente o qualsiasi entità esterna che utilizza quell'applicazione SaaS. A seconda di come è progettata l'applicazione, ciò significa che i tenant potrebbero accedere a risorse condivise APIs, a database o ad altre risorse. È importante mantenere l'isolamento dei tenant, vale a dire costrutti che controllano rigorosamente l'accesso alle risorse e bloccano qualsiasi tentativo di accesso alle risorse di un altro tenant, per impedire agli utenti di un tenant di accedere alle informazioni private di un altro tenant. Le applicazioni SaaS sono spesso progettate per garantire che l'isolamento dei tenant sia mantenuto in tutta l'applicazione e che i tenant possano accedere solo alle proprie risorse.
D: Perché ho bisogno di un modello di controllo degli accessi?
R. I modelli di controllo degli accessi vengono utilizzati per creare un metodo coerente per determinare come concedere l'accesso alle risorse di un'applicazione. Ciò può essere fatto assegnando ruoli agli utenti strettamente allineati alla logica aziendale, oppure può basarsi su altri attributi contestuali, come l'ora del giorno o se un utente soddisfa una condizione predefinita. I modelli di controllo degli accessi costituiscono la logica di base utilizzata dall'applicazione per prendere decisioni di autorizzazione per determinare le autorizzazioni degli utenti.
D: Il controllo dell'accesso alle API è necessario per la mia applicazione?
R. Sì. APIs deve sempre verificare che il chiamante disponga dell'accesso appropriato. Il controllo pervasivo degli accessi alle API garantisce inoltre che l'accesso sia concesso solo in base ai tenant, in modo da poter mantenere l'isolamento appropriato.
D: Perché i motori di policy sono o PDPs sono consigliati per l'autorizzazione?
R. Un punto di decisione sulle politiche (PDP) consente di scaricare la logica di autorizzazione nel codice dell'applicazione su un sistema separato. Questo può semplificare il codice dell'applicazione. Fornisce inoltre un'interfaccia easy-to-use idempotente per prendere decisioni di autorizzazione per microservizi APIs, livelli di Backend for Frontend (BFF) o qualsiasi altro componente dell'applicazione.
D: Cos'è un PEP?
R. Un Policy Enforcement Point (PEP) è responsabile della ricezione delle richieste di autorizzazione inviate al PDP per la valutazione. Un PEP può trovarsi in qualsiasi punto di un'applicazione in cui i dati e le risorse devono essere protetti o in cui viene applicata la logica di autorizzazione. PEPs sono relativamente semplici rispetto a. PDPs Un PEP è responsabile solo della richiesta e della valutazione di una decisione di autorizzazione e non richiede alcuna logica di autorizzazione per essere incorporata in essa.
D: Come devo scegliere tra Amazon Verified Permissions e OPA?
R. Per scegliere tra Autorizzazioni verificate e Open Policy Agent (OPA), tieni sempre a mente il tuo caso d'uso e i tuoi requisiti unici. Verified Permissions offre un modo completamente gestito per definire autorizzazioni dettagliate, controllare le autorizzazioni tra le applicazioni e centralizzare il sistema di amministrazione delle policy per le applicazioni, soddisfacendo al contempo i requisiti di latenza delle applicazioni con un'elaborazione in millisecondi. OPA è un motore di policy open source generico che può anche aiutarti a unificare le policy in tutto lo stack di applicazioni. Per eseguire OPA è necessario ospitarlo nel proprio AWS ambiente, in genere con un contenitore o delle funzioni. AWS Lambda
Verified Permissions utilizza il linguaggio di policy open source Cedar, mentre OPA utilizza Rego. Pertanto, la familiarità con una di queste lingue potrebbe indurti a scegliere quella soluzione. Tuttavia, ti consigliamo di leggere informazioni su entrambe le lingue e poi di risolvere il problema che stai cercando di risolvere per trovare la soluzione migliore per il tuo caso d'uso.
D: Esistono alternative open source alle autorizzazioni verificate e all'OPA?
R. Esistono alcuni sistemi open source simili a Verified Permissions e Open Policy Agent (OPA), come il Common Expression Language (CEL).
D: Devo scrivere un servizio di autorizzazione per utilizzare OPA o posso interagire direttamente con OPA?
R. È possibile interagire direttamente con OPA. Nel contesto di questa guida, un servizio di autorizzazione si riferisce a un servizio che traduce le richieste di decisione di autorizzazione in interrogazioni OPA e viceversa. Se l'applicazione è in grado di interrogare e accettare direttamente le risposte OPA, non è necessario introdurre questa complessità aggiuntiva.
D: Come posso monitorare i miei agenti OPA per scopi di uptime e controllo?
R. OPA fornisce la registrazione e il monitoraggio di base dell'uptime, sebbene la sua configurazione predefinita sia probabilmente insufficiente per le implementazioni aziendali. Per ulteriori informazioni, consultate la sezione relativa al DevOpsmonitoraggio e alla registrazione precedente di questa guida.
D: Come posso monitorare le autorizzazioni verificate per scopi di operatività e controllo?
R. Verified Permissions è un servizio AWS gestito e la disponibilità può essere monitorata tramite. AWS Health Dashboard Inoltre, Verified Permissions è in grado di accedere ad AWS CloudTrail Amazon CloudWatch Logs, Amazon S3 e Amazon Data Firehose.
D: Quali sistemi operativi e AWS servizi posso usare per eseguire OPA?
R. È possibile eseguire OPA su macOS, Windows e Linux
D: Quali sistemi operativi e servizi posso usare per eseguire le autorizzazioni verificate AWS?
R. Verified Permissions è un servizio AWS gestito ed è gestito da. AWS Non è necessaria alcuna configurazione, installazione o hosting aggiuntivi per utilizzare le autorizzazioni verificate, ad eccezione della possibilità di effettuare richieste di autorizzazione al servizio.
D: Posso eseguire OPA su? AWS Lambda
R. È possibile eseguire OPA su Lambda come libreria Go. Per informazioni su come eseguire questa operazione per un autorizzatore Lambda API Gateway, consulta il post del AWS blog Creazione di un autorizzatore Lambda personalizzato utilizzando Open Policy Agent
D: Come devo decidere tra un approccio PDP distribuito e un PDP centralizzato?
R. Dipende dall'applicazione. Molto probabilmente verrà determinato in base alla differenza di latenza tra un modello PDP distribuito e uno centralizzato. Ti consigliamo di creare un proof of concept e di testare le prestazioni dell'applicazione per verificare la soluzione.
D: Posso usare OPA anche per altri casi d'uso? APIs
R. Sì. La documentazione OPA fornisce esempi per Kubernetes
D: Posso utilizzare le autorizzazioni verificate anche per altri casi d'uso? APIs
R. Sì. Verified Permissions può fornire una DENY risposta ALLOW OR a qualsiasi richiesta di autorizzazione ricevuta. Verified Permissions può fornire risposte di autorizzazione per qualsiasi applicazione o servizio che richieda decisioni di autorizzazione.
D: Posso creare policy in Verified Permissions utilizzando il linguaggio di policy IAM?
R. No. È necessario utilizzare il linguaggio delle politiche Cedar per creare politiche. Cedar è progettato per supportare la gestione delle autorizzazioni per le risorse delle applicazioni dei clienti, mentre il linguaggio di policy AWS Identity and Access Management (IAM) si è evoluto per supportare il controllo degli accessi alle risorse. AWS
