Arquitectures de seguretat al Cloud

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Arquitectures de seguretat al Cloud.

1. El model de responsabilitat compartida

Principi rector de tota la seguretat al núvol: la responsabilitat es reparteix entre proveïdor i client segons el model de servei.

Regla: el proveïdor és responsable de la seguretat DEL núvol; el client, de la seguretat EN el núvol. En tots els models, les dades, les identitats i la configuració són sempre del client, i la responsabilitat jurídica com a responsable del tractament no es delega mai (RGPD).

Conseqüència pràctica: la causa número u dels incidents al núvol no és una vulnerabilitat del proveïdor, sinó la configuració incorrecta del client —cubells d'emmagatzematge públics, grups de seguretat oberts, claus a repositoris, permisos excessius.

2. Els quatre C

Model de seguretat en capes concèntriques per a aplicacions natives al núvol: Cloud → Cluster → Container → Code. La capa Cloud és la que aquest tema desenvolupa (apartats 3 a 7: identitat, dades, xarxa, eines i operació); les capes Cluster, Container i Code —pròpies de l'orquestració de contenidors— es desenvolupen a tic/aplicaciones-nativas-en-la-nube, apartat 6.

3. Identitat: el nou perímetre

• IAM (Identity and Access Management) del proveïdor: usuaris, rols, polítiques, identitats de càrrega de treball (service accounts, managed identities, IRSA: IAM Roles for Service Accounts), i federació amb l'IdP corporatiu.
• Mínim privilegi i permisos temporals: assumir rols en lloc de credencials permanents; accés just a temps.
• MFA (Multi-Factor Authentication) obligatori, especialment per als comptes arrel i administratius; el compte arrel no s'usa mai per a l'operació diària.
• Eliminació de claus estàtiques: la fuita de claus d'accés a repositoris és un vector clàssic.
• Revisió d'accessos i detecció de permisos excessius (CIEM).
• Zero Trust (NIST SP (Special Publication) 800-207): cada petició s'autentica i s'autoritza, amb polítiques dinàmiques basades en context; al núvol es reforça amb identitats de càrrega de treball i xarxa Zero Trust (SASE/SSE, apartat 6). Els set principis del model i la seva arquitectura completa (PDP: Policy Decision Point/PEP: Policy Enforcement Point), independents de l'entorn, es desenvolupen a tic/arquitecturas-de-seguridad-on-premise, apartat 6 → tema 70.

4. Protecció de les dades

• Xifratge en repòs per defecte a tots els serveis, i en trànsit amb TLS (Transport Layer Security) 1.2/1.3.
• Gestió de claus: KMS (Key Management Service) del proveïdor, claus gestionades pel client (CMK: Customer Managed Key), BYOK (Bring Your Own Key, portar la pròpia clau) i HYOK (Hold Your Own Key, mantenir la clau fora del proveïdor). Si el proveïdor no té la clau, la dada que li puguin requerir és inintel·ligible → tema 60.
• Confidential computing: xifratge de les dades en ús, dins d'enclavaments segurs.
• Classificació i etiquetatge de la informació abans de decidir on va.
• Prevenció de pèrdua de dades (DLP: Data Loss Prevention) i descobriment de dades sensibles als magatzems.
• Còpies immutables i aïllades, amb bloqueig d'objectes (WORM: Write Once Read Many) i comptes separats → tema 57.
• Residència i sobirania → tema 60.

5. Seguretat de la xarxa al núvol

• Xarxes virtuals (VPC: Virtual Private Cloud/VNet) amb subxarxes públiques i privades, taules d'encaminament i passarel·les NAT (Network Address Translation).
• Grups de seguretat (amb estat, a nivell d'instància) i ACL (Access Control List) de xarxa (sense estat, a nivell de subxarxa).
• Punts finals privats (private endpoints) i PrivateLink per accedir als serveis gestionats sense sortir a Internet.
• WAF (Web Application Firewall) i protecció anti-DDoS gestionats.
• Connectivitat híbrida: VPN (Virtual Private Network) i connexió dedicada (Direct Connect, ExpressRoute, Interconnect).
• Microsegmentació i malla de serveis amb mTLS → tema 47.
• Egress controlat: filtrar també la sortida, no només l'entrada.

6. Les categories d'eines de seguretat al núvol

Aquest és el bloc de sigles que cau a l'examen:

Els avantatges principals d'un CASB —la pregunta d'examen: proporcionar visibilitat i control centralitzats sobre l'ús dels serveis al núvol per part de l'organització, incloent-hi la detecció del shadow IT (aplicacions SaaS usades sense aprovació), l'aplicació uniforme de les polítiques de seguretat i de protecció de dades sobre múltiples serveis SaaS, i la detecció d'usos anòmals o de risc. És exactament la resposta quan l'escenari diu que cal millorar la visibilitat i el control sobre l'ús que fan les persones usuàries de les aplicacions i els serveis al núvol.

Els quatre pilars del CASB: visibilitat, compliment, seguretat de les dades i protecció davant amenaces.

Modes de desplegament del CASB: API (Application Programming Interface; fora de banda, sobre el servei SaaS, sense afectar el trànsit), proxy directe (a l'endpoint o a la xarxa) i proxy invers (per a dispositius no gestionats, integrat amb l'IdP).

7. Operació segura

• Registres i auditoria: activar els registres del pla de control (CloudTrail, Activity Log, Cloud Audit Logs) a tots els comptes i regions, enviar-los a un compte separat i immutable, i integrar-los al SIEM (Security Information and Event Management).
• Monitoratge i detecció gestionats (GuardDuty, Defender for Cloud, Security Command Center).
• Gestió de secrets amb magatzems dedicats (Secrets Manager, Key Vault, HashiCorp Vault); mai secrets al codi ni a les imatges.
• Infraestructura com a codi amb anàlisi de seguretat (Checkov, tfsec, Terrascan) i polítiques com a codi (OPA: Open Policy Agent, Sentinel, Kyverno).
• Estructura de comptes (landing zone): separar producció, preproducció, desenvolupament i seguretat en comptes o subscripcions diferents, amb barreres de protecció (guardrails) a nivell d'organització (SCP: Service Control Policy, Azure Policy). La separació de comptes és el control d'aïllament més fort del núvol.
• Gestió de vulnerabilitats d'imatges i de dependències al pipeline.
• Resposta a incidents al núvol: cal preveure com s'aïlla una instància, com es preserva l'evidència (instantànies) i qui té accés d'emergència.

8. Compliment al sector públic

• ENS: els serveis al núvol han de ser conformes amb l'ENS; el RD (Reial Decret) 311/2022 hi dedica la família op.nub (serveis al núvol) i el CCN (Centro Criptológico Nacional) publica el perfil de compliment específic per a serveis al núvol i la CCN-STIC-823 (Seguridad de las Tecnologías de la Información y las Comunicaciones). Cal verificar la conformitat del proveïdor i assumir la part del client.
• RGPD: el proveïdor és encarregat; cal el contracte de l'RGPD, art. 28, control de subencarregats, ubicació i transferències internacionals (RGPD, art. 44 i següents), i sovint AIPD (Avaluació d'Impacte de Protecció de Dades) → temes 67 i 60.
• NIS2 (Network and Information Security 2) i RDL (Reial Decret Llei) 12/2018: gestió de riscos de la cadena de subministrament i notificació d'incidents.
• LCSP: al plec, conformitat ENS, SLA (Service Level Agreement), auditoria, reversibilitat i portabilitat, propietat de les dades, notificació d'incidents i condicions de sortida.
• Data Act: obligacions de facilitar el canvi de proveïdor.
• Certificacions de referència del proveïdor: ENS, ISO/IEC 27001, ISO/IEC 27017 (seguretat al núvol), ISO/IEC 27018 (dades personals al núvol), SOC (System and Organization Controls) 2, CSA (Cloud Security Alliance) STAR (Security, Trust, Assurance and Risk), basada en la seva CCM (Cloud Controls Matrix), i el futur EUCS (European Union Cybersecurity Certification Scheme for Cloud Services) europeu.

9. Errors habituals

1. Assumir que el proveïdor ho protegeix tot: el model és compartit.
2. Emmagatzematge exposat públicament per configuració per defecte mal entesa.
3. Credencials i claus al codi o a repositoris públics.
4. Permisos excessius i rols amb comodins.
5. Manca de registre o registres no centralitzats ni protegits.
6. Comptes sense MFA, especialment els administratius.
7. Un únic compte per a tot, sense separació d'entorns.
8. Recursos orfes sense propietari ni actualització.
9. No provar la recuperació.
10. Shadow IT: serveis contractats fora del control de TI (Tecnologies de la Informació), sense contracte d'encarregat ni avaluació de riscos.

Claus d'examen

• CASB és la resposta quan l'escenari parla de visibilitat i control centralitzat sobre l'ús que fan les persones usuàries de les aplicacions i els serveis al núvol —incloent-hi el shadow IT—, no quan parla de correlacionar registres (SIEM), protegir l'endpoint (EDR: Endpoint Detection and Response) o només evitar fuites de dades (DLP), que és una de les quatre capacitats del CASB, no la seva definició (TS-TIC 2023 específic, p. 78).
• El CASB no substitueix el tallafoc ni gestiona identitats: aquestes són les distractores habituals. Gestiona polítiques i visibilitat sobre serveis gestionats i no gestionats; la gestió d'identitats és funció de l'IAM/IdP (TS-TIC 2025 específic, p. 79).

Per recordar

• Responsabilitat compartida: el proveïdor protegeix el núvol; el client, el que hi posa. Dades, identitats i configuració són sempre del client.
• La causa número u dels incidents al núvol és la configuració incorrecta del client.
• CASB = visibilitat i control sobre l'ús dels serveis al núvol, detecció de shadow IT, aplicació de polítiques i protecció de dades. Quatre pilars: visibilitat, compliment, seguretat de les dades i protecció davant amenaces.
• CSPM = configuracions incorrectes; CWPP = càrregues de treball; CIEM = permisos; CNAPP = tot integrat.
• SASE = xarxa + seguretat al núvol; ZTNA substitueix la VPN donant accés a l'aplicació, no a la xarxa.
• BYOK/HYOK: si el proveïdor no té la clau, la dada requerida és inintel·ligible.
• Grups de seguretat = amb estat, per instància; ACL de xarxa = sense estat, per subxarxa.
• Separar comptes per entorn és el control d'aïllament més fort.
• L'ENS hi dedica la família op.nub, i el CCN publica el perfil de compliment per a serveis al núvol.