Nel mio ruolo in DoiT lavoro ogni giorno con startup che muovono i primi passi nel cloud.
E continuo a vedere gli stessi errori, ripetuti all'infinito.
Ne condivido qui alcuni, nella speranza che possiate evitarli prima che diventino costosi, dolorosi o difficili da risolvere:
1\. L'account AWS viene aperto con l'email personale di un founder
Molto spesso il primo account AWS viene creato usando l'indirizzo Gmail privato di un founder.
In questa situazione, l'account appartiene legalmente e operativamente a una persona, non all'azienda.
Se il founder lascia l'azienda, sorge un conflitto o (nel peggiore dei casi) gli accade qualcosa, la titolarità dell'account si trasforma in un serio rischio per il business.
Inoltre, un'email personale è di norma meno sicura di una casella aziendale: niente MFA obbligatoria, nessun audit centralizzato, una governance dell'identità più debole e un grosso ostacolo nel momento in cui si affronta un audit per una certificazione.
La compromissione dell'email del founder si traduce spesso nel controllo totale dell'ambiente AWS aziendale.
Si crea così anche un single point of failure.
Best practice:
Create una casella di gruppo condivisa, ad esempio: [email protected]
Aggiungete almeno due membri del team (c'è sempre qualcuno malato, in ferie o a una conferenza) e usate il plus-addressing per separare gli ambienti nei diversi account AWS:
2\. Creare risorse nel Management Account
Una startup parte con un singolo account AWS che ospita tutto: produzione, sviluppo, demo e il playground degli sviluppatori.
Con la crescita dell'azienda, diventa necessario separare gli ambienti. La via più semplice sembra trasformare questo unico account nel Management Account di AWS Organizations e creare i nuovi member account tramite l'organizzazione.
Il problema: il management account è l'unico che non può essere governato dai controlli a livello di organizzazione.
Documentazione delle Service Control Policies di AWS Organizations
Le tipiche policy che si vorrebbero applicare:
- Tutti i volumi EBS di EC2 devono essere cifrati.
- Le risorse non possono essere create in regioni non autorizzate.
- I tipi di istanza più costosi (GPU) sono limitati.
- Gli utenti IAM non sono ammessi (sono consentiti solo i ruoli).
Nessuna di queste si applica al Management Account che, in questo caso, è anche l'account di produzione.
A peggiorare le cose, AWS non consente di convertire un Management Account in un Member Account.
Una volta che l'account di produzione coincide con il management account, l'unica soluzione è una migrazione organizzativa completa: ricostruire l'organizzazione, ricreare le policy, riconfigurare i permessi e rifare l'onboarding di ogni dipendente su un nuovo endpoint Single Sign On (SSO).
Se vi trovate oggi in una fase in cui tutto gira su un singolo account AWS e volete iniziare a separare gli ambienti, create un nuovo account AWS standalone, impostatelo come Management Account tramite AWS Organizations e invitate l'account di produzione esistente a entrare come member account nella nuova organizzazione.
3\. Rimandare la compliance
Se avete intenzione di vendere a clienti enterprise, prima o poi vi verrà richiesta la compliance:
- SOC 2 / ISO 27001 per il B2B SaaS
- HIPAA per il settore sanitario
- PCI DSS per fintech e pagamenti
Adeguare a posteriori un prodotto e un'organizzazione già avviati a nuovi requisiti di compliance è un'impresa estremamente complessa.
Non riguarda solo l'architettura cloud, ma anche i workflow di sviluppo, il controllo degli accessi e persino i contratti di lavoro (titolarità della IP, riservatezza, device management, ecc.).
Sistemare l'infrastruttura cloud è impegnativo, ma fattibile. Modificare contratti e processi organizzativi a posteriori è molto più difficile. Per questo, affiancarsi a un partner di consulenza sulla compliance fin dalle prime righe di codice del vostro prodotto rende il percorso decisamente più semplice.
4\. Tutte le uova nello stesso paniere
AWS consente di gestire registrazione, rinnovo del dominio e DNS all'interno di Route 53: comodo, ma anche pericoloso.
Se l'account AWS viene sospeso (per un problema di fatturazione, un incidente di sicurezza o una chiave IAM trapelata), anche il vostro dominio può risentirne.
E quando l'email smette di funzionare, diventa molto difficile comunicare con il Supporto AWS per risolvere il problema.
post da r/aws su Reddit.com
Best practice:
Tenete il dominio principale dell'azienda al di fuori dell'account AWS di produzione, ad esempio presso un provider separato come GoDaddy o NameCheap, oppure in un account AWS dedicato. Se venite tagliati fuori dall'account di produzione, potrete comunque gestire i record DNS sull'altro provider o account.
5\. Tenete un calendario delle scadenze per non perdere date di rinnovo critiche
Già nel primo anno, una startup accumula in fretta:
- Contratti
- Chiavi API
- Carte di credito
Hanno tutti una cosa in comune: una data di scadenza.
Le conseguenze indesiderate sono di solito:
- Account AWS bloccati per mancato pagamento.
- Interruzioni di servizio inattese per una chiave API scaduta.
- Negoziazioni di rinnovo contrattuale fatte di corsa, perché la data è stata mancata o è ormai imminente.
Un calendario condiviso con promemoria automatici ("La carta di credito 3344 scade tra 30 giorni", "Rinnovo contratto MAP Provider tra 45 giorni") aiuta a prevenire questi problemi.
Una riflessione finale
Le sfide da affrontare sono molte. Consiglio vivamente di trovare un mentor che sia stato founder in passato e abbia già guidato più startup. Un consiglio basato sull'esperienza vale davvero oro.
Se volete costruire il vostro cloud nel modo giusto fin dal primo giorno, DoiT mette a disposizione tecnologia, competenze e anni di esperienza nell'aiutare startup e grandi aziende globali a evitare proprio questi errori, e molti altri.
Trasformiamo insieme il vostro cloud in un motore di crescita, non in un fattore di rischio.