Profil OpenVPN v Gitu: kaj odstraniti pred potrditvijo

Profili služijo dvema namenoma hkrati: zapisujejo nastavitve povezave in nosijo delujoč niz poverilnic. Končnica datoteke vam ne pove ničesar o tem, katero od obeh imate v roki. Preberite vsebino, preden se odločite, da spada v shrambo.

Spodnji koraki predpostavljajo, da se obravnava predloga odjemalca za nadzor različic. Izvedite jih po vrsti in se ustavite, preden potrdite kar koli, česar ne morete preklicati.

Preberite datoteko, ki jo boste dodali v indeks

Začnite pri dejanskih bajtih, ker je profil, ki se sklicuje na ločene datoteke, videti povsem drugače kot tisti, ki jih vgradi. Poiščite oznake bloka PEM in vgrajene oznake z imeni ca, cert, key, tls-auth in tls-crypt, in isti pregled vam bo pokazal oba primera. Šifriran zasebni ključ še vedno šteje kot občutljivo gradivo, deljen ključ tls-auth ali tls-crypt pa je poverilnica, tudi če ni identiteta uporabnika. Enak pregled uporabite za vse, kar se doda v indeks skupaj s profilom, vključno z arhivi in namestitvenimi skripti, ki se sklicujejo na datoteko s poverilnicami.

Nato glejte pripravljeni niz, ne delovnega drevesa. git diff --cached pokaže, kaj bo potrditev v resnici vsebovala, in to je edina različica, ki je za to odločitev pomembna.

Odločite, kaj sme shramba razširjati

Predloga lahko nosi deljene, pregledane nastavitve in imenovana mesta za vse, kar oseba prejme ob vpisu. Česar ne more nositi, je uporabna identiteta, ker se shramba razširja vsem, ki jo lahko berejo, vključno z avtomatizacijo. Zasebna shramba zoži občinstvo, ne spremeni pa vprašanja, ali je vsak bralec pooblaščen za to poverilnico.

Pravilo prezrtja preprečuje prihodnje dodatke in ne naredi ničesar glede tega, kar je že zapisano. To asimetrijo je vredno ponotranjiti pred prvim potrditvijo in ne po deseti. Imena in naslovi infrastrukture so ločena presoja: niso avtentikacijske skrivnosti, lahko pa razkrijejo več, kot namerava ekipa objaviti. To odločitev sprejmite izrecno, namesto da bi vsako vrstico razvrščali med geslo ali javno.

Če je gradivo že v zgodovini

Odstranitev vrstice v novi potrditvi pusti staro različico nedotaknjeno za vsakogar, ki jo prenese. Izpostavljenost obravnavajte kot resnično: določite vrsto poverilnice in nato poiščite organ, ki jo lahko razveljavi. Odjemalski certifikat se prekliče in seznam preklicanih se znova ustvari; deljeni ključ krmilnega kanala se zamenja na strežniku in pri vsakem odjemalcu, ki ga uporablja.

Oba imata zelo različen doseg, in načrt bi moral pred začetkom navesti, katerega izvajate. Poiščite potrditev, ki je vnesla gradivo, s preiskavo vrste git log --all -S 'BEGIN PRIVATE KEY', da bo obseg čiščenja znan in ne ugiban. Kolegov klon ali razvejanje lahko že hrani stari objekt, zato preklic pride prvi, čiščenje pa drugo.

Počistite šele po omejitvi

Prepis zgodovine spremeni vsako potrditev po tisti, ki jo urejate, zato najprej potrebuje soglasje lastnika shrambe in ljudi, ki v njej delajo. Prisilni push ni popravilo; je usklajevalni dogodek z lastnim tveganjem razveljavitve. Načrtujte ga, naredite varnostno kopijo in ekipi povejte, kdaj se bo zgodil.

Nato preverite trenutno drevo in preostalo zgodovino, namesto da bi zaupali povzetku orodja.

Rezultat shranite kot dva artefakta: predlogo, ki je varna za deljenje, in seznam poverilnic, izdanih med postopkom vpisa. Nobeden od njiju ne zahteva, da v shrambi živi uporabna identiteta.

Ta ločitev je pravo popravilo in preživi naslednjo osebo, ki bo želela potrditi profil.