Logolás sértetlenség biztosításával

Fórumok

Sziasztok

 

Különböző felhasználó interakciókat kellene eltárolnom, amit 5 év után is bizonyítani tudjak, hogy mit csinált vagy nem csinált.

Ezek részben adatvédelemmel összefüggő cselekmények, pl. bepipálta-e az adott elfogadom checkbox-ot, ő töltött-e fel az adott fájlt, stb.

Erre kevés egy adatbázis adott cellája, ahol 0-t 1-re váltok, mert ki mondja meg, hogy nem módosították?

 

Gondolom logolni kellene ezeket az eseményeket folytatólagos logban és szavatolni, hogy a logot ne lehessen módosítani.

Mi ennek a szép, IT életben bejáratott megoldása?

Minden nap vagy óránként rotálom a logot és checksumot készítek belőle? A logot meg a checksumot 2 elkülönített helyre elteszem?

Sosem kellett ennyire rágörcsölni a témára, de most igen. Nincs ilyenben rutin, de nem találnám fel a kereket.

Tudtok adni pár kulcsszót, bevált elvet erre?

Ha a logolással rossz irányban mentem el, jöhet sql oldalról is bevált módszer.

 

Köszönöm szépen!

Hozzászólások

Blockchain :)

“The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.”

Szerkesztve: 2021. 09. 20., h – 12:34

Egyszer _régen_ csinált valaki olyat, hogy sornyomtató és leporelló. Na abba nem lehetett belenyúlni. A tárolás és a feldolgozás elég macerás lehetett.

2021-ben nyilván csak napi humornak szántam.

a Paksi atomerőmű egyik irányítótermében láttam ilyet, ugyan nem mostanában, de már bőven az után, hogy az ilyen nyomtatók már máshonnan eltűntek. 

“The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.”

a strukturalt adatot ellatod idobelyegzovel, majd alairatod vagy alairod digitalisan, mint pl. ahogy az e-szamlaban az xml-t

neked aztan fura humorod van...

5 év után is bizonyítani tudjak

Ki felé kell bizonyítani?
Az a fél mit fogad el hitelesnek?

Gondolom a NAIH felé kell bizonyítani.

A szolgáltatás megrendelése és teljesítése 10-15 év kifutású is lehet és felmerült, mi van ha a megrendelő kritizálja a korábban elfogadott ÁSZF-et és a NAIH felé keres jogorvoslatot. Ebben az esetben bizonyító erejű megoldás kell.

A projekt kitalálója megbízott egy adatvédelmi és információbiztonsági szakértőt is, aki azért felel, hogy olyan műszaki megoldások és jogi ÁSZF, adatvédelmi dokumentumok legyenek, hogy be legyen védve a projekt gazdája, tulajdonosa. Na ez a szakértő vetette fel ezt a problémát és megoldást, de úgy, mintha triviális volna. Én tizen sok év alatt nem találkoztam ilyennel a tényleges gyakorlatban, de akkor úgy látom másnál sem tipikus elvárás.

Egyébként egy speciális, hosszú kifutású webes szolgáltatásról van szó. Viszont sikerült olyan adatvédelmi csapatot találni, aki nálam is paranoidabb, de durván.

Ez szépen hangzik, mint követlemény, azonban ezt a gyakorlatban még a legnagyobb bankok sem tudják igazából biztosítani.

Ők is megelékszenek azzal, hogy egy tanúsított rendszerre kerülnek a logok, és innentől elhiszik (csak egy egyszerű checksum van a palyload mellet, ugyan azon a diszken :) hogy az ott van, és senki nem módosítja...

Lehet még külsős időbélyegekkel is ellátni mindezt, de ehhez meg külső szolgéltató kell, ami további macera, és pénz. legtöbbször nem is rentábilis a dolog.

Szerkesztve: 2021. 09. 20., h – 13:14

Mi csinálunk ilyet - HAR (hosszútávú archiváló rendszer, LTV - Long Term Validation)  2 cégtől időbélyeggel ellátott csomagokba rakjuk napi 2-4millió rekord/xml, beküldő adatok aláírás tanusítvánnyal vannak ellátva -> NAV.

Mi szt csináltuk 2013-ban, hogy minden sor tartalmazta az előző sor hashét is, hogy ne lehessen közéjük új sort beszúrni, és minden sort külön aláírtunk digitálisan.

Nem sok értelme volt, de ezt kérték, ezt kapták.

Ma már valószínűleg valamilyen (H)MAC-alapú megoldást keresnék, ha nem ragaszkodunk az aszimmetrikus megkötéshez.

Rosszindulatú rendszergazda be tud állítani az igazi rendszer mellé N darab kamu logokat előállító rendszert, ami ugyanúgy "hiteles" lesz, és ha valamit bizonyítani kell, rögtön tudsz bizonyítani bármit meg annak az ellenkezőjét is.

Azt kellene előbb definiálni, hogy ki számít rosszindulatúnak, és kiben lehet megbízni, aki egyrészt hiteles bizonyítékot szolgáltat neked, és esetleg láthatja a logok tartalmát is.

Ha tényleg teljesen független rendszerre logol, azt el szokták fogadni önmagában is, de jó lenne látni az igényt, mert határ a csillagos ég:

Blockchain, időbélyeg, WORM-ra archiválás

A frontend egy webtárhely, itt generálódik az adat.

A backend egy NAT mögött lévő szerver lesz, ami lehúzza az adatokat és sok évig tárolja. A szerver nyúl ki a webtárhelyhez és soha nem fordítva. Alapból más adatok tárolására találtuk ki, de egyre merülnek fel olyan adatok, amiket hitelesen kellene tárolni. Így gondoltam a védett hálózatban lévő szerver alkalmas lehet rá.

Úgy gondolom, ha én valamilyen sql-ből kinyert adatot letárolok ott, az 10 év múlva is úgy lesz ott. Kérdés elfogadja-e a tisztelt hivatal, hogy nem magamat kompromittáltam meg, hogy igazam legyen az ügyféllel szemben? Vizsgálja-e a hatóság ezeket az eseteket, kell-e magammal szemben is valami hitelességet biztosítanom. 

Elindulunk a lejtőn és jól bele lehet csavarodni :)

Nyugi, ne gondold túl. Az átadott log jóságát a szavad hitelesíti, ha belenyúlsz az onnantól BTK. Igazából ha nincs jogszabályod ami definiálja mitől lenne hiteles a log, mindegy mit csinálsz, hitvita lesz hogy az jó e (szinte kizárt hogy tényleg jó szakértőt kapj, a többiek meg azt nézik mennyire konzisztens amit mondasz). Legyen olyan amit szakmailag jónak tartasz és a rendszer értéke mellett nem csillagháborús. 

Köszi, ez mondjuk jelentősen leegyszerűsíti a problémát. Felvetem a szakértő felé. Ha nem köt bele, a NAT mögötti szerver lesz a hitelesnek tekinthető szerver, hiszen kívűlről nem törhető. Harmadik fél által elérhető szolgáltatás nem fut rajta.

Sylog-ng -nek van egy logstore nevu destination -ja, ami titkositott es idobelyegzett tud lenni. Mi is hasznaljuk, es mindig elfogadja az auditor ezt a technologiat.

De ha olyat kell bizonyitanod, hogy valaki beikszelte a beixelnivalot (nyelvtannaci trigger fired) akkor addig ne engedd tovabb a web oldalon a submit gombot amig nincs ott a pipa, es termeszetesen szerver oldalon is ellonirzd. Ha ezt a kodot le tudod tenni idopecsetes mentesbe, hogy marpedig akkor ez mukodott, akkor nincs vita, hogy mondjuk egy regisztracional valaki nem fogadta el az ASZF -t.

De majd egy jogasz megmondja, hogy ez eeleg-e, hiszen ha meg elrakod a joember nevet, cimet, kattintasat, akkor meg johet a GDPR szopattyu, hogy felejtesi jog, magyaran nyulj legyszives vissza a 4 eve WORM szalagra kiirt idopecsetelt adathalmazhoz amit ugye modositas ellen talaltak fel, es torold ki belole a Gipsz Jakabot, mert mar ugyveddel az oldalan uvoltozik a recepcion. Egy ora mulva kesz, ugye? :-)

"addig ne engedd tovabb a web oldalon a submit gombot amig nincs ott a pipa, es termeszetesen szerver oldalon is ellonirzd. Ha ezt a kodot le tudod tenni idopecsetes mentesbe, hogy marpedig akkor ez mukodott"

Ez volt a másik tippem. A szakértő szerint járható, csak el kell tennem minden módosítást és megőrizni akár 15 évig is. 

Kettő dolog kell: használható logüzenetek, meg egy aláírásra alkalmas, logokat tartalmazó termék, mondjuka One Identity (Balabit) syslog-ng Store Box. Vagyis 3, mert még elő kellnfizetni valamely 3rd party timestamp szolgáltatásra is.

Szerkesztve: 2021. 09. 20., h – 15:53

-

Hat en is betolnam valami kozpontiba (amire rengeteg megoldas van: ElasticSearch, talpas rsyslog, Splunk). A kerdes az, hogy mitol lesznek hitelesek a sorok. Hitelesiteni kell a kuldot (tls, api key, etc) es magat a sort is (itt mar felemrul hogy ket helyre kell akkor kuldeni es a ket helyet nem adminisztralhatjak ugyanazok). Aztan authorizalni (rbac:mihez fer hozza es abac:melyik mezohoz fer hozza valaki) es auditalni kell a logokhoz valo hozzaferest is.

Es akkor nem beszeltunk meg arrol, hogy milyen felhasznalasi terulete van ezeknek a nem strukturalt, semanelkuli adatolknak (sql szeruen akarja valaki lekerdezni vagy csak siman fulltext search)