Crea politiche di approvazione per i tuoi nodi - AWS Systems Manager

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à.

Crea politiche di approvazione per i tuoi nodi

Le politiche di approvazione definiscono le approvazioni di cui gli utenti hanno bisogno per accedere a un nodo. Poiché l'accesso ai just-in-time nodi elimina la necessità di autorizzazioni di lunga data ai nodi tramite le policy IAM, è necessario creare politiche di approvazione per consentire l'accesso ai nodi. Se non esistono politiche di approvazione applicabili a un nodo, gli utenti non possono richiedere l'accesso al nodo.

Nell'accesso al just-in-time nodo, esistono tre tipi di politiche. I tipi di policy sono approvazione automatica, negazione dell'accesso e approvazione manuale.

Just-in-time tipi di policy di accesso ai nodi

  • Una politica di approvazione automatica definisce a quali nodi gli utenti possono connettersi automaticamente.

  • Le politiche di approvazione manuale definiscono il numero e i livelli di approvazioni manuali da fornire per accedere ai nodi specificati.

  • Una politica di negazione dell'accesso impedisce esplicitamente l'approvazione automatica delle richieste di accesso ai nodi specificati.

Una politica di negazione dell'accesso si applica a tutti gli account di un'organizzazione. AWS Organizations Ad esempio, puoi negare esplicitamente le approvazioni automatiche per il Intern gruppo ai nodi contrassegnati con la chiave. Production Le politiche di approvazione automatica e manuale si applicano solo al luogo in cui vengono create Account AWS . Regioni AWS Ogni account membro della tua organizzazione gestisce le proprie politiche di approvazione. Le politiche di approvazione vengono valutate nel seguente ordine:

  1. Negare l'accesso

  2. Approvazione automatica

  3. Manuale

Sebbene tu possa avere solo una politica di negazione dell'accesso per organizzazione e una politica di approvazione automatica per account e regione, probabilmente avrai diverse politiche di approvazione manuale in un account. Quando si valutano le politiche di approvazione manuale, l'accesso ai just-in-time nodi predilige sempre la politica più specifica per un nodo. Le politiche di approvazione manuale vengono valutate nel seguente ordine:

  1. Target specifico per il tag

  2. Obiettivo di tutti i nodi

Ad esempio, hai un nodo etichettato con la Demo chiave. Nello stesso account, hai una politica di approvazione manuale che si rivolge a tutti i nodi e richiede un'approvazione per un livello. Hai anche una politica di approvazione manuale che richiede due approvazioni da due livelli per i nodi contrassegnati con la Demo chiave. Systems Manager applica la policy che ha come target il Demo tag al nodo poiché è più specifica della policy che si rivolge a tutti i nodi. Ciò consente di creare una politica generale per tutti i nodi dell'account, garantendo agli utenti la possibilità di inviare richieste di accesso e consentendoti di creare politiche più granulari in base alle esigenze.

A seconda dell'organizzazione, potrebbero essere applicati più tag ai nodi. In questo scenario, se a un nodo si applicano più politiche di approvazione manuale, le richieste di accesso hanno esito negativo. Ad esempio, un nodo viene contrassegnato con le Database chiavi Production and. Nello stesso account, hai una politica di approvazione manuale che si applica ai nodi contrassegnati con la Production chiave e un'altra politica di approvazione manuale che si applica ai nodi contrassegnati con la Database chiave. Ciò si traduce in un conflitto per il nodo etichettato con entrambe le chiavi e le richieste di accesso hanno esito negativo. Systems Manager reindirizza l'utente alla richiesta non riuscita. Qui possono visualizzare i dettagli sulle politiche e sui tag in conflitto in modo da apportare le modifiche necessarie se dispongono delle autorizzazioni richieste. In caso contrario, possono notificare a un collega della propria organizzazione le autorizzazioni necessarie per modificare le politiche. I conflitti di policy che portano a richieste di accesso non riuscite generano EventBridge eventi che consentono la flessibilità necessaria per creare flussi di lavoro di risposta personalizzati. Inoltre, Systems Manager invia notifiche e-mail per i conflitti di policy che comportano richieste di accesso non riuscite ai destinatari specificati. Per ulteriori informazioni sulla configurazione delle notifiche e-mail per i conflitti di policy, vedere. Configurare le notifiche per le richieste di just-in-time accesso

In una politica di negazione dell'accesso, si utilizza il linguaggio di policy Cedar per definire a quali nodi gli utenti non possono connettersi automaticamente in modo esplicito all'interno dell'organizzazione. Questa politica viene creata e condivisa dall'account amministratore delegato dell'organizzazione. La politica di negazione dell'accesso sostituisce tutte le politiche di approvazione automatica. È possibile avere una sola politica di negazione dell'accesso per organizzazione.

In una politica di approvazione automatica, si utilizza il linguaggio delle policy Cedar per definire quali utenti possono connettersi automaticamente ai nodi specificati senza approvazione manuale. La durata di accesso per una richiesta di accesso approvata automaticamente è di 1 ora. Questo valore non può essere modificato. Puoi avere solo una politica di approvazione automatica per account e regione.

In una politica di approvazione manuale, specifichi la durata dell'accesso, quanti livelli di approvazione sono richiesti, il numero di approvatori richiesti per livello e i nodi a cui possono approvare just-in-time le richieste di accesso. La durata dell'accesso per una politica di approvazione manuale deve essere compresa tra 1 e 336 ore. Se si specificano più livelli di approvazione, le approvazioni per la richiesta di accesso vengono elaborate un livello alla volta. Ciò significa che tutte le approvazioni necessarie per un livello devono essere fornite prima che il processo di approvazione passi ai livelli successivi. Se si specificano più tag in una politica di approvazione manuale, questi vengono valutati come or dichiarazioni e non and come dichiarazioni. Ad esempio, se si crea un criterio di approvazione manuale che include i tag e Application WebTest, il criterio si applica a qualsiasi nodo contrassegnato con una di queste chiavi. La policy non si applica solo ai nodi etichettati con tutte e tre le chiavi.

Ti consigliamo di utilizzare una combinazione di policy manuali con la tua policy di approvazione automatica per aiutarti a proteggere i nodi con dati più critici, permettendo al contempo agli utenti di connettersi a nodi meno critici senza alcun intervento. Ad esempio, puoi richiedere approvazioni manuali per le richieste di accesso ai nodi del database e approvare automaticamente le sessioni per i nodi di livello di presentazione non persistenti.

Le procedure seguenti descrivono come creare politiche di approvazione per l'accesso ai nodi. just-in-time

Argomenti