CA partajată, uși separate: un serviciu pe fișier de admitere

Un certificat validat față de o autoritate partajată a trecut un test de încredere, nu un test de apartenență. Aceste două decizii sunt adesea contopite pentru că ambele au loc la momentul conectării, iar contopirea rămâne invizibilă până când într-un serviciu este admis cineva care nu ar trebui să fie acolo. Soluția nu este o a doua autoritate; este o a doua decizie, luată pe serviciu și consemnată unde demonul o citește. Țineți cele două separate și cea mai mare parte a confuziei din acest domeniu dispare.

Un lanț de încredere nu spune nimic despre apartenența la serviciu

Două servicii pot accepta aceeași ierarhie emitentă și totuși avea populații diferite. Un laptop aparține primului și nu trebuie să ajungă la al doilea, în timp ce alți clienți ai aceleiași ierarhii aparțin într-adevăr acolo. Eliminarea autorității din acel serviciu ar bloca pe toți cei care îl folosesc legitim, așa că munca este de admitere, nu de încredere.

Ajută să ne imaginăm două lacăte pe o singură ușă. Certificatul deschide lacătul exterior, iar o decizie pe serviciu îl deschide pe cel interior; niciunul nu îl înlocuiește pe celălalt. Un serviciu cu doar lacătul exterior nu aplică deloc apartenența, doar autentifică. Notați ambele decizii înainte de a schimba ceva, pentru că o politică ce există doar sub forma unei conexiuni funcționale nu poate fi auditată. Ce urmează privește lacătul interior.

Transformați suprascrierile opționale într-o poartă de admitere

Un director de configurare a clientului este de obicei o comoditate: fișierele din el suprascriu setările clienților pe care îi numesc, iar un client fără fișier rulează pur și simplu cu valorile implicite ale serverului. O singură directivă transformă acea comoditate într-o poartă, astfel încât un fișier lipsă înseamnă că conexiunea este refuzată.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

Ediția comunitară a OpenVPN 2.6 ccd-exclusive documentează în pagina sa de manual exact această condiție, iar căutarea fișierului numit depinde de identitatea efectivă a clientului. Alte compilări și servere administrate de produse pot diferi, așa că verificați versiunea instalată înainte de a vă baza pe aceeași semantică în altă parte.

Tratați calea de mai sus ca exemplu și verificați aspectul efectiv implementat în loc să creați un director inventat de un ghid. Lăsați verificările de certificat, verificările identității serverului și autentificarea contului exact așa cum erau, pentru că fragmentul adaugă o condiție și nu elimină nimic. Pregătiți schimbarea înainte de producție, deoarece un refuz ridicat în locul greșit arată ca o defecțiune de certificat și trimite investigația către autoritate. Apoi confirmați că linia de jurnal pentru un client refuzat numește fișierul de configurare lipsă și nu lanțul.

Un director pe serviciu, nu o listă partajată

Apartenența aparține serviciului care o aplică, așa că fiecare serviciu își ține propriul director și propriile fișiere. Direcționarea a două servicii către o singură listă le face să împartă apartenența indiferent dacă cineva a intenționat asta sau nu, iar schimbarea rezultată este greu de urmărit până la o decizie. Autoritatea partajată poate rămâne partajată; fișierele de admitere nu pot. Păstrarea lor separate înseamnă și că o eroare într-un serviciu nu poate extinde în tăcere altul.

O intrare DEFAULT este cazul care îi induce în eroare pe oameni. Oferă setări de rezervă atunci când nu se găsește niciun fișier numit, dar nu este fișierul numit pe care îl cere poarta, așa că nu poate admite un client de una singură. Testați un client care nu are nicio intrare și confirmați refuzul; dacă acel client este admis, se aplică rezerva și ccd-exclusive nu este în vigoare în acea instanță.

Identitatea efectivă decide ce fișier este citit

Căutarea folosește identitatea cu care clientul s-a autentificat efectiv, care este de obicei numele comun al certificatului. Acolo unde serverul verifică și un nume de utilizator și o parolă și mapează acel nume la numele comun, fișierul trebuie să corespundă numelui de utilizator autentificat. O nepotrivire lasă un director plin de nume de fișiere plauzibile care nu sunt niciodată selectate.

Citirea este cealaltă jumătate. Demonul renunță de obicei la privilegii după pornire, așa că contul redus are nevoie de acces de citire la director și la fiecare intrare din el. Clienții nu trebuie să poată crea propria intrare prin nicio cale care permite scrierea, pentru că admiterea în regim self-service anulează complet mecanismul. Verificați permisiunile de montare și de partajare și nu doar modul fișierului, deoarece un director care pare închis pentru un cont poate fi deschis pentru altul. Apoi confirmați ce cont folosește efectiv procesul în execuție, și nu ce cont menționează fișierul unit. Cele două sunt identice doar când nimic altceva nu le-a schimbat.

Observați refuzul, admiterea și revocarea separat

Încercați o identitate care aparține serviciului și confirmați că se conectează. Încercați un certificat valid fără intrare și confirmați că este refuzat. Încercați o identitate admisă în celălalt serviciu și confirmați că aici nu este admisă. Notați instanța serviciului și identitatea efectivă lângă fiecare rezultat, pentru că un rezultat fără acel context nu poate fi reprodus de nimeni altcineva.

Retragerea este o operațiune separată de revocare. Editarea unui fișier de admitere elimină un drept pentru un serviciu în timp ce identitatea rămâne validă oriunde altundeva, pe când o cheie compromisă necesită răspunsul de revocare al organizației. Decideți dinainte ce se întâmplă cu sesiunile deja stabilite, pentru că nici editarea directorului nici lista de revocare nu le încheie de la sine.

Admiterea este și doar prima poartă. Aderarea la un serviciu nu spune nimic despre subrețelele, bazele de date sau interfețele de administrare din spate, iar acea politică de resurse trebuie scrisă și testată separat.