Dispositiu de camp, TLS i VPN: quina frontera protegeix què

Un dispositiu de camp obre una connexió a un servei i la pregunta de disseny arriba com una tria entre VPN i TLS. Aquest plantejament és erròni, perquè tots dos fan feines diferents. TLS autentica el punt final de l’aplicació i protegeix la conversa; mentre que una VPN controla l’abastabilitat i protegeix els paquets entre iguals. Recorreu la connexió des del dispositiu cap enfora i cada capa té la seva resposta.

Si no podeu dir on acaba TLS, no podeu dir què confia realment l’aplicació.

Trobeu on acaba realment TLS

Comenceu per l’aplicació del dispositiu i seguiu la connexió fins al procés que completa l’apretada de mans. Si un proxy acaba TLS abans del mainframe, el camí protegit acaba al proxy. El salt restant necessita la seva pròpia protecció documentada.

Anomenar-ho d’extrem a extrem per suposició és com una revisió de disseny aprova un forat. Dibuixeu el punt d’acabament i l’àncora de confiança al mateix diagrama.

TLS transporta peticions i respostes en tots dos sentits, així que una aplicació bidireccional no necessita inherentment una VPN en lloc de TLS. El revés també és cert: un desplegament pot necessitar encara una VPN per a altres protocols al mateix dispositiu.

Decidiu què ha d’autenticar el dispositiu

Configureu la validació de la identitat del servidor i les arrels de confiança previstes. Si cada dispositiu ha de provar la seva pròpia identitat, trieu un model d’autenticació de client compatible i inscriviu una credencial diferent per dispositiu. Les credencials compartides converteixen un sol dispositiu robat en un problema per a tota la flota.

Planifiqueu la protecció de claus, la renovació, la revocació i la recuperació abans de l’enviament. Un dispositiu al camp que no es pot tornar a inscriure després d’una renovació fallida es converteix en una visita tècnica, i aquest cost dona forma al disseny més que l’apretada de mans.

Utilitzeu una biblioteca compatible i les directrius actuals. Directrius modernes de desplegament de TLS prohibeixen negociar TLS 1.0 i 1.1, i una referència a TLSv1 en una nota de disseny antiga no és un requisit.

Tanqueu quan falla l’apretada de mans

Una apretada de mans fallida o una comprovació d’identitat fallida no ha de tornar en silenci al protocol de text clar original. Aquest retrocés és la vulnerabilitat que la feina de TLS havia de tancar. Feu visible la fallada per a l’operador del dispositiu i per al servei, i exigiu el canal protegit per a les operacions sensibles. Després deixeu que l’autorització de l’aplicació decideixi què pot fer un dispositiu autenticat.

Definiu la vida de la connexió, l’emmarcament, els temps d’espera i el comportament de reintent com a part del contracte. El xifratge no fa segura una ordre repetida, i un reintent després d’una operació anterior incerta necessita una resposta a nivell d’aplicació.

Escriviu la regla de retrocés. «Es reconnecta sense TLS si falla l’apretada de mans» és una decisió de disseny, i hauria de ser explícita.

Doneu a la VPN només la feina que pot fer

Una VPN pot restringir l’abastabilitat i protegir els paquets fins al seu igual. TLS protegeix la relació de l’aplicació amb el punt final seleccionat. Els seus punts d’acabament poden diferir, i cap dels dos protegeix les dades emmagatzemades del punt final ni l’accés administratiu.

Mesureu el cost de l’apretada de mans, la missatgeria estable i la reconnexió al dispositiu real en lloc de suposar que un mecanisme és més ràpid. Després proveu els quatre casos que importen: l’intercanvi previst, una identitat de servidor incorrecta, un dispositiu no autoritzat i una reconnexió després d’una operació incerta. Anoteu el resultat de cada cas, incloent-hi l’error que mostra el dispositiu.