Waarom bediener-sleutels en gebruikersbewyse aparte eienaars nodig het

Die sleutel wat bewys dat jou poortwag homself is, en die bewys dat ’n persoon mag aansluit, is albei geheime, en dit is waar die ooreenkoms eindig. Die een identifiseer ’n diens teenoor elke kliënt; die ander identifiseer een gebruiker teenoor daardie diens. Om hulle te vermeng spaar ’n stap tydens die opstelling en kos ’n middag tydens ’n voorval, want die herstel vir elkeen is nie dieselfde bewerking nie. Die skeiding is vervelig om op te stel en onthoubaar om oor te slaan.

Twee geheime, twee verskillende eienaars

Die poortwag hou ’n private sleutel of sertifikaat waarvan die enigste taak is om sy identiteit tydens die handdruk te bewys. Kliënte het die ooreenstemmende publieke materiaal nodig om dit te verifieer, en hulle het nooit die private helfte nodig nie. Daardie asimmetrie maak bediener-verifikasie moontlik sonder om elke gebruiker die vermoë te gee om die bediener na te boots.

Gebruikersmateriaal is die ander rigting. ’n Kliënt se private sleutel, ’n kliëntsertifikaat of ’n wagwoord wys dat hierdie bepaalde persoon of toestel toegang gekry het. Dit word verwag om versprei te word, tussen toestelle gekopieer te word en uiteindelik ingetrek te word.

WireGuard maak die skeiding duidelik omdat elke deelnemer ’n sleutelpaar het: die bediener se private sleutel bly op die bediener, en ’n konfigurasielêer wat jy aan ’n gebruiker gee, bevat hul eie private sleutel plus die bediener se publieke sleutel. ’n Profiel wat die bediener se private sleutel bevat, is nie ’n kortpad nie, dit is ’n kompromie wat op ’n lêerdeling wag.

Drie vrae wat die skeiding bepaal

Vra wie die geheim moet kan lees, wat ’n blootstelling ’n aanvaller sou laat doen, en of die oplossing een intrekking of ’n herbou van die diens is.

As ’n gebruiker dit kan lees en dit bewys die poortwag se identiteit, is die antwoord op die tweede vraag dat die aanvaller jou bediener teenoor elke kliënt kan naboots — die slegste uitkoms, want kliënte is ontwerp om daardie identiteit te vertrou. As dit net een gebruiker bewys, gee die blootstelling daardie gebruiker se toegang tot een eweknie, en intrekking is ’n roetine-bewerking. As dit ’n sertifikaatowerheid-sleutel is, is blootstelling slegter as albei, want die aanvaller kan identiteite skep wat elke eindpunt vertrou.

Daardie drie antwoorde lewer die stoorreël: die CA-sleutel woon vanlyn of in ’n kluis, die poortwag-sleutel woon op die poortwag, en gebruikersleutels woon by gebruikers. Enige uitleg wat al drie in een gids vir gerief plaas, het ’n besluit in ’n ongeluk laat ontaard.

Wat ’n kliënt werklik nodig het

’n Kliënt het die publieke sertifikaat of publieke eweknie-sleutel nodig, die CA-materiaal of vingerafdruk wat dit moet vertrou, sy eie private sleutel en die eindpunt-besonderhede. Daardie lys bevat niks wat aan die poortwag se private identiteit behoort nie.

Dokumentasie is waar dit uitlek. ’n Gids wat sê jy moet die bediener-gids kopieer en uitvee wat jy nie nodig het nie, het alreeds die verkeerde model geleer, want die lêer wat ná die uitvee-stap oorbly, word selde deur iemand nagegaan.

Trek een gebruiker in sonder om aan die poortwag te raak

Omdat gebruikersidentiteite apart uitgereik word, kan hulle apart teruggetrek word. ’n Sertifikaat-gebaseerde ontplooiing trek die kliëntsertifikaat in en publiseer ’n bygewerkte intrekkingslys; ’n WireGuard-ontplooiing verwyder die eweknie-inskrywing uit die bediener-konfigurasie. Nie een van daardie bewerkings verander die poortwag se eie sleutel nie.

Hou die uitreikingsrekord, anders sal jy nie weet watter identiteit om terug te trek nie. ’n Sigblad is genoeg, mits dit die persoon, die toestel, die reeksnommer of publieke sleutel en die datum noem, en mits iemand dit besit nadat die persoon wat dit gebou het, vertrek.

Die opdragte hieronder ondersoek ’n kliëntsertifikaat en trek dit dan in deur ’n OpenSSL-agtige owerheid, wat die vloei is wat easy-rsa omhul:

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

Publiseer die nuwe lys waar kliënte dit nagaan, anders is die intrekking ’n nota in ’n lêer wat niks verander nie. As jou poortwag kliëntsertifikate aanvaar sonder om ’n intrekkingslys te raadpleeg, sê dit uitdruklik eerder as om te impliseer dat intrekking werk.

Hou rugsteune so apart soos die geheime

’n Herbou-argief bevat wettiglik die poortwag-sleutel en die CA-materiaal, want sonder hulle kan ’n herstel nie die diens herproduseer nie. ’n Kliënt-opstelpakket mag dit nie bevat nie, en die twee mag nie saam gestoor word nie. Merk elke argief volgens wie dit mag hou, nie volgens die datum waarop dit gemaak is nie. Daardie etiket is wat ’n moeë administrateur twee in die oggend lees.

Daardie onderskeid bepaal ook wie elkeen mag ophaal. Die poortwag bestuur, gebruikersidentiteite uitreik en rugsteune lees is drie verskillende magte, en ’n persoon wat een nodig het, het nie outomaties die ander nodig nie. Skryf daardie toestemmings neer en kontroleer dit dan teen wat jou stoorkeuse werklik toelaat, want gids-erfenis verleen stilweg meer as wat die beleid bedoel.