Sicurezza Cloud e DevSecOps: La Guida Pillar Definitiva per Pipeline Sicure e Infrastruttura Solida

State spingendo codice in produzione ogni giorno. Avete CI/CD, container, Kubernetes, automation. Ma quante di queste pipeline hanno integrati controlli di sicurezza reali? Noi di Meteora Web lo vediamo spesso: aziende che investono in cloud ma trascurano la sicurezza nella catena di consegna del software. Il risultato? Misconfigurazioni che aprono porte a chiunque, segreti lasciati nei repository, vulnerabilità nei container che aspettano solo di essere sfruttate.

Questa guida pillar è scritta per chi vuole passare da "deploy veloce e sicuro? boh" a "deploy sicuro per progettazione". Parliamo di DevSecOps, IAM, secrets management, container security, SAST/DAST, Kubernetes hardening, Zero Trust, SIEM e compliance cloud. Nessuna teoria astratta: ogni sezione finisce con un'azione concreta che potete eseguire subito.

DevSecOps: Integrare la Sicurezza nella Pipeline senza Rallentare

DevSecOps non è un tool. È un cambio di mentalità: la sicurezza entra nel ciclo di sviluppo come un requisito, non come un audit finale. Noi abbiamo visto progetti dove i test di sicurezza arrivano tre giorni prima del deploy, e indovinate? Si tagliano, si rimandano, e poi si piange. La chiave è spostare a sinistra (shift left) i controlli, automatizzandoli in CI/CD.

Pipeline a più stadi di sicurezza

Una pipeline DevSecOps matura ha gate automatizzati in ogni fase:

• Pre-commit: linting, secret scanning (es. git-secrets, Talisman).
• Build: SAST (static analysis) sul codice, scansione delle dipendenze (SCA).
• Test: DAST su ambiente di staging, container scanning.
• Deploy: policy as code (OPA, Kyverno) per Kubernetes, firma delle immagini.
• Runtime: monitoring continuo, SIEM, anomaly detection.

Azioni concrete: integrate gitleaks o truffleHog in pre-commit localmente e in GitHub Actions. Esempio di workflow:

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Secret scanning
        uses: gitleaks/gitleaks-action@v2

IAM su AWS: Least Privilege e Policy Management

L'errore più comune? Policy troppo larghe. Action: "*" e Resource: "*" sono il biglietto da visita per il disaster recovery involontario. Noi partiamo sempre dal principio: ogni ruolo deve avere solo i permessi minimi necessari per svolgere la sua funzione. E li controlliamo con strumenti di analisi.

Best practice IAM AWS

• Usare ruoli, non utenti a lungo termine per servizi. Access keys? Rotazione ogni 90 giorni.
• Policy basate su attributi (ABAC) o su condizioni (es. aws:SourceIp).
• Applicare una Service Control Policy (SCP) a livello di organizzazione per limitare azioni sensibili (es. disabilitare la creazione di utenti IAM per account non autorizzati).
• Abilitare AWS IAM Access Analyzer per identificare policy pubbliche o cross-account non volute.

Esempio di policy restrittiva per un'EC2 che deve solo leggere da S3:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::my-bucket/*",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": "10.0.0.0/16"
                }
            }
        }
    ]
}

Azioni immediate: controllare le policy non utilizzate con IAM Last Accessed, rimuovere quelle in eccesso. Disattivare le access keys che non vengono usate da 30 giorni.

Secrets Management: HashiCorp Vault, AWS Secrets Manager, GitHub Secrets

Lasciare credenziali in chiaro in un repo è come lasciare le chiavi di casa sotto lo zerbino. Noi, di Meteora Web, abbiamo visto database compromise perché un file .env finiva su GitHub. La soluzione non è un solo tool, ma un approccio: centralizzare, rotare, cifrare. HashiCorp Vault è la scelta matura per ambienti multi-cloud. AWS Secrets Manager è integrato nativamente. Per CI/CD: GitHub Secrets e GitLab CI Variables.

Pattern da seguire

• Non hardcode mai segreti in codice.
• Iniettare segreti via variabili d'ambiente, mai via file versionati.
• Usare OIDC per scambio di token tra GitHub Actions e AWS (evitare access keys).
• Rotazione automatica ogni 90 giorni (o meno per segreti ad alto rischio).
• Audit log di accesso ai segreti.

Esempio di accesso a Vault da un'app Python:

import hvac
client = hvac.Client(url='https://vault.example.com', token='s.xxx')
client.secrets.kv.v2.read_secret_version(path='myapp/db_password')

Azione immediata: cercate pattern di segreti nei vostri repository con git log -p | grep -E "(password|secret|api_key)". Se trovate, rotate e rimuovete con git filter-branch o bfg. Poi migrate a Secrets Manager.

Container Security: Trivy, Docker Scout e Hardening delle Immagini

I container non sono thin client sicuri per default. Un'immagine base con vulnerabilità critiche è una bomba a orologeria. Noi usiamo Trivy per scansione locale e in pipeline, e Docker Scout per analisi delle dipendenze. Ma il vero passo è l'hardening dell'immagine: multistage build, utente non root, ridurre superficie d'attacco.

Hardening minimo per Docker

• Usare immagini base ufficiali e slim (es. python:3.11-slim).
• Multistage build: il container finale non contiene compilatori o tool di sviluppo.
• Eseguire con utente non root: USER appuser.
• Non esporre porte non necessarie.
• Aggiungere HEALTHCHECK e limitare risorse (--memory, --cpus).

Esempio di Dockerfile multistage per Node.js:

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:20-alpine
RUN addgroup -g 1001 -S appgroup && adduser -S appuser -u 1001
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY --chown=appuser:appgroup . .
USER appuser
EXPOSE 3000
CMD ["node", "server.js"]

Azioni immediate: avviare Trivy su tutte le immagini in produzione. Se trovate vulnerabilità critiche, ricostruite l'immagine base. Impostate un workflow di scansione obbligatorio prima del push.

SAST e DAST: Analisi Statica e Dinamica nella Pipeline

SAST analizza il codice senza eseguirlo (es. SonarQube, Semgrep). DAST testa l'applicazione in esecuzione (es. OWASP ZAP, Burp Suite). Non basta uno solo: il codice può essere pulito ma l'applicazione esposta a SQL injection se la configurazione runtime è sbagliata.

Integrazione pratica

Inseriamo SAST nella build e DAST in staging. Esempio di step Docker Scout su GitHub Actions:

- name: Analyze for vulnerabilities
  uses: docker/scout-action@v1
  with:
    command: cves
    image: myapp:latest

Per DAST, possiamo usare OWASP ZAP con GitHub Actions e generare report:

- name: ZAP DAST
  uses: zaproxy/action-full-scan@v0.11.0
  with:
    target: 'https://staging.myapp.com'

Azione immediata: se non avete SAST, provate Semgrep con regole di sicurezza OWASP Top 10. Se non avete DAST, mockate un ambiente di staging e lanciate ZAP. I risultati vi stupiranno (in negativo).

Kubernetes Security: RBAC, Network Policy e Pod Security Standards

K8s è un sistema complesso: errori di configurazione possono esporre l'intero cluster. Noi vediamo spesso ServiceAccount con permessi eccessivi (cluster-admin per un pod web), o NetworkPolicy assenti. La sicurezza in K8s si basa su tre pilastri: RBAC, Network Policy, Pod Security.

RBAC restrittivo

Non usare i token di default. Creare ruoli con scope a namespace specifici e limitati. Esempio di Role che permette solo lettura di pod e servizi:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]

Network Policy

Default deny in ingresso e uscita, poi aprire solo ciò che serve. Esempio di policy che permette traffico solo da un namespace monitoring:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-except-monitoring
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: monitoring

Pod Security Standards

Applicare i controlli di security context: runAsNonRoot: true, readOnlyRootFilesystem: true, seccompProfile. Usare Pod Security Admission (incluso in K8s 1.23+) per applicare le policy a livello di namespace: baseline, restricted.

Azioni immediate: auditare i permessi dei ServiceAccount con kubectl auth can-i. Controllare se ci sono NetworkPolicy: kubectl get networkpolicy --all-namespaces. Se non ce ne sono, partire da una default deny.

Cloud Misconfigurations: Errori Comuni e Come Evitarli

Uno studio Gartner dice che oltre l'80% delle violazioni cloud è dovuto a misconfigurazioni. Noi lo confermiamo: bucket S3 pubblici, security group aperti a 0.0.0.0/0, database RDS esposti, IAM policy con scrittura su tutte le risorse. La soluzione è una combinazione di policy as code e scanning continuo.

Strumenti di prevenzione

• CloudFormation Guard o Terraform Sentinel per validare gli IaC prima del deploy.
• AWS Config con regole di compliance (es. s3-bucket-public-read-prohibited).
• Scanners come ScoutSuite, Prowler (open source) per audit periodici.

Esempio di controllo Terraform con Open Policy Agent (OPA):

package terraform
violations[msg] {
  resource = input.resource.aws_s3_bucket[_]
  resource.acl = "public-read"
  msg := sprintf("Bucket %s non deve essere pubblico", [resource.bucket])
}

Azione immediata: lanciate Prowler sul vostro account AWS: prowler aws. Esaminatelo i primi errori critici. Riparate subito bucket pubblici e security group aperti.

Zero Trust Architecture: Principi e Implementazione Pratica

Lo Zero Trust si basa su "non fidarti mai, verifica sempre". Non importa se la richiesta arriva dalla rete interna o da un IP fidato. Noi lo applichiamo con:

• Autenticazione forte (MFA per tutti, SSO con OIDC).
• Microsegmentazione: ogni servizio parla solo con ciò che deve.
• Accesso just-in-time per admin: permessi temporanei su richiesta.
• Controllo continuo del dispositivo: non basta l'utente, anche il device deve essere compliant.

Implementazione con BeyondCorp

Un modo pratico è usare un service mesh (es. Istio) con mTLS obbligatorio, e un API gateway con autenticazione a livello di ogni richiesta. Google ha rilasciato BeyondCorp Enterprise; in cloud AWS si può replicare con AWS Verified Access.

Azione immediata: introducete MFA per tutti gli account (inclusi quelli di servizio? No, per utenti umani). Per le macchine, usate certificati e rotazione.

SIEM e Monitoring di Sicurezza: Elastic Security e Alert

Non basta prevenire: bisogna rilevare in tempo reale. Un SIEM (Security Information and Event Management) centralizza log da cloud, container, applicazioni. Noi abbiamo esperienza con Elastic Security (basato su Elasticsearch) per correlare eventi e generare alert. Alternative: Splunk, Wazuh (open source).

Logging essenziale

• CloudTrail (AWS) o equivalenti.
• Log di Kubernetes (fluentd → Elastic).
• Firewall e intrusion detection (Snort, Suricata).
• Alert sulle anomalie: tentativi di accesso non autorizzati, spikes di traffico, modifica di policy.

Esempio di configurazione di un alert Elastic su fallimenti di login SSH da più IP in 5 minuti:

rules:
  - rule_id: 'ssh_brute_force'
    type: query
    query: 'source.ip:* AND event.action: "ssh_failed"'
    group_by: ['host.name']
    timespan: '5m'
    threshold: 10
    actions:
      - slack: '#security'

Azione immediata: assicuratevi che i log siano centralizzati. Se non avete un SIEM, partite con Wazuh: si installa in Docker e aggrega i log di sistema e cloud.

Compliance Cloud: SOC2, ISO27001 e GDPR

Le certificazioni non sono solo carta. Dimostrano che i controlli sono in atto. Noi aiutiamo i clienti a preparare il terreno: inventory delle risorse, policy documentate, evidenze di audit. Le piattaforme cloud offrono report di compliance (AWS Artifact, Azure Compliance Manager).

Cosa fare per iniziare

• Mappare i controlli richiesti (es. ISO 27001:2022 Annex A) con i controlli cloud nativi.
• Configurare regole di Config + GuardDuty per evidenze continue.
• Documentare i processi di incident response e change management.
• Eseguire penetration test annuali.
• Conservare log per almeno 90 giorni (per GDPR anche di più).

Azione immediata: scaricate il AWS Compliance Whitepaper e confrontate la vostra configurazione con i controlli base. Identificate le lacune.

In sintesi – Cosa fare adesso

1. Pipeline scan: abilitate secret scanning e SAST sui vostri repo. Subito.
2. IAM audit: riducete i permessi eccessivi. Applicate least privilege.
3. Container hardening: multistage build e Trivy in CI.
4. K8s security: RBAC ristretto e NetworkPolicy.
5. Cloud misconfiguration: lanciate Prowler e correggete le criticità.
6. Zero Trust: MFA obbligatoria e microsegmentazione.
7. SIEM: se non esiste, installate Wazuh o Elastic Security.
8. Compliance: create un backlog di gap analysis.

Noi di Meteora Web offriamo audit completi e implementazione DevSecOps per aziende che vogliono sicurezza vera, non solo checklist. Veniamo dalla contabilità e dal codice: ogni policy ha un costo e un ritorno. Se volete un confronto, contattateci.