Ciao a tutti e bentornati.
Nel video di oggi parleremo delle strategie di utilizzo dei criteri di controllo dei servizi.
In una panoramica di alto livello, ci sono due strategie principali che si possono utilizzare per configurare i passaggi
all'interno del conto.
Una è la strategia basata sull'elenco dei rifiuti e l'altra è la strategia basata sull'elenco dei permessi.
Nel video di oggi, quindi, parleremo di entrambi in modo molto dettagliato.
Ora, il primo approccio primario è l'elenco di negazione e nell'elenco di negazione le azioni sono consentite per impostazione predefinita
a livello di IP.
E poi si specifica quali sono i servizi e le azioni che si vogliono negare.
Quando si parla di organizzazioni e di politiche di controllo dei servizi, per impostazione
predefinita, si fa uso di questa strategia basata su liste di rifiuto e ciò si ottiene utilizzando la politica CB di accesso completo che è collegata
alla radice.
Ora, se diamo una rapida occhiata all'aspetto di questo criterio di accesso completo, questa è la dichiarazione del criterio in cui tutto
è consentito per impostazione predefinita.
Ora, si noti che questo potrebbe essere un po' confuso perché la strategia della negazione è in realtà consentita.
All'inizio, quindi, la situazione è un po' confusa.
Ora, analizziamo rapidamente anche questo aspetto.
Attualmente mi trovo in un'organizzazione che non ha l'IPS abilitato.
Quindi, se si guarda a uno dei conti qui, se si guarda alle polizze, non ci sono
polizze associate in questa fase.
Ogni volta che si attivano i criteri di controllo del servizio, in questa fase si nota che viene creato un
criterio primario, ovvero l'accesso completo.
Il tipo è una polizza gestita.
E se si guarda a questo, gli obiettivi dei criteri sono associati alla radice e a tutti gli account che fanno
parte di questo approccio di base.
Se si esamina la dichiarazione politica generale, si può dire che si permette tutto.
Quindi, per impostazione predefinita, tutto sarà consentito a livello di SP e poi si negherà esplicitamente qualsiasi servizio che si desidera
proibire.
Ad esempio, se non si vuole che nessuno si connetta al servizio, si aggiunge esplicitamente un'istruzione deny.
Poiché si tratta di un criterio gestito, ci sono alcune restrizioni, quindi si può procedere alla creazione
di un nuovo set di criteri.
Non sarà possibile eseguire varie operazioni.
Ad esempio, se si vuole cancellare, proviamo a fare un accesso completo.
E nella descrizione si legge che non è possibile modificare e gestire i criteri.
Sono grandi solo in lettura.
Ora, dopo aver capito questo concetto di base, analizziamo alcuni dei vantaggi che questo tipo di strategia offre.
Come già sappiamo, utilizzando la strategia di negazione, l'amministratore dell'account può delegare tutti i servizi
e le azioni fino a quando non si crea un allegato CFP che nega un servizio specifico.
Quindi, per impostazione predefinita, tutto sarà consentito.
Quindi si aggiunge il criterio di negazione esplicita per negare un servizio o un'azione specifica.
È necessario notare che le dichiarazioni di negazione richiedono meno manutenzione, perché non è necessario
aggiornare il criterio quando si aggiungono nuovi servizi.
Se un'azienda dispone di centinaia di servizi, dal momento che ha autorizzato esplicitamente tutti i servizi a livello ACP,
non c'è bisogno di preoccuparsi perché anche se viene lanciato un nuovo servizio, gli utenti potranno
accedervi.
Considerando che hanno le autorizzazioni appropriate.
Oltre a questo, un altro vantaggio è che le istruzioni di negazione di solito utilizzano meno spazio, facilitando così
il rispetto delle dimensioni massime delle politiche di controllo dei servizi.
Ora, se si esamina un esempio di criterio basato sull'elenco di negazione, potrebbe avere un aspetto simile a
questo, in cui si ha un'affermazione ad alta voce e poi un'affermazione di negazione esplicita sull'azione e sul servizio.
Quindi qui l'azione è Dynamo DB star con questa strategia di base, esaminiamo anche la strategia numero
due, che è allow list.
Ora, per utilizzare l'elenco di permessi, è necessario sostituire l'ACP ad accesso completo gestito con
un nuovo ACP che permetta esplicitamente solo i servizi e le azioni che si desidera consentire.
Ora è necessario ricordare che rimuovendo l'accesso completo predefinito ACP, tutte le azioni per tutti
i servizi sono ora implicitamente negate.
Questa è una parte molto importante da ricordare.
Quindi, poiché tutte le azioni e i servizi sono implicitamente negati, si aggiunge un ACP personalizzato che sovrascrive questo
rifiuto implicito con un permesso esplicito solo per le azioni che si desidera consentire.
Quindi, se si esamina questo esempio di politica basata sugli elenchi di permessi, ecco come si presenta.
Si presume quindi che questo ACP ad accesso completo non sia associato agli account.
E poi si aggiunge questo criterio specifico che consente alcuni servizi come EC two star cloud watch star.
Quindi, a parte questo insieme di servizi, gli utenti non potranno eseguire operazioni su nessuno di essi.
Ora, prima di procedere oltre, vediamo anche una rapida dimostrazione associata a questo.
Ora, permettetemi di mostrarvi rapidamente una dimostrazione.
A questo punto, si noti che stiamo solo esaminando la questione dal punto di vista dimostrativo per assicurarci che i nostri concetti
siano compresi meglio.
Per la dimostrazione di oggi ho un'altra politica per l'elenco dei permessi del college.
Quindi, se si esamina il criterio dell'elenco dei permessi, questo è associato alla root e anche
a un account sandbox.
A questo punto, affinché il criterio dell'elenco dei permessi entri in vigore, è necessario assicurarsi che il proprio accesso
completo non sia associato agli account.
Quindi, se si guarda agli obiettivi, è solo associato all'account di gestione.
Non è associato ad altri conti.
Quindi se devo mostrarvelo.
Quindi in root abbiamo l'account di gestione e l'account sandbox.
Quindi questo criterio specifico che abbiamo, il criterio dell'elenco dei permessi, è associato se si guarda all'account
sandbox e non c'è un criterio di accesso completo qui.
Quindi andiamo avanti e proviamo rapidamente.
Per questo motivo, se si esamina il contenuto, ora è possibile testare EC due stelle e cloud watch star.
Ho effettuato l'accesso come utente root a uno degli account membri.
Ora, dal momento che conosciamo solo EC due e Cloud Watcher, proviamo a esplorare immediatamente
altri servizi come SES.
Abbiamo ricevuto un errore che indica che c'è un errore nell'ACP.
Proviamo anche un altro servizio.
Ripeto, il gateway API riceve un errore.
Allo stesso modo, proviamo e c a questa volta e ec due funziona perfettamente.
Sarà possibile lanciare istanze, ecc.
Va bene.
Spero quindi che abbiate compreso le basi degli elenchi di permessi e degli elenchi di negazione.
Di nuovo, una cosa che volevo mostrarvi, guardiamo rapidamente qui.
Se si esaminano i criteri dell'account sandbox, si tratta solo dei criteri dell'elenco dei permessi.
Qui non esiste una politica di accesso totale.
E questo è il motivo per cui le cose stanno prendendo piede.
Ora, prima di concludere, è necessario prendere nota di alcune importanti indicazioni.
Il primo è che ogni account root o tu e deve avere almeno un criterio di controllo del servizio collegato.
Per questo motivo, se si desidera sostituire il criterio di accesso completo predefinito con un ACP che limiti i permessi,
è necessario collegare l'SFP sostitutivo prima di rimuovere quello predefinito.
Ad esempio, in questa fase si noterà che l'account sandbox ha un criterio di elenco dei permessi.
Quindi, in quel momento, è necessario allegare una polizza.
Quindi, se si vuole passare da un elenco a un elenco di negazione, è necessario associare un criterio di elenco
di negazione e poi rimuovere l'elenco di autorizzazione.
Ottimo.
Questa è la panoramica di alto livello sulle strategie che potete utilizzare.
Ancora una volta, da quello che ho visto nelle organizzazioni, la maggior parte di esse utilizza la strategia predefinita basata sulle liste
di rifiuto.
Non optano per la allow list nel caso in cui si utilizzi una lista bassa, anche se questa sembra
buona, ma richiede anche molti sforzi.
Nella maggior parte delle organizzazioni, il team di sicurezza o il team che gestisce tutti gli ssp sono
piuttosto piccoli e non hanno il tempo e le risorse necessarie per gestire i criteri degli elenchi di permessi,
oltre alle altre configurazioni relative alla sicurezza su cui devono lavorare come parte dell'infrastruttura
complessiva.
Con questo si conclude il video di oggi.