{"id":5726,"date":"2023-03-31T12:00:15","date_gmt":"2023-03-31T10:00:15","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=5726"},"modified":"2023-03-31T15:06:04","modified_gmt":"2023-03-31T13:06:04","slug":"iam-policy-e-service-control-policies-scps-come-gestire-in-modo-sicuro-accessi-e-permessi-allinterno-di-una-landing-zone-su-aws","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/iam-policy-e-service-control-policies-scps-come-gestire-in-modo-sicuro-accessi-e-permessi-allinterno-di-una-landing-zone-su-aws\/","title":{"rendered":"IAM Policy e Service Control Policies (SCPs): come gestire in modo sicuro accessi e permessi all\u2019interno di una Landing Zone su AWS"},"content":{"rendered":"\n

Bentornati su Proud2beCloud! <\/em><\/p>\n\n\n\n

Oggi vi presentiamo un’uscita speciale: direttamente dal blog di <\/em>Noovolari Leapp<\/a> dedicato a IAM, Nicol\u00f2 Marchesi – Nico per gli amici! \ud83d\ude42 – ci guider\u00e0 alla scoperta di uno degli aspetti-chiave per una strategia multi-account di successo su AWS.<\/em><\/p>\n\n\n\n

Vi abbiamo gi\u00e0 parlato in questa serie<\/a> dell’importanza di impostare fin da subito un ambiente AWS sicuro, dinamico, scalabile e “a prova di futuro” e di come, in questo contesto, una la Landing Zone progettata a regola d’arte giochi un ruolo fondamentale. <\/em><\/p>\n\n\n\n

Nella sua implementazione, tuttavia, occorre prestare particolare attenzione ad alcuni aspetti. Uno di questi \u00e8 la gestione sicura degli accessi a risorse, ambienti e account. Abbiamo chiesto a chi di Cloud Access Management se ne intende per davvero di raccontarci tutto ci\u00f2 che sa sull’argomento. In particolare, oggi ci parler\u00e0 di come utilizzare le IAM Policy e le Service Control Policies (SCPs) in modo efficace per permettere alle aziende a soddisfare vincoli di security e governance. <\/em><\/p>\n\n\n\n

Parola a Nico! <\/em><\/p>\n\n\n\n

Ciao compagni di cloud! <\/p>\n\n\n\n

Oggi approfondiremo la serie sulla cloud landing zone<\/strong> per esplorare un contesto affascinante ma spesso ignorato… le Service Control Policies (SCP)! Le SCP sono potenti, ma ci sono alcune precauzioni e trucchi per farle funzionare efficacemente con ogni diverso tipo di policy IAM<\/strong>. In questo post del blog, vedremo come interagisce l’intero ecosistema IAM e come possiamo sfruttare efficacemente gli strumenti per implementare una strategia IAM nella nostra landing zone.<\/p>\n\n\n\n

C’\u00e8 molto da dire, quindi iniziamo subito!<\/p>\n\n\n\n

\n\n\n\n

Non voglio tediarti con tutti i dettagli su AWS Organizations in modo da poter mantenere il nostro focus sul flusso IAM. Se ti serve, consulta prima uno dei migliaia di articoli sul web o controlla QUESTO<\/a> che ho scritto.<\/p>\n\n\n\n

\n\n\n\n

Policy<\/h2>\n\n\n\n

Quindi, andiamo a coprire le basi (per i pi\u00f9 pigri di voi, saltate pure a dopo il grafico, c’\u00e8 un pratico riassunto in punti). Prima di passare direttamente alle interazioni, dobbiamo capire che strumenti abbiamo a disposizione nella nostra strategia IAM:<\/p>\n\n\n\n

    \n
  1. Le Identity-based policies<\/strong> sono il tipo di policy pi\u00f9 comune. Sono legate agli utenti, ai gruppi e ai ruoli IAM e specificano le azioni che tali entit\u00e0 possono eseguire su determinati servizi AWS.<\/li>\n\n\n\n
  2. D’altra parte, le Resource-based policies<\/strong> sono policy direttamente associate a una risorsa AWS, come un bucket S3 o un’istanza EC2. Queste policies specificano chi ha accesso alla risorsa e quali azioni possono eseguire. Non tutti i servizi AWS le supportano (per una lista completa, controllare la pagina AWS services that work with IAM<\/a><\/strong>), e di solito vengono utilizzate per scenari molto specifici.<\/li>\n\n\n\n
  3. Le Permission Boundaries (PBs)<\/strong> sono policy che definiscono le autorizzazioni massime che un’entit\u00e0 IAM pu\u00f2 avere. Queste politiche limitano le autorizzazioni di un’entit\u00e0, garantendo che non possa eseguire azioni che superano il loro ambito autorizzato. I limiti di autorizzazione sono scritti anche nel linguaggio delle politiche AWS e possono essere allegati alle entit\u00e0 IAM.<\/li>\n\n\n\n
  4. Le Service Control Policies (SCPs)<\/strong> impongono restrizioni sugli account AWS all’interno di un’organizzazione AWS. Le SCP sono policy gerarchiche applicate all’intera Organization o a Organizational Unit (OU) specifiche. Le SCP possono essere utilizzate per limitare le azioni che un account AWS pu\u00f2 eseguire, impedendo loro di eseguire attivit\u00e0 al di fuori del loro perimetro autorizzato.<\/li>\n\n\n\n
  5. Le Session Policies<\/strong> sono applicate alle credenziali temporanee create dai ruoli IAM. Le Session Policies limitano le autorizzazioni di un set di credenziali temporanee, garantendo che non possano eseguire azioni che superano il loro perimetro autorizzato. Tuttavia, funzionano principalmente come PB e SCP: non concedono autorizzazioni e vengono applicate solo per la durata del token. Per semplicit\u00e0, le introdurremo solo alla fine, quindi per ora, non lo considereremo.<\/li>\n<\/ol>\n\n\n\n

    Avvertenze<\/h2>\n\n\n\n

    Come potreste gi\u00e0 intuire, esiste una differenza fondamentale tra queste policy, ed \u00e8 illustrata nel diagramma dall’azione che collega la policy alle effettive autorizzazioni.<\/p>\n\n\n\n

    NOTA: Permission Boundaries e Service Control Policies NON conferiscono ALCUNA autorizzazione.<\/em><\/p>\n\n\n\n

    Un’identit\u00e0 pu\u00f2 accedere a una risorsa solo attraverso le policy basate sull’identit\u00e0 e sulle risorse. Le Permission Boundaries e le Service Control Policies possono solo limitare le autorizzazioni menzionate in precedenza. Ci\u00f2 significa che abbiamo bisogno di una policy basata sull’identit\u00e0 o sulla risorsa che consente esplicitamente l’autorizzazione per permettere all’elaboratore di valutare positivamente la policy.<\/p>\n\n\n\n

    <\/p>\n\n\n

    \n
    \"permission<\/figure><\/div>\n\n\n

    <\/p>\n\n\n\n

    In breve, le Identity-based e le Resource-based policies definiscono chi pu\u00f2 accedere alle risorse e quali azioni possono eseguire. Le Permission boundaries e le Service Control Policies limitano la portata di tali autorizzazioni, garantendo che le entit\u00e0 non possano eseguire azioni non autorizzate.<\/p>\n\n\n\n

    Rappresentazione visiva dell’interazione tra le policy<\/strong><\/h2>\n\n\n\n

    Vediamo ora una rappresentazione visiva delle nostre policy: iniziamo vedendo come funziona in un singolo account, e poi vediamo come le cose cambiano aggiungendo AWS Organizations all’equazione.<\/p>\n\n\n\n

    S\u00ec, so che le icone differiscono dal framework di AWS, ma per favore abbiate pazienza; voglio evidenziare le differenze e il fatto che stiamo lavorando con policy fondamentalmente diverse.<\/p>\n\n\n\n

    Singolo account (senza Organizzazioni)<\/strong><\/h3>\n\n\n\n

    Come potete vedere, i tre elementi che possiamo utilizzare sono le Identity-based e le Resource-based policies, e le Permission boundaries:<\/p>\n\n\n\n

    <\/p>\n\n\n

    \n
    \"aws<\/figure><\/div>\n\n\n

    <\/p>\n\n\n\n

    Come possiamo vedere, mentre le policy che entrano e escono dall’Identit\u00e0 e dalle Risorse concedono l’accesso, le Permission Boundaries limitano invece quel set di autorizzazioni.<\/p>\n\n\n\n

    \u00c8 di fatto impossibile concedere autorizzazioni aggiuntive tramite l’uso delle Permission Boundaries.<\/p>\n\n\n\n

    Struttura dell’organizzazione<\/strong><\/h3>\n\n\n\n

    Quando integriamo il servizio AWS Organizations, acquisiamo la capacit\u00e0 di utilizzare le Service Control Policies per avere un maggiore controllo sul nostro ambiente:<\/p>\n\n\n\n

    <\/p>\n\n\n

    \n
    \"aws<\/figure><\/div>\n\n\n

    <\/p>\n\n\n\n

    Il comportamento \u00e8 praticamente lo stesso delle Permission Boundaries, ma vedremo presto che ha una leggera differenza<\/p>\n\n\n\n

    Quindi, per riassumere brevemente:<\/p>\n\n\n\n

      \n
    1. AWS Identity-based policies:<\/strong>\n