Skrbniška shramba in glavni ključ

S skrbniško shrambo prehod svoje obratovalne podatke – vire podatkov, pravila, dodelitve, osebe, ključe in pravilnik prijave – hrani v lastni datoteki namesto v konfiguracijski datoteki. Skrivnosti v njej so zapečatene, imena, pravila in dnevnik sprememb pa so berljivi. Spremembe začnejo veljati brez ponovnega zagona. Ta stran pojasni, kaj je shranjeno kje, kako spremembe začnejo veljati in kaj varuje glavni ključ.

• Spremembe veljajo brez ponovnega zagona, neveljavna različica pa se nikoli ne uveljavi.
• Nizi povezave in podatki za izračun kod 2FA (dvostopenjsko preverjanje identitete) so zapečateni; sama kopija datoteke ne odpre ničesar.
• Glavni ključ lahko zamenjate brez izgube podatkov, z dvema kratkima ponovnima zagonoma.
• Dnevnik prijav in dnevnik obremenitve sta v lastni datoteki dnevnikov z nastavljivo zgornjo mejo velikosti.

Obratovalni podatki potrebujejo prednosti datoteke in prednosti podatkovne zbirke hkrati. SQLite združuje oboje:

Iz tega izhajajo omejitve, opisane spodaj: en primerek na datoteko, samo lokalni disk in dnevnik sprememb, ki ni zaščiten pred ponarejanjem.

Z Gateway:Store prehod svoje obratovalne podatke hrani v lastni datoteki SQLite namesto v konfiguracijski datoteki. Sprememba v njej začne veljati brez ponovnega zagona.

{
  "Gateway": {
    "Store": {
      "Path": "store/gateway.db",
      "MasterKey": "env:WKL_GW_MASTER_KEY",
      "PollSeconds": 5
    }
  }
}

Prvi zagon. Če je shramba nova, prehod enkrat prevzame obratovalne podatke iz konfiguracijske datoteke – z vrednostmi, ki tam dejansko veljajo, torej tudi z nizom povezave iz spremenljivke okolja. Od tedaj odloča shramba. Če so v datoteki še vedno obratovalni podatki, jih zagon navede v opozorilu in jih ne uporabi. Za Security:SignInRules prehod ne opozori, čeprav tudi ta pravila od tedaj veljajo samo iz shrambe: sprememba pravil prijave v datoteki nima učinka. Shramba, v kateri so bili pozneje izbrisani vsi viri podatkov, vnosov iz datoteke ne prevzame znova.

Spremembe med obratovanjem. Prehod vsakih PollSeconds sekund SQLite vpraša, ali je v datoteko pisala kakšna druga povezava (PRAGMA data_version); pri tem ne bere podatkov. Šele po spremembi podatke naloži znova in rezultat preveri z enakim preverjanjem kot ob zagonu. Če rezultat preverjanja ne opravi, ostane v veljavi dosedanja različica, dnevnik pa navede vsako napako. Naložena različica se nikoli ne spreminja, temveč se zamenja kot celota. Vir podatkov, katerega nastavitve so ostale enake, obdrži že prebrani katalog; znova ga prebere le spremenjeni vir.

Viri podatkov po imenu in s stikalom. V shrambi je ključ ime, ne položaj. Vsak vir podatkov ima stikalo Enabled (uporabno tudi v konfiguracijski datoteki, privzeto true): onemogočen vir podatkov ostane skupaj z vsemi pravili, ki ga navajajo, njegovega aliasa pa prehod ne najde – zahteva dobi enak odgovor kot za neznan alias, noben seznam aliasov pa ga ne pokaže. Namenjeno je vzdrževanju ali selitvi podatkovne zbirke, ne da bi bilo treba brisati vnose.

Nizi povezave in podatki za izračun kod 2FA so zapečateni. Zaščiteni so z overjenim šifriranjem XChaCha20-Poly1305 – podključ, izpeljan s HChaCha20 iz prvih 16 bajtov 24-bajtnega enkratnika, nato ChaCha20-Poly1305 izvajalnega okolja .NET – iz lastne knjižnice za identitete (Wkl.Identity, CredentialProtection). Ključ se za vsak namen (DataSourceConnection, TotpSecret) izpelje iz MasterKey s HKDF, namen pa je vključen tudi v overjene podatke, tako da je zapečateno vrednost mogoče odpreti samo za njen namen. Glavni ključ nikoli ni shranjen v datoteki. Posledice:

