De ce cheile serverului și acreditările utilizatorilor au nevoie de proprietari separați

Cheia care dovedește că gateway-ul tău este el însuși și acreditarea care spune că o persoană se poate alătura sunt ambele secrete, și acolo se termină asemănarea. Una identifică un serviciu în fața fiecărui client; cealaltă identifică un utilizator în fața acelui serviciu. Amestecarea lor economisește un pas la configurare și costă o după-amiază în timpul unui incident, pentru că recuperarea fiecăreia nu este aceeași operațiune. Separarea este plictisitoare de configurat și memorabilă de omis.

Două secrete, doi proprietari diferiți

Gateway-ul păstrează o cheie privată sau un certificat a cărui singură sarcină este să își dovedească identitatea în timpul strângerii de mână. Clienții au nevoie de materialul public corespunzător pentru a-l verifica și nu au niciodată nevoie de jumătatea privată. Această asimetrie face posibilă autentificarea serverului fără a da fiecărui utilizator capacitatea de a imita serverul.

Materialul utilizatorului merge în direcția opusă. O cheie privată de client, un certificat de client sau o parolă arată că acestei persoane sau acestui dispozitiv i s-a acordat acces. Se așteaptă să fie distribuit, copiat între dispozitive și în cele din urmă revocat.

WireGuard face separarea evidentă pentru că fiecare participant are o pereche de chei: cheia privată a serverului rămâne pe server, iar un fișier de configurare pe care îl dai unui utilizator conține propria cheie privată plus cheia publică a serverului. Un profil care conține cheia privată a serverului nu este o scurtătură, ci o compromitere care așteaptă o partajare de fișiere.

Trei întrebări care decid separarea

Întreabă cine trebuie să poată citi secretul, ce i-ar permite unui atacator o expunere și dacă remedierea este o singură revocare sau o reconstrucție a serviciului.

Dacă un utilizator îl poate citi și acesta dovedește identitatea gateway-ului, răspunsul la a doua întrebare este că atacatorul poate imita serverul tău în fața fiecărui client — cel mai rău rezultat, pentru că clienții sunt proiectați să aibă încredere în acea identitate. Dacă dovedește doar un utilizator, expunerea îi acordă acelui utilizator acces la un peer, iar revocarea este o operațiune de rutină. Dacă este o cheie de autoritate de certificare, expunerea este mai rea decât ambele, întrucât atacatorul poate crea identități în care fiecare punct final are încredere.

Aceste trei răspunsuri produc regula de stocare: cheia CA trăiește offline sau într-un seif, cheia gateway-ului trăiește pe gateway, iar cheile utilizatorilor trăiesc la utilizatori. Orice aranjament care le pune pe toate trei într-un singur director pentru comoditate a transformat o decizie într-un accident.

De ce are nevoie de fapt un client

Un client are nevoie de certificatul public sau de cheia publică a peer-ului, de materialul CA sau de amprenta în care trebuie să aibă încredere, de propria cheie privată și de detaliile punctului final. Lista nu conține nimic ce aparține identității private a gateway-ului.

Documentația este locul unde se scurge acest lucru. Un ghid care spune copiază directorul serverului și șterge ce nu ai nevoie a predat deja modelul greșit, pentru că fișierul care rămâne după pasul de ștergere este rareori verificat de cineva.

Revocă un utilizator fără să atingi gateway-ul

Deoarece identitățile utilizatorilor sunt emise separat, ele pot fi retrase separat. O implementare bazată pe certificate revocă certificatul de client și publică o listă de revocare actualizată; o implementare WireGuard elimină intrarea peer-ului din configurația serverului. Niciuna dintre aceste operațiuni nu schimbă cheia proprie a gateway-ului.

Păstrează registrul de emitere, altfel nu vei ști ce identitate să retragi. O foaie de calcul este suficientă, cu condiția să numească persoana, dispozitivul, numărul de serie sau cheia publică și data, și cu condiția ca cineva să o administreze după ce persoana care a construit-o pleacă.

Comenzile de mai jos inspectează un certificat de client și apoi îl revocă printr-o autoritate în stil OpenSSL, care este fluxul pe care easy-rsa îl împachetează:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

Publică lista nouă acolo unde clienții o verifică, altfel revocarea este o notă într-un fișier care nu schimbă nimic. Dacă gateway-ul tău acceptă certificate de client fără să consulte o listă de revocare, spune asta explicit în loc să sugerezi că revocarea funcționează.

Păstrează copiile de siguranță la fel de separate ca secretele

O arhivă de reconstrucție conține în mod legitim cheia gateway-ului și materialul CA, pentru că fără ele o restaurare nu poate reproduce serviciul. Un pachet de instalare pentru client nu trebuie, iar cele două nu trebuie păstrate împreună. Etichetează fiecare arhivă după cine o poate păstra, nu după data la care a fost făcută. Acea etichetă este ceea ce citește un administrator obosit la două dimineața.

Această distincție stabilește și cine poate recupera fiecare. Administrarea gateway-ului, emiterea identităților de utilizator și citirea copiilor de siguranță sunt trei puteri diferite, iar cine are nevoie de una nu are automat nevoie de celelalte. Notează aceste permisiuni și apoi verifică-le față de ceea ce permite de fapt stocarea ta, pentru că moștenirea directoarelor acordă în tăcere mai mult decât intenționează politica.