AWS Security: Guida Pratica per Developer

Introduzione: security by design, non come afterthought

Mettere in sicurezza un'infrastruttura AWS non significa solo "bloccare tutto": richiede bilanciare protezione, usabilità e costi. Molti breach documentati derivano da configurazioni sbagliate—bucket S3 pubblici, IAM roles over-permissive, security group troppo aperti—non da vulnerabilità nel codice. Questa guida fornisce pratiche concrete per sviluppatori che devono deployare in produzione senza dedicare mesi a diventare security expert.

IAM: Identity and Access Management

Principio di least privilege

IAM controlla chi (utente, servizio, ruolo) può fare cosa (azione) su quali risorse AWS. Il principio fondamentale è least privilege: concedere solo i permessi minimi necessari per svolgere un task specifico.

Errori comuni:

• Usare policy predefinite troppo ampie come AdministratorAccess per utenti non-admin.
• Creare un unico ruolo IAM condiviso da tutte le Lambda o EC2 del progetto.
• Assegnare Resource: "*" quando si potrebbe limitare a bucket, tabella o funzione specifica.

Best practices:

Policy granulari per servizio

• Ogni Lambda, ECS task o EC2 dovrebbe avere il proprio execution role dedicato.
• Esempio per Lambda che legge da DynamoDB e scrive su S3:

Evita dynamodb:* o s3:*—specifica solo le azioni realmente usate.

IAM Access Analyzer

• Tool AWS che scansiona policy e identifica permessi over-provisioned o risorse condivise esternamente.
• Attivalo su ogni Region e revisiona regolarmente i finding.

MFA per utenti umani

• Abilita Multi-Factor Authentication per tutti gli utenti IAM con accesso console o CLI.
• Usa policy di tipo Condition: {"Bool": {"aws:MultiFactorAuthPresent": "true"}} per operazioni sensibili (es. eliminare risorse, modificare IAM).

Rotazione credenziali

• Ruota access key ogni 90 giorni per utenti IAM programmatici.
• Preferisci IAM roles con STS temporary credentials invece di long-lived access key dove possibile.

Service Control Policies (SCP) per Organizations

• Se usi AWS Organizations, applica SCP per limitare azioni a livello di account (es. blocca creazione di utenti IAM root, impedisci deploy fuori da certe Region).

KMS: Key Management Service per crittografia

Crittografia at-rest e in-transit

AWS offre crittografia automatica per molti servizi (S3, EBS, RDS), ma gestire le chiavi in modo sicuro è cruciale.

Cosa cifrare:

• S3: bucket con dati sensibili (PII, credenziali, backup).
• EBS: volumi attached a EC2 con database o file confidenziali.
• RDS/Aurora: snapshot e dati a riposo.
• Secrets Manager / Parameter Store: credenziali applicative, API key, token OAuth.

Best practices KMS:

Customer Managed Keys (CMK) invece di AWS Managed

• Le CMK ti danno controllo totale: audit via CloudTrail, rotazione automatica, policy di accesso granulari.
• Esempio: crea una CMK dedicata per cifrare variabili d'ambiente Lambda o RDS encryption.

Key policies e grants

• Ogni CMK ha una key policy che definisce chi può usarla per cifrare/decifrare.
• Usa grants per concedere temporaneamente accesso a servizi (es. EBS può usare la chiave per cifrare volumi).

Rotazione automatica

• Abilita automatic key rotation (ogni anno) per CMK simmetriche.
• La rotazione è trasparente: dati cifrati con chiavi vecchie restano accessibili, nuovi dati usano la chiave ruotata.

Envelope encryption per grandi volumi

• KMS cripta data key, che poi cripta i dati effettivi localmente—riduce chiamate API a KMS e accelera performance.
• Usato automaticamente da servizi come S3 con SSE-KMS.

Monitoring via CloudTrail

• Ogni chiamata a KMS (Encrypt, Decrypt, GenerateDataKey) è loggata su CloudTrail.
• Configura allarmi CloudWatch per detect anomalie (es. spike improvviso di decrypt da un servizio non previsto).

Security Groups e Network Access Control

Security Groups: firewall stateful per istanze

Security Groups controllano traffico in ingresso (inbound) e uscita (outbound) da risorse EC2, RDS, Lambda in VPC.

