Policy basate sull'identità e sulle risorse

In AWS, le autorizzazioni derivano da policy associate in due punti: a un'identità (utente, gruppo o ruolo) oppure a una risorsa (come un bucket S3 o una chiave KMS). Sapere quale tipo si applica e come si combinano i due tipi è essenziale per l'esame, perché l'accesso tra account dipende interamente da questa distinzione.

Una policy basata sull'identità è associata a un principal IAM e definisce ciò che tale principal può fare. Non contiene alcun elemento Principal, perché il principal è quello a cui la policy è associata. Queste policy possono essere gestite da AWS, gestite dal cliente oppure inline e rappresentano il modo più comune per concedere autorizzazioni.

Una policy basata sulle risorse è associata direttamente a una risorsa e include un elemento Principal che indica chi può accedere. Ne sono esempi le policy dei bucket S3, le policy delle chiavi KMS, le policy delle code SQS e le policy delle funzioni Lambda. Specificano sia chi (Principal) sia che cosa (Action) può essere eseguito su quella risorsa.

Questa policy di bucket S3 concede a un altro account l'accesso in lettura. Principal identifica l'account considerato attendibile, operazione possibile solo con una policy basata sulle risorse.

All'interno di un singolo account, le policy basate sull'identità e quelle basate sulle risorse si combinano come un'unione: una richiesta è consentita se viene autorizzata da una delle due (e nulla la nega). Pertanto, è possibile accedere a un oggetto S3 se lo consente la policy dell'utente oppure la policy del bucket. È sufficiente che una delle due conceda l'accesso.

Per l'accesso tra account, la regola è più restrittiva: entrambi i lati devono consentirlo. Il principal deve disporre di una policy basata sull'identità che autorizzi l'azione e la policy basata sulle risorse nell'altro account deve concedere l'accesso a quel principal. Se manca una delle due parti, la richiesta viene negata. Questa distinzione è verificata frequentemente.

Le policy di attendibilità dei ruoli sono tecnicamente un tipo di policy basata sulle risorse. Per questo, l'assunzione di un ruolo tra account richiede la policy di attendibilità oltre all'autorizzazione basata sull'identità sts:AssumeRole del chiamante. Riconoscere la policy di attendibilità come policy basata sulle risorse aiuta a creare un modello mentale coerente del modo in cui vengono concesse le autorizzazioni.

Non tutti i servizi supportano le policy basate sulle risorse. Tra i principali vi sono S3, KMS, SQS, SNS, Lambda, Secrets Manager ed ECR. Quando un servizio non dispone di policy delle risorse, l'accesso tra account deve essere concesso tramite l'assunzione di un ruolo. L'esame può verificare se un approccio scelto sia effettivamente possibile per un determinato servizio.

Utilizzi le policy basate sull'identità per autorizzazioni generali del tipo "questo team può eseguire queste operazioni". Utilizzi le policy basate sulle risorse quando deve concedere l'accesso a uno specifico principal esterno, abilitare la condivisione tra account in un servizio che la supporta oppure impostare autorizzazioni che rimangano associate alla risorsa stessa.

Poiché l'accesso può provenire da entrambi i lati, per una verifica completa è necessario controllarli entrambi. IAM Access Analyzer analizza le policy basate sulle risorse per individuare quelle condivise esternamente o pubblicamente. La simulazione delle policy e i dati sugli ultimi accessi aiutano a verificare il lato dell'identità. Una revisione completa non considera mai un solo tipo di policy.

L'accesso nello stesso account è un'unione (una delle due policy può consentirlo), mentre l'accesso tra account richiede che siano consentite entrambe la policy dell'identità e la policy della risorsa. Le policy dell'identità non hanno Principal; quelle delle risorse sì. Scelga il tipo di policy in base allo scenario e ricordi quali servizi supportano effettivamente le policy basate sulle risorse.

Le policy basate sull'identità sono associate ai principal e non contengono l'elemento Principal; le policy basate sulle risorse sono associate alle risorse e indicano un Principal. L'accesso nello stesso account è un'unione delle due; l'accesso tra account richiede che siano consentite entrambe. Solo alcuni servizi (S3, KMS, SQS, SNS, Lambda, Secrets Manager ed ECR) supportano le policy delle risorse; negli altri casi occorre assumere un ruolo.