Crea policy di approvazione per i tuoi nodi

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

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

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

Sebbene tu possa avere solo una policy di negazione dell'accesso per organizzazione e una di approvazione automatica per account e Regione, probabilmente avrai numerose policy di approvazione manuale in un account. Durante la valutazione delle policy di approvazione manuale, l'accesso ai nodi just-in-time favorisce sempre la policy più specifica per un nodo. Le policy di approvazione manuale sono valutate nell'ordine seguente:

Ad esempio, hai un nodo etichettato con la chiave Demo. Nello stesso account, hai una policy di approvazione manuale che si rivolge a tutti i nodi e richiede un'approvazione da un livello. Hai anche una policy di approvazione manuale che richiede due approvazioni da due livelli per i nodi contrassegnati con la chiave Demo. Systems Manager applica la policy che ha come destinazione il tag Demo al nodo, poiché è più specifica di quella che è destinata a tutti i nodi. Ciò ti consente di creare una policy generale per tutti i nodi del tuo account, garantendo agli utenti la possibilità di inviare richieste di accesso, consentendoti di creare policy 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ù policy di approvazione manuale, le richieste di accesso hanno esito negativo. Ad esempio, un nodo viene contrassegnato con il Database e le chiavi Production. Nello stesso account, hai una policy di approvazione manuale che si applica ai nodi contrassegnati con la chiave Production e un'altra policy di approvazione manuale che si applica ai nodi contrassegnati con la chiave Database. 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 è possibile visualizzare i dettagli sulle policy e sui tag in conflitto, in modo che sia possibile apportare le modifiche necessarie, se si hanno le autorizzazioni richieste. In caso contrario, è possibile notificare a un collega della propria organizzazione le autorizzazioni necessarie per modificare le policy. 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 via e-mail per i conflitti di policy che comportano richieste di accesso non riuscite ai destinatari specificati. Per ulteriori informazioni sulla configurazione delle notifiche via e-mail per i conflitti delle policy, consulta Configura le notifiche per le richieste di accesso just-in-time.

In una policy di negazione dell'accesso, utilizzi il linguaggio delle policy Cedar per definire a quali nodi gli utenti non possono connettersi automaticamente nella tua organizzazione. Questa politica viene creata e condivisa dall'account amministratore delegato dell'organizzazione. La policy di negazione dell'accesso sostituisce tutte le politiche di approvazione automatica. È possibile avere una sola policy 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 un'ora. Questo valore non può essere modificato. Puoi avere una sola policy di approvazione automatica per account e regione.

In una policy di approvazione manuale, si specifica la durata dell'accesso, il numero di livelli di approvazione richiesti, il numero di approvatori richiesti per livello e i nodi a cui questi possono approvare le richieste di accesso just-in-time. La durata dell'accesso per una policy di approvazione manuale deve essere compresa tra 1 e 336 ore. Se si specificano più livelli di approvazione, le approvazioni per il processo della 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 policy di approvazione manuale, questi vengono valutati come istruzioni or e non come istruzioni and. Ad esempio, se si crea una policy di approvazione manuale che include i tag Application, Web e Test, la policy 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 proteggere i nodi con dati più critici, consentendo al contempo agli utenti di connettersi ai 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 policy di approvazione per l'accesso ai nodi just-in-time.