Sommario

La scalabilità e la sicurezza del cloud enterprise poggiano su una premessa fondamentale: l'isolamento dei carichi di lavoro tramite una struttura multi-account rigidamente governata. Per un gruppo bancario con centinaia di applicazioni core, requisiti stringenti di segregazione dei compiti e controlli normativi continui, una Landing Zone non è semplicemente un template di bootstrap, ma un sistema operativo infrastrutturale. Questo articolo approfondisce la progettazione di una Landing Zone enterprise, analizzando l'albero delle Organizational Units (OU), l'automazione tramite Account Vending Machine (AVM) e l'applicazione di Service Control Policies (SCP) per garantire la conformità preventiva agli standard EBA e DORA.

I limiti del single-account e la necessità della segregazione perimetrale

Nelle prime fasi di adozione del cloud, molte organizzazioni hanno tentato di gestire più ambienti (sviluppo, collaudo, produzione) e diversi domini di business all'interno di un unico account o di poche sottoscrizioni, affidandosi esclusivamente a policy IAM e tagging per garantire la separazione. In un contesto bancario, questo modello mostra rapidamente limiti insormontabili:

• Rischio di Blast Radius incontrollato: Un errore di configurazione IAM o una compromissione delle credenziali in un ambiente di test può impattare le risorse di produzione condivise sullo stesso control plane.
• Saturazione dei Quota Limits delle API: I cloud provider impongono limiti sul numero di chiamate API e sulla creazione di risorse per singolo account (es. VPC, route tables, certificati KMS). La coesistenza di decine di team porta inevitabilmente a fenomeni di "noisy neighbor" e blocchi operativi durante i picchi transazionali.
• Complessità di Audit e Conformità Finanziaria: Gli auditor di Banca d'Italia e le linee guida EBA sull'outsourcing richiedono prove inoppugnabili di isolamento logico dei dati finanziari e una netta separazione dei privilegi (Segregation of Duties). Dimostrare questa conformità su account condivisi richiede matrici RBAC labirintiche e fragili.

La risposta architetturale risiede nell'adottare il principio per cui l'account cloud è l'unità fondamentale di isolamento di sicurezza e fatturazione.

Architettura dell'Albero delle Organizational Unit (OU)

Una Landing Zone bancaria richiede un'alberatura gerarchica progettata per applicare policy ereditate in modo deterministico, distinguendo tra account di piattaforma centralizzati e account applicativi per i tenant.

flowchart TD
    Root["Root Organization (Management Account)"] --> CoreOU["Core / Foundation OU"]
    Root --> SecurityOU["Security & Compliance OU"]
    Root --> WorkloadsOU["Workloads OU"]
    Root --> SandboxOU["Sandbox OU (No Direct Network)"]

    CoreOU --> NetHub["Network Hub Account (Transit Gateway / Firewall)"]
    CoreOU --> SharedSvc["Shared Services (CI/CD / Artifact Registry)"]

    SecurityOU --> LogArchive["Log Archive Account (Immutable S3 / KMS)"]
    SecurityOU --> SecAudit["Security Tooling (GuardDuty / SIEM Gateway)"]

    WorkloadsOU --> ProdOU["Production OU"]
    WorkloadsOU --> NonProdOU["Non-Production OU"]

    ProdOU --> CoreBank["Core Banking Account (PCI-DSS Zone A)"]
    ProdOU --> Payments["Payment Engine Account (Confidential VM)"]

Funzione dei macro-account di piattaforma

1. Management Account: Destinato esclusivamente alla fatturazione consolidata e alla gestione dell'organizzazione. Nessun carico applicativo viene eseguito qui, e l'accesso è protetto da MFA hardware con procedure break-glass.
2. Security & Audit Account: Aggrega centralmente i segnali di sicurezza (AWS GuardDuty, Security Hub, Inspector, o GCP Security Command Center). I security engineer hanno visibilità in sola lettura su tutti i tenant.
3. Log Archive Account: Raccoglie tutti i log immutabili (CloudTrail, VPC Flow Logs, log di audit applicativi). Le bucket policy implementano l'Object Lock in modalità Compliance, impedendo qualsiasi cancellazione anche da parte di utenti root.
4. Network Hub Account: Concentra la connettività perimetrale (Direct Connect/Interconnect verso i mainframe on-premise, Next-Generation Firewall per l'ispezione egress verso Internet e Transit Gateway).

Service Control Policies (SCP) come guardrail preventivi

Le SCP rappresentano il meccanismo con cui il team di Cloud Governance impone limiti invalicabili all'interno dell'organizzazione, indipendentemente dai permessi concessi dagli amministratori dei singoli account.

Esempio di Service Control Policy di conformità bancaria

Il manifest seguente applica tre controlli critici su tutta la Workloads OU: blocca l'uso di regioni geografiche non autorizzate (garantendo la sovranità del dato in UE), impedisce la disattivazione dei log di audit e vieta la creazione di bucket storage privi di cifratura con chiavi gestite dal cliente (CMEK/KMS):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceEURegionBoundary",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "route53:*",
        "budgets:*",
        "support:*",
        "wafv2:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "eu-south-1",
            "eu-central-1",
            "eu-west-1"
          ]
        }
      }
    },
    {
      "Sid": "ProtectSecurityServicesAndLogging",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail",
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "securityhub:DisableSecurityHub"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyUnencryptedS3Storage",
      "Effect": "Deny",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::*/*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "true"
        }
      }
    }
  ]
}

Questo pattern garantisce che anche in caso di compromissione totale dei permessi AdministratorAccess su un account tenant, l'attaccante non possa mai disattivare i meccanismi di tracciamento né esfiltrare dati al di fuori delle regioni autorizzate.

Automazione tramite Account Vending Machine (AVM)

Creare manualmente gli account in un'organizzazione bancaria rallenta il time-to-market e introduce difformità configurative. L'adozione di un'Account Vending Machine (AVM) dichiarativa gestita tramite Infrastructure as Code (Terraform/OpenTofu) automatizza l'intero ciclo di vita:

1. Richiesta del Tenant: Il team applicativo compila un file dichiarativo (es. tenant-request.yaml) indicando il business domain, il livello di classificazione dei dati (PCI-DSS, dati ordinari) e il cost center per il FinOps.
2. Pipeline di Provisioning: La pipeline CI/CD invoca il modulo AVM che crea l'account all'interno della corretta OU, vi associa le SCP corrispondenti, istanzia il peering/attachment con il Transit Gateway di rete e inietta il ruolo IAM federato con l'Identity Provider enterprise (Entra ID / Okta).
3. Baseline Security Bootstrapping: Vengono attivati automaticamente i controlli di sicurezza minimi (default EBS encryption, blocco dell'accesso pubblico a S3 a livello di account, forward dei log verso il Log Archive).

# Esempio di invocazione del modulo AVM con Terraform
module "core_banking_account" {
  source = "git::https://git.internal.bank.corp/cloud-foundation/terraform-aws-avm.git?ref=v3.2.0"

  account_name               = "payments-clearing-prod"
  account_email              = "[email protected]"
  parent_ou_id               = data.aws_organizations_organizational_unit.prod_workloads.id
  budget_monthly_limit_eur   = 15000
  cost_center                = "CC-BANKING-PAY-04"
  compliance_framework       = "PCI-DSS-4.0"

  vpc_cidr_block             = "10.140.0.0/20"
  transit_gateway_attachment = true
  enable_kms_cmk_baseline    = true
}

Conclusione

Una Landing Zone Multi-Account progettata secondo i principi di isolamento preventivo e automazione as-code costituisce l'architrave su cui poggia l'intera strategia cloud di una banca moderna.

Per un Cloud Architect, il valore risiede nella capacità di disaccoppiare la velocità degli sviluppatori dai vincoli di sicurezza: attraverso guardrail ereditari, segregazione delle reti perimetrali e provisioning deterministico, la conformità a standard stringenti come DORA e PCI-DSS non è più un collo di bottiglia a valle, ma una proprietà intrinseca della piattaforma.