TLS natiu, reenviament SSH o VPN per a un servei al núvol

La pregunta poques vegades és si cal xifrar alguna cosa entre dues màquines al núvol; és quina interfície xifreu i qui comprova la identitat de qui. Començo aquestes converses pel servei i no pel diagrama de xarxa, perquè el servei ja sap què necessita. Tres fronteres cobreixen la majoria de casos: el TLS propi de l'aplicació, un únic port TCP reenviat per SSH i una superposició enrutada que dona una adreça a cada participant. No s'ordenen per força, sinó per quant del problema cobreixen.

Comença pel servei, no per la xarxa

Avanceu des del procés cap enfora. Quin protocol parla, quin nom verificarà el client i qui pot obrir una connexió? Aquestes tres respostes eliminen opcions més de pressa que qualsevol taula comparativa, i la configuració pròpia del servei normalment les respon en un parell de minuts.

Agafeu una API interna petita que ja serveix HTTPS al port 8443 amb un certificat per a api.internal.example. ss -ltnp a l'amfitrió mostra a què s'enllaça, i openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example mostra si el certificat valida per al nom que el client farà servir realment. Si tots dos són sans, el servei pot protegir el seu propi flux i només queda l'abast. Això és un problema molt més petit que construir una xarxa.

Pas 1: el servei es protegeix a si mateix?

Aquesta és l'opció a prendre quan encaixa, i encaixa més sovint del que els equips assumeixen. El xifratge del servei cobreix tot el camí entre client i servidor, incloent-hi cada salt intermedi, cosa que cap túnel al voltant del mig millora. Configureu el nom esperat i la confiança explícitament en lloc de confiar en el que contingui per casualitat el magatzem per defecte del client.

El xifratge i l'abast segueixen sent controls separats, i fusionar-los és on aquesta opció falla. Un servei TLS en un oient públic sense restriccions encara accepta intents de connexió de qualsevol, així que l'oient i les regles de xarxa s'han d'abastar independentment del fet que la càrrega estigui protegida. Després comproveu les dependències, perquè una API sobre TLS no diu res sobre el punt de descoberta, el port d'administració o el canal de transferència massiva del costat. Cadascun necessita la seva pròpia resposta, i un germà desprotegit n'hi ha prou per convertir tota la frontera en una ficció.

Pas 2: un sol port TCP és tot el requisit?

Quan el requisit és realment un sol port TCP, un reenviament és la cosa més petita que funciona. Un reenviament local SSH porta aquest port per una connexió autenticada que ja existeix.

La forma és ssh -N -L 8443:127.0.0.1:8443 [email protected], i el detall que importa és l'adreça de destinació: 127.0.0.1 es resol al costat remot, així que la connexió al servei s'obre des del bastió i no des del vostre portàtil. Enllaceu l'oient local estretament com a -L 127.0.0.1:8443:... per no publicar el servei a la vostra xarxa local per accident. Al costat del servidor, limiteu què pot reenviar el compte en lloc de confiar que el client es comporti bé. PermitOpen, AllowTcpForwarding local i un GatewayPorts no per defecte són els tres paràmetres que converteixen un relé genèric en un canal concret.

El contracte és estret en totes dues direccions. SSH protegeix el seu propi canal, i un salt addicional del bastió a una altra aplicació necessita la seva pròpia protecció. Un servei que només escolta al loopback del bastió té una exposició molt diferent d'un al qual s'arriba per una altra xarxa, i el reenviament no ho canvia. Mantingueu l'autenticació i les comprovacions TLS de l'aplicació en lloc de tractar el túnel com a substitut.

Això funciona bé per a una connexió amb un propietari. A escala es converteix en un sistema: conflictes de ports locals, supervisió, rotació de claus i la pregunta de qui reinicia el reenviament després d'un reinici.

Pas 3: l'enrutament és el requisit real?

Aquesta llista és el cost honest de l'opció més petita, i per això els equips acaben substituint un grapat d'ordres de fons oblidades per una cosa gestionada. La substitució no és automàticament una VPN. Si el requisit continua sent un sol port TCP, un reenviament supervisat amb un propietari documentat és més barat d'executar que una superposició i falla de maneres que podeu veure. Mesureu la propietat operativa abans de mesurar l'elegància.

L'enrutament es converteix en la resposta correcta quan l'enrutament és el requisit. Diverses aplicacions que necessiten connectivitat IP corrent, protocols que un reenviament TCP no pot portar o serveis que es mouen entre amfitrions apunten tots en la mateixa direcció.

Una superposició dona als participants una adreça i una ruta, i llavors comença la feina real: rangs que no se solapen, propietat de rutes, DNS, inscripció, revocació i què passa quan un pare desapareix. Res d'això arriba amb l'adreça. Un pare admès a la superposició tampoc no està autoritzat automàticament per a cada operació a la destinació, així que l'autenticació a nivell de servei es manté.

Què posseeixes després

Dues coses pertanyen al registre que deixeu. La primera és la identitat que s'espera que el client verifiqui, perquè cadascuna d'aquestes fronteres es degrada en silenci quan es relaxa una comprovació de nom per fer funcionar alguna cosa. La segona és el pas de retirada: quina clau, quina regla o quina ruta desapareix quan acaba l'accés, i qui ho fa.

El recorregut acaba on va començar, al servei. Trieu la frontera que cobreix el trànsit real i verifica els pars que volíeu verificar, i després anoteu com s'actualitza, es monitora i es retira l'accés. La referència d'OpenSSH és el lloc per confirmar les opcions de reenviament abans de prometre un contracte estret. Si no podeu descriure el pas de retirada en una frase, la frontera és més gran que el problema.