In questo articolo analizzeremo e dettaglieremo gli aspetti su cui costruire una Landing Zone e i servizi AWS da sfruttare.<\/p>\n\n\n\n
Di seguito verranno presi in considerazione gli aspetti che compongono la Landing Zone.<\/p>\n\n\n\n
Organization<\/h2>\n\n\n\n
Il primo argomento che va preso in considerazione riguarda \u00e8 la struttura degli account – ovvero l\u2019Organization – che, come specificato dalla Legge di Conway<\/a>, deve rispecchiare la struttura organizzativa dell\u2019azienda. Questo significa che diversi team hanno le loro responsabilit\u00e0 e le loro esigenze di risorse diverse.<\/p>\n\n\n\n Qui entra in gioco il servizio AWS Organizations<\/strong> che ci permette di organizzare gli account per scope<\/em>, di creare Organizational Units<\/em> (OU), semplificare l\u2019allocazione dei costi e di automatizzare la creazione di nuovi Accounts. Un account \u00e8 l’unico modo vero per separare i costi a livello di fatturazione. Pi\u00f9 account aiutano a separare i volumi generati a livello di fatturazione tra business unit, team funzionali o singoli utenti.<\/p>\n\n\n\n La strategia multi-account porta al massimo livello di isolamento delle risorse e della sicurezza. L\u2019isolamento, a seconda dei casi, deve avvenire anche a livello dati. Il primo passo sul percorso che ci porta ad una corretta configurazione, prevede di creare due macro gruppi di account: quelli Foundational<\/strong> e quelli dedicati a Products and Workloads<\/strong>. <\/p>\n\n\n\n I Foundational<\/strong> account sono, appunto, dedicati ai team di struttura, atti a soddisfare le esigenze dell\u2019azienda stessa. <\/p>\n\n\n\n Per i Product and Workloads<\/strong> \u00e8 conveniente creare delle OU per prodotti dove gli account vengono divisi secondo gli ambienti di sviluppo (da Dev a Produzione), ma anche OU dedicate ad ospitare gli ambienti dedicati a gruppi di workload come quelli di struttura. Business unit o prodotti diversi potrebbero avere scopi e processi diversi. <\/p>\n\n\n\n Da non sottovalutare \u00e8 anche la presenza delle quote predefinite dei servizi negli account AWS. La separazione dei carichi di lavoro in account diversi impedisce loro di consumare limiti, snellendo i processi aziendali.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Il principio dei privilegi minimi \u00e8 il mantra di chi deve gestire gli accessi e i permessi ad infrastrutture o a parti di esse. Rispettare questo principio significa ridurre il blast-radius<\/em> nel caso di sottrazione maliziosa dei diritti di accesso all\u2019ambiente Cloud. <\/p>\n\n\n\n Questo principio non deve portarci ad una complicazione nella gestione, sottintendendo, quindi, la necessit\u00e0 di una gestione centralizzata delle credenziali. <\/p>\n\n\n\n Nello scenario AWS \u00e8 possibile creare risorse sia mediante la console web che tramite l\u2019utilizzo delle API REST Autenticate. La possibilit\u00e0, quindi, di poter automatizzare le nostre azioni tramite l\u2019utilizzo di queste API ci sottolinea ancora di pi\u00f9 quanto sia attuale la gestione delle credenziali di accesso. <\/p>\n\n\n\n Vanno sicuramente implementate pratiche come quella della Multi-Factor Authentication<\/strong>, della rotazione automatica<\/strong> delle credenziali, di password policy<\/strong> forte e di autorizzazione ristretta. <\/p>\n\n\n\n Per autenticazione<\/strong> e autorizzazione<\/strong> AWS ci offre diverse possibilit\u00e0: dall\u2019utilizzo di AWS IAM<\/strong> alla possibilit\u00e0 di integrare l\u2019Identity Provider (IdP)<\/strong> aziendale con AWS SSO<\/strong>. Questi servizi permettono sia una gestione centralizzata degli accessi sia di applicare tutte le pratiche di sicurezza descritte in precedenza. <\/p>\n\n\n\n Per l\u2019accesso in console si pu\u00f2 creare una landing page che ci permetta di discriminare le nostre credenziali e, magari, avere un client che ci aiuti a gestire i nostri accessi \u201cprogrammatici\u201d di tutti i giorni. Complementariamente ai servizi di gestione centralizzata di autorizzazione e autenticazione, per aiutare i nostri utenti ad essere efficienti ed efficaci in questi passaggi quotidiani, ci viene in soccorso Leapp<\/a><\/strong>, un tool open-source per gestire in modo sicuro e automatizzato le credenziali di accesso agli ambienti Cloud.<\/p>\n\n\n\n Fondamentale \u00e8 la raggiungibilit\u00e0 dell\u2019ambiente Cloud. Dalle connessioni degli utenti aziendali o dei collaboratori, alle connessioni dei nostri utenti esterni, come ad esempio integratori o utenti pubblici. <\/p>\n\n\n\n Prima di tutto bisogna strutturare la ripartizione del networking privato definendo i CIDR<\/strong> da assegnare alle varie reti virtuali presenti nei vari account definiti nella sezione Organizations<\/em>. Qui \u00e8 importante evitare l\u2019overlapping<\/strong> per non incorrere in scenari complicati a livello implementativo e gestionale. Centralizzare i propri endpoint e il controllo delle loro rotte \u00e8 importante per facilitare la gestione delle connessioni e la loro creazione. <\/p>\n\n\n\n Le nostre reti virtuali vengono definite tramite il servizio AWS VPC <\/strong>che vanno configurate a dovere tenendo conto dell\u2019infrastruttura fisica del provider e dei requisiti di disponibilit\u00e0 delle infrastrutture. La connettivit\u00e0 verso il pubblico \u00e8 fornita tramite l\u2019Internet Gateway<\/strong> gestito e tramite l\u2019implementazione di AWS Managed<\/strong> NAT Gateway<\/strong>. <\/p>\n\n\n\n Su AWS troviamo anche AWS Transit Gateway<\/strong> che ci permette di gestire centralmente e connetterci sia fisicamente, tramite Direct Connect<\/strong>, sia in maniera virtuale, tramite AWS SiteToSite Managed VPN<\/strong>. A questo concentratore possiamo collegare il nostro ufficio, i nostri data center e tutte le connessioni con i nostri partners, clienti e integratori. Transit Gateway ci viene in soccorso anche per le comunicazioni inter-vpc. <\/p>\n\n\n\n Da non trascurare sono anche gli accessi alle nostre reti virtuali da parte dei nostri utenti privati sparsi in giro per il mondo. In questi casi va tenuta in considerazione l\u2019implementazione di una VPN Dial Up<\/strong> tramite AWS<\/strong> Client VPN<\/strong> che si integra con Transit Gateway. <\/p>\n\n\n\n Sotto il cappello del networking vanno considerati anche i DNS e la gestione dei domini. AWS Route 53<\/strong> e le sue peculiarit\u00e0 come il DNS Resolver vanno sfruttate sia per gestire i domini privati che pubblici oltre che determinare da che reti sia possibile risolvere i record.<\/p>\n\n\n\n La security \u00e8 un processo che implica pratiche che toccano in maniera basilare tutti gli aspetti dell\u2019IT. Anche la terminologia si aggiorna e la pratica DevOps si trasforma in DevSecOps<\/strong>. Nel mondo delle buzzword serve a sottolineare l\u2019importanza della security che va applicata su tutti i livelli. <\/p>\n\n\n\n Tra i canoni fondamentali su cui costruire la nostra Landing Zone spiccano in particolare la tracciabilit\u00e0<\/strong>, la protezione dei dati in transito e a riposo<\/strong>, l\u2019implementazione di solide fondamenta sulle identit\u00e0<\/strong> e l\u2019isolamento<\/strong>. Per quanto riguarda questi ultimi due argomenti, una corretta progettazione dell\u2019organizzazione e una gestione centralizzata degli utenti ci facilitano nel far rispettare le best-practises in questo campo.<\/p>\n\n\n\n Come detto in precedenza, il Cloud AWS \u00e8 costituito da API autenticate (sfruttate dalla console stessa). Ogni chiamata a queste API viene tracciata tramite il servizio AWS CloudTrail<\/strong> che pu\u00f2 consolidare in un unico punto tutti i log. <\/p>\n\n\n\n Anche il traffico proveniente da internet pu\u00f2 essere regolato tramite una gestione centralizzata delle regole di AWS WAF<\/strong>, il firewall web gestito del provider.<\/p>\n\n\n\n Security groups e Network ACL servono, invece, per controllare pi\u00f9 puntualmente protocolli di comunicazione e specifiche connessioni tra reti. Con questi strumenti determiniamo quali comunicazioni, tra gli utenti interni e i workload aziendali, sono lecite. <\/p>\n\n\n\n Ci\u00f2 non prescinde dal dover criptare tutte le nostre comunicazioni web pubbliche. Una gestione centralizzata dei certificati SSL collegati ai nostri domini pu\u00f2 facilitare il controllo e la distribuzione.<\/p>\n\n\n\n Mentre la Governance<\/strong> identifica chi ha potere e responsabilit\u00e0 e chi prende le decisioni, la Compliance<\/strong> \u00e8 la conformit\u00e0 delle attivit\u00e0 aziendali alle disposizioni normative, ai regolamenti, alle procedure ed ai codici di condotta.<\/p>\n\n\n\n Ogni azienda ha le proprie policy, i propri processi e deve poter implementare i propri controlli anche in ambiente Cloud. L\u2019implementazione delle regole deve comunque permettere spazi di azione per i team, definendo quali guardrails in cui operare. <\/p>\n\n\n\n Abbiamo gi\u00e0 parlato di quanto sia importante implementare la sicurezza nelle nostre pratiche. I dati, come gi\u00e0 detto, non si devono esimere e devono venire criptati at-rest<\/em>. Bisogna assicurarsi che, nel tempo, ogni workload rispetti questo canone. Anche evitare che vengano aggiunte regole di firewall che espongono la nostra infrastruttura a rischi \u00e8 un altro canone fondamentale da far rispettare. Uno dei casi pi\u00f9 classici prevede l\u2019esposizione al pubblico di protocolli con vulnerabilit\u00e0 note. <\/p>\n\n\n\n L\u2019automatizzazione dell\u2019applicazione di queste regole e le rimediazioni automatiche si gestiscono centralmente affidandosi al servizio AWS Config<\/strong>.<\/p>\n\n\n\n AWS offre una vasta gamma di servizi adatti a scopi molto differenti. Non tutte le aziende hanno bisogno di sfruttare ogni servizio. Stessa cosa vale anche per le region globali su cui si possono mettere in opera i workload. Al fine di evitare che questi servizi e region vengano utilizzati vanno implementati dei guardrails tramite le Service Control Policies<\/strong>. <\/p>\n\n\n\n I controlli prevedono anche di implementare una classificazione delle risorse presenti in ambiente AWS. Una corretta strategia di tagging ci porta ad avere un\u2019efficiente ripartizione dei costi e la possibilit\u00e0 di gestire i permessi su base ABAC<\/strong> (Attribute-based Access Control). A supporto di questa tematica esistono le Tag Policies<\/strong> che ci permettono di gestire centralmente i nostri Tag e di imporre che vengano utilizzati su tutte le risorse create. <\/p>\n\n\n\n Fin da subito vanno anche decise tutte le pratiche di deprovisioning delle risorse inutilizzate per non trovarsi in una situazione confusionaria in cui sia difficile attribuire e capire i propri costi.<\/p>\n\n\n\n Le organizzazioni necessitano di un modo semplice e immediato per accedere alle informazioni di fatturazione<\/strong> di AWS, incluso un riepilogo delle spese<\/strong>, una ripartizione di tutti i costi<\/strong> di servizio sostenuti dagli account all’interno dell’organizzazione, insieme a sconti <\/strong>e crediti<\/strong>. <\/p>\n\n\n\n Fondamentale \u00e8 la consolidazione delle fatture (consolidated billing) e predisporre protezioni adeguate in modo da poter mantenere il controllo su costi, governance e sicurezza. AWS consente alle organizzazioni di bilanciare la libert\u00e0 e il controllo consentendo la governance delle autorizzazioni granulari dell’utente.<\/p>\n\n\n\n Per prendere decisioni consapevoli \u00e8 necessaria una visibilit\u00e0 completa, quasi in tempo reale, dei costi e delle informazioni sull’utilizzo. AWS fornisce strumenti per organizzare le risorse in base alle esigenze, visualizzare e analizzare i dati di costi e di utilizzo in un unico riquadro. Oltre che controllare centralmente i costi, \u00e8 possibile fornire in tempo reale informazioni sui costi, utili ai team di progettazione, applicazione e business. I dati dettagliati e allocabili sui costi consentono ai team di avere visibilit\u00e0 e informazioni per rendere conto della propria spesa.<\/p>\n\n\n\n AWS Cost Explorer<\/strong> presenta un’interfaccia di facile utilizzo che permette di visualizzare, analizzare e gestire i costi e l’utilizzo di AWS nel tempo. AWS<\/strong> Budget<\/strong> consente di impostare budget personalizzati per tenere traccia dei costi e dell’utilizzo dai casi d’uso pi\u00f9 semplici a quelli pi\u00f9 complessi.<\/p>\n\n\n\n \u201cEverything fails all the time\u201d<\/em> – Werner Vogel. <\/p>\n\n\n\n Tutto fallisce continuamente. Progettare con l\u2019idea di fallimento in testa \u00e8 fondamentale per costruire infrastrutture resilienti. Per questo motivo il Disaster Recovery<\/strong> \u00e8 una strategia che va messa in campo gi\u00e0 dalla progettazione della nostra Landing Zone. <\/p>\n\n\n\n Le tipologie di disastro che si possono verificare in cloud, e in generale, vengono divise in tre macro-categorie:<\/p>\n\n\n\n AWS non garantisce la resilienza delle nostre infrastrutture, ma ci fornisce tutti gli strumenti che dobbiamo sfruttare per poterle rendere resistenti ai fallimenti. Tutto questo \u00e8 definito nello Shared Responsibility Model<\/a><\/strong> di AWS.<\/p>\n\n\n\n In questo contesto va prevista una strategia multi-region e multi-account, separando anche l\u2019organization principale da quella preposta al Disaster Recovery. Anche gli accessi alle due strutture vanno separati e assegnati a personale differente. <\/p>\n\n\n\n Le strategie di Disaster Recovery disponibili sono categorizzabili in vari approcci, che vanno da costi bassi e complessit\u00e0 bassa per il backup&restore a strategie pi\u00f9 costose e complesse di tipo active-active. <\/p>\n\n\n\n
L’isolamento dei data store su un account limita il numero di persone che possono accedere e gestire quel data store aiutando a rispettare il Regolamento generale sulla protezione dei dati (GDPR).<\/p>\n\n\n\n![\"Landing](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2022\/07\/Landing-Zone-organization-1024x705.png\")
<\/figure><\/div>\n\n\nIdentity and Access Management<\/h2>\n\n\n\n
Networking<\/h2>\n\n\n\n
Security <\/h2>\n\n\n\n
Governance e Compliance<\/h2>\n\n\n\n
Controllo dei costi<\/h2>\n\n\n\n
Disaster Recovery<\/h2>\n\n\n\n
\n