Errori comuni:

• Security group con 0.0.0.0/0 su porta SSH (22) o RDP (3389)—espone istanze a brute-force attack.
• Nessuna regola outbound configurata (default permette tutto).
• Security group condiviso tra ambienti dev/staging/prod, violando isolation.

Best practices:

Least privilege per inbound rules

• Permetti solo IP sorgenti specifici per SSH/RDP (es. IP ufficio o VPN aziendale).
• Per servizi pubblici (ALB, API Gateway), limita a porte necessarie (80, 443) e usa Web Application Firewall (WAF) come layer aggiuntivo.

Segmentazione per tier

• Web tier: Security Group che accetta traffico da internet su 443, può chiamare app tier.
• App tier: accetta solo traffico da web tier, può chiamare database tier.
• Database tier: accetta solo traffico da app tier, nessun accesso diretto da internet.

Logging con VPC Flow Logs

• Abilita Flow Logs per monitorare traffico accettato/rifiutato dai Security Group.
• Invia log a CloudWatch Logs o S3, analizza con Athena per detect pattern anomali.

Audit con AWS Config

• Crea Config Rules per verificare compliance (es. "nessun Security Group deve avere 0.0.0.0/0 su SSH").
• Notifica automatica quando una regola viene violata.

Secrets management: non hardcodare mai credenziali

AWS Secrets Manager e Systems Manager Parameter Store

Hardcodare password, API key o token nel codice o variabili d'ambiente in chiaro è una pratica vulnerabile.

Soluzioni sicure:

Secrets Manager

• Cifra automaticamente segreti con KMS.
• Supporta rotazione automatica per database RDS, Redshift, DocumentDB.
• Esempio: archivia credenziali RDS, Lambda le recupera via SDK all'avvio.

Parameter Store (SSM)

• Alternativa più economica di Secrets Manager (gratis fino a 10k parametri).
• Supporta encryption via KMS per parametri SecureString.
• Ideale per configurazioni non-rotanti (chiavi OAuth, endpoint API).

Best practices:

• Carica segreti fuori dall'handler Lambda (a livello globale), non a ogni invocazione—riduce chiamate API e latenza.
• Cachea segreti in memoria per 5-10 minuti, riducendo costi e migliorando performance.
• Non loggare mai segreti in CloudWatch Logs—sanitizza log output prima di scrivere.
• Usa IAM per limitare quali servizi possono leggere quali segreti (principle of least privilege).

Logging, monitoring e incident response

CloudWatch Logs e CloudTrail

CloudWatch Logs:

• Centralizza log di Lambda, EC2, RDS, API Gateway.
• Configura log retention policy (es. 30 giorni) per evitare accumulo infinito di log costosi.
• Usa Metric Filters per estrarre metriche custom (es. contare error log) e creare allarmi.

CloudTrail:

• Registra ogni chiamata API verso AWS (chi ha fatto cosa, quando).
• Essenziale per audit e forensics post-incident.
• Attiva CloudTrail in tutte le Region, invia log a S3 bucket cifrato con KMS e protetto da Object Lock per prevenire manomissione.

AWS GuardDuty

• Threat detection automatico basato su ML che analizza CloudTrail, VPC Flow Logs e DNS logs.
• Identifica comportamenti anomali (es. accesso da IP sospetto, privilege escalation, cryptomining su EC2).
• Costa pochi dollari/mese e può prevenire breach costosi—sempre attivarlo in produzione.

Checklist completa per infrastruttura sicura

IAM e Identity

Crittografia e Secrets

Network Security

Logging e Monitoring

Compliance e Audit

Deployment e Code Security

Risorse per approfondire

• AWS Well-Architected Framework - Security Pillar: guida ufficiale AWS con best practice approfondite.
• CIS AWS Foundations Benchmark: checklist standard industry per configurazioni sicure.
• OWASP Top 10 for Cloud: adattamento delle vulnerabilità web più comuni al contesto cloud.
• AWS Security Blog: case study reali, nuove feature e best practice aggiornate.

Mettere in sicurezza un'infrastruttura AWS è un processo continuo, non un task "fatto una volta". Usa questa checklist come punto di partenza, implementa monitoring robusto e mantieni aggiornato il tuo threat model man mano che l'architettura evolve.