Audit — axborot tizimida kim, qachon, qaysi resurs ustida qanday amal bajarganini tekshiriladigan yozuvlar orqali qayd etish va baholash jarayonidir. Audit log operatsion debug logdan farq qiladi: uning asosiy vazifasi javobgarlik, o‘zgarish tarixi, xavfsizlik tekshiruvi va muvofiqlik dalilini ta’minlashdir.
Audit hodisasi
Yaxshi audit yozuvi quyidagi savollarga javob beradi:
- actor — foydalanuvchi, service account yoki qurilma;
- action — read, create, update, delete, login yoki privilege change;
- resource — obyekt turi va barqaror identifikator;
- vaqt — aniq timezone va sinxronlangan timestamp;
- natija — success, deny yoki failure;
- manba — IP, device, session va correlation ID;
- sabab — policy, ticket yoki approval konteksti.
To‘liq request body’ni saqlash shart emas. Secret, token, parol va ortiqcha shaxsiy ma’lumot maskalanadi. O‘zgargan fieldlar old/new qiymat bilan saqlansa sensitive columnlar alohida policy oladi.
Application va database auditi
Application user intent va business operationni yaxshi biladi. “Buyurtma tasdiqlandi” hodisasi SQL update’dan ma’noliroq. Database trigger yoki native audit esa applicationni chetlab o‘tgan administrator va boshqa writerlarni ham ko‘radi.
Ikki qatlam birga ishlashi mumkin. Correlation ID application eventini database session bilan bog‘laydi. Bir xil hodisani har qatlamda nazoratsiz loglash duplicate va storage shovqinini oshiradi.
Muvaffaqiyatsiz urinish
Transaction ichidagi audit trigger business write rollback bo‘lsa auditni ham rollback qiladi. Bu muvaffaqiyatli o‘zgarish uchun atomiklik beradi, lekin rad etilgan yoki rollback qilingan urinish tarixini saqlamaydi. Security gateway yoki alohida append-only audit kanali failure’ni qayd etadi.
Login failure, ruxsatsiz access va policy deny xavfsizlik uchun muhim. Ularni haddan ortiq ko‘p loglash brute-force paytida storage exhaustion keltirishi mumkin; rate aggregation va alert ishlatiladi, original dalil retention asosida saqlanadi.
O‘zgarmaslik
Audit actor o‘z izini o‘chira olmasligi kerak. Application roli audit tablega insert qilishi, update va delete huquqiga ega bo‘lmasligi mumkin. Log boshqa account yoki append-only storagega uzatiladi. WORM retention belgilangan muddat yozuvni o‘zgartirishdan himoya qiladi.
Hash chain ketma-ket eventlar yaxlitligini tekshirishi mumkin, digital signature esa trusted signer bilan bog‘laydi. Bu storage administratorining barcha nusxalarni o‘chirib yuborishiga qarshi o‘zi yetarli emas; remote replication va access separation zarur.
Vaqt va identitet
NTP yoki ishonchli vaqt manbai hodisalarni tizimlar orasida tartiblashga yordam beradi. Clock drift bir requestning child eventini parentdan oldin ko‘rsatishi mumkin. Sequence, transaction ID va trace context timestampni to‘ldiradi.
Shared database account haqiqiy userni yashiradi. Application actor IDni imzolangan yoki database tekshiradigan session context orqali beradi. Client bevosita actor_id=admin yubora olmaydi.
Qidiruv va alert
Audit pipeline strukturali schema, immutable event ID va versionga ega. Search index tez tahlil uchun nusxa bo‘lishi mumkin, authoritative archive esa uzoq retentionni saqlaydi. Indexdan o‘chirish original audit dalilini yo‘q qilmasligi kerak.
Privilege escalation, yangi API key, ko‘p delete, noodatiy region va audit configuration o‘zgarishi alert qilinadi. Alertning o‘zi ham kim ko‘rgan va yopganini audit qiladi.
Access va retention
Audit log juda sezgir: u foydalanuvchi harakati, resource nomi va ichki topologiyani ko‘rsatadi. Auditorga read-only, tor scope beriladi. Developer production auditni kundalik debug uchun to‘liq ko‘rmasligi mumkin.
Retention huquqiy va incident investigation muddatiga mos bo‘ladi. Legal hold odatiy expirationni to‘xtatadi. O‘chirish policy bo‘yicha bajarilib, o‘chirish amalining o‘zi ham yuqori darajadagi auditga yoziladi.
Bog‘liq tushunchalar
Audit log, Access control, Database trigger, Immutable storage, Correlation ID, Retention, Security monitoring