Infraestructura híbrida: com connectar l’oficina amb el núvol

Portar serveis al núvol no elimina la infraestructura: l’estén. Una part de les aplicacions i les dades passa a executar-se a Azure, AWS o Google Cloud, una altra es queda a l’oficina, i totes dues han de funcionar com una única xarxa, amb la mateixa seguretat, la mateixa identitat i una estratègia de còpies comuna. Quan això no es dissenya, el núvol hereta els problemes de la xarxa local i hi afegeix els seus: serveis exposats a internet, connectivitat improvisada, costos sense control i còpies de seguretat al mateix lloc que les dades.

Aquesta guia recull els criteris tècnics que apliquem en dissenyar infraestructures híbrides per a empreses: què portar al núvol, com connectar-lo amb l’oficina, com dissenyar les xarxes virtuals, la resolució DNS, la identitat, el backup i el control de costos.

1. Què portar al núvol i què mantenir en local

No totes les càrregues de treball es beneficien igual del núvol. La decisió s’ha de prendre aplicació per aplicació, tenint en compte la latència que tolera, el volum de dades que mou amb els usuaris, el seu llicenciament, les seves dependències amb altres sistemes i el cost d’operar-la en cada entorn.

• Bons candidats per al núvol: aplicacions amb usuaris distribuïts o en mobilitat, serveis amb demanda variable, entorns de desenvolupament i proves, i còpies de seguretat fora de l’oficina.
• Candidats a quedar-se en local: sistemes que intercanvien grans volums de dades amb els llocs de treball de l’oficina, equipament amb dependència física (control industrial, CCTV, sistemes de producció) i aplicacions heretades el cost d’adaptació de les quals no compensa.

Criteri: abans de migrar, cal inventariar les aplicacions i els seus fluxos de dades. Un servidor que es mou al núvol però que continua intercanviant fitxers pesants amb l’oficina cada dia trasllada el problema a l’enllaç d’internet i genera costos de transferència de sortida que no s’havien previst.

2. Connectivitat entre l’oficina i el núvol

L’accés als recursos privats del núvol s’ha de fer per un canal xifrat entre la xarxa de l’oficina i la xarxa virtual, sense exposar serveis a internet. Hi ha dues aproximacions principals:

• VPN IPsec site-to-cloud: entre el firewall de l’oficina i la passarel·la VPN del proveïdor (Azure VPN Gateway, AWS Site-to-Site VPN, Google Cloud HA VPN). És l’opció habitual per a la majoria d’empreses. Els proveïdors ofereixen túnels redundants i convé configurar-los tots, idealment amb encaminament dinàmic BGP.
• Interconnexió dedicada: un circuit privat fins al proveïdor (Azure ExpressRoute, AWS Direct Connect, Google Cloud Interconnect), indicada quan calen amplades de banda elevades, latència previsible o requisits de compliment que exclouen el trànsit per internet.

Criteri: en una arquitectura híbrida, la connexió a internet de l’oficina passa a ser un component crític: si cau, els usuaris perden l’accés a les aplicacions que s’executen al núvol. Per això la redundància WAN, amb dos operadors o reserva 5G i commutació automàtica, forma part del disseny, no és un afegit. Ho expliquem a la guia sobre talls de connectivitat.

3. Pla d’adreçament

Un dels errors més costosos de corregir és el solapament de rangs IP. Si la xarxa virtual al núvol fa servir el mateix rang que l’oficina, una seu remota o la xarxa domèstica habitual dels usuaris en teletreball, l’encaminament entre elles no és possible sense recórrer al NAT, amb la complexitat que comporta. Refer l’adreçament d’una xarxa virtual en producció implica tornar a desplegar recursos.

Criteri: definir un pla d’adreçament global abans de crear la primera xarxa virtual, assignant blocs no solapats a l’oficina, a cada seu, a cada xarxa virtual i a cada entorn (producció, proves), i evitant els rangs més comuns en xarxes domèstiques. Documentar-lo i reservar espai per créixer.

4. Disseny de les xarxes virtuals

Una VPC o VNet és una xarxa, i es dissenya amb els mateixos principis que la de l’oficina. És freqüent trobar màquines virtuals amb adreça pública i accés remot exposat a internet, totes en una única subxarxa i amb regles d’entrada permissives creades durant la posada en marxa i mai revisades.

• Subxarxes per funció: separar frontals públics, aplicacions, bases de dades i gestió, amb la majoria de recursos en subxarxes privades sense adreça pública.
• Filtratge: Security Groups o Network Security Groups amb mínim privilegi, denegant per defecte i referenciant grups en lloc de rangs amplis.
• Sortida a internet controlada: mitjançant NAT gateway o firewall al núvol, perquè els recursos privats es puguin actualitzar sense ser accessibles des de fora.
• Accés d’administració: RDP i SSH mai oberts a internet; accés a través de la VPN o d’un servei bastió gestionat.
• Serveis gestionats per xarxa privada: bases de dades i emmagatzematge accessibles mitjançant endpoints privats en lloc de les seves adreces públiques.

Els principis són els mateixos que a la xarxa local, i els tractem a la guia de segmentació de xarxa.

5. DNS híbrid

La resolució de noms és el punt que genera més incidències en entorns híbrids, i un dels menys planificats. Els equips de l’oficina necessiten resoldre els noms privats dels recursos al núvol, inclosos els endpoints privats dels serveis gestionats, i els recursos al núvol necessiten resoldre els noms del domini intern de l’oficina. Si no es configura, els clients resolen l’adreça pública del servei en lloc de la privada i el trànsit surt per internet o falla.

Criteri: reenviament condicional en tots dos sentits. Al núvol, mitjançant el servei de resolució híbrida del proveïdor (Azure DNS Private Resolver, Amazon Route 53 Resolver amb endpoints d’entrada i de sortida, zones de reenviament de Google Cloud DNS); a l’oficina, reenviadors condicionals als servidors DNS interns cap a aquests endpoints. Verificar la resolució des de tots dos costats abans de migrar cada servei.

6. Identitat i permisos

Al núvol, la identitat és el perímetre: qui obté credencials amb prou permisos pot crear, modificar o esborrar infraestructura completa des de qualsevol lloc. Les troballes habituals són comptes arrel o de propietari utilitzats en el dia a dia, credencials compartides entre diverses persones, claus d’accés de llarga durada en scripts i permisos d’administració assignats per comoditat.

• Identitat centralitzada, integrada amb el directori corporatiu quan n’hi ha, i MFA obligatori per a tots els accessos administratius.
• Compte arrel o de propietari protegit i reservat per a emergències.
• Permisos per rol amb mínim privilegi i revisió periòdica.
• Identitats de servei o rols per a les aplicacions, en lloc de claus estàtiques.
• Separació d’entorns en comptes, subscripcions o projectes diferents.

7. Backup i continuïtat

Que un servei s’executi al núvol no vol dir que les seves dades estiguin protegides. L’alta disponibilitat del proveïdor protegeix davant de fallades de la seva infraestructura, no davant d’un esborrat accidental, un error de configuració o un atac de ransomware que xifri o elimini les dades amb credencials legítimes. Una còpia emmagatzemada al mateix compte i amb els mateixos permisos que les dades originals es pot perdre en el mateix incident.

Criteri: definir RPO i RTO per servei i dissenyar les còpies en conseqüència: almenys una còpia separada de la infraestructura principal, en un altre compte, regió o proveïdor, amb immutabilitat o retenció bloquejada perquè no es pugui esborrar des de l’entorn de producció. El mateix s’aplica en sentit invers: els servidors locals han de tenir una còpia fora de l’oficina. I, sobretot, provar la restauració periòdicament: una còpia que no s’ha restaurat mai no és cap garantia.

8. Costos, govern i monitoratge

Al núvol, cada recurs oblidat continua facturant. Les desviacions de cost habituals vénen de màquines sobredimensionades, recursos de proves que ningú no elimina, discos i adreces IP sense associar, instantànies acumulades i transferència de dades de sortida no prevista.

• Etiquetatge obligatori per projecte, entorn i responsable, per saber què és cada recurs i de qui és.
• Pressupostos i alertes de cost configurats des del primer dia.
• Revisió periòdica del dimensionament segons l’ús real i eliminació de recursos orfes.
• Infraestructura com a codi perquè cada entorn sigui reproduïble i els canvis quedin registrats.
• Monitoratge unificat: estat dels túnels VPN, latència entre oficina i núvol, disponibilitat dels serveis i registres de flux de xarxa, integrats amb el monitoratge de la xarxa local.

Quan cal una intervenció especialitzada

En els nostres projectes de cloud i infraestructura híbrida dissenyem l’arquitectura completa: anàlisi de les aplicacions, pla d’adreçament, connectivitat amb l’oficina, xarxes virtuals segures, identitat, backup amb RPO i RTO definits i migració per fases sense aturar l’activitat, a Azure, AWS o Google Cloud.

Com que el núvol depèn de com hi arriba l’oficina, ho abordem juntament amb l’arquitectura de xarxa i la seguretat perimetral, i ho integrem en el monitoratge. Per a una valoració general de la seva infraestructura, pot fer servir el nostre autodiagnòstic de xarxa.