• Sama kopija datoteke – varnostna kopija, priponka k zahtevku za podporo – ne odpre nobene povezave. Berljiva ostanejo imena virov podatkov, pravila in dodelitve.
• Z istim glavnim ključem datoteka deluje na vsakem računalniku (za selitev datoteko in ključ prenesete ločeno). Namenoma ni uporabljen DPAPI: ta se veže na računalnik ali račun in bi prav takšno selitev onemogočil.
• Če ključ ne ustreza ali je bila vrednost v datoteki spremenjena, preverjanje navede vsak prizadeti vir podatkov; zaradi načina šifriranja obeh vzrokov ni mogoče razlikovati.
• Če glavni ključ izgubite, so izgubljeni tudi nizi povezave. Hranite ga ločeno od varnostnih kopij datoteke.
• Vsaka vrednost navaja identifikator ključa, s katerim je bila zapečatena (oblika ovojnice 2 knjižnice za identitete). Identifikator in oblika sta prav tako overjena: spremenjen identifikator vodi v zavrnitev, nikoli v odpiranje z drugim ključem.

Primeren ključ je 32 naključnih bajtov v zapisu Base64:

[Convert]::ToBase64String([Security.Cryptography.RandomNumberGenerator]::GetBytes(32))

Datoteka in dostop. SQLite deluje v načinu WAL: ponovno nalaganje bere med pisanjem in vedno vidi stanje zadnje potrditve, eno branje pa zajame vse tabele v eni transakciji. Mapo in datoteko, ki ju ustvari prehod, smeta brati samo račun storitve in skrbniki računalnika (v sistemu Windows seznam za nadzor dostopa brez dedovanja s temi vnosi, drugod način 700/600). Skrbniki ta dostop potrebujejo za ukaze na strežniku; brez njega init-admin ne bi mogel odpreti shrambe prehoda, ki teče kot NetworkService. Če init-admin shrambo ustvari, preden je prehod sploh kdaj tekel, --service-account navede račun, pod katerim bo prehod tekel. SQLite ob datoteki zapiše še datoteki -wal in -shm; ti podedujeta pravice mape, zato shramba potrebuje lastno mapo. Če lahko obstoječo datoteko bere tudi kak drug račun, ga zagon navede v opozorilu in ničesar ne spremeni. Uporabljajte eno datoteko na primerek in samo na lokalnem disku: zaklepanje SQLite v omrežnih skupnih rabah ni zanesljivo.

Dnevnik prijav in dnevnik obremenitve sta v drugi datoteki SQLite poleg shrambe, v datoteki dnevnikov. Ta raste z uporabo; shramba sama ostane majhna ter se hitro znova naloži in varnostno kopira. Brez navedbe ima ime shrambe s pripono -logs in je v isti mapi – za store/gateway.db torej store/gateway-logs.db. Drugo mesto določa `Gateway:Store:LogPath`.

Osebe po oznaki. Datoteka dnevnikov osebo navaja z oznako njene vrstice v shrambi, ne z imenom: preimenovana oseba ohrani svojo zgodovino. Množice pokažejo trenutno ime; če osebe ni več, pokažejo # in oznako.

Velikost, ne starost. Datoteka ostane znotraj `Gateway:Store:LogMaxMegabytes` (privzeto 4096 MB). Ko mejo preseže, prehod enkrat na uro odstrani najstarejše vnose v tem vrstnem redu: posamezne počasne zahteve, posamezne dogodke prijave, dnevne vrednosti profilov, ugotovitve, nazadnje najstarejše dneve urnih vrednosti in obremenitve po osebi. Oblike in shranjeni namigi o obremenitvi ostanejo; teh je malo in ne navajajo oseb. Roki Gateway:SignInLog:HourDays in Gateway:LoadLog veljajo dodatno.

Dostop in varnostna kopija. Za datoteko dnevnikov veljajo enake pravice dostopa kot za shrambo. Vsebuje osebne podatke (naslove, osebe, čase), ne pa gesel ali ključev. backup-store jo kopira skupaj s shrambo; obe kopiji, vrnjeni druga ob drugo, se odpreta kot izvirnik.

Selitev iz prejšnje različice. Če je shramba dnevnike še hranila sama, jih prehod ob prvem zagonu enkrat preseli v datoteko dnevnikov in jih nato odstrani iz shrambe. Ugotovitve pravil prijave se začnejo z dogodki po selitvi; prejšnji dogodki se naknadno ne vrednotijo.

Skrbniška shramba pripada natanko enemu primerku prehoda. Dva primerka na različnih računalnikih si datoteke ne moreta deliti (brez omrežnih skupnih rab, glejte zgoraj), dva primerka na istem računalniku z isto datoteko pa nista podprta. Če poganjate več primerkov – na primer zaradi odpornosti na izpad –, ima vsak svojo shrambo in s tem svoje osebe, ključe in seje; usklajevanja med njimi ni. Odpornost dosežete z enim primerkom in varnostno kopijo, ki jo lahko obnovite (glejte Varnostno kopiranje, obnovitev in selitev skrbniške shrambe).

Vsaka sprememba prek skrbniškega vmesnika v isti transakciji zapiše vrstico v dnevnik sprememb (množica ChangeLog: čas, kdo, dejanje, množica, vrstica, vrednosti pred spremembo in po njej; zaupna vrednost, kot je niz povezave, samo kot opomba “(neu gesetzt)” (na novo nastavljeno), nikoli kot vrednost ali ovojnica). Prek vmesnika je dnevnik mogoče samo brati. Pred ponarejanjem namenoma ni zaščiten: kdor sme pisati v datoteko – račun storitve in skrbniki računalnika –, lahko spremeni tudi dnevnik; verige zgoščenih vrednosti ali podpisa ne vodi. Če potrebujete dokaz, ki ga skrbnik računalnika ne more spremeniti, ChangeLog sproti berite (številka strogo narašča) in ga zapisujte v dnevnik zunaj tega računalnika. Takšnega posredovanja prehod ne ponuja.

Za politiko hrambe in brisanja po Splošni uredbi o varstvu podatkov (GDPR; omejitev shranjevanja, člen 5(1)(e); pravica do izbrisa, člen 17) se shramba dejansko vede takole:

Osebe s sledmi se onemogočijo, ne izbrišejo. Dnevnik prijav in dnevnik obremenitve navajata osebo z oznako njene vrstice, dnevnik sprememb z njenim imenom. Če bi osebo izbrisali, bi ti vnosi kazali na nikogar – ali na poznejšo osebo z enakim imenom. Prehod zato izbris zavrne s 422, brž ko za osebo obstaja vsaj nekaj od naslednjega:

• osebni ključ ali seja, tudi preklicana ali potekla;
• posamezen dogodek v dnevniku prijav ali vnos v dnevniku obremenitve zanjo;
• vnos v dnevniku sprememb, ki ga je zapisala sama – kot izvajalec je tam njeno ime, njeno ime s ključem ali “(Selbstbedienung)”, njen račun Windows ali njena prijava SQL Server.

Vnosi, ki so jih o osebi zapisali drugi, na primer njeno ustvarjanje ali dodelitve pravil, niso sledi. Osebo, ki je bila ustvarjena, a nikoli uporabljena, je torej mogoče izbrisati. Osebe, ki so pustile vnose v dnevniku prijav ali dnevniku obremenitve, je mogoče izbrisati, ko so ti vnosi odstranjeni iz datoteke dnevnikov in drugih sledi ni več. Dnevne vrednosti njihovega profila in ugotovitve o njih lahko tedaj še obstajajo; osebo pokažejo kot # z oznako.

Posledica za izbrisane osebe. Vsaka sprememba osebe je zapisana v dnevniku sprememb z vrednostmi pred spremembo in po njej – vključno z imenom, računom Windows in e-poštnim naslovom. Po izbrisu osebe te vrstice ostanejo, prav tako njen identifikator kot izvajalec sprememb, ki jih je naredila sama. Roka, po katerem bi prehod vnose odstranil ali psevdonimiziral, ni. To je omejitev prehoda: politike brisanja, ki to zahteva, samo s prehodom ni mogoče izvajati. Mogoče je le od zunaj, z ustavljeno prehodom in orodjem za SQLite nad datoteko; pri tem se izgubita dokazna vrednost dnevnika in primerljivost s starejšimi varnostnimi kopijami, varnostne kopije pa vnose še vedno vsebujejo.

Zamenjavo glavnega ključa opisuje Zamenjava glavnega ključa, varnostno kopiranje, selitev in obnovitev pa Varnostno kopiranje, obnovitev in selitev skrbniške shrambe.

• Konfiguracija: Gateway:Store
• Ukazi na strežniku
• HTTP: skrbništvo