E bentornati ora in questo video di cui parleremo, gli attacchi aerei incrociati sono ora
in molte organizzazioni.
Ci sono requisiti che alcuni blog siano centralizzati.
E uno dei servizi in cui i blog sono generalmente centralizzati è un libro di storia.
Quindi supponiamo che ci siano tre secondo account Atabay.
Saranno in una valuta ora, essendo una valuta.
Hai più istanze della tua produzione in esecuzione ora.
Come parte del reclamo, hai l'obbligo che tutti i log che fanno parte dell'U. S. due istanze devono essere
archiviate per i prossimi sette anni.
Quindi dove lo conserverai ora?
Un'opzione è o creerai un libro di storia, può essere archiviato.
I registri in quella cronologia lo registrano di nuovo, creano un certificato in un negozio di valuta, tutti i
registri nell'account e così via.
Ora, questo funzionerà, ma non è realmente scalabile.
Al giorno d'oggi, le organizzazioni hanno centinaia di account e questo approccio per creare un mercato libero in
un account Idalis locale non è l'approccio migliore.
Quindi quello che farai, il migliore è che tu abbia un account centrale, che è l'area dell'account.
Qui crei un tre bucket e tutti i log di tutti gli altri account possono essere archiviati in questo
bucket S3 centrale.
Ora, non che questi log possano includere anche log di altri servizi come cloud trail, cloud watch, log delle
applicazioni, log di sistema e così via.
Ora, in genere, quello che succede nelle imprese è che quando si ha una S. UN. M. soluzioni che rilevano attacchi alla
sicurezza e così via, questi S. UN. M. i sistemi non sono direttamente collegati ai singoli account.
Sono collegati al bucket S3 di un account centrale e da tre bucket diversi tutti
i log richiesti da tutti gli altri account disponibili come parte dell'organizzazione.
Ora, per raggiungere questo obiettivo, devi creare un tre bucket che consenta l'accesso da più
account diversi.
E come farlo è qualcosa di cui parleremo oggi.
Sai, ogni volta che stai progettando l'accesso al bucket dell'account S3, l'approccio consigliato è creare una
policy di bucket.
Quindi quello che accadrà è che stiamo prendendo in considerazione per semplicità.
Quindi hai Al-Ghamdi, che è l'account centrale, e hai l'account B, che ha le due
semplici istanze dell'ambiente di produzione in esecuzione.
Quindi quello che vuoi vuoi che l'account B memorizzi i dati nei tre bucket della contabilità.
Quindi il modo consigliato è creare una nuova policy del bucket e quella policy del bucket, ciò che afferma,
consente all'account B di inviare i log al bucket decentralizzato.
Quindi, una volta che associ questa policy del bucket al bucket centralistico, questo bucket andrà avanti e
consentirà il push dei log, considerando che provengono dall'account B, quindi questa è una panoramica di
altissimo livello.
Ora esaminiamo l'aspetto esatto di questa policy del bucket.
Quindi questo è il semplice screenshot di una policy di bucket.
Ora, se vedrai in questa azione dei criteri del bucket, sono consentite tre azioni.
Devi obiettare, mettere oggetto e mettere oggetto è.
Quindi, in pratica, ciò che vuoi è che l'account invii i dati, per centralizzare il bucket.
Non vuoi nemmeno varie cose come l'operazione di eliminazione.
Altrimenti ciò che accadrà è diciamo che una delle due istanze in azione con un aggressore
compromesso può essenzialmente eliminare tutti i dati dallo stesso bucket.
Quindi, nello specifico, ogni volta che si progetta un account incrociato, una politica a tre bucket,
è molto importante consentire solo azioni minime richieste.
Questo è molto importante.
Va bene.
Quindi l'azione è un grande oggetto, metti l'oggetto e metti gli oggetti qui.
Questo va bene per il momento.
Ora siamo in un principio profondo.
Questa è una parte molto importante.
Stai specificando l'area dell'account B, quindi hai il numero di account seguito dal percorso.
Quindi, in tali casi, qualsiasi utente nell'account B o qualsiasi i. e. coinvolti con l'India possono considerare la giusta politica
che ha detto loro che saranno in grado di eseguire queste tre operazioni sulla risorsa, che è
l'ordine centrale di Strathbogie.
Quindi questa è la politica del secchio di base.
Quindi facciamo una cosa.
Andiamo avanti e proviamo entrambi, che discuteranno le cose in modo più dettagliato.
Così simile all'architettura di cui stavamo discutendo per la demo di oggi, avremo due account.
Hai account e account B ora nel mio browser Chrome, ho una contea, quindi considereremo questa come la
nostra contea.
E ho un altro account, che fa parte del mio browser Firefox, e lo considereremo come
sarà.
Quindi, alla fine del video, dovremmo essere in grado di trasferire i log dall'account B alla cassa toracica centralizzata dell'account
A.
Quindi, per prima cosa, andiamo avanti e creiamo il budget centralistico.
Quindi, all'interno del mio browser Chrome, andiamo avanti e creiamo un nuovo.
Chiamiamolo è il mio trattino centrale di Gabey Labs una volta, quindi andiamo avanti e creiamo un perfetto tre
secchio di Solares.
Ora, se guardi le autorizzazioni qui, torniamo indietro.
Quindi, all'interno della policy del bucket, a partire da ora, vedi che in realtà non hai alcuna policy del bucket.
Ciò significa che gli altri account non saranno in grado di inviare i propri dati alla prenotazione centrale.
Quindi ciò di cui abbiamo bisogno è che qui sia abilitata una policy di bucket.
Quindi facciamo una cosa.
Andiamo avanti e aggiungiamo una policy bucket.
Quindi non importava quanto fosse centrale la policy a tre bucket che abbiamo a disposizione e ne abbiamo già
discusso.
Quindi hai tre azioni e all'interno della risorsa hai il nome dei tre bucket.
Ora, una parte importante di cui stiamo discutendo è che devi aggiungere il tuo numero di account dell'account
che spingerà i blocchi a questo bucket aggiuntivo a cui è associata questa politica.
Quindi dal mio Firefox, lasciami andare avanti e copiare il numero di account di e sarò revisore dei
conti una volta.
Allora copiamo la politica del secchio e lasciami essere sincero con te.
Quindi è così che sembra.
Andiamo avanti e salviamo la modifica.
Perfetto.
Quindi una policy a tre bucket è stata aggiunta correttamente?
Grande.
Quindi la nostra prima parte è completata.
Ora la seconda parte è relativa alla configurazione responsabile.
Ora, per questo esempio, abbiamo utilizzato due istanze, ma può anche essere un Amusa.
Supponiamo che io sia un utente dell'account B che desideri caricare alcuni elenchi di data center critici presso l'utente finale che dovrebbe essere in
grado di farlo.
Quindi, per il video di oggi, andremo avanti e creeremo un nuovo utente AYAM a scopo di test.
Quindi andiamo rapidamente al servizio finale dall'account B e
all'interno.
Andiamo avanti e creiamo un nuovo utente solo per semplicità.
Lo chiameremo solo questo.
Gli utenti forniranno all'utente i permessi di accesso programmatico.
Evitiamo fin d'ora e andremo avanti e creeremo l'utente.
Perfetto.
Ora, solo per semplicità del nostro scopo di test, ho anche una posizione facile con Amazon Linux.
E all'interno di questo facile fare, dal momento che creo un nuovo utente e un nome
utente, le qualità delle lesbiche saranno Orleck e andremo avanti e passeremo l'utente all'account B e all'interno di questo utente
assoceremo l'accesso Kadian Secret Access.
Quindi vediamo configurare i dilettanti.
Aggiungo la chiave di accesso.
Manteniamo una chiave di accesso segreta e il nome della regione.
Usiamo solo la regione predefinita di due dollari e anche il nostro bucket è stato creato quasi perfetto.
Quindi il nostro account è associato alle credenziali stabilite.
In questa fase, quando esegui un estriol dovresti vedere l'accesso di cui hanno bisogno, principalmente perché in
realtà non hai alcuna policy IAM associata a questo account.
Ora la seconda parte importante di questa architettura è che l'entità IBM, forse io sono un utente o Ambro, deve avere anche
un permesso per spingere i dati per centralizzare il rebudget.
Non è che tu abbia consentito la policy del bucket in Rivergate centralizzato e tutte le entità IAM
nell'account.
Saremo in grado di farlo.
La politica deve anche essere associata all'account modificato.
Quindi quello che dobbiamo fare è creare una nuova policy IAM per l'utente IAM che abbiamo creato e che
sarà.
E cosa ci permette di fare questa politica.
Di nuovo, le reazioni prendi oggetto, metti oggetto e metti oggetto è qui e qui stiamo specificando, decentralizzando, lavorando
su di esso.
Quindi spero che tu abbia capito l'importanza della politica dell'acronimo.
Quindi andremo avanti e copieremo questo e il criterio qui e assoceremo questo criterio IAM con l'account
per essere Amusa.
Quindi apriamo l'utente qui.
Aggiungiamo una nuova policy in linea che andrà a Jason.
Ho basato la politica qui.
Facciamo una politica di revisione e il nome dell'account incrociato della scala mobile di Liz è tre andrà avanti e creerà una
politica.
Perfetto.
Quindi ora tutta la configurazione necessaria per account e achonwa è stata completata.
Quindi testiamo le cose.
Quindi, per prima cosa, caricherò alcuni dati di esempio nel bucket degli attributi della contabilità.
Quindi questo è qualcosa che possiamo fare direttamente dalla console stessa.
Facciamolo.
definisco il file .
Puoi semplicemente aggiungere qualsiasi file temporaneo che hai nel tuo sistema.
Perfetto.
Quindi il file viene aggiunto nel bucket centrale.
Ora, poiché all'interno della policy del bucket abbiamo consentito l'oggetto gate, ciò significa sostanzialmente
l'immensità dell'account.
Dovremmo essere in grado di recuperare i dati dalla cronologia.
Quindi dall'account proviamolo.
Dirò che il posto è tre.
Prova a copiare i dati, che è quello di pagare per DataDot, e il budget sarà probabilmente meno centrale e sarà
il contenuto qui.
E vedi che l'operazione di download funziona perfettamente.
Quindi, se faccio una piccola area, dobbiamo pagare per DataDot.
Queste cose funzionano come previsto.
Allo stesso modo, proviamo anche a caricare alcuni dati da te.
Quindi creiamo un nuovo file, lo chiamerò come testo punto dell'account B e proviamo a copiare questo file
come tre account B rigoroso, e vogliamo collegarlo al centro del trattino sinistro.
E vedi che anche il caricamento funziona perfettamente.
Quindi ora se aggiorno la pagina qui, dovresti vedere che hai contabilizzato e anche il punto è disponibile.
Grande.
Quindi spero che con questo tu abbia capito a una panoramica di alto livello sul flusso di lavoro alla base del successo dei contenuti
di Corozal.
Ma in questa fase non abbiamo ancora finito.
Questa è una parte molto importante che deve essere esaminata.
Ne parleremo in dettaglio nel prossimo video.
Ma ti darò solo un'idea del problema che dovrai affrontare in questa architettura.
Ora, quello che è successo è che entrambi questi file fanno parte di questo bucket, ma le
autorizzazioni associate a entrambi questi file sono completamente diverse.
Esaminiamolo rapidamente ora per l'account.
Sii sporco ogni volta che vado avanti e provo a scaricare questo file.
Vedete, ricevo il messaggio di accesso negato.
Molto interessanti in modo simile i file che sono stati caricati dall'account stesso.
Quando provo a scaricare quel file, proviamo a farlo.
Vedete, il download del file funziona perfettamente.
Quindi il motivo principale per cui questo non funziona è che questo account di file finanziato o B è associato
all'account B e il file successivo da pagare per DataDot è associato all'account A ora, anche se ho un
accesso amministrativo nell'account E, questo non significa che ho permessi o file che sono
stati caricati dall'account per essere così ne parlerò in dettaglio.
Ma è molto importante sapere che se lo stai implementando in un ambiente di produzione, ho riscontrato
questo problema in cui ci sono più team che collaborano in un bucket S3 centrale e l'altro team sta
caricando tutti i propri dati in centinaia di gigabyte.
E in seguito si rendono conto che tutti i dati che sono stati caricati nel bucket S3 centrale, nessuno degli utenti della nostra
contea è stato in grado di accedervi.
Quindi questo è stato un po 'doloroso e discuterà sul perché questo accade e sul modo migliore per risolverlo.
Quindi con questo concluderò il video di oggi.