Log dalil bo’la oladimi

Insident tergovida logga ikki tomondan savol beriladi. Birinchisi oddiy: bu yozuv haqiqatanmi, uni kim yozgan va qachon yozilgan? Ikkinchisi ancha qiyin: bu yozuvlardan qaysi biri o’chirilgan?

Oddiy fayl yoki qidiruv indeksi ikkinchi savolga javob bera olmaydi. O’chirilgan qator o’zidan iz qoldirmaydi — sizda faqat qolganlari bo’ladi va ular butun ko’rinadi. Elasticsearch indeksidan bitta hujjatni o’chirish `DELETE /index/_doc/id` so’rovi bilan bajariladi va indeks bundan keyin ham mutlaqo sog’lom ko’rinadi. ClickHouse’da `ALTER TABLE ... DELETE` mutatsiyasi ham xuddi shunday: natijada jadval bor, unda esa kimdir ko’rmoqchi bo’lmagan qator yo’q.

Hujumchi uchun eng arzon usul ham shu. Windows muhitida bu bitta hodisa qoldiradi — 1102, «audit log tozalandi» — va aynan shuning uchun tajribali hujumchi butun jurnalni tozalamaydi: u SIEM’dagi bitta indeksdan bitta qatorni oladi, chunki u yerda 1102 ekvivalenti yo’q.

Shuning uchun «loglar saqlanadi» degan javob auditor uchun ham, sud uchun ham hech narsani anglatmaydi. Saqlash — mavjudlik haqidagi gap; dalil — o’zgarmaganlik haqidagi gap. Bular ikki xil texnik talab va ular ikki xil mexanizm bilan bajariladi.

Ko’p tizim logni normalizatsiya qilib saqlaydi va asl matnni tashlaydi. Bu qidiruv uchun qulay: maydonlar bir xil nomlanadi, sana ISO 8601 ga keltiriladi, ortiqcha belgilar olib tashlanadi. Dalil uchun esa halokatli — siz endi manbani emas, o’z talqiningizni ko’rsatasiz.

Farqni ko’rish uchun bitta misol yetarli. Nginx’ning `$request` maydonida `GET /a?b=%2e%2e%2f HTTP/1.1` bo’lsin. Normalizator uni dekodlab `GET /a?b=../` qilib yozadi. Endi siz hujumni ko’rsatyapsiz — lekin mijozdan aynan nima kelganini emas. Advokat birinchi shu farqni so’raydi, chunki dekodlash o’zi bir qaror va u xato bo’lishi mumkin.

To’g’ri yondashuv — ikkalasini birga saqlash. Normalizatsiya qilingan ko’rinish qidiruv va korrelyatsiya uchun, o’zgartirilmagan asl yozuv esa taqdim etish uchun. Ular bir-biriga bog’lanadi, lekin asl yozuv hech qachon qayta yozilmaydi.

Buning ikkinchi foydasi ham bor, va u kundalik ishda birinchisidan ko’ra tez-tez ishlaydi. Yangi razbor qoidasi chiqsa yoki eski qoidada xato topilsa, u saqlangan asl yozuvga qayta qo’llanadi. Asl matnni tashlagan tizimda esa xato abadiy qoladi: qayta hisoblash uchun manba yo’q, va siz o’tgan olti oylik ma’lumotni «shunday ekan» deb qabul qilishga majbursiz.

Har yozuv uchun nazorat summasi hisoblanadi — amalda SHA-256, chunki u tez va uni jiddiy qabul qilishadi. Yozuvlar bloklarga yig’iladi, blok uchun umumiy hash chiqariladi, va har blokning hashi oldingi blok hashini o’z ichiga oladi.

Bu — oddiy hash-zanjir. Hech qanday blokcheyn, hech qanday tarmoq, hech qanday token kerak emas. Aynan shu mexanizm systemd’ning journald’ida `Seal=yes` sozlamasi ostida ishlaydi va u yerda Forward Secure Sealing deb ataladi; sertifikat shaffofligi jurnallari esa xuddi shu g’oyani Merkle daraxti ko’rinishida ishlatadi. Ya’ni bu ekzotik narsa emas, standart amaliyot.

Natijada bitta yozuvni o’zgartirish yoki o’chirish o’sha blokning hashini buzadi, u esa keyingi blokning hashini buzadi va shu tariqa zanjirning oxirigacha ketadi. Bitta qatorni yashirish uchun undan keyingi butun tarixni qayta hisoblash kerak bo’ladi.

Zanjirning qiymati aynan shundan kelib chiqadi: u o’zgartirishni imkonsiz qilmaydi, u o’zgartirishni sezilarli qiladi. Dalil uchun kerak bo’lgan narsa ham shu. Hech kim «bu faylga hech kim tegmagan» deb isbotlay olmaydi; isbotlanadigan narsa — «tegilganda bu ko’rinadi».

Agar hash-zanjir loglar bilan bir joyda, bir xil huquqlar ostida yotsa, u himoya emas — bezak. Log-serverga root huquqi bilan kirgan odam ikkalasini birga qayta hisoblaydi va hech narsa sezilmaydi. Bu nazariy e’tiroz emas: hujumchining birinchi maqsadi ko’pincha aynan log-server bo’ladi, chunki u yerda hamma narsa bir joyga yig’iladi.

Shuning uchun blok hashlari alohida saqlanadi: boshqa tizimda, boshqa hisob ostida, yozgandan keyin o’zgartirib bo’lmaydigan rejimda. Amalda bu S3 Object Lock (compliance rejimida), WORM diskli tokcha yoki oddiygina boshqa tashkilotdagi mashina bo’lishi mumkin.

Ba’zi tashkilotlarda hashlar kunlik hisobot sifatida uchinchi tomonga yuboriladi — auditorga yoki notariusga. Bu ham yetarli, chunki muhim narsa nusxa emas, ajratilgan nazorat. Yana bir variant — RFC 3161 bo’yicha vaqt tamg’asi xizmati: u sizga «shu hash shu vaqtda mavjud edi» degan imzoni beradi.

Amaliy o’lchov oddiy va uni bitta savol bilan tekshirasiz: log-tizimning to’liq administratori hash jurnalini o’zgartira oladimi? Agar javob «ha» bo’lsa, sizda yaxlitlik nazorati yo’q — sizda yaxlitlik nazorati haqidagi hujjat bor.

Zanjir o’z-o’zidan hech narsani aniqlamaydi. U faqat tekshirilganda gapiradi. Tekshirilmagan zanjir — bu yozib qo’yilgan, lekin hech qachon o’qilmagan kafolat.

Shuning uchun tekshiruv fon rejimida, jadval bo’yicha ishlashi kerak: har blok yopilgandan keyin bir marta va butun davr bo’yicha muntazam. Oraliq muhim, chunki buzilish sodir bo’lgan payt emas, keyin oylab sezilmay qolishi mumkin. Kunlik to’liq tekshiruv katta arxivda qimmat bo’lsa, tasodifiy tanlov ishlatiladi — kuniga bir necha yuz blok, plyus oxirgi hafta to’liq.

Ikkinchi talab — davr bo’yicha yaxlitlik hisoboti: qaysi bloklar tekshirildi, qaysi biri nomuvofiq chiqdi, qachon. Insidentdan keyin auditor aynan shu hisobotni so’raydi, log fayllarini emas. Va bu hisobot bir necha soniyada chiqishi kerak — qo’lda tayyorlanadigan hisobot demak hech qachon tayyorlanmaydi.

Nomuvofiqlik topilganda nima bo’lishi ham oldindan yozilishi kerak. Ko’p tizimda bu bitta qator log yozadi va shu bilan tugaydi. To’g’ri javob — insidentga aylantirish: yaxlitlik buzilishi o’z-o’zidan hodisa, va u odam ko’radigan navbatga tushishi kerak.

Yaxlitlik faqat yozuvga tegishli emas. Kim qidirdi, qanday so’rov berdi, nimani eksport qildi, saqlash siyosatini kim o’zgartirdi — bularning hammasi alohida audit iziga tushishi kerak.

Aks holda savol o’rin almashadi: log o’zgartirilmagan bo’lishi mumkin, lekin uni kim ko’rgani va tashqariga chiqargani noma’lum qoladi. Ichki tergovlarda ko’pincha aynan shu ikkinchi savol muhimroq bo’ladi — ayniqsa SIEM’da mijoz ma’lumoti, to’lov izlari yoki xodimlarning yozishmalari bo’lsa.

Eng ko’p unutiladigan nuqta — saqlash muddatini o’zgartirish. Muddatni 90 kundan 7 kunga tushirish o’sha qatorlarni o’chirish bilan bir xil natija beradi, lekin hech qanday «o’chirish» amali qayd etilmaydi: retention siyosati ishladi, xolos. Shuning uchun siyosat o’zgarishi ham audit izining bir qismi, va u alohida tasdiqlashni talab qilishi kerak.

Eksport ham shunday. CSV yuklab olish — bu ma’lumotning tizimdan chiqishi, va u yerdan keyin nima bo’lgani sizning nazoratingizdan tashqarida. Kamida kim, qachon, qancha qator va qaysi filtr bo’yicha olganini bilishingiz kerak.

Dalilning ikkinchi zaif joyi — vaqt. Yozuvlar o’nlab serverdan keladi va har birining soati o’zicha yuradi. Ikki hodisaning qaysi biri oldin bo’lganini aytolmasangiz, sizda hodisalar to’plami bor, lekin voqealar zanjiri yo’q.

Shuning uchun barcha manbalar bitta NTP manbasiga bog’lanadi — amalda chrony yoki ntpd, va ular ham o’z holatini logga yozadi. Yozuvda esa ikkita vaqt saqlanadi: manba ko’rsatgan vaqt va tizim qabul qilgan vaqt. Ular orasidagi farq o’z-o’zidan foydali signal: sezilarli siljish odatda soat buzilganini yoki yozuv keyin qo’shilganini bildiradi.

Vaqt mintaqasi ham alohida tuzoq. Log ichida `+05:00` yozilmagan bo’lsa, u qaysi mintaqada yozilganini faqat taxmin qilasiz — va serverlar ko’chirilganda taxmin buziladi. Barcha yozuvlar UTC’da saqlanadi, mahalliy vaqt esa faqat ko’rsatishda qo’llanadi.

Blok chegarasi ham vaqt bo’yicha belgilanadi. Shunda «14:05 dan 14:10 gacha bo’lgan yozuvlar o’zgartirilmagan» degan gap tekshiriladigan da’voga aylanadi — aks holda u shunchaki ishonch iltimosi bo’lib qoladi.

Provayder yoki tizim tanlashda to’rtta savol yetarli. Asl yozuv normalizatsiya qilingan ko’rinish bilan birga saqlanadimi? Hash jurnali qayerda turadi va uni kim o’zgartira oladi? Tekshiruv qanday jadval bilan ishlaydi va hisobotni ko’rsata olasizmi? O’qish va eksport amallari qayd etiladimi?

Javoblar «ha» bo’lsa, keyingi qadam — namoyish. Ixtiyoriy davr tanlang va o’sha davr uchun yaxlitlik hisobotini so’rang. Ikkinchi so’rov yanada foydali: sinov muhitida bitta yozuvni ataylab o’zgartiring va tizim buni qancha vaqtda ko’rsatishini o’lchang.

Bu talablarning hech biri qimmat emas va hech biri ekzotik emas. PCI DSS ning 10-bo’limi ham, ISO 27001 ning jurnal himoyasi bo’yicha nazorati ham aynan shu narsani talab qiladi — faqat boshqacha so’zlar bilan.

Lekin ular loyihaning boshida qo’yilishi kerak, chunki keyin qo’shib bo’lmaydi: o’tgan yilgi loglar uchun zanjir hisoblab bo’lmaydi. Bugun hisoblangan hash faqat bugundan keyingi narsani himoya qiladi.