"Hiteles" naplózás.

Java

Sziasztok!

Van e arra valami lehetőség, hogy a napló állományokat valamilyen módon hitelessé lehessen tenni.
Pl. ha a megrendelő mindenre kiterjedő jogot szeretne kapni az alkalmazás felett, tehát írási joga is van a napló állományokra, akkor valamilyen módon lehessen garantálni, hogy a napló bejegyzéseit nem írhatja át vagy ha átírta akkor az derüljön ki.

  • 1102 megtekintés

( nxu | 2017. 04. 05., sze – 14:16 )

Valamilyen aszimmetrikus kulcsos megoldás szóba jöhet, de ha a "mindenre kiterjedő jog"-ba beletartozik a privát komponenshez való hozzáférés is, akkor veszett fejsze nyele.

Az aszimmetrikus kulcsos megoldáson én is gondolkodtam, illetve azon hogy valamilyen algoritmussal egy ellenőrző összeget generálok és hozzá fűzöm a log bejegyzéshez, így az olvasható marad, az ellenőrző összeggel meg meg tudom állapítani hogy megváltoztatták e. Viszont itt még mindig fen áll az a lehetőség, hogy kitöröl sorokat a logból.
Erre lehetne megoldás, a 2 állomány párhuzamos kezelése, egyikbe a log bejegyzés a másikba az ellenőrző összeg. Illetve egy számláló hogy hány log bejegyzés van, mert ha elég ügyes akkor még mindig ki tud törölni sorokat a két párhuzamos állományból.
Csak ez a megoldás lehet elég költséges, kérdés mennyi erőforrást igényel, az aszimmetrikus megoldás vagy az ellenőrző összeg generálása, illetve a két fájlba való írás.

Szerintem ha görgetve számolsz egy kriptográfiai hasht (m5 vagy SHA-1 :-), és azt a keletkezés pillanatában - kvázi azonnal - egy általad menedzselt gépre továbbítod, az elegendő arra, hogy ha esetleg belepiszkáltak, akkor azt utólag bizonyítani tudod, illetve viszonylag egyszerűen ellenőrizni tudod automatikusan, hogy piszkáltak-e. Egy hash számítás a naplóra szerintem "nem túl nagy" overhead, hogy pontosan mennyi, az könnyen mérhető a napló keletkezésének adatsebessége ismeretében. (Illetve még az számíthat, hogy milyen granularitással akarod védeni a naplót.)

De ha az eredeti gép felett teljes kontrolljuk van, akkor ez sem véd teljesen, mert az eredeti programot is megpiszkálhatják, ami eleve hanisított naplót tud generálni. Tehát ha nem megbízható félnek írási joga van, akkor lehetetlen megvédeni az adatok integritását - elvi szinten. Persze a belepiszkálás költségeit lehet növelni.

Ha a sorokat külön kezeled, akkor nem sok esélyed van. Én láncolt checksum-ban gondolkodnék. Az első logsor megkapná a saját kivonatát, a második sorhoz hozzárakandó összeget meg úgy generálnám, hogy az előző kiírt sor (azaz logbejegyzés+checksum)+a kiírandó bejegyzés összefűzésére adódó checksum-ot raknám hozzá. Ezzel bármelyik sor esetén egyszerűen ellenőrizhető, hogy lett-e törölve az előtte lévő sor, illetve ha töröltek egy sort is akár, az összes többit újra kell generálni ahhoz, hogy ez ne tűnjön föl - ami (az alkalmazás nem a fájlból, hanem a saját memóriaterületéről veszi az utolsó kiírt logsor+checksum tartalmát a következő sor checksum-jának elkészítéséhez) az alkalmazás leállítását és a fájl elmozgatását/ürítését igényli ahhoz, hogy az újragenerálás se legyen észlelhető.

( Vizibirka | 2017. 04. 05., sze – 14:23 )

syslog-ng premium edition. pont azt tudja amit kersz

( Jason v | 2017. 04. 05., sze – 14:23 )

Altalad kontrollalt gepre logok atszivattyuzasa?

Ha az a cél, hogy az ügyfél és a szolgáltató-fejlesztő is lásson naplót, akkor ez megoldás, de ha pl. support feltételeket sértő hibákat akar az ügyfél mutogatni, hivatkozni valamire, akkor hiába mutogatom az én naplóm, amit ugyan úgy én is kipucolhatok :).

Jó kis dolog ez az üzlet és bizonyítósdi.