ETİMAD

Vahid İnformasiya Təhlükəsizliyi, Uyğunluq və İnsan Risklərinin İdarəedilməsi Platforması

Sənəd tipi: Product Requirements Document (PRD) + Sistem Arxitekturası + Prioritetləşdirilmiş Backlog Versiya: 0.9 (Draft for Review) Tarix: 2026-09-14 Status: Discovery / Architecture Baseline — təsdiq üçün Hədəf auditoriya: Dövlət qurumunun İT və İnformasiya Təhlükəsizliyi rəhbərliyi, GRC komandası, development komandası, daxili audit, satınalma Məxfilik: Daxili istifadə üçün

0. Sənəd haqqında

0.1 Repository analizi

Təqdim olunmuş işçi qovluq (/root/etimad) boşdur — mövcud kod bazası, texnologiya stack-i, migration və ya konfiqurasiya faylı yoxdur.

Nəticə: Layihə greenfield-dir. Buna görə bu sənəd mövcud arxitekturanın analizi bölməsini deyil, sıfırdan texnologiya seçimi və əsaslandırması bölməsini ehtiva edir (bax: §9).

Gələcəkdə repository doldurulduqda bu sənədin §9–§14 bölmələri "as-built" sənədə çevrilməli, hər dəyişiklik ADR (Architecture Decision Record) ilə müşayiət olunmalıdır.

0.2 Necə oxunmalıdır

0.3 Terminologiya (AZ ↔ EN)

Platformanın bütün UI mətnləri Azərbaycan dilində olacaq. Aşağıdakı lüğət normativdir — kod, API və UI-da eyni terminlər istifadə olunmalıdır.

0.4 Qəbul edilmiş fərziyyələr (Assumptions)

Aşağıdakı fərziyyələr işi dayandırmamaq üçün qəbul edilib. Hər biri §27-də açıq qərar kimi təkrar qeyd olunub və təsdiq tələb edir.

1. Executive Summary

1.1 Problem

Dövlət qurumunda informasiya təhlükəsizliyinin idarə edilməsi hazırda parçalanmış vəziyyətdədir:

• Sənədlər — paylaşılan qovluqlarda Word/PDF faylları; hansı versiyanın qüvvədə olduğu, kimin oxuduğu bilinmir.
• Uyğunluq (ISO 27001) — Excel cədvəllərində SoA və nəzarət tədbirləri; audit ərəfəsində sübutlar əl ilə toplanır, 3–6 həftə vaxt aparır.
• Risklər — ayrıca Excel reyestri; qalıq risk hesablanması subyektivdir, yenilənmə tezliyi aşağıdır.
• İnsan amili — maarifləndirmə təlimləri epizodikdir, iştirak sübutu zəifdir; fişinq simulyasiyası ya aparılmır, ya da açıq kodlu alətlə (GoPhish) nəzarətsiz aparılır.
• Məlumat sızması — məlumat təsnifatı rəsmiləşdirilməyib; DLP tətbiqi üçün zəruri olan təsnifat taksonomiyası, həssas məlumat kataloqu və siyasət idarəetməsi yoxdur.
• Audit izi — kim nəyi nə vaxt dəyişdi sualına cavab yoxdur.

Nəticədə: audit hazırlığı bahalı, risk mənzərəsi qeyri-şəffaf, insan riski ölçülməz, məlumat sızması riski idarəolunmazdır.

1.2 Həll

ETİMAD — on-premise, Active Directory ilə inteqrasiya olunmuş, modulyar vahid platformadır. O, 15 funksional istiqaməti bir məlumat modeli və bir iş axını mühərriki ətrafında birləşdirir.

Platformanın fərqləndirici xüsusiyyəti — modulların bir-birini məlumatla qidalandırması:

Fişinq nəticəsi ──▶ İnsan Riski Profili ──▶ Risk Reyestri (BEC riski) ──▶ Düzəldici tapşırıq
       │                    │                                                    │
       └──▶ Mikro-təlim ◀───┘                                              Audit sübutu
                                                                                 │
DLP hadisəsi ──▶ Məlumat Riski ──▶ Nəzarət tədbirinin effektivliyi ──▶ SoA ──▶ Audit hazırlığı
       │
       └──▶ Təsnifat siyasətinin pozulması ──▶ Policy istisnası / Təlim təyinatı

1.3 Əsas nəticələr (Business Outcomes)

1.4 Skoup sərhədləri

Platforma EDİR:

• Siyasət, risk, nəzarət tədbiri, sübut, audit, təchizatçı, aktiv idarəetməsi
• Təlim və imtahan (LMS funksiyası)
• Fişinq simulyasiyası (öz mail göndərici ilə)
• Məlumat təsnifatı taksonomiyası və həssas məlumat kataloqu
• DLP siyasətlərinin dizaynı, təsdiqi, versiyalaşdırılması və hadisələrinin idarə edilməsi
• AD-dən oxuma, iş axını, tapşırıq, bildiriş, hesabat, audit izi

Platforma ETMİR (MVP-də və ya ümumiyyətlə):

• ❌ Endpoint agent / kernel driver (DLP enforcement) — üçüncü tərəf məhsulu ilə inteqrasiya (bax A7)
• ❌ Email gateway / proxy kimi trafik kəsmə
• ❌ SIEM əvəzləyicisi (log toplama və korrelyasiya) — inteqrasiya var, əvəzləmə yox
• ❌ Vulnerability scanner / pentest aləti
• ❌ Tam CMDB (yalnız GRC üçün yüngül aktiv reyestri)
• ❌ HR sistemi (AD/HR-dən oxuyur, yazmır)
• ❌ AD-yə yazma (default olaraq read-only)
• ❌ Rəsmi ISO 27001 mətninin yayımlanması

1.5 Arxitektura qərarı — bir cümlə ilə

Modular Monolith (.NET 9 / ASP.NET Core + PostgreSQL 16 + Redis + RabbitMQ + OpenSearch + MinIO, React 19 frontend, Keycloak IAM), Docker Compose (kiçik quraşdırma) və ya Kubernetes (HA) üzərində, modul sərhədləri kod səviyyəsində bərk şəkildə təmin olunur ki, gələcəkdə istənilən modul ayrıca servisə çıxarıla bilsin. Əsaslandırma: §9.3.

1.6 Mərhələlər və müddət (yüksək səviyyə)

Ümumi: ~76 həftə (≈18 ay) tam funksionallıq üçün; istifadəyə yararlı MVP 28 həftədən sonra.

2. Məhsulun məqsədi

2.1 Missiya

Dövlət qurumunda informasiya təhlükəsizliyinin idarə olunan, ölçülən və audit edilə bilən prosesə çevrilməsini təmin edən vahid platforma yaratmaq.

2.2 Məhsul prinsipləri (normativ)

2.3 Uğur meyarları (Definition of Success)

Faza 1 (MVP) uğurlu sayılır, əgər:

1. 100% işçi AD SSO ilə daxil ola bilir, rolları avtomatik təyin olunur.
2. Ən azı 3 məcburi siyasət nəşr olunub və ≥ 90% tanışlıq təsdiqi toplanıb.
3. ISO 27001:2022 Annex A-nın 93 nəzarət tədbirinin hamısı sistemdə mövcuddur və SoA generasiya olunur (PDF/XLSX).
4. Ən azı 1 fişinq kampaniyası təhlükəsiz şəkildə keçirilib, heç bir real parol saxlanılmayıb (təsdiq: təhlükəsizlik testi).
5. Risk reyestrində ≥ 30 risk, hər birinin sahibi və qalıq riski var.
6. Bütün kritik əməliyyatlar audit logunda; log bütövlüyü yoxlaması keçir.
7. Negative authorization testlərinin 100%-i keçir.

3. Əsas istifadəçi rolları

3.1 Persona-lar

P1 — Adi əməkdaş (Elnur, 38, baş məsləhətçi)

• Nə edir: İldə 4–6 təlim, siyasətlərlə tanışlıq, şübhəli email bildirmək.
• Ağrı nöqtəsi: "Mənə nə lazımdır?" sualına cavab tapmaq. 15 modul onu qorxudur.
• Ehtiyac: Tək səhifə — "Mənim vəzifələrim", 3 klikdən çox olmayan axın, Azərbaycan dilində aydın dil.
• Uğur meyarı: İlk girişdən 60 saniyə ərzində nə etməli olduğunu başa düşür.

P2 — Şöbə müdiri (Aygün, 45, şöbə müdiri)

• Nə edir: Öz şöbəsinin təlim/siyasət statusunu izləyir, eskalasiyaları qəbul edir, təsdiqlər verir.
• Ağrı nöqtəsi: Kimin geciktiyini bilmək və xatırlatmaq üçün vaxt sərf etmək.
• Ehtiyac: Şöbə dashboard-u, bir kliklə xatırlatma, öz strukturundan kənarı görməmək.

P3 — Təhlükəsizlik / GRC mütəxəssisi (Rəşad, 33, aparıcı mütəxəssis)

• Nə edir: Nəzarət tədbirləri, risklər, sübutlar, fişinq kampaniyaları, DLP hadisələri.
• Ağrı nöqtəsi: Excel-lər arasında əlaqəni əl ilə saxlamaq.
• Ehtiyac: Hər obyektdən əlaqəli obyektlərə keçid, toplu əməliyyatlar, güclü filtr, saxlanmış görünüşlər.

P4 — Compliance Officer (Nigar, 41)

• Nə edir: SoA, gap analiz, audit hazırlığı, framework mapping.
• Ehtiyac: Bir nəzarət tədbirinin bütün framework-lərdə əksini görmək, sübut boşluqlarını dərhal tapmaq.

P5 — Daxili auditor (Kamran, 50)

• Nə edir: Audit planı, checklist, müsahibə, tapıntı, düzəldici tədbirin yoxlanışı.
• Ehtiyac: Sübutu dəyişdirmədən görmək, öz iş kağızlarını ayrıca saxlamaq, tapıntının tam tarixçəsi.
• SoD tələbi: Auditor öz yoxladığı nəzarət tədbirinin sahibi ola bilməz.

P6 — DLP analitiki (Tural, 29, SOC)

• Nə edir: DLP hadisələrinin triage-ı, yanlış pozitivlərin işarələnməsi, eskalasiya.
• Ağrı nöqtəsi: Həddindən artıq hadisə, çox yanlış pozitiv.
• Ehtiyac: Maskalanmış önizləmə, tam məzmun üçün səbəb tələb edən ayrıca icazə, toplu triage.

P7 — Data Owner (Səbinə, 44, HR şöbə müdiri)

• Nə edir: HR məlumatlarının təsnifatını təsdiqləyir, DLP istisnalarını rəy verir.
• Ehtiyac: Texniki olmayan dil, sadə təsdiq ekranı.

P8 — Rəhbərlik (Müavin, 55)

• Nə edir: Rüblük baxış, qərar.
• Ehtiyac: 1 ekran, 8 göstərici, trend, drill-down opsional. PDF hesabat.

P9 — Platform administratoru (İT, 35)

• Nə edir: AD sinxronizasiyası, rol təyinatı, konfiqurasiya, monitorinq.
• Məhdudiyyət: Məxfi sübut məzmununu və DLP hadisə məzmununu görmür.

P10 — Xarici auditor (müvəqqəti)

• Nə edir: Yalnız oxuyur, yalnız ona açılan audit skoupunda, müddətli hesabla.

3.2 Rol kataloqu

3.3 Segregation of Duties (SoD) qaydaları — normativ

Sistem aşağıdakı kombinasiyaları bloklamalıdır (rol təyinatı zamanı xəbərdarlıq + təsdiq tələbi, və ya tam blok):

Realizasiya: sod_rule cədvəli (konfiqurasiya edilə bilən), rol təyinatı və obyekt təyinatı zamanı SoDEvaluator xidməti. Blok halında əməliyyat rədd edilir və SOD_VIOLATION_BLOCKED audit hadisəsi yazılır. Xəbərdarlıq halında ikinci administratorun təsdiqi (dual control) tələb olunur və SOD_OVERRIDE_APPROVED yazılır.

4. Funksional modullar

4.0 Modul xəritəsi

Bünövrə modulları (M14, M17, M18) Faza 0/1-in əvvəlində hazır olmalıdır — bütün digər modullar onlardan asılıdır.

4.1 M01 — Maarifləndirmə Təlimi

4.1.1 Məqsəd

İşçilərin informasiya təhlükəsizliyi üzrə bilik səviyyəsini planlı, rola uyğun və sübut edilə bilən şəkildə artırmaq; ISO 27001 A.6.3 (Information security awareness, education and training) tələbinə sübut bazası yaratmaq.

4.1.2 İstifadəçilər

4.1.3 Funksiyalar

Məzmun (Content)

• Dərs tipləri: text (rich text), image (şəkilli slayd), video (MP4/WebM, daxili saxlama, xarici hosting YOXDUR), interactive (ssenari/branching), micro (≤ 5 dəq), scorm (SCORM 1.2 / 2004 paketi), xapi
• Dərs kateqoriyaları (ierarxik): Fişinq, Parol, Məxfi məlumat, Sosial mühəndislik, Fiziki təhlükəsizlik, Uzaqdan iş, Mobil cihaz, Hadisə bildirilməsi, Rola xas mövzular
• Versiyalaşdırma: hər dərsin versiyası; yayımlanmış versiya dəyişdirilə bilməz, yeni versiya yaradılır
• Çoxdillilik: lesson_translation — AZ/EN/RU; tərcümə olmadıqda default dilə fallback + görünən xəbərdarlıq
• Media: video üçün altyazı (WebVTT) məcburi (accessibility), transkript opsional
• SCORM/xAPI: SCORM paketi daxili player-də (offline, CDN-siz); xAPI ifadələri daxili LRS-ə (xapi_statement cədvəli). Qiymətləndirmə: SCORM Faza 2-ə köçürülür — MVP-də native dərs formatı kifayətdir, SCORM əsasən hazır kommersiya məzmunu üçün lazımdır.

Proqram və kampaniya

• TrainingProgram — dərslərin sıralı və ya sərbəst ardıcıllığı + imtahan + keçid şərti
• TrainingCampaign — proqramın konkret auditoriyaya, konkret müddətə təyinatı
• Təkrarlanan kampaniya (illik məcburi təlim): cron ifadəsi ilə

İmtahan

• Sual bankı: multiple_choice (tək/çox cavab), true_false, scenario (situasiya + variantlar), ordering, matching
• Sual metadata: çətinlik (1–5), kateqoriya, dil, izah (cavabdan sonra göstərilir)
• Təsadüfi seçim: "N sualdan M-ni seç", kateqoriya üzrə kvota (məs. Fişinq: 4, Parol: 3)
• Variantların qarışdırılması (shuffle)
• Minimum keçid balı (proqram səviyyəsində, default 80%)
• Vaxt limiti (dəqiqə), serverdə yoxlanılır (klient saatına güvənilmir)
• Təkrar cəhd: maksimum sayı, cəhdlər arası gözləmə müddəti (cooldown)
• Nəticənin göstərilməsi: bal, keçdi/keçmədi, səhv cavabların izahı (konfiqurasiya edilə bilər)

Təyinat (Assignment)

• Əl ilə təyinat (istifadəçi / qrup / şöbə)
• Qayda əsaslı avtomatik təyinat — AssignmentRule:

`` ŞƏRT (AD qrupu ∈ {...}) VƏ (departament ∈ {...}) VƏ (vəzifə LIKE '%...%') VƏ (human_risk_band ∈ {high, critical}) VƏ (əvvəlki nəticə < 80) ⇒ TƏYİN ET proqram X, müddət 14 gün, prioritet: yüksək ``

• Tetikleyicilər: yeni işçi (AD-də yaranma), şöbə dəyişikliyi, AD qrupuna əlavə olunma, fişinq uğursuzluğu, DLP hadisəsi, siyasət nəşri, risk səviyyəsinin artması
• Rola görə məcburi proqramlar (bax 4.1.4)

İzləmə və eskalasiya

• Deadline, xatırlatma cədvəli (məs. −7, −3, −1 gün, +1, +3 gün)
• Eskalasiya: gecikmə +N gün → şöbə müdiri; +M gün → müdirin müdiri; +K gün → HR/Təhlükəsizlik
• Tamamlanma sübutu: TrainingResult + PDF sertifikat (unikal nömrə, QR ilə doğrulama linki — daxili)
• Tam tarixçə: kim, nə vaxt, hansı versiyanı, neçə dəqiqə, hansı cəhddə

4.1.4 Rola görə məcburi təlim matrisi (default, konfiqurasiya edilə bilər)

4.1.5 Məlumat obyektləri

Lesson, LessonVersion, LessonTranslation, LessonCategory, MediaAsset, TrainingProgram, ProgramItem, TrainingCampaign, AssignmentRule, TrainingAssignment, TrainingProgress, Exam, ExamQuestionPool, Question, QuestionOption, QuestionTranslation, ExamAttempt, ExamAnswer, TrainingResult, Certificate, XapiStatement

4.1.6 İş axını

Dərs:      Draft → Review → Published → (Superseded) → Archived
Kampaniya: Draft → Scheduled → Active → Completed → Archived
Təyinat:   Assigned → In Progress → Exam Pending → Passed | Failed → (Retake) → Completed
           └─(deadline keçdi)→ Overdue → Escalated

4.1.7 Səlahiyyətlər

4.1.8 Audit log hadisələri

TRAINING_LESSON_CREATED, TRAINING_LESSON_PUBLISHED, TRAINING_CAMPAIGN_LAUNCHED, TRAINING_ASSIGNED, TRAINING_STARTED, TRAINING_COMPLETED, EXAM_STARTED, EXAM_SUBMITTED, EXAM_RESULT_OVERRIDDEN, CERTIFICATE_ISSUED, TRAINING_DEADLINE_EXTENDED, TRAINING_ESCALATED, TRAINING_RESULT_VIEWED (başqasının nəticəsi), ASSIGNMENT_RULE_CHANGED

4.1.9 API

GET    /api/v1/trainings/my                      # öz təyinatlarım
GET    /api/v1/trainings/my/{assignmentId}
POST   /api/v1/trainings/my/{assignmentId}/start
POST   /api/v1/trainings/my/{assignmentId}/progress   # {lessonId, position, completed}
GET    /api/v1/lessons?category=&lang=&status=
POST   /api/v1/lessons
PUT    /api/v1/lessons/{id}
POST   /api/v1/lessons/{id}/publish
POST   /api/v1/lessons/{id}/translations
GET    /api/v1/training-programs
POST   /api/v1/training-programs
GET    /api/v1/training-campaigns
POST   /api/v1/training-campaigns
POST   /api/v1/training-campaigns/{id}/launch
POST   /api/v1/training-campaigns/{id}/pause
GET    /api/v1/training-campaigns/{id}/statistics
POST   /api/v1/training-assignments/bulk           # toplu təyinat
PATCH  /api/v1/training-assignments/{id}/deadline   # {newDate, justification}
GET    /api/v1/assignment-rules
POST   /api/v1/assignment-rules
POST   /api/v1/assignment-rules/{id}/simulate       # neçə nəfərə təsir edəcək
GET    /api/v1/exams/{id}/attempt                   # aktiv cəhd (server-side timer)
POST   /api/v1/exams/{id}/attempts
POST   /api/v1/exams/attempts/{attemptId}/answers
POST   /api/v1/exams/attempts/{attemptId}/submit
GET    /api/v1/questions?category=&difficulty=
POST   /api/v1/questions/import                     # CSV/XLSX
GET    /api/v1/certificates/{id}/download           # PDF
GET    /api/v1/certificates/verify/{code}           # daxili doğrulama
GET    /api/v1/reports/training-completion

4.1.10 UI səhifələri

4.1.11 Metriklər

• Təlim tamamlanma faizi (ümumi / şöbə / proqram / kampaniya)
• Vaxtında tamamlanma faizi
• Orta imtahan balı, ilk cəhddən keçmə faizi
• Orta tamamlanma müddəti (təyinatdan bitməyə)
• Gecikmiş təyinatların sayı və yaşı
• Ən çox səhv cavablanan suallar (məzmun təkmilləşdirməsi üçün)
• Kateqoriya üzrə zəiflik xəritəsi (şöbə × mövzu)

4.1.12 Digər modullarla əlaqə

4.1.13 Qəbul meyarları (Acceptance Criteria)

1. Yeni AD istifadəçisi sinxronizasiyadan sonra ≤ 15 dəqiqə ərzində rola uyğun məcburi proqramlar təyin olunur.
2. İmtahan taymeri serverdə saxlanılır; brauzer bağlanıb açıldıqda qalan vaxt düzgün göstərilir; vaxt bitdikdə cavab qəbul edilmir (HTTP 409).
3. İmtahan sualları və düzgün cavablar heç bir halda klient API cavabında düzgünlük bayrağı ilə göndərilmir (test: response body-də isCorrect yoxdur).
4. Eyni istifadəçi eyni imtahanda paralel iki cəhd aça bilmir.
5. Sertifikat PDF-i unikal nömrə, verilmə tarixi, proqram adı, versiya və doğrulama kodu ilə yaranır; kod ilə doğrulama səhifəsi işləyir.
6. Deadline uzadılması səbəbsiz mümkün deyil; səbəb audit logunda saxlanılır.
7. Şöbə müdiri başqa şöbənin nəticəsini API vasitəsilə birbaşa ID ilə də ala bilmir (negative authorization testi HTTP 403 qaytarır).
8. AZ tərcüməsi olmayan dərs AZ interfeysdə açıq xəbərdarlıq ilə default dildə göstərilir.
9. Video dərsdə altyazı faylı yoxdursa dərs Published statusuna keçə bilmir.
10. Kampaniya 5 000 istifadəçiyə ≤ 5 dəqiqə ərzində təyin olunur (background job, idempotent).

4.2 M02 — Fişinq Simulyasiyası və İnsan Riskinin İdarəetməsi

4.2.1 Məqsəd

İşçilərin sosial mühəndislik hücumlarına real davranışını təhlükəsiz, etik və ölçülə bilən şəkildə qiymətləndirmək; nəticəni hədəflənmiş təlimə və risk reyestrinə bağlamaq.

Fərq (GoPhish-dən irəli): təsdiq iş axını, fövqəladə dayandırma, real parolun texniki olaraq saxlanmasının qeyri-mümkünlüyü, AD-əsaslı hədəfləmə, insan riski profili, avtomatik remediasiya, SIEM inteqrasiyası, məlumat minimallaşdırılması və etik nəticə paylaşımı.

4.2.2 İstifadəçilər

Fişinq kampaniya meneceri (qurur), Təhlükəsizlik rəhbəri (təsdiqləyir), Şöbə müdiri (öz şöbəsinin aqreqat nəticəsini görür), Əməkdaş (yalnız öz nəticəsini + təlimini görür), SOC (bildirilən emailləri qəbul edir).

4.2.3 Funksiyalar

Şablon və məzmun

• Email şablon qurucusu: vizual (drag-and-drop bloklar) + HTML mənbə redaktoru + düz mətn alternativi
• Dəyişənlər: {{FirstName}}, {{LastName}}, {{Department}}, {{Position}}, {{ManagerName}}, {{Date}}, {{TrackingUrl}}, {{QrCode}}, {{AttachmentName}}
• Şablon versiyalaşdırılması, çətinlik səviyyəsi (1–5), dil, kateqoriya (BEC, təchizatçı hesab-fakturası, İT dəstəyi, HR, kuryer, dövlət qurumu bildirişi)
• Landing page qurucusu: təlim səhifəsi, "bu simulyasiya idi" izahı, kredensial formu simulyasiyası
• Şablon kitabxanası: AZ dilində ≥ 25 hazır şablon (dövlət qurumu kontekstinə uyğun)

Göndərmə infrastrukturu

• SenderProfile: göndərən adı, from/reply-to, SMTP host/port/TLS/auth, göndərmə sürəti (msg/dəq)
• TrackingDomain: ayrıca domen/subdomen, sertifikat, marşrut; əsas qurum domenindən fərqli olmalıdır
• Email gateway inteqrasiyası: allowlist (simulyasiya IP/domeni spam filtrindən keçsin), header-lə işarələmə (X-ETIMAD-Simulation: <campaignToken>) — real hücumdan ayırd etmək üçün
• Göndərmə pəncərəsi: iş saatları, təsadüfi paylanma (məs. 4 saat ərzində bərabər), vaxt zonası nəzərə alınmaqla

Hədəfləmə

• Mənbələr: AD qrupu, OU, departament, vəzifə, risk bandı, əvvəlki kampaniya nəticəsi, əl ilə siyahı, CSV
• İstisna siyahısı (ExclusionList): rəhbərlik (opsional), xəstəliyə görə məzuniyyətdə olanlar, HR-in müəyyən etdiyi həssas hallar, təhlükəsizlik komandası (opsional), xidməti hesablar (həmişə istisna)
• Suppression list: son N gün ərzində kampaniyada iştirak edənlər (təlim yorğunluğunun qarşısı)
• Hədəf sayının önizləməsi və "kimlər" siyahısı (təsdiqdən əvvəl)

Kampaniya tipləri

• Link simulyasiyası (klik izlənir)
• Kredensial simulyasiyası (form göndərilməsi izlənir — dəyər YOX)
• Qoşma simulyasiyası (təhlükəsiz fayl: makro OLMAYAN docx/pdf, açılış izlənir tracking pixel və ya daxili link ilə)
• QR fişinq (email və ya çap üçün QR kod, skan izlənir)
• Yalnız bildirmə testi (report-only: məqsəd klik deyil, bildirmə nisbətini ölçmək)

İdarəetmə

• Təsdiq iş axını (bax 4.2.6) — təsdiqsiz kampaniya göndərilə bilməz
• Planlaşdırma, təkrarlanan kampaniyalar (rüblük)
• Fövqəladə dayandırma (Emergency Stop): bir düymə → növbə boşaldılır, landing page-lər "kampaniya dayandırıldı" səhifəsinə yönlənir, SOC-a bildiriş. Səlahiyyət: kampaniya meneceri, təhlükəsizlik rəhbəri, platform admin.
• Test göndərişi: kampaniyadan əvvəl özünə/test qutusuna
• Real vaxtda izləmə paneli

Bildirmə (Reporting) inteqrasiyası

• Outlook add-in / M365 "Report Phishing" düyməsi: bildirilən email ETİMAD-a göndərilir; header token varsa → simulyasiya kimi tanınır, dərhal "Təşəkkür, bu bizim simulyasiyamız idi" cavabı; token yoxdursa → real şübhəli email kimi M15-ə hadisə açılır
• Gmail Report Phishing (opsional, əgər Google Workspace varsa)
• Fallback: phishing-report@qurum.gov.az poçt qutusunun IMAP ilə oxunması

Real fişinqin təlim nümunəsinə çevrilməsi

• SOC real fişinq emailini M15-dən "Şablona çevir" düyməsi ilə götürür
• Sanitizasiya boru xətti (məcburi, avtomatik):
1. Bütün xarici linklər # və ya simulyasiya URL-i ilə əvəzlənir
2. Bütün qoşmalar silinir (yalnız adı və tipi saxlanılır)
3. Bütün <script>, <iframe>, <object>, event handler-lər silinir (HTML allowlist sanitizer)
4. Remote resurslar (şəkil, font) daxili proxy-yə köçürülür və ya silinir
5. Real qurbanın məlumatları (email, ad) maskalanır
6. Nəticə insan tərəfindən nəzərdən keçirilir və təsdiqlənir
• original_source_incident_id saxlanılır (audit üçün)

4.2.4 Toplanan hadisələr

Törəmə metrik: time_to_click = clicked_at − delivered_at, time_to_report = reported_at − delivered_at

4.2.5 🔒 Kredensial simulyasiyasının təhlükəsizlik dizaynı (KRİTİK)

Bu bölmə normativdir və dəyişdirilə bilməz.

Test halı (məcburi, hər relizdə): avtomatlaşdırılmış test kredensial səhifəsinə password=P@ssw0rd123! göndərir; sonra bütün DB cədvəlləri, bütün log faylları, mesaj növbəsi və fayl saxlamasında bu sətir axtarılır → 0 nəticə tələb olunur. Nəticə 0 deyilsə → build fail.

4.2.6 İş axını

Kampaniya:
  Draft
    → Ready for Review        (menecer təqdim edir)
    → Security Review         (təhlükəsizlik rəyi: şablon, hədəf, etika)
    → Approved                (təhlükəsizlik rəhbəri; SoD: yaradan təsdiqləyə bilməz)
    → Scheduled
    → Running                 (Pause / EMERGENCY STOP mümkündür)
    → Completed
    → Report Issued
    → Archived

  Rədd yolu: Security Review → Rejected → Draft

Təsdiq üçün məcburi yoxlama siyahısı (sistem avtomatik yoxlayır):

• <input type="checkbox" disabled> Hədəf sayı və siyahısı nəzərdən keçirilib
• <input type="checkbox" disabled> Xidməti hesablar istisna edilib
• <input type="checkbox" disabled> Suppression list tətbiq olunub
• <input type="checkbox" disabled> Şablon sanitizasiyadan keçib (əgər real emaildən götürülübsə)
• <input type="checkbox" disabled> Tracking domeni əsas domendən fərqlidir
• <input type="checkbox" disabled> Email gateway allowlist konfiqurasiya olunub
• <input type="checkbox" disabled> SOC xəbərdar edilib (kampaniya pəncərəsi bildirilib)
• <input type="checkbox" disabled> Landing page kredensial saxlamır (avtomatik yoxlama nəticəsi: PASS)
• <input type="checkbox" disabled> Təlim təyinatı konfiqurasiya olunub
• <input type="checkbox" disabled> HR/hüquq razılığı (qurum siyasətinə görə tələb olunursa)

4.2.7 İnsan Riski Profili (Human Risk Score)

Məqsəd: işçinin davranış riskini vahid, izah edilə bilən, etik göstərici ilə ifadə etmək.

Formula (konfiqurasiya edilə bilən, default):

HRS = 100 − (w1·P + w2·T + w3·R + w4·D + w5·A)   → 0..100, yüksək = yüksək risk

Əslində müsbət risk toplusu kimi hesablanır:

Zaman sönməsi (time decay): hər hadisənin çəkisi exp(−age_days / 180) ilə azalır — 6 aylıq yarı ömür. Bu, işçinin "əbədi damğalanmasının" qarşısını alır (P7 prinsipi).

Bandlar: Aşağı (0–24), Orta (25–49), Yüksək (50–74), Kritik (75–100)

Şəffaflıq tələbi: hər HRS dəyəri üçün HumanRiskScoreBreakdown saxlanılır — hansı hadisə nə qədər əlavə etdi. İstifadəçi öz balının izahını görə bilər.

Aqreqatlar: Şöbə Riski = üzvlərin ölçülmüş ortası (kritiklik çəkisi ilə); Qurum HRS = şöbələrin ortası.

4.2.8 Metriklər

4.2.9 ⚖️ Etika və məxfilik qaydaları (normativ)

4.2.10 Səlahiyyətlər

4.2.11 Audit log hadisələri

PHISHING_TEMPLATE_CREATED, PHISHING_TEMPLATE_SANITIZED, PHISHING_CAMPAIGN_CREATED, PHISHING_CAMPAIGN_SUBMITTED, PHISHING_CAMPAIGN_APPROVED, PHISHING_CAMPAIGN_REJECTED, PHISHING_CAMPAIGN_LAUNCHED, PHISHING_CAMPAIGN_PAUSED, PHISHING_CAMPAIGN_EMERGENCY_STOPPED, PHISHING_TARGET_LIST_VIEWED, PHISHING_INDIVIDUAL_RESULTS_EXPORTED, PHISHING_EXCLUSION_CHANGED, HRS_RECALCULATED, HRS_BREAKDOWN_VIEWED, SENDER_PROFILE_CHANGED, TRACKING_DOMAIN_CHANGED

4.2.12 API

GET  /api/v1/phishing/templates
POST /api/v1/phishing/templates
POST /api/v1/phishing/templates/{id}/sanitize-preview
POST /api/v1/phishing/templates/from-incident/{incidentId}
GET  /api/v1/phishing/landing-pages
POST /api/v1/phishing/landing-pages
GET  /api/v1/phishing/sender-profiles
POST /api/v1/phishing/sender-profiles/{id}/test
GET  /api/v1/phishing/tracking-domains
GET  /api/v1/phishing-campaigns
POST /api/v1/phishing-campaigns
POST /api/v1/phishing-campaigns/{id}/preview-targets     # sayı + siyahı
POST /api/v1/phishing-campaigns/{id}/send-test
POST /api/v1/phishing-campaigns/{id}/submit-for-approval
POST /api/v1/phishing-campaigns/{id}/approve             # SoD yoxlanır
POST /api/v1/phishing-campaigns/{id}/reject
POST /api/v1/phishing-campaigns/{id}/schedule
POST /api/v1/phishing-campaigns/{id}/pause
POST /api/v1/phishing-campaigns/{id}/emergency-stop
GET  /api/v1/phishing-campaigns/{id}/events?type=&from=
GET  /api/v1/phishing-campaigns/{id}/statistics
GET  /api/v1/phishing-campaigns/{id}/report?format=pdf|xlsx
GET  /api/v1/human-risk/me
GET  /api/v1/human-risk/me/breakdown
GET  /api/v1/human-risk/users/{id}          # səlahiyyət tələb edir
GET  /api/v1/human-risk/departments/{id}
POST /api/v1/human-risk/recalculate          # admin/job
GET  /api/v1/phishing/exclusions
POST /api/v1/phishing/exclusions

# Publik (autentifikasiyasız, ayrıca servis, rate-limited):
GET  /t/{token}/o.gif          # open pixel
GET  /t/{token}/c              # click redirect
GET  /t/{token}/q              # QR
GET  /t/{token}/a              # attachment open
POST /t/{token}/submitted      # YALNIZ {"fieldCount": n}
GET  /t/{token}/training       # açıqlama + mikro-təlim

4.2.13 UI səhifələri

4.2.14 Digər modullarla əlaqə

M01 (mikro-təlim təyinatı), M05 (BEC/sosial mühəndislik riskinin yenidən qiymətləndirilməsi), M13 (DLP davranışı HRS-ə), M14 (AD hədəfləmə), M15 (real fişinq bildirişi → hadisə), M16 (dashboard), M17 (remediasiya tapşırığı), M07 (kampaniya hesabatı → sübut).

4.2.15 Qəbul meyarları

1. Kredensial testi: simulyasiya formuna unikal test sətri göndərilir; DB, log, növbə və fayl saxlamasında həmin sətir tapılmır (avtomatlaşdırılmış test, CI-də bloklayıcı).
2. Təsdiqlənməmiş kampaniya API ilə də başladıla bilmir (HTTP 409).
3. Kampaniyanı yaradan şəxs onu təsdiqləyə bilmir (HTTP 403, SOD_VIOLATION_BLOCKED logu).
4. Fövqəladə dayandırma ≤ 30 saniyə ərzində bütün gözləyən emailləri ləğv edir və landing səhifələrini neytral səhifəyə yönləndirir.
5. Xidməti hesablar (AD servicePrincipalName olan və ya konfiqurasiya olunmuş OU) heç bir kampaniyaya daxil edilmir — hədəf önizləməsində də görünmür.
6. Bütün simulyasiya emailləri X-ETIMAD-Simulation header-i daşıyır və bu header SIEM tərəfindən tanınır.
7. Şöbə müdiri başqa şöbənin fərdi nəticə siyahısını ala bilmir (403).
8. HRS-in izahı istifadəçiyə hansı hadisələrin neçə bal əlavə etdiyini göstərir.
9. UI-da və kod bazasında "repeat offender" / "təkrar günahkar" ifadəsi yoxdur (avtomatlaşdırılmış lint qaydası).
10. Real emaildən yaradılan şablonda heç bir xarici link, skript və ya qoşma qalmır (sanitizasiya testi).
11. Tracking domeni əsas qurum domeni ilə eynidirsə kampaniya təsdiqə göndərilə bilmir.
12. 5 000 emailin göndərilməsi konfiqurasiya olunmuş sürət limitini aşmır və 4 saatlıq pəncərəyə bərabər paylanır.

4.3 M03 — Siyasət və Sənəd İdarəetməsi

4.3.1 Məqsəd

Qurumun informasiya təhlükəsizliyi sənədlərinin (siyasət, prosedur, təlimat, standart, qayda) tam həyat dövrünü — yaradılmadan arxivləşdirməyə qədər — idarə etmək, işçilərin tanışlığını sübut etmək və sənədləri nəzarət tədbirləri, risklər və sübutlarla əlaqələndirmək. ISO 27001 bənd 5.2, 7.5 və A.5.1 tələblərinə cavab verir.

4.3.2 İstifadəçilər

Siyasət müəllifi, rəyçi, təsdiqləyici, Compliance Officer, hüquq şöbəsi, bütün əməkdaşlar (tanışlıq), auditor (oxuma).

4.3.3 Sənəd tipləri və ierarxiya

Siyasət (Policy)            — "nə" və "niyə", rəhbərlik təsdiqi
  └─ Prosedur (Procedure)   — "kim, nə vaxt, necə", addım-addım
      └─ Təlimat (Instruction) — konkret texniki addımlar
  └─ Standart (Standard)    — məcburi texniki parametrlər
  └─ Guideline              — tövsiyə xarakterli
  └─ Forma/Şablon (Form)    — doldurulası sənədlər
  └─ Reyestr (Register)     — siyahı sənədləri

Hər sənədin parent_document_id sahəsi ilə ierarxiya qurulur; sənəd ağacı UI-da göstərilir.

4.3.4 Funksiyalar

Redaktə

• Web əsaslı rich-text redaktor (başlıq səviyyələri, cədvəl, siyahı, şəkil, daxili keçid, sənədlərarası keçid, dipnot)
• Struktur şablonları: Məqsəd / Əhatə dairəsi / Terminlər / Rollar və məsuliyyətlər / Tələblər / İstisnalar / Əlaqəli sənədlər / Nəzarət tədbirləri / Baxış qaydası / Versiya tarixçəsi
• Avtosave (30 saniyə + fokus itkisi), qeyd olunmamış dəyişiklik xəbərdarlığı
• Draft idarəetməsi: eyni anda bir aktiv draft; başqası redaktə edərkən kilid (optimistic lock + "X redaktə edir" göstəricisi)
• Şablon kitabxanası: ISO 27001 üçün hazır 20+ AZ şablonu (İT istifadəsi siyasəti, Parol siyasəti, Giriş nəzarəti, Aktivlərin idarəolunması, Hadisələrə cavab, Fiziki təhlükəsizlik, Təchizatçı təhlükəsizliyi, Şifrələmə, Backup, Uzaqdan iş, Mobil cihazlar, Məlumat təsnifatı, Təmiz masa, Log və monitorinq, Dəyişikliklərin idarəolunması, Fasiləsizlik, ...)

Versiyalaşdırma

• Semantik versiya: major.minor (məs. 2.1). Major = məzmun dəyişikliyi → yenidən tanışlıq tələb olunur; minor = redaktə/orfoqrafiya → tanışlıq tələb olunmur (konfiqurasiya edilə bilər)
• Hər versiya dəyişməzdir (immutable) nəşrdən sonra
• Dəyişiklik tarixçəsi: nə, kim, nə vaxt, niyə (change summary məcburi)
• Sənəd müqayisəsi (diff): iki versiya yan-yana, əlavə/silinmiş hissələr işarələnir (rəng + +/− işarəsi, yalnız rəng yox)

Əməkdaşlıq

• Rəy sorğusu (parallel və ya ardıcıl rəyçilər)
• Şərhlər (mətn parçasına bağlı, thread), həll olundu işarəsi
• @qeyd (mention) → bildiriş
• Rəy müddəti və xatırlatma

Nəşr və tanışlıq

• Effektiv tarix (gələcək tarix üçün planlanmış nəşr)
• Tətbiq dairəsi: bütün qurum / departament / AD qrupu / vəzifə / rol
• Tanışlıq (acknowledgement): "Oxudum və başa düşdüm" + opsional qısa test (3–5 sual, keçid balı)
• Tanışlıq izləmə: kim, hansı versiyanı, nə vaxt, hansı IP-dən, nə qədər vaxt sərf etdi (minimum oxuma müddəti konfiqurasiya edilə bilər)
• Yenidən tanışlıq: major versiya, illik təkrar, rol dəyişikliyi
• Geri çəkilmə (withdrawal), əvəzlənmə (superseded by), arxivləşdirmə
• Baxış tarixi (review date) — çatanda sahibə tapşırıq yaranır
• Bitmə tarixi (expiration) — keçəndə status Expired, dashboard-da xəbərdarlıq

İxrac və nəşr formatı

• PDF (rəsmi tərtibat: gerb/loqo, başlıq, altbaşlıq, səhifə nömrəsi, versiya, təsnifat etiketi, su nişanı), DOCX, HTML
• Su nişanı: draft üçün "LAYİHƏ", məhdud sənədlər üçün istifadəçi adı + tarix (sızma izlənməsi üçün)
• Çap üçün QR: sənədin daxili linki və versiyası (çap edilmiş nüsxənin aktuallığını yoxlamaq üçün)

Əlaqələr Siyasət ↔ Prosedur, ↔ Nəzarət tədbiri (M04), ↔ Risk (M05), ↔ Sübut (M07), ↔ Aktiv (M08), ↔ Təsnifat səviyyəsi (M10), ↔ Təlim (M01)

4.3.5 İş axını

Draft
 → Internal Review        (müəllifin şöbəsi / mövzu üzrə ekspert)
 → Security Review        (İT təhlükəsizliyi)
 → Legal/Compliance Review (hüquq + uyğunluq)
 → Pending Approval
 → Approved
 → Published              (effektiv tarixdə avtomatik)
 → Acknowledgement Campaign (aktiv)
 → Active
 → Under Periodic Review  (baxış tarixində avtomatik)
 → (Revised → yeni versiya Draft)  |  (Withdrawn)  |  (Archived)

Rədd yolları: hər review mərhələsindən → Changes Requested → Draft

Mərhələlər konfiqurasiya edilə bilər — qurum "Legal Review"-u ləğv edə və ya "Rəhbərlik baxışı" əlavə edə bilər (M17 iş axını mühərriki).

4.3.6 Siyasət istisnası (Policy Exception)

Qayda: Aktiv istisna olan nəzarət tədbiri SoA-da və uyğunluq hesabatında görünən şəkildə işarələnir ("İstisna ilə").

4.3.7 ISO mətninin hüquqi statusu (KRİTİK)

• Framework strukturu read-only reference kimi işarələnir — istifadəçi bənd nömrəsini və rəsmi başlığı dəyişə bilmir.
• Sistemdə açıq qeyd: "ISO/IEC standartlarının tam mətni müəllif hüququ ilə qorunur. Platforma standartın mətnini yaymır. Rəsmi mətn üçün qurumun lisenziyalı nüsxəsinə müraciət edin."
• Qurum lisenziya alıbsa, tam mətn opsional əlavə modul kimi, məhdud girişlə (yalnız lisenziya əhatəsindəki istifadəçilər) yüklənə bilər — bu, konfiqurasiya qərarıdır, default söndürülüb.

4.3.8 Məlumat obyektləri

Document, DocumentVersion, DocumentTranslation, DocumentTemplate, DocumentComment, DocumentReviewRequest, DocumentApproval, DocumentApplicability, PolicyAcknowledgement, PolicyQuiz, PolicyQuizResult, PolicyException, PolicyExceptionApproval, DocumentLink (polimorf əlaqələr)

4.3.9 Səlahiyyətlər

4.3.10 Audit hadisələri

DOCUMENT_CREATED, DOCUMENT_UPDATED, DOCUMENT_VERSION_CREATED, DOCUMENT_SUBMITTED_FOR_REVIEW, DOCUMENT_REVIEWED, DOCUMENT_APPROVED, DOCUMENT_REJECTED, DOCUMENT_PUBLISHED, DOCUMENT_WITHDRAWN, DOCUMENT_ARCHIVED, DOCUMENT_VIEWED (məhdud təsnifatlı sənədlər üçün), DOCUMENT_EXPORTED, POLICY_ACKNOWLEDGED, POLICY_QUIZ_COMPLETED, POLICY_EXCEPTION_REQUESTED, POLICY_EXCEPTION_APPROVED, POLICY_EXCEPTION_REJECTED, POLICY_EXCEPTION_EXPIRED, POLICY_EXCEPTION_EXTENDED, POLICY_EXCEPTION_REVOKED, DOCUMENT_APPLICABILITY_CHANGED

4.3.11 API

GET    /api/v1/policies?type=&status=&department=&search=
POST   /api/v1/policies
GET    /api/v1/policies/{id}
PUT    /api/v1/policies/{id}                      # If-Match (ETag) tələb olunur
GET    /api/v1/policies/{id}/versions
GET    /api/v1/policies/{id}/versions/{v}
GET    /api/v1/policies/{id}/diff?from=1.0&to=2.0
POST   /api/v1/policies/{id}/submit-review
POST   /api/v1/policies/{id}/review               # {decision, comments}
POST   /api/v1/policies/{id}/approve
POST   /api/v1/policies/{id}/publish              # {effectiveDate, requireAck}
POST   /api/v1/policies/{id}/withdraw
GET    /api/v1/policies/{id}/export?format=pdf|docx
GET    /api/v1/policies/{id}/comments
POST   /api/v1/policies/{id}/comments
GET    /api/v1/policies/my/pending-acknowledgements
POST   /api/v1/policies/{id}/acknowledge          # {versionId, quizAttemptId?}
GET    /api/v1/policies/{id}/acknowledgements     # hesabat
GET    /api/v1/policy-exceptions
POST   /api/v1/policy-exceptions
POST   /api/v1/policy-exceptions/{id}/approve
POST   /api/v1/policy-exceptions/{id}/reject
POST   /api/v1/policy-exceptions/{id}/extend
POST   /api/v1/policy-exceptions/{id}/revoke
GET    /api/v1/document-templates

4.3.12 UI səhifələri

4.3.13 Metriklər

Tanışlıq faizi (ümumi/şöbə/sənəd), vaxtı keçmiş sənədlər, baxış tarixi yaxınlaşan sənədlər, təsdiq gözləmə müddəti (orta), aktiv istisnaların sayı və risk cəmi, sənəd-nəzarət tədbiri əhatəsi (neçə A.x nəzarət tədbirinin sənədi var).

4.3.14 Digər modullarla əlaqə

M04 (nəzarət tədbiri ↔ siyasət), M05 (istisna → risk), M07 (nəşr olunmuş siyasət = sübut), M01 (siyasət testi), M08 (aktivə aid siyasət), M10 (təsnifat siyasəti), M14 (AD qrupu → tətbiq dairəsi), M17 (təsdiq iş axını).

4.3.15 Qəbul meyarları

1. Nəşr olunmuş versiya heç bir rol tərəfindən redaktə edilə bilmir (403); dəyişiklik yalnız yeni versiya ilə.
2. Müəllif öz sənədini təsdiqləyə bilmir (SoD-1, 403 + audit).
3. Major versiya nəşr olunduqda tətbiq dairəsindəki bütün istifadəçilərə yenidən tanışlıq tapşırığı yaranır.
4. Tanışlıq qeydi sənədin konkret versiya ID-si ilə saxlanılır.
5. Effektiv tarixi gələcək olan sənəd həmin tarixə qədər əməkdaşlara görünmür, avtomatik həmin gün görünür.
6. Baxış tarixi çatan sənəd üçün sahibə tapşırıq və bildiriş yaranır; 30 gün gecikdikdə müdirə eskalasiya.
7. PDF ixracında versiya, effektiv tarix, təsnifat etiketi və su nişanı mövcuddur.
8. İstisna bitmə tarixində avtomatik Expired olur və əlaqəli nəzarət tədbirinin statusuna təsir edir.
9. Kompensasiya edən nəzarət göstərilməyən istisna əlavə (yüksək səviyyəli) təsdiq tələb edir.
10. ISO framework bəndinin rəsmi başlığı və nömrəsi UI-da redaktə edilə bilmir (input disabled + API 403).
11. Sənəd üzərində eyni anda iki redaktə cəhdi optimistic lock ilə qarşısı alınır (HTTP 412).

4.4 M04 — Uyğunluq İdarəetməsi

4.4.1 Məqsəd

Bir və ya bir neçə uyğunluq çərçivəsinin (framework) tələblərini qurumun daxili nəzarət tədbirləri ilə əlaqələndirmək, icra statusunu izləmək, boşluqları aşkarlamaq və Tətbiq Oluna Bilənlik Bəyannaməsini (SoA) avtomatik yaratmaq.

4.4.2 Əsas konsepsiya — Unified Control Framework

Framework (ISO 27001:2022)
   └─ Domain (A.5 Organizational controls)
        └─ Requirement (A.5.1 Policies for information security)
                    ▲
                    │ ControlMapping (N:M, versiyalanmış)
                    ▼
       İnternal Control (CTL-0012 "Təhlükəsizlik siyasətlərinin idarə olunması")
          ├─ ControlAssessment (dövri qiymətləndirmə)
          ├─ Evidence[] (M07)
          ├─ Policy[] (M03)
          ├─ Risk[] (M05)
          ├─ Asset[] (M08)
          └─ Task[] (remediasiya, M17)

Prinsip: Qurumun bir daxili nəzarət tədbiri bir neçə framework tələbini ödəyə bilər. Bu, ikinci framework əlavə edildikdə işin 60–80%-nin təkrarlanmasının qarşısını alır.

4.4.3 Framework idarəetməsi

• Framework strukturu JSON/YAML import faylı ilə yüklənir (kod dəyişikliyi yoxdur — P11)

```yaml framework: { code: ISO27001, version: "2022", name_az: "...", authority: "ISO/IEC" } domains:

• code: A.5

name_az: "Təşkilati nəzarət tədbirləri" requirements:

• code: A.5.1

title_en: "Policies for information security" title_az: "İnformasiya təhlükəsizliyi siyasətləri" type: preventive attributes: { cia: [C,I,A], concepts: [Govern], capabilities: [Governance] } ```

• Framework versiyalaşdırılması: ISO 27001:2013 → 2022 keçidi üçün requirement_crosswalk cədvəli
• Faza 1: ISO/IEC 27001:2022 (bənd 4–10 + Annex A 93 nəzarət tədbiri) + lokal normativ tələblər
• Faza 2+: NIST CSF 2.0, CIS Controls v8.1, PCI DSS 4.0, SOC 2 (TSC), GDPR, ISO 22301, ISO 27701, ISO 42001

Lokal normativ tələblər — ayrıca "framework" kimi modelləşdirilir: Azərbaycan Respublikasının informasiya təhlükəsizliyi üzrə normativ aktları, dövlət informasiya sistemləri üzrə tələblər, fərdi məlumatlar haqqında qanunvericilik. Bəndlər qurum tərəfindən daxil edilir (hüquqi mətn saxlanılmır, istinad saxlanılır).

4.4.4 Nəzarət tədbirinin (Control) sahələri

4.4.5 Statuslar

4.4.6 Statement of Applicability (SoA)

Ayrıca modul + hesabat. ISO 27001 bənd 6.1.3 d) tələbi.

SoA sətri: Annex A nəzarət tədbiri | Tətbiq olunur? (Bəli/Xeyr) | Tətbiq/xaric etmə əsaslandırması | Daxili nəzarət tədbiri (mapping) | İcra statusu | Sübut mövcudluğu | İstisna varmı | Sahib | Son baxış

Funksiyalar:

• SoA versiyalaşdırılır və dondurulur (baseline): audit üçün "2026-10-01 tarixinə SoA" dəyişməz nüsxə kimi saxlanılır (hash ilə)
• SoA təsdiqi: rəhbərlik imzası (elektron təsdiq + audit qeydi)
• İki SoA versiyasının müqayisəsi (nə dəyişdi)
• İxrac: PDF (rəsmi tərtibat), XLSX
• Doldurulmamış əsaslandırmalar dərhal görünən şəkildə işarələnir

4.4.7 Control Mapping

• control_mapping (control_id, requirement_id, coverage, rationale, mapped_by, mapped_at, version, valid_from, valid_to)
• coverage: full / partial / supporting
• Bir tələb bir neçə nəzarət tədbiri ilə ödənilə bilər; bir nəzarət tədbiri bir neçə tələbi ödəyə bilər
• Versiyalaşdırma: mapping dəyişikliyi köhnə sətri valid_to ilə bağlayır, yenisini yaradır — heç nə silinmir
• Mapping təklifi (Faza 4): oxşar mətn/atribut əsasında avtomatik təklif, insan təsdiqi ilə
• Cross-framework görünüşü: bir nəzarət tədbiri seçilir → hansı framework-lərin hansı bəndlərini ödədiyi göstərilir

4.4.8 Uyğunluq balı (Compliance Score) — şəffaf hesablama

Tələb balı:
  not_applicable            → tələb bala daxil edilmir (məxrəcdən çıxarılır)
  operating_effectively     → 100
  implemented               → 80
  partially_implemented     → implementation_percentage × 0.8
  planned                   → 20
  not_implemented           → 0
  ineffective               → 10
  not_assessed              → 0  (və "qiymətləndirilməyib" sayğacına düşür)

Düzəlişlər:
  − Sübut yoxdursa və ya vaxtı keçibsə:      × 0.7
  − Aktiv istisna varsa:                      × 0.8
  − Baxış tarixi 90+ gün gecikibsə:           × 0.9
  − Açıq major nonconformity varsa:           balı 40-la məhdudlaşdır

Framework balı = Σ(tələb balı) / (tətbiq olunan tələb sayı)

Hər bal UI-da "?" ikonu ilə izah edilə bilər: hansı düzəliş tətbiq olundu və nəyə görə.

4.4.9 Məlumat obyektləri

Framework, FrameworkVersion, Domain, Requirement, RequirementCrosswalk, Control, ControlMapping, ControlAssessment, ControlTest, SoA, SoAVersion, SoAItem, ComplianceSnapshot (trend üçün gündəlik)

4.4.10 İş axını

Nəzarət tədbiri:
  Draft → Active → Under Assessment → Assessed → (Remediation Required → Remediation In Progress) → Active
        → Retired

Qiymətləndirmə (ControlAssessment):
  Planned → In Progress → Evidence Collection → Reviewed → Approved → Closed

SoA:
  Draft → Review → Approved → Baselined (frozen) → Superseded

4.4.11 Səlahiyyətlər

4.4.12 Audit hadisələri

FRAMEWORK_IMPORTED, CONTROL_CREATED, CONTROL_UPDATED, CONTROL_OWNER_CHANGED, CONTROL_APPLICABILITY_CHANGED, CONTROL_STATUS_CHANGED, CONTROL_MAPPING_CREATED, CONTROL_MAPPING_REMOVED, CONTROL_ASSESSMENT_STARTED, CONTROL_ASSESSMENT_COMPLETED, CONTROL_TEST_RECORDED, SOA_GENERATED, SOA_BASELINED, SOA_EXPORTED, COMPLIANCE_SCORE_RECALCULATED

4.4.13 API

GET  /api/v1/frameworks
POST /api/v1/frameworks/import                   # YAML/JSON
GET  /api/v1/frameworks/{id}/requirements
GET  /api/v1/frameworks/{id}/coverage            # hansı tələb örtülüb
GET  /api/v1/controls?framework=&status=&owner=&applicability=
POST /api/v1/controls
GET  /api/v1/controls/{id}
PUT  /api/v1/controls/{id}
GET  /api/v1/controls/{id}/mappings
POST /api/v1/controls/{id}/mappings              # {requirementId, coverage, rationale}
DELETE /api/v1/controls/{id}/mappings/{mid}      # soft, valid_to
GET  /api/v1/controls/{id}/evidence
POST /api/v1/controls/{id}/assessments
POST /api/v1/controls/{id}/tests
GET  /api/v1/controls/{id}/related               # risk, policy, asset, finding
GET  /api/v1/soa?frameworkId=&versionId=
POST /api/v1/soa/generate
POST /api/v1/soa/{id}/baseline                   # dondurma + hash
GET  /api/v1/soa/{id}/export?format=pdf|xlsx
GET  /api/v1/soa/compare?from=&to=
GET  /api/v1/compliance/score?frameworkId=
GET  /api/v1/compliance/score/explain?requirementId=
GET  /api/v1/compliance/gaps?frameworkId=
GET  /api/v1/compliance/trend?frameworkId=&from=&to=

4.4.14 UI səhifələri

4.4.15 Metriklər

Framework uyğunluq balı, tətbiq olunan/olunmayan tələb sayı, sübutu olmayan nəzarət tədbirləri, effektiv olmayan nəzarət tədbirləri, vaxtı keçmiş baxışlar, mapping əhatəsi (%), açıq boşluqlar və orta yaşı, audit hazırlığı balı (M06 ilə birgə).

4.4.16 Digər modullarla əlaqə

M03 (siyasət = nəzarət tədbirinin sənədləşdirilməsi), M05 (nəzarət tədbiri riski azaldır → qalıq risk), M06 (tapıntı nəzarət tədbirinə bağlanır), M07 (sübut), M08 (aktivə tətbiq olunan nəzarət), M09 (təchizatçı nəzarətləri), M10/M12 (təsnifat və DLP nəzarət tədbirləri A.5.12, A.5.13, A.8.12), M01 (A.6.3 sübutu), M16 (dashboard).

4.4.17 Qəbul meyarları

1. ISO 27001:2022-nin 93 Annex A nəzarət tədbiri + bənd 4–10 tələbləri import faylı ilə yüklənir; heç bir kod dəyişikliyi tələb olunmur.
2. not_applicable statusu əsaslandırma olmadan saxlanıla bilmir (400).
3. SoA bütün Annex A tədbirlərini əhatə edir; heç biri siyahıdan düşmür.
4. Baseline edilmiş SoA dəyişdirilə bilmir; hash ilə bütövlüyü yoxlanıla bilir.
5. Bir nəzarət tədbiri ≥ 2 framework tələbinə map edildikdə hər iki framework-in balı yenilənir.
6. Mapping silindikdə sətir fiziki silinmir, valid_to qoyulur və audit logunda görünür.
7. Uyğunluq balının izahı hər tələb üçün UI-da göstərilir.
8. Vaxtı keçmiş sübutu olan nəzarət tədbirinin balı avtomatik 0.7 əmsalı ilə azalır və bu izahda görünür.
9. Framework strukturunun (bənd nömrəsi, rəsmi başlıq) redaktəsi bütün rollar üçün bağlıdır.
10. 93 nəzarət tədbiri üçün SoA PDF-i ≤ 20 saniyədə generasiya olunur.

4.5 M05 — Risk İdarəetməsi

4.5.1 Məqsəd

İnformasiya təhlükəsizliyi risklərinin müəyyən edilməsi, təhlili, qiymətləndirilməsi, emalı və monitorinqi üçün ISO 27001 bənd 6.1 və ISO 27005 metodologiyasına uyğun vahid reyestr yaratmaq.

4.5.2 Risk metodologiyası

Risk identifikasiyası yanaşması: aktiv-təhdid-zəiflik (asset–threat–vulnerability) + ssenari əsaslı hibrid.

Risk = f(Təhdid, Zəiflik, Aktiv, Mövcud nəzarət)

İlkin risk (Inherent)  = Ehtimal(nəzarətsiz) × Təsir(nəzarətsiz)
Qalıq risk (Residual)  = İlkin risk × (1 − Nəzarətlərin effektivliyi)
Hədəf risk (Target)    = Emal planından sonra gözlənilən səviyyə

Nəzarət effektivliyi M04-dən avtomatik gəlir:

effectiveness = Σ(control.effectiveness_score × coverage_weight) / Σ(coverage_weight)
  operating_effectively = 1.0 | implemented = 0.7 | partially = 0.4 | ineffective/not_impl = 0.0

Bu avtomatik təklifdir; risk sahibi əl ilə üstündən yaza bilər (əsaslandırma ilə) — dəyər manual_override bayrağı ilə işarələnir.

4.5.3 Konfiqurasiya edilə bilən skorinq

Default 5×5 matris:

Təsir →      1(Cüzi) 2(Az)  3(Orta) 4(Ciddi) 5(Fəlakətli)
Ehtimal ↓
5 (Çox yüksək)   5     10     15      20       25
4 (Yüksək)       4      8     12      16       20
3 (Orta)         3      6      9      12       15
2 (Aşağı)        2      4      6       8       10
1 (Çox aşağı)    1      2      3       4        5

Zolaqlar: 1–4 Aşağı | 5–9 Orta | 10–15 Yüksək | 16–25 Kritik

Matris dəyişdirildikdə mövcud risklər avtomatik yenidən hesablanmır — miqrasiya sihirbazı göstərilir və dəyişiklik audit olunur (köhnə/yeni dəyərlər saxlanılır).

4.5.4 Risk sahələri (tam siyahı)

Risk kateqoriyaları (default): Kiber hücum, Zərərli proqram, Sosial mühəndislik, Daxili təhdid, Məlumat sızması, Giriş nəzarəti, Fiziki təhlükəsizlik, Fasiləsizlik/Fəlakət, Təchizatçı/Üçüncü tərəf, Uyğunluq/Hüquqi, İnsan resursu, Texnoloji köhnəlmə, Konfiqurasiya, Bulud/Hosting, Şəbəkə.

4.5.5 İş axını

Identified
  → Under Assessment
  → Assessed
  → Treatment Planning
  → Treatment In Progress   (tapşırıqlar M17-də)
  → Pending Acceptance      (qəbul seçilibsə)
  → Accepted                (müddətli; bitmə tarixi var)
  → Monitoring
  → Under Review            (dövri baxış tarixində avtomatik)
  → Closed                  (risk aradan qalxıb)
  → Reopened

Risk qəbulu (Risk Acceptance) qaydaları:

• Qalıq risk səviyyəsinə görə təsdiq: Aşağı → risk sahibi; Orta → şöbə müdiri; Yüksək → CISO; Kritik → qurum rəhbərliyi
• Qəbul həmişə müddətlidir (default maks 12 ay) və bitmə tarixində avtomatik Under Review-a keçir
• SoD-2: risk sahibi öz riskinin qəbulunu təsdiqləyə bilməz
• Qəbul edilmiş risklər ayrıca hesabatda (Risk Acceptance Report) və executive dashboard-da

4.5.6 Avtomatik risk siqnalları (Cross-module risk signals)

Bu, platformanın əsas differensiatorudur — konfiqurasiya edilə bilən qayda mühərriki.

Qayda strukturu:

rule:
  name: "Maliyyə şöbəsində BEC riskinin artması"
  trigger:
    source: phishing_campaign_completed
    condition: "department == 'Maliyyə' AND credential_submission_rate > 0.15"
  actions:
    - recalculate_risk: { risk_id: RSK-2026-0014, likelihood_delta: +1, reason_template: "..." }
    - notify: { recipients: [risk_owner, ciso], template: risk_signal_alert }
    - assign_training: { program: "BEC və ödəniş fırıldağı", audience: department, due_days: 14 }
    - create_task: { title: "Maliyyə şöbəsi üçün əlavə nəzarət", owner: risk_owner, due_days: 30 }
    - dashboard_alert: { severity: high }
  mode: require_approval        # auto | require_approval
  approver_role: risk_manager

Hazır siqnal şablonları (default):

Vacib: mode: require_approval defaultdur — sistem avtomatik risk balını dəyişmir, risk menecerinə təklif göndərir ("Təklif olunan dəyişiklik: ehtimal 3 → 4. Səbəb: ... Qəbul et / Rədd et"). Qəbul edildikdə dəyişiklik RiskAssessment tarixçəsinə source: automated_signal ilə yazılır.

4.5.7 Vizualizasiya

• Risk istilik xəritəsi: 5×5 matris, hər xanada risk sayı + kliklə drill-down. Accessibility: rəng + rəqəm + naxış (pattern)
• İlkin vs qalıq müqayisəsi (eyni matris üzərində iki nöqtə, oxla birləşdirilmiş)
• Risk trendi (aylıq snapshot əsasında: ümumi risk sayı, yüksək/kritik sayı, orta qalıq bal)
• Şöbə risk profili (radar və ya bar)
• Emal irəliləyişi (burn-down: planlanmış vs icra olunmuş)
• Top 10 risk (executive üçün)

4.5.8 Məlumat obyektləri

Risk, RiskAssessment (tarixçəli qiymətləndirmələr), RiskTreatment, RiskAcceptance, RiskCategory, RiskMatrix, RiskScaleLevel, RiskSignalRule, RiskSignalEvent, RiskComment, RiskAttachment, RiskSnapshot (trend), ThreatCatalog, VulnerabilityCatalog

4.5.9 Səlahiyyətlər

4.5.10 Audit hadisələri

RISK_CREATED, RISK_UPDATED, RISK_ASSESSED, RISK_SCORE_CHANGED (köhnə/yeni dəyərlərlə), RISK_OWNER_CHANGED, RISK_TREATMENT_PLANNED, RISK_TREATMENT_COMPLETED, RISK_ACCEPTED, RISK_ACCEPTANCE_EXPIRED, RISK_CLOSED, RISK_REOPENED, RISK_MATRIX_CHANGED, RISK_SIGNAL_TRIGGERED, RISK_SIGNAL_APPROVED, RISK_SIGNAL_REJECTED, RISK_MANUAL_OVERRIDE (avtomatik hesablamanın üstündən yazma)

4.5.11 API

GET   /api/v1/risks?level=&status=&owner=&department=&category=&search=
POST  /api/v1/risks
GET   /api/v1/risks/{id}
PUT   /api/v1/risks/{id}
GET   /api/v1/risks/{id}/assessments               # tarixçə
POST  /api/v1/risks/{id}/assessments
POST  /api/v1/risks/{id}/treatment
POST  /api/v1/risks/{id}/accept                    # SoD yoxlanır
POST  /api/v1/risks/{id}/close
POST  /api/v1/risks/{id}/reopen
GET   /api/v1/risks/{id}/related
POST  /api/v1/risks/{id}/recalculate               # nəzarət effektivliyindən
GET   /api/v1/risks/heatmap?department=&category=
GET   /api/v1/risks/trend?from=&to=
GET   /api/v1/risks/top?n=10
GET   /api/v1/risk-matrix
PUT   /api/v1/risk-matrix                          # admin, miqrasiya sihirbazı
GET   /api/v1/risk-categories
GET   /api/v1/risk-signals/rules
POST  /api/v1/risk-signals/rules
GET   /api/v1/risk-signals/pending                 # təsdiq gözləyən təkliflər
POST  /api/v1/risk-signals/{id}/approve
POST  /api/v1/risk-signals/{id}/reject
GET   /api/v1/reports/risk-register?format=xlsx|pdf

4.5.12 UI səhifələri

4.5.13 Metriklər

Ümumi risk sayı (səviyyə üzrə), orta qalıq bal, iştahadan yuxarı risklərin sayı, emalı gecikmiş risklər, vaxtı keçmiş baxışlar, qəbul edilmiş risklərin sayı və dəyəri, risk azalma trendi (ilkin→qalıq fərqi), şöbə üzrə risk profili, avtomatik siqnalların sayı və qəbul faizi.

4.5.14 Digər modullarla əlaqə

M04 (nəzarət effektivliyi → qalıq risk; risk → nəzarətin əsaslandırılması), M02 (fişinq → insan riski → BEC riski), M13 (DLP hadisə → məlumat riski), M06 (tapıntı → risk), M08 (aktiv kritikliyi → təsir), M09 (təchizatçı riski), M03 (istisna → risk), M17 (emal tapşırıqları), M16 (dashboard).

4.5.15 Qəbul meyarları

1. Risk matrisi 3×3, 5×5 və custom formalarda konfiqurasiya edilə bilir; dəyişiklik audit olunur və mövcud risklər avtomatik dəyişmir.
2. Qalıq risk nəzarət effektivliyindən avtomatik hesablanır; əl ilə üstündən yazma əsaslandırma tələb edir və manual_override işarəsi ilə görünür.
3. Risk sahibi öz riskinin qəbulunu təsdiqləyə bilmir (403 + SoD audit qeydi).
4. Risk qəbulunun müddəti bitdikdə status avtomatik Under Review olur və bildiriş gedir.
5. Fişinq kampaniyası bitdikdə konfiqurasiya olunmuş siqnal qaydası işə düşür və require_approval rejimində risk balını dəyişmir, yalnız təklif yaradır.
6. Siqnal təklifi qəbul edildikdə RiskAssessment tarixçəsində source=automated_signal ilə yeni sətir yaranır.
7. İstilik xəritəsi yalnız rəngə əsaslanmır — hər xanada rəqəm və naxış var (WCAG testi).
8. Risk reyestri XLSX ixracında bütün sahələr və əlaqəli obyekt ID-ləri mövcuddur.
9. Risk sahibi başqasının riskini API ilə redaktə edə bilmir (403).
10. 1 000 riskdən ibarət reyestrdə filtr + sıralama ≤ 1 saniyə cavab verir.

4.6 M06 — Audit İdarəetməsi

4.6.1 Məqsəd

Daxili audit proqramının planlaşdırılması, icrası, tapıntıların idarə edilməsi və düzəldici tədbirlərin izlənməsi (ISO 27001 bənd 9.2 — Daxili audit, bənd 10.2 — Uyğunsuzluq və düzəldici tədbir).

4.6.2 İstifadəçilər

Daxili auditor, audit rəhbəri, auditee (yoxlanan şöbə/nəzarət tədbirinin sahibi), Compliance Officer, xarici auditor (məhdud), rəhbərlik.

4.6.3 Funksiyalar

Planlaşdırma

• İllik audit planı: dövr, əhatə olunacak sahələr, resurs, risk əsaslı prioritetləşdirmə
• Risk əsaslı skoup təklifi: yüksək qalıq riskli sahələr, əvvəlki tapıntıları olan sahələr, son audit tarixindən keçən müddət
• Audit planının təsdiqi (rəhbərlik) və versiyalaşdırılması
• Audit təqvimi (Gantt görünüşü)

Audit (Engagement)

İcra

• Audit checklist: nəzarət tədbirlərindən avtomatik generasiya (skoupdakı hər nəzarət üçün bir sətir) + əl ilə əlavə
• Sətir: tələb / sual / test proseduru / nəticə (uyğun / uyğunsuz / qismən / tətbiq olunmur) / qeyd / sübut
• Müsahibə qeydləri: kim, nə vaxt, mövzu, qeydlər, iştirakçılar (məxfi — yalnız audit komandası)
• Sübut sorğusu (Evidence Request): auditor → auditee, deadline, statusla izlənir (M07 ilə inteqrasiya)
• Seçmə (Sampling): populyasiya ölçüsü, seçmə metodu (təsadüfi / sistematik / risk əsaslı), seçmə ölçüsü, seçilmiş elementlər, nəticələr
• İş kağızları (Working papers): auditorun daxili sənədləri — auditee görmür
• Audit vaxt qeydiyyatı (opsional)

Tapıntılar

Tapıntı sahələri: finding_id (FND-YYYY-NNN), başlıq, təsvir, tip, meyar (hansı tələb pozulub), sübut, təsir, risk əlaqəsi, nəzarət tədbiri əlaqəsi, auditee, sahib, deadline, status, aşkarlanma tarixi.

Kök səbəb analizi (RCA): metod seçimi (5 Why / Ishikawa / Fault Tree), addımlar, nəticə kök səbəb, kateqoriya (proses / insan / texnologiya / idarəetmə / xarici).

Düzəldici tədbir planı (CAP):

• Dərhal tədbir (correction) — nəticənin aradan qaldırılması
• Düzəldici tədbir (corrective action) — kök səbəbin aradan qaldırılması
• Profilaktik tədbir (opsional)
• Hər biri üçün: məsul, müddət, resurs, gözlənilən nəticə, tapşırıq (M17)
• Effektivliyin yoxlanması tarixi

4.6.4 Tapıntı iş axını

Draft
 → Auditor Review        (audit rəhbərinin yoxlaması)
 → Issued                (auditee-yə rəsmi verilir, SLA saatı başlayır)
 → Management Response   (auditee razılaşır / etiraz edir, RCA təqdim edir)
    ├─ Disputed → Auditor Review (yenidən)
 → Corrective Action Planned
 → Corrective Action In Progress
 → Evidence Submitted
 → Auditor Verification
    ├─ Verified → Closed
    └─ Not Verified → Reopened → Corrective Action In Progress
 → Closed
 → (Effectiveness Review, 3–6 ay sonra) → Confirmed Closed | Reopened

4.6.5 Audit iş axını

Planned → Scheduled → Opening Meeting → Fieldwork → Findings Drafted
 → Closing Meeting → Draft Report → Report Review → Report Issued
 → Follow-up → Closed

4.6.6 Audit hazırlığı balı (Audit Readiness Score) — şəffaf hesablama

Audit Readiness Score (0–100) = Σ(komponent × çəki)

1. Nəzarət tədbirlərinin icrası      30%
   = Σ(control implementation score) / control count   (M04 §4.4.8 ilə eyni bal)

2. Sübut tamlığı                     25%
   = (sübutu olan və vaxtı keçməmiş nəzarət tədbirləri) / (tətbiq olunan nəzarət tədbirləri)

3. Sənəd tamlığı                     15%
   = (aktual, təsdiqlənmiş, baxış tarixi keçməmiş məcburi sənədlər) / (tələb olunan sənədlər)
   × tanışlıq faizi (≥95% → 1.0, 80-95% → 0.9, <80% → 0.75)

4. Açıq tapıntılar                   15%
   = 100 − (major × 20 + minor × 8 + observation × 3), minimum 0
   + gecikmiş tapıntılar üçün əlavə cəza: hər gecikmiş major −10

5. Risk idarəetməsinin aktuallığı    10%
   = (baxış tarixi keçməmiş risklər) / (ümumi risklər)
   × (emalı gecikməmiş risklər) / (emal tələb edən risklər)

6. Təlim və maarifləndirmə            5%
   = məcburi təlimlərin tamamlanma faizi

Düzəliş: aktiv major nonconformity varsa ümumi bal 60-la məhdudlaşdırılır.

Şəffaflıq: /compliance/audit-readiness səhifəsində hər komponentin dəyəri, çəkisi, töhfəsi və "nəyi düzəltsəm nə qədər artar" simulyasiyası göstərilir.

4.6.7 Məlumat obyektləri

AuditPlan, Audit, AuditScope, AuditTeamMember, AuditChecklist, AuditChecklistItem, AuditInterview, AuditSample, WorkingPaper, AuditFinding, RootCauseAnalysis, CorrectiveAction, AuditReport, AuditFollowUp, AuditReadinessSnapshot

4.6.8 Səlahiyyətlər

4.6.9 Audit hadisələri

AUDIT_PLAN_CREATED, AUDIT_PLAN_APPROVED, AUDIT_CREATED, AUDIT_STARTED, AUDIT_SCOPE_CHANGED, AUDITOR_ASSIGNED, CHECKLIST_ITEM_COMPLETED, WORKING_PAPER_CREATED, WORKING_PAPER_VIEWED, INTERVIEW_RECORDED, EVIDENCE_REQUESTED, FINDING_CREATED, FINDING_ISSUED, FINDING_DISPUTED, MANAGEMENT_RESPONSE_SUBMITTED, RCA_SUBMITTED, CORRECTIVE_ACTION_CREATED, CORRECTIVE_ACTION_COMPLETED, FINDING_VERIFIED, FINDING_CLOSED, FINDING_REOPENED, AUDIT_REPORT_ISSUED, EXTERNAL_AUDITOR_ACCESS_GRANTED, EXTERNAL_AUDITOR_ACCESS_REVOKED

4.6.10 API

GET  /api/v1/audit-plans
POST /api/v1/audit-plans
POST /api/v1/audit-plans/{id}/approve
GET  /api/v1/audits?status=&year=&type=
POST /api/v1/audits
GET  /api/v1/audits/{id}
POST /api/v1/audits/{id}/start
GET  /api/v1/audits/{id}/checklist
POST /api/v1/audits/{id}/checklist/generate       # skoupdan avtomatik
PATCH /api/v1/audits/{id}/checklist/{itemId}
GET  /api/v1/audits/{id}/working-papers
POST /api/v1/audits/{id}/working-papers
POST /api/v1/audits/{id}/interviews
POST /api/v1/audits/{id}/samples
POST /api/v1/audits/{id}/evidence-requests
GET  /api/v1/audits/{id}/report
POST /api/v1/audits/{id}/report/issue
GET  /api/v1/findings?type=&status=&overdue=true&department=
POST /api/v1/findings
POST /api/v1/findings/{id}/issue
POST /api/v1/findings/{id}/response                # auditee
POST /api/v1/findings/{id}/rca
POST /api/v1/findings/{id}/corrective-actions
POST /api/v1/findings/{id}/submit-evidence
POST /api/v1/findings/{id}/verify                  # SoD-7 yoxlanır
POST /api/v1/findings/{id}/close
POST /api/v1/findings/{id}/reopen
GET  /api/v1/compliance/audit-readiness
GET  /api/v1/compliance/audit-readiness/explain
GET  /api/v1/compliance/audit-readiness/simulate?controlId=&newStatus=

4.6.11 UI səhifələri

/audits (siyahı + təqvim), /audits/{id} (Ümumi / Skoup / Checklist / Müsahibələr / Seçmələr / İş kağızları / Tapıntılar / Hesabat), /audits/{id}/checklist (iki panelli: sətir siyahısı + detal), /findings (cədvəl, gecikmiş qırmızı + ikon), /findings/{id} (Tapıntı / Cavab / RCA / Düzəldici tədbirlər / Sübut / Yoxlama / Tarixçə), /my/findings (auditee üçün), /compliance/audit-readiness (bal + komponentlər + simulyasiya), /admin/audits/plan.

4.6.12 Metriklər

Planlanmış vs icra olunmuş auditlər, tapıntı sayı (tip üzrə), açıq/gecikmiş tapıntılar, orta bağlanma müddəti, təkrar açılan tapıntı faizi, şöbə üzrə tapıntı sıxlığı, audit hazırlığı balı və trendi, düzəldici tədbirlərin vaxtında icrası.

4.6.13 Digər modullarla əlaqə

M04 (nəzarət tədbiri ← checklist, tapıntı → status), M05 (tapıntı → risk), M07 (sübut sorğusu), M17 (düzəldici tədbir tapşırığı), M03 (siyasət meyarı), M09 (təchizatçı auditi), M16 (dashboard).

4.6.14 Qəbul meyarları

1. Audit skoupundan checklist avtomatik generasiya olunur (hər nəzarət tədbiri üçün sətir).
2. Auditor öz sahibi olduğu nəzarət tədbirinin auditinə təyin edilə bilmir (SoD-3, 403).
3. Düzəldici tədbiri icra edən şəxs onu yoxlaya bilmir (SoD-7, 403).
4. İş kağızları və müsahibə qeydləri auditee rolu tərəfindən API ilə də açıla bilmir (403).
5. Major nonconformity yaradıldıqda dərhal bildiriş + 15 günlük SLA sayğacı başlayır.
6. Tapıntı SLA-nı keçdikdə avtomatik eskalasiya (sahib → müdir → CISO) işə düşür.
7. Audit hazırlığı balının hər komponenti izah səhifəsində rəqəmlə göstərilir.
8. Xarici auditorun girişi yalnız təyin olunmuş audit skoupu ilə məhdudlaşır və müddəti bitdikdə avtomatik ləğv olunur.
9. Xarici auditorun hər sübut baxışı/yükləməsi audit logunda qeyd olunur.
10. Audit hesabatı PDF-i tapıntıları, RCA-nı və düzəldici tədbirləri əhatə edir.

4.7 M07 — Sübut İdarəetməsi

4.7.1 Məqsəd

Uyğunluğun sübutunu mərkəzləşdirilmiş, təhlükəsiz, versiyalanmış və bütövlüyü yoxlanıla bilən şəkildə saxlamaq; sübut vaxtı keçdikdə uyğunluq balına və audit hazırlığına avtomatik təsir etmək.

4.7.2 Sübut tipləri

4.7.3 Sahələr

evidence_id (EVD-YYYY-NNNNN), başlıq, təsvir, tip, mənbə (source_system), sahib, toplayan, toplanma tarixi, valid_from, valid_until, expiration_date, avtomatik yenilənmə tezliyi, təsnifat səviyyəsi (M10), status, rəyçi, təsdiq tarixi, versiya, file_hash (SHA-256), file_size, mime_type, malware_scan_status, malware_scan_at, əlaqəli nəzarət tədbirləri[], risklər[], siyasətlər[], aktivlər[], auditlər[], tapıntılar[], teqlər[].

4.7.4 Funksiyalar

• Yükləmə: drag-and-drop, çoxlu fayl, toplu metadata təyinatı
• Sübut sorğusu (Evidence Request): auditor/compliance → sahib; deadline, təsvir, tələb olunan format; statusla izlənir; xatırlatma və eskalasiya
• Versiyalaşdırma: eyni sübutun yeni dövr üçün yenilənməsi; köhnə versiya saxlanılır
• Bütövlük: yükləmədə SHA-256 hesablanır və saxlanılır; dövri fon işi (həftəlik) bütün faylların hashını yenidən hesablayır və uyğunsuzluqda kritik alarm yaradır
• Vaxtı bitmə: valid_until − 30/14/7 gün bildiriş; keçdikdə status Expired → əlaqəli nəzarət tədbirinin balı düşür
• Təkrar istifadə: bir sübut N nəzarət tədbirinə, M framework tələbinə bağlana bilər
• Önizləmə: PDF/şəkil brauzerdə (sandboxed iframe, ayrıca origin), Office faylları üçün yalnız yükləmə və ya server-side render (Faza 2)
• Axtarış: metadata + fayl mətni (OCR/text extraction, OpenSearch)
• Toplu əməliyyatlar: teq əlavə et, sahib dəyiş, nəzarət tədbirinə bağla, ixrac

4.7.5 🔒 Təhlükəsizlik tələbləri (normativ)

4.7.6 İş axını

Sübut:         Draft → Submitted → Under Review → Approved → Active → Expiring → Expired → Renewed/Archived
                                        └→ Rejected → Draft
Sübut sorğusu: Requested → Acknowledged → In Progress → Submitted → Accepted | Rejected → Closed
                     └(deadline) → Overdue → Escalated

4.7.7 Səlahiyyətlər

4.7.8 Audit hadisələri

EVIDENCE_UPLOADED, EVIDENCE_METADATA_UPDATED, EVIDENCE_VERSION_CREATED, EVIDENCE_APPROVED, EVIDENCE_REJECTED, EVIDENCE_PREVIEWED, EVIDENCE_DOWNLOADED, EVIDENCE_LINKED, EVIDENCE_UNLINKED, EVIDENCE_EXPIRED, EVIDENCE_DELETED, EVIDENCE_INTEGRITY_CHECK_FAILED, EVIDENCE_MALWARE_DETECTED, EVIDENCE_REQUEST_CREATED, EVIDENCE_REQUEST_FULFILLED, EVIDENCE_REQUEST_OVERDUE, EVIDENCE_CLASSIFICATION_CHANGED

4.7.9 API

GET    /api/v1/evidence?control=&risk=&status=&expiring=30d&classification=
POST   /api/v1/evidence                          # multipart; virus scan sinxron/asinxron
GET    /api/v1/evidence/{id}
PUT    /api/v1/evidence/{id}                     # metadata
POST   /api/v1/evidence/{id}/versions
GET    /api/v1/evidence/{id}/preview-url         # qısamüddətli imzalı URL
GET    /api/v1/evidence/{id}/download-url        # ayrıca permission + səbəb
POST   /api/v1/evidence/{id}/approve
POST   /api/v1/evidence/{id}/reject
POST   /api/v1/evidence/{id}/links               # {objectType, objectId}
DELETE /api/v1/evidence/{id}/links/{linkId}
GET    /api/v1/evidence/{id}/integrity           # hash yoxlaması
POST   /api/v1/evidence/bulk-link
GET    /api/v1/evidence-requests
POST   /api/v1/evidence-requests
POST   /api/v1/evidence-requests/{id}/fulfill
GET    /api/v1/reports/evidence-expiration

4.7.10 UI səhifələri

/evidence (cədvəl + filtr: bitmə tarixi, təsnifat, nəzarət tədbiri; sütunda bitmə xəbərdarlığı ikonu), /evidence/{id} (metadata + önizləmə + əlaqələr + versiyalar + giriş tarixçəsi), /evidence/upload (drag-drop + toplu metadata), /evidence/requests (mənə gələn / mənim göndərdiyim), /evidence/expiring (dashboard widget-dən keçid).

4.7.11 Metriklər

Ümumi sübut sayı, sübutu olmayan nəzarət tədbirləri, 30/60/90 gün ərzində bitən sübutlar, vaxtı keçmiş sübutlar, sübut sorğularının orta yerinə yetirilmə müddəti, gecikmiş sorğular, bütövlük yoxlaması uğursuzluqları, avtomatik toplanmış sübut faizi (Faza 4 hədəfi ≥ 40%).

4.7.12 Qəbul meyarları

1. Zərərli proqram aşkarlandıqda fayl karantinə alınır, heç bir istifadəçiyə əlçatan olmur və dərhal alarm göndərilir.
2. Fayl uzantısı ilə magic bytes uyğun gəlmədikdə yükləmə rədd edilir (400).
3. Yükləmə URL-i 5 dəqiqədən sonra işləmir (401/403).
4. Məxfi təsnifatlı sübutu platform_admin avtomatik olaraq önizləyə/yükləyə bilmir (403).
5. Hər önizləmə və yükləmə audit logunda kim/nə vaxt/IP ilə görünür.
6. Fayl hash-ı saxlamada dəyişdikdə həftəlik yoxlama uğursuz olur və kritik alarm yaranır.
7. Sübut Expired olduqda əlaqəli nəzarət tədbirinin uyğunluq balı avtomatik azalır və izahda görünür.
8. Sübut sahibi öz sübutunu təsdiqləyə bilmir (SoD-9).
9. Zip bomb faylı yükləndikdə sistem qorunur (limitlər tətbiq olunur, xəta qaytarılır).
10. Sübut heç bir rol tərəfindən fiziki silinə bilmir; yalnız soft delete + səbəb.

4.8 M08 — Aktiv və Sahiblik Reyestri

4.8.1 Məqsəd

GRC üçün kifayət edən yüngül aktiv reyestri — tam CMDB deyil. Məqsəd: aktiv sahibliyi, kritikliyi, təsnifatı və nəzarət/risk əlaqələrini müəyyən etmək (ISO 27001 A.5.9–A.5.13).

Skoup qərarı: CMDB funksiyaları (avtomatik discovery, konfiqurasiya elementlərinin dərin əlaqələri, dəyişikliklərin idarəolunması) daxil deyil. Mövcud CMDB varsa, ondan import (CSV / API) dəstəklənir.

4.8.2 Aktiv tipləri

application, server, virtual_machine, cloud_service, network_device, database, storage, endpoint_group (fərdi endpoint yox, qrup), information_asset (məlumat toplusu), business_process, physical_location, vendor_service, department, document_repository

4.8.3 Sahələr

asset_id (AST-NNNNN), ad, təsvir, tip, alt-tip, sahib (biznes sahibi), custodian (texniki saxlayıcı), departament, təşkilati vahid, yer, mühit (prod/test/dev/dr), kritiklik (1–5 və ya Aşağı–Kritik), məlumat təsnifatı (M10), CIA tələbləri (C/I/A ayrı-ayrılıqda 1–5), RTO, RPO, əlaqəli risklər[], əlaqəli nəzarət tədbirləri[], əlaqəli təchizatçılar[], əlaqəli siyasətlər[], əlaqəli sübutlar[], həyat dövrü statusu (planned / in_procurement / active / deprecated / decommissioned), istismara verilmə tarixi, baxış tarixi, xarici sistem ID-si (CMDB korrelyasiyası üçün), teqlər.

Kritikliyin avtomatik təklifi: criticality = max(C, I, A) ilə korrelyasiya + əlaqəli biznes prosesinin kritikliyi. Təklif göstərilir, sahib təsdiqləyir.

4.8.4 Funksiyalar

• Əl ilə yaratma + CSV/XLSX import (mapping sihirbazı ilə) + API import
• Aktiv ağacı: biznes prosesi → tətbiq → server → verilənlər bazası (asılılıq əlaqələri, sadə N:M)
• Sahiblik attestasiyası: dövri (illik) — sahibə "bu aktivin sahibi hələ də sizsiniz?" sorğusu; təsdiq və ya ötürmə
• Aktiv üzrə risk və nəzarət əhatəsi göstəricisi ("bu aktiv üçün 0 nəzarət tədbiri var" xəbərdarlığı)
• Həyat dövrünün sonu: decommissioned edildikdə əlaqəli risklərin, sübutların statusunun yoxlanması tapşırığı
• Məlumat aktivi üçün əlavə: məlumat tipləri (M11), saxlanma müddəti, məlumat sahibi, hüquqi əsas

4.8.5 Səlahiyyətlər

4.8.6 Audit hadisələri

ASSET_CREATED, ASSET_UPDATED, ASSET_OWNER_CHANGED, ASSET_CRITICALITY_CHANGED, ASSET_CLASSIFICATION_CHANGED, ASSET_DECOMMISSIONED, ASSET_IMPORTED, ASSET_OWNERSHIP_ATTESTED, ASSET_LINKED

4.8.7 API

GET  /api/v1/assets?type=&criticality=&owner=&department=&classification=
POST /api/v1/assets
GET  /api/v1/assets/{id}
PUT  /api/v1/assets/{id}
GET  /api/v1/assets/{id}/related            # risk, control, vendor, evidence
POST /api/v1/assets/{id}/transfer-ownership
POST /api/v1/assets/{id}/attest
POST /api/v1/assets/import                  # CSV/XLSX
GET  /api/v1/assets/coverage                # nəzarət/risk əhatəsi olmayan aktivlər
GET  /api/v1/reports/asset-register?format=xlsx

4.8.8 UI səhifələri

/assets (cədvəl + qrup görünüşü), /assets/{id} (Ümumi / CIA / Risklər / Nəzarət tədbirləri / Təchizatçılar / Sübutlar / Tarixçə), /assets/import, /assets/coverage (boşluqlar), /my/assets (sahib üçün + attestasiya sorğuları).

4.8.9 Metriklər

Aktiv sayı (tip/kritiklik üzrə), sahibi olmayan aktivlər, təsnifatı olmayan aktivlər, nəzarət tədbiri olmayan kritik aktivlər, baxış tarixi keçmiş aktivlər, attestasiya tamamlanma faizi.

4.8.10 Qəbul meyarları

1. Sahibi və ya təsnifatı olmayan aktiv active statusuna keçə bilmir.
2. Kritik aktivə bağlı ən azı bir nəzarət tədbiri yoxdursa boşluq hesabatında görünür.
3. Sahibliyin ötürülməsi yeni sahibin qəbulunu tələb edir (iki addımlı).
4. CSV import ≤ 5 000 sətir üçün ≤ 60 saniyə, xəta sətirləri ayrıca hesabatda.
5. Aktivin kritikliyi dəyişdikdə əlaqəli risklərin yenidən qiymətləndirilməsi üçün siqnal yaranır.

4.9 M09 — Təchizatçı Riskinin İdarəetməsi

4.9.1 Məqsəd

Üçüncü tərəflərin (təchizatçı, podratçı, xidmət provayderi, bulud provayderi) informasiya təhlükəsizliyi risklərini qiymətləndirmək və izləmək (ISO 27001 A.5.19–A.5.23).

4.9.2 Təchizatçı profili

vendor_id (VND-NNNN), ad, VÖEN/qeydiyyat nömrəsi, kateqoriya (İT xidməti / proqram təminatı / bulud / autsorsinq / konsaltinq / avadanlıq / təmizlik-fiziki giriş / digər), daxili sahib (vendor_owner), əlaqə şəxsləri, göstərilən xidmət, kritiklik (biznes üçün), məlumat girişi səviyyəsi (yoxdur / metadata / daxili / şəxsi məlumat / məxfi / xüsusi əhəmiyyətli), sistem girişi (yoxdur / oxuma / yazma / inzibati / fiziki), hosting yeri (ölkə, data mərkəzi), subprosessorlar, müqavilə nömrəsi/başlanğıc/bitmə/avtomatik uzadılma, NDA (var/yox, tarix), DPA (var/yox, tarix), sertifikatlar (ISO 27001, ISO 9001, SOC 2, PCI DSS — nömrə, orqan, etibarlılıq müddəti, sənəd), SLA, çıxış (offboarding) statusu, risk balı, son qiymətləndirmə tarixi, növbəti qiymətləndirmə tarixi.

4.9.3 Təhlükəsizlik sorğu vərəqəsi (Questionnaire)

• Şablon qurucusu: bölmələr, suallar (bəli/xeyr, çoxvariantlı, sərbəst mətn, fayl tələbi, rəqəm), hər cavab üçün risk çəkisi və bayraq (red_flag)
• Şablon nümunələri: Qısa (25 sual, aşağı kritiklik), Standart (60 sual), Genişləndirilmiş (120+ sual, kritik təchizatçılar), Bulud xidməti üçün xüsusi, Şəxsi məlumat emalı üçün xüsusi
• Şablonlar ISO 27001 Annex A domenlərinə map edilir
• Göndərmə: təchizatçıya xarici portal linki (token ilə, autentifikasiyasız, müddətli) və ya daxili istifadəçi kimi
• Təchizatçı cavabları + sübut faylları yükləyir
• Qismən yadda saxlama, deadline, xatırlatma
• Cavabların rəyi: daxili qiymətləndirici hər cavabı qəbul edir / dəqiqləşdirmə istəyir / tapıntı yaradır

⚠️ Təhlükəsizlik qeydi: xarici portal internetə açıq olmalıdırsa, ayrıca DMZ-də yerləşən, əsas platformadan izolyasiya olunmuş komponent kimi (yalnız API vasitəsilə) yerləşdirilməlidir. Alternativ: sorğu vərəqəsini XLSX kimi göndərmək və cavabı import etmək (internetsiz mühit üçün default).

4.9.4 Risk balı

Vendor Risk Score (0–100) =
    0.30 × İnherent risk (kritiklik × məlumat girişi × sistem girişi)
  + 0.40 × Sorğu vərəqəsi balı (100 − Σ(çəkili mənfi cavablar))
  + 0.15 × Sertifikat/sənəd tamlığı (ISO/SOC/NDA/DPA var və etibarlıdır)
  + 0.15 × Açıq tapıntılar (major −25, minor −10 hər biri)

Düzəliş: red_flag cavab varsa → minimum "Yüksək" səviyyə (avtomatik eskalasiya)
Zolaqlar: 0–24 Aşağı | 25–49 Orta | 50–74 Yüksək | 75–100 Kritik

4.9.5 İş axını

Təchizatçı:      Prospective → Under Assessment → Approved → Active
                    → Conditionally Approved (tapıntılarla) → Under Remediation
                    → Suspended → Offboarding → Terminated
Qiymətləndirmə:  Initiated → Questionnaire Sent → In Progress → Submitted
                    → Under Review → Findings Raised → Remediation → Completed → Approved/Rejected

Offboarding checklist: girişlərin ləğvi, məlumatların geri qaytarılması/məhvi (sertifikat tələbi), açarların ləğvi, NDA-nın davam edən öhdəlikləri, aktiv reyestrinin yenilənməsi, müqavilənin bağlanması sənədi.

4.9.6 Avtomatik xəbərdarlıqlar

Müqavilə bitməsinə 90/60/30 gün, sertifikat bitməsinə 60/30 gün, illik yenidən qiymətləndirmə tarixi, DPA/NDA yoxdur + şəxsi məlumat girişi var (dərhal), təchizatçı tərəfli təhlükəsizlik hadisəsi qeyd edildi.

4.9.7 Səlahiyyətlər

4.9.8 Audit hadisələri

VENDOR_CREATED, VENDOR_UPDATED, VENDOR_CRITICALITY_CHANGED, VENDOR_ASSESSMENT_INITIATED, QUESTIONNAIRE_SENT, QUESTIONNAIRE_SUBMITTED, QUESTIONNAIRE_REVIEWED, VENDOR_RISK_SCORE_CHANGED, VENDOR_APPROVED, VENDOR_REJECTED, VENDOR_SUSPENDED, VENDOR_OFFBOARDING_STARTED, VENDOR_OFFBOARDING_COMPLETED, VENDOR_DOCUMENT_UPLOADED, VENDOR_PORTAL_TOKEN_ISSUED, VENDOR_PORTAL_ACCESS

4.9.9 API

GET  /api/v1/vendors?criticality=&riskLevel=&category=&contractExpiring=90d
POST /api/v1/vendors
GET  /api/v1/vendors/{id}
PUT  /api/v1/vendors/{id}
GET  /api/v1/vendors/{id}/assessments
POST /api/v1/vendors/{id}/assessments
POST /api/v1/vendors/{id}/assessments/{aid}/send-questionnaire
GET  /api/v1/vendors/{id}/documents
POST /api/v1/vendors/{id}/documents
POST /api/v1/vendors/{id}/offboard
GET  /api/v1/questionnaire-templates
POST /api/v1/questionnaire-templates
GET  /api/v1/reports/vendor-risk?format=xlsx|pdf

# Xarici portal (ayrıca servis, token auth, rate limited):
GET  /vendor-portal/{token}
POST /vendor-portal/{token}/answers
POST /vendor-portal/{token}/documents
POST /vendor-portal/{token}/submit

4.9.10 UI səhifələri

/vendors (cədvəl: ad, kritiklik, risk balı+zolaq, müqavilə bitmə, son qiymətləndirmə), /vendors/{id} (Profil / Müqavilə / Sənədlər / Qiymətləndirmələr / Tapıntılar / Risklər / Aktivlər / Tarixçə), /vendors/{id}/assessments/{aid} (sorğu cavabları + rəy paneli), /admin/vendors/questionnaires (şablon qurucusu), /vendors/expiring (müqavilə/sertifikat xəbərdarlıqları).

4.9.11 Metriklər

Təchizatçı sayı (kritiklik/risk zolağı üzrə), qiymətləndirilməmiş kritik təchizatçılar, gecikmiş yenidən qiymətləndirmələr, 90 gün ərzində bitən müqavilələr/sertifikatlar, açıq təchizatçı tapıntıları, DPA/NDA olmayan şəxsi məlumat emalçıları, orta təchizatçı risk balı və trendi.

4.9.12 Qəbul meyarları

1. Şəxsi məlumata girişi olan təchizatçı DPA olmadan Approved statusuna keçə bilmir.
2. red_flag cavab avtomatik olaraq risk səviyyəsini minimum "Yüksək" edir və bildiriş göndərir.
3. Sorğu vərəqəsi tokeni müddətli və birdəfəlikdir; müddəti bitdikdən sonra 403.
4. Xarici portal əsas platformanın verilənlər bazasına birbaşa girişə malik deyil (arxitektura yoxlaması).
5. Sertifikat bitmə tarixi keçdikdə təchizatçının risk balı avtomatik yenilənir.
6. Offboarding checklist-inin bütün bəndləri tamamlanmadan təchizatçı Terminated olmur.

4.10 M10 — Məlumat Təsnifatı

4.10.1 Məqsəd

DLP-nin bünövrəsi. Qurumun məlumatlarını rəsmi taksonomiya üzrə təsnif etmək, hər səviyyə üçün istifadə qaydalarını müəyyən etmək və bu qaydaları texniki icraya (DLP, şifrələmə, saxlama) çevirmək (ISO 27001 A.5.12, A.5.13, A.5.14).

Kritik prinsip: DLP təsnifat olmadan işləmir. Təsnifat taksonomiyası Faza 3-ün birinci işi, DLP qaydaları isə ikincidir.

4.10.2 Təsnifat səviyyələri (ilkin nümunə — konfiqurasiya edilə bilən)

Konfiqurasiya edilə bilir: səviyyələrin sayı, adları, kodları, rəngləri, ardıcıllığı. Dövlət qurumunun rəsmi terminologiyası (məsələn qanunvericiliklə müəyyən edilmiş "xidməti istifadə üçün" kimi terminlər) tətbiq oluna bilər.

4.10.3 Hər səviyyə üçün siyasət konfiqurasiyası

4.10.4 Təsnifatın tətbiqi

Obyektlər: sənəd (M03), sübut (M07), aktiv (M08), məlumat toplusu (data inventory), DLP hadisəsi (M13), hesabat, ixrac faylı.

Üsullar:

Yüksəltmə (upgrade): sərbəst — istənilən istifadəçi öz obyektinin təsnifatını yüksəldə bilər. Endirmə (downgrade): həmişə təsdiq tələb edir — məlumat sahibi (data_owner) və ya təsnifat administratoru. Əsaslandırma məcburi. Audit olunur.

Yenidən təsnifat (reclassification): dövri baxış tarixi (səviyyəyə görə), məlumatın aktuallığını itirməsi (məs. 5 ildən sonra CONFIDENTIAL → INTERNAL), avtomatik xatırlatma.

4.10.5 Office/PDF etiket inteqrasiyası (dizayn)

Hədəf: ETİMAD-da müəyyən edilmiş taksonomiya faylların özünə "yapışsın".

Qərar: MVP-də (Faza 3) A + B realizasiya olunur — platforma daxilində yaradılan/ixrac edilən bütün fayllar etiketlənir. C və D sonrakı mərhələdə, qurumun endpoint mühitindən asılı olaraq.

4.10.6 Məlumat inventarı və axın xəritəsi (Data Inventory & Flow Mapping)

Məlumat toplusu (DataSet) sahələri:

Axın xəritəsi (Data Flow): data_flow (id, dataset_id, source_asset_id, destination_asset_id, direction, transfer_method, protection, frequency, volume, is_external, is_cross_border, legal_basis, approved_by, approved_at)

Vizualizasiya: yönlü qraf (sistem → sistem), kənarlar təsnifat rənginə görə; xarici ötürmələr qalın/fərqli naxışla; sərhədlərarası ötürmələr xüsusi ikonla. Bu xəritə həm GDPR/fərdi məlumat uyğunluğu üçün, həm də DLP qaydalarının layihələndirilməsi üçün əsasdır.

4.10.7 Məlumat obyektləri

ClassificationScheme, ClassificationLevel, ClassificationPolicy (səviyyə üzrə qaydalar), ClassificationAssignment (polimorf: obyekt → səviyyə), ClassificationHistory, ClassificationRequest (endirmə sorğusu), DataSet, DataFlow, DataOwnerAttestation, LabelTemplate

4.10.8 İş axını

Təsnifat sxemi:  Draft → Review → Approved → Active → Superseded
Endirmə sorğusu: Requested → Data Owner Review → Security Review (səviyyəyə görə) → Approved/Rejected → Applied
Yenidən baxış:   Scheduled → Owner Review → Confirmed | Changed
Məlumat toplusu: Draft → Owner Review → Approved → Active → Under Review → Archived

4.10.9 Səlahiyyətlər

4.10.10 Audit hadisələri

CLASSIFICATION_SCHEME_CREATED, CLASSIFICATION_LEVEL_CHANGED, CLASSIFICATION_POLICY_CHANGED, OBJECT_CLASSIFIED, CLASSIFICATION_UPGRADED, CLASSIFICATION_DOWNGRADE_REQUESTED, CLASSIFICATION_DOWNGRADE_APPROVED, CLASSIFICATION_DOWNGRADE_REJECTED, CLASSIFICATION_BULK_APPLIED, DATASET_CREATED, DATASET_OWNER_CHANGED, DATAFLOW_CREATED, DATAFLOW_APPROVED, LABEL_APPLIED_TO_FILE, LABEL_INTEGRITY_VIOLATION

4.10.11 API

GET  /api/v1/classifications                       # sxem + səviyyələr
POST /api/v1/classifications/levels
PUT  /api/v1/classifications/levels/{id}
GET  /api/v1/classifications/levels/{id}/policy
PUT  /api/v1/classifications/levels/{id}/policy
POST /api/v1/classifications/assign                # {objectType, objectId, levelId, justification}
POST /api/v1/classifications/bulk-assign
POST /api/v1/classifications/downgrade-requests
POST /api/v1/classifications/downgrade-requests/{id}/approve
GET  /api/v1/classifications/history?objectType=&objectId=
GET  /api/v1/datasets?owner=&classification=&personalData=true
POST /api/v1/datasets
GET  /api/v1/datasets/{id}
GET  /api/v1/datasets/{id}/flows
POST /api/v1/datasets/{id}/flows
GET  /api/v1/data-flows/graph?scope=            # vizualizasiya üçün
POST /api/v1/datasets/{id}/attest
GET  /api/v1/reports/data-classification?format=xlsx

4.10.12 UI səhifələri

4.10.13 Metriklər

Təsnif edilmiş obyektlərin faizi (tip üzrə), səviyyələr üzrə paylanma, təsnifatı olmayan kritik aktivlər, endirmə sorğularının sayı və təsdiq faizi, baxış tarixi keçmiş təsnifatlar, sahibi olmayan məlumat toplusu, xarici axınların sayı, DPA-sız xarici axınlar.

4.10.14 Qəbul meyarları

1. Təsnifat səviyyələrinin sayı, adı və qaydaları kod dəyişikliyi olmadan admin panelindən konfiqurasiya olunur.
2. Təsnifatın endirilməsi əsaslandırma və təsdiq olmadan mümkün deyil (403).
3. Hər təsnifat dəyişikliyi tam tarixçədə (köhnə/yeni səviyyə, kim, nə vaxt, niyə) saxlanılır.
4. Platformadan ixrac edilən PDF/DOCX faylda təsnifat etiketi (başlıq/altbaşlıq) və metadata mövcuddur.
5. Fayl metadatasındakı etiket HMAC ilə qorunur; dəyişdirilmə aşkarlandıqda hadisə yaranır.
6. Təsnifat səviyyəsi yalnız rənglə deyil, ikon və mətnlə də göstərilir (WCAG testi).
7. Məlumat toplusu sahibi və təsnifatı olmadan Approved ola bilmir.
8. Axın xəritəsi qrafının mətn alternativi (cədvəl) mövcuddur.

4.11 M11 — Həssas Məlumatın Aşkarlanması (Sensitive Data Discovery)

4.11.1 Məqsəd

Həssas məlumat tiplərinin mərkəzi kataloqunu yaratmaq, aşkarlama qaydalarını (detection rules) müəyyən etmək və bu qaydaları həm platforma daxilində (sübut, sənəd yükləmələri), həm də xarici DLP konnektorları üçün vahid mənbə kimi təqdim etmək.

Skoup aydınlığı: ETİMAD detection rule authority-dir — qaydalar burada yaradılır, test edilir, versiyalanır. Faktiki skan endpoint/email/şəbəkə agent-ləri tərəfindən aparılır (A7). Platforma daxilində isə öz məzmununu (yüklənən sənədlər, sübutlar) özü skan edir.

4.11.2 Aşkarlama mexanizmləri

4.11.3 Confidence scoring

Match confidence (0–100) =
    base_confidence(mexanizm)          # regex 40, checksum 70, EDM 95, fingerprint 85 ...
  + context_bonus                       # kontekst sözü tapıldı: +20
  + proximity_bonus                     # yaxınlıq şərti ödəndi: +15
  + occurrence_bonus                    # min occurrence aşıldı: +10 (loqarifmik)
  − exclusion_penalty                   # istisna pattern tapıldı: −40
  − location_penalty                    # istisna edilmiş yol: −100 (yəni ləğv)

Hədlər: ≥85 "Yüksək", 60–84 "Orta", 40–59 "Aşağı", <40 hadisə yaradılmır (yalnız log)

4.11.4 Həssas məlumat tipləri kitabxanası (AZ kontekstində)

4.11.5 Yanlış pozitivlərin azaldılması

4.11.6 Qayda test mühərriki (kritik funksiya)

• Sandbox test: qayda yaradarkən nümunə mətn yapışdırılır → dərhal nəticə (uyğunluq var/yox, confidence, hansı hissə uyğun gəldi — vurğulanmış)
• Retrospektiv test: qayda mövcud sübut/sənəd korpusu üzərində işlədilir → neçə nəticə, neçə ehtimal yanlış pozitiv
• A/B müqayisə: iki qayda versiyasının eyni korpusda nəticələri
• Regression test seti: hər qayda üçün "bu mətn uyğun gəlməlidir" / "bu mətn uyğun gəlməməlidir" nümunələri saxlanılır; qayda dəyişdikdə avtomatik yoxlanılır

4.11.7 EDM (Exact Data Match) dizaynı

1. Mənbə: HR sistemindən CSV ixracı (FİN, ad, soyad, telefon)
2. İndeksləmə (offline, izolyasiya olunmuş prosesdə):
   - Hər sahə normallaşdırılır (böyük hərf, boşluqlar silinir)
   - salt + SHA-256 → yalnız hash saxlanılır
   - Orijinal CSV indeksləmədən dərhal sonra təhlükəsiz silinir
3. Saxlama: hash indeksi şifrələnmiş, yalnız detection engine oxuya bilir
4. Uyğunluq: skan edilən mətndən çıxarılan namizəd dəyərlər eyni qayda ilə hash-lənir və indekslə müqayisə olunur
5. Heç bir real dəyər loglanmır və ya hadisədə göstərilmir — yalnız "EDM uyğunluğu: HR_EMPLOYEES indeksi, 12 uyğunluq"

4.11.8 Məlumat obyektləri

SensitiveDataType, DetectionRule, DetectionPattern, Dictionary, DictionaryEntry, EdmIndex, EdmIndexEntry (hash), DocumentFingerprint, ExclusionRule, DetectionRuleTest, DetectionRuleVersion, ScanJob, ScanResult

4.11.9 Səlahiyyətlər

4.11.10 Audit hadisələri

SDT_CREATED, SDT_UPDATED, DETECTION_RULE_CREATED, DETECTION_RULE_UPDATED, DETECTION_RULE_TESTED, DETECTION_RULE_PUBLISHED, DICTIONARY_UPLOADED, EDM_INDEX_CREATED, EDM_INDEX_REBUILT, EDM_SOURCE_PURGED, EXCLUSION_RULE_CREATED, SCAN_JOB_STARTED, SCAN_JOB_COMPLETED, FINGERPRINT_CREATED

4.11.11 API

GET  /api/v1/sensitive-data-types?category=&status=
POST /api/v1/sensitive-data-types
GET  /api/v1/sensitive-data-types/{id}/rules
POST /api/v1/sensitive-data-types/{id}/rules
POST /api/v1/detection-rules/{id}/test           # {sampleText} → matches, confidence
POST /api/v1/detection-rules/{id}/backtest       # korpus üzərində
POST /api/v1/detection-rules/{id}/publish
GET  /api/v1/detection-rules/{id}/versions
GET  /api/v1/dictionaries
POST /api/v1/dictionaries                        # CSV upload
POST /api/v1/edm-indexes                         # data_owner təsdiqi tələb olunur
POST /api/v1/edm-indexes/{id}/rebuild
POST /api/v1/fingerprints                        # sənəd yüklə → barmaq izi
GET  /api/v1/exclusion-rules
POST /api/v1/exclusion-rules
POST /api/v1/scan-jobs                           # daxili korpus skanı
GET  /api/v1/scan-jobs/{id}/results

# Konnektorlar üçün (agent-lər qaydaları çəkir):
GET  /api/v1/dlp/rule-bundle?version=&connectorId=   # imzalanmış qayda paketi

4.11.12 UI səhifələri

/dlp/data-types (kataloq: ad, kateqoriya, mexanizm, status, yanlış pozitiv nisbəti), /dlp/data-types/{id} (qaydalar + test paneli: sol mətn sahəsi, sağ nəticələr, vurğulanmış uyğunluqlar), /dlp/dictionaries, /dlp/edm-indexes (mənbə yükləmə sihirbazı + xəbərdarlıqlar), /dlp/exclusions, /dlp/rule-testing (sandbox).

4.11.13 Metriklər

Aktiv məlumat tipləri, qayda üzrə uyğunluq sayı, qayda üzrə yanlış pozitiv nisbəti (analitik işarələməsindən), confidence paylanması, öyrənmə rejimindəki qaydalar, EDM indekslərinin yaşı və ölçüsü, regression test keçmə faizi.

4.11.14 Qəbul meyarları

1. Qayda monitor rejimini keçmədən enforce rejiminə çıxa bilmir (minimum 14 gün, konfiqurasiya edilə bilər).
2. EDM mənbə faylı indeksləmədən sonra ≤ 1 dəqiqə ərzində təhlükəsiz silinir (yoxlanılır).
3. EDM indeksində real dəyərlər saxlanılmır — yalnız salt+hash (kod review + DB inspeksiya).
4. Qayda testi nümunə mətndə uyğunluğu vurğulayır və confidence hesablamasını izah edir.
5. Regression test seti uğursuz olarsa qayda nəşr edilə bilmir.
6. Bank kartı nümunə nömrələri (test kartları) istisna siyahısı sayəsində hadisə yaratmır.
7. Skan nəticələrində tapılan həssas dəyər tam şəkildə göstərilmir (maskalanır: AZE****789).

4.12 M12 — DLP Siyasətlərinin İdarəetməsi

4.12.1 Məqsəd

Məlumat sızmasının qarşısının alınması siyasətlərinin mərkəzi dizaynı, təsdiqi, versiyalaşdırılması, mərhələli tətbiqi və konnektorlara paylanması.

4.12.2 Qayda strukturu

DLP Rule:
  ŞƏRT (hamısı VƏ ilə birləşir, hər biri opsional):
    • Data Type        ∈ {AZ_FIN, BANK_CARD, ...}           (M11)
    • Classification   ∈ {CONFIDENTIAL, TOP_SECRET}          (M10)
    • User / AD Group  ∈ {...} / ∉ {...}
    • Department       ∈ {...}
    • Device           ∈ {managed, unmanaged, specific}
    • Channel          ∈ {email, web_upload, usb, ...}
    • Destination      ∈ {external_domain, specific_domain, ip_range, app}
    • Context          : iş saatı / iş saatı xarici, məkan (VPN/ofis/uzaq),
                         həcm (>N fayl / >N MB / >N qeyd),
                         tezlik (son 1 saatda >N əməliyyat),
                         confidence ≥ N
  ⇒ ACTION (bir neçəsi birlikdə):
    • allow | log | monitor | notify_user | warn_user
    • require_justification | require_manager_approval | require_data_owner_approval
    • encrypt | quarantine | block
    • create_incident | escalate_to_soc | notify_security

4.12.3 Kanallar və icra imkanları

Vacib: ETİMAD-ın öz daxilində DLP tam işləyir (ixracın bloklanması, təsnifata görə yükləmə məhdudiyyəti). Xarici kanallarda ETİMAD orkestratordur.

4.12.4 Konnektor arxitekturası (DLP Integration Gateway)

ETİMAD DLP Policy Store
        │
        ├── (1) Qayda paketi (imzalanmış JSON, versiyalanmış)
        │        GET /api/v1/dlp/rule-bundle
        │        ▼
        │   [Konnektor adapteri]  ── tərcümə ──▶  Vendor formatı
        │     • Exchange Transport Rule (PowerShell/Graph)
        │     • Forcepoint / Symantec / Trellix DLP policy XML
        │     • Squid/Proxy ICAP qaydaları
        │     • Endpoint agent policy (vendor API)
        │
        └── (2) Hadisə qəbulu (webhook / syslog CEF / API push / file drop)
                 POST /api/v1/dlp/incidents/ingest
                 ▼
             Normalizasiya → dedupe → zənginləşdirmə (AD, təsnifat, aktiv)
                 ▼
             DLP Incident (M13)

Normalizasiya sxemi (vendor-neutral):

{
  "externalId": "FP-2026-88213",
  "connectorId": "exchange-tr-01",
  "detectedAt": "2026-09-14T10:22:31Z",
  "user": { "upn": "elnur.m@qurum.gov.az", "sid": "S-1-5-21-..." },
  "device": { "hostname": "WS-0432", "ip": "10.20.30.44" },
  "channel": "email",
  "destination": { "type": "external_email", "value": "***@gmail.com" },
  "matchedPolicyRef": "DLP-014",
  "matches": [ { "dataType": "AZ_FIN", "count": 23, "confidence": 92 } ],
  "file": { "name": "siyahi.xlsx", "sha256": "...", "size": 18422, "type": "xlsx" },
  "classification": "CONFIDENTIAL",
  "actionTaken": "blocked",
  "contentSample": null,          // default null — məzmun ötürülmür
  "contentRef": "vault://fp/88213" // yalnız istinad
}

4.12.5 Siyasət həyat dövrü və rejimlər

Draft → Internal Review → Security Review → Approved
  → TEST MODE       (yalnız simulyasiya, heç bir istifadəçi görmür, statistika)
  → MONITOR MODE    (loglanır, hadisə yaranır, istifadəçi görmür)
  → WARN MODE       (istifadəçi xəbərdarlıq görür, əməliyyat davam edir)
  → JUSTIFY MODE    (istifadəçi səbəb yazmalıdır, sonra davam edir)
  → PILOT ENFORCE   (yalnız pilot qrupda bloklanır)
  → FULL ENFORCE    (tam bloklama)
  → Suspended | Retired

Təhlükəsiz rollout modeli (məcburi ardıcıllıq, atlanma təsdiq tələb edir):

4.12.6 Siyasət idarəetməsi funksiyaları

• Versiyalaşdırma və rollback (əvvəlki versiyaya bir kliklə qayıtma, audit ilə)
• Dəyişiklik tarixçəsi: nə dəyişdi (diff), kim, niyə
• Effektiv tarix / bitmə tarixi
• Qayda prioriteti və münaqişənin həlli:
• Qaydalar prioritet nömrəsinə görə sıralanır (kiçik = yüksək)
• İlk uyğun gələn qayda tətbiq olunur (first-match) — default
• Alternativ: most-restrictive-wins (bütün uyğun qaydalar arasında ən ciddi action)
• Münaqişə detektoru: yeni qayda əlavə edildikdə sistem mövcud qaydalarla kəsişməni hesablayır və xəbərdarlıq verir ("DLP-007 bu qaydanı kölgələyir")
• Skoup və pilot qrup: qayda yalnız müəyyən AD qrupu/şöbə üçün aktivləşdirilə bilər
• Fövqəladə söndürmə (Emergency Disable): bir kliklə bütün enforce qaydalarını monitor-a keçirmək; dual control (2 nəfər) + avtomatik alarm + 24 saatdan sonra avtomatik bərpa sorğusu
• Simulyasiya: "bu qayda son 30 gündə neçə hadisə yaradardı?" (tarixi hadisələr üzərində)
• İstisnalar (DLP Exception): istifadəçi/qrup/destinasiya/fayl üçün müddətli istisna; təsdiq iş axını; avtomatik bitmə; bax M03 istisna modeli ilə eyni pattern

4.12.7 Nümunə siyasətlər (default kitabxana)

4.12.8 Məlumat obyektləri

DLPPolicy, DLPPolicyVersion, DLPRule, DLPRuleCondition, DLPRuleAction, DLPChannel, DLPConnector, DLPConnectorMapping, DLPException, DLPPolicyDeployment, DLPSimulationRun, PilotGroup

4.12.9 Səlahiyyətlər

P8 prinsipinin konkret tətbiqi: dlp_admin siyasət yaradır, lakin hadisələrin məzmununu görmür. Bu, "siyasəti özünə uyğunlaşdırıb məlumat oxumaq" hücum ssenarisini bağlayır.

4.12.10 Audit hadisələri

DLP_POLICY_CREATED, DLP_POLICY_UPDATED, DLP_POLICY_APPROVED, DLP_POLICY_MODE_CHANGED (köhnə→yeni rejim), DLP_POLICY_DEPLOYED, DLP_POLICY_ROLLED_BACK, DLP_POLICY_SUSPENDED, DLP_EMERGENCY_DISABLE, DLP_EMERGENCY_DISABLE_APPROVED, DLP_RULE_PRIORITY_CHANGED, DLP_EXCEPTION_CREATED, DLP_EXCEPTION_APPROVED, DLP_EXCEPTION_EXPIRED, DLP_CONNECTOR_CONFIGURED, DLP_RULE_BUNDLE_FETCHED, DLP_SIMULATION_RUN

4.12.11 API

GET  /api/v1/dlp-policies?status=&mode=&channel=
POST /api/v1/dlp-policies
GET  /api/v1/dlp-policies/{id}
PUT  /api/v1/dlp-policies/{id}
GET  /api/v1/dlp-policies/{id}/versions
POST /api/v1/dlp-policies/{id}/rollback/{versionId}
POST /api/v1/dlp-policies/{id}/submit-review
POST /api/v1/dlp-policies/{id}/approve
POST /api/v1/dlp-policies/{id}/mode                  # {mode, justification, pilotGroupId?}
POST /api/v1/dlp-policies/{id}/simulate?days=30
GET  /api/v1/dlp-policies/{id}/conflicts
POST /api/v1/dlp-policies/emergency-disable          # dual control
GET  /api/v1/dlp-exceptions
POST /api/v1/dlp-exceptions
POST /api/v1/dlp-exceptions/{id}/approve
GET  /api/v1/dlp-connectors
POST /api/v1/dlp-connectors
POST /api/v1/dlp-connectors/{id}/test
GET  /api/v1/dlp/rule-bundle?connectorId=&since=      # imzalanmış

4.12.12 UI səhifələri

4.12.13 Metriklər

Siyasət sayı rejim üzrə, enforce rejiminə keçmə müddəti (orta), yanlış pozitiv nisbəti siyasət üzrə, xəbərdarlıqdan sonra davam etmə faizi (override rate), istisnaların sayı və müddəti, konnektor sağlamlığı (son hadisə vaxtı), qayda münaqişələrinin sayı.

4.12.14 Qəbul meyarları

1. Yeni siyasət yalnız Test rejimində yaradıla bilər; birbaşa Enforce mümkün deyil (400).
2. Rejim keçidi ardıcıllığı pozulduqda əlavə təsdiq tələb olunur və audit qeydi yaranır.
3. dlp_admin hadisə məzmununa API ilə də çata bilmir (403).
4. Fövqəladə söndürmə iki fərqli istifadəçinin təsdiqi olmadan işləmir.
5. Qayda paketi rəqəmsal imza ilə imzalanır; konnektor imzanı yoxlamadan qəbul etmir.
6. Yeni qayda mövcud qayda ilə münaqişə yaradırsa saxlanılmadan əvvəl xəbərdarlıq göstərilir.
7. Simulyasiya real hadisə yaratmır və heç bir istifadəçiyə bildiriş göndərmir.
8. İstisna müddəti bitdikdə avtomatik deaktiv olur və qayda yenidən tam qüvvəyə minir.

4.13 M13 — DLP Hadisələrinin İdarəetməsi

4.13.1 Məqsəd

DLP aşkarlamalarının vahid triage, istintaq və bağlanma prosesi; məlumat minimallaşdırılması prinsipi ilə.

4.13.2 Hadisə sahələri

4.13.3 Severity avtomatik hesablanması

base = classification_weight    (PUBLIC 0, INTERNAL 10, RESTRICTED 30, CONFIDENTIAL 60, TOP_SECRET 90)
     + destination_weight       (internal 0, trusted_external 10, external 25, personal_cloud 35, unknown 30)
     + volume_weight            (log10(count) × 10, maks 30)
     + confidence_adjustment    (confidence/100 çarpanı)
     + repeat_factor            (eyni istifadəçi son 30 gündə N hadisə: +5×N, maks +25)
     + privileged_user_factor   (+15 əgər imtiyazlı istifadəçidir)
     − action_mitigation        (bloklandı: −20; xəbərdarlıq: −5; icazə verildi: 0)

Severity: ≥90 Kritik | 60–89 Yüksək | 30–59 Orta | <30 Aşağı

Analitik severity-ni əl ilə dəyişə bilər (əsaslandırma ilə, audit olunur).

4.13.4 🔒 Məlumat minimallaşdırılması (normativ — P13)

Maskalama qaydaları: hər SensitiveDataType üçün maska şablonu (AZ_FIN: ilk 3 + ****; BANK_CARD: son 4; EMAIL: ilk hərf + ***@domain; FULL_NAME_AZ: ad + soyadın ilk hərfi).

Fayl adının özü həssas ola bilər (Maaş_cədvəli_2026_MƏXFİ.xlsx) — buna görə fayl adı da təsnifat səviyyəsinə görə qismən maskalana bilər (konfiqurasiya).

4.13.5 İş axını

New
 → Triage                 (analitik baxır; SLA: kritik 1s, yüksək 4s, orta 24s, aşağı 72s)
    ├─ False Positive     → Closed (FP) → qayda tuning tapşırığı
    ├─ Duplicate          → Closed (merged)
    └─ Confirmed
 → Investigating
    ├─ User Response Required     (istifadəçidən izahat)
    ├─ Manager Response Required  (müdirdən təsdiq/rəy)
 → Contained              (əməliyyat bloklandı / fayl geri alındı / giriş kəsildi)
 → Resolved               (kök səbəb aradan qaldırıldı)
 → Closed
    ├─ (eskalasiya) → Security Incident (M15) / Risk (M05) / HR prosesi

Eskalasiya qaydaları: Kritik severity → dərhal SOC + CISO; təsdiqlənmiş qəsdli sızma → M15 təhlükəsizlik hadisəsi + hüquqi; imtiyazlı istifadəçi + məxfi məlumat → dərhal CISO; SLA keçdi → avtomatik eskalasiya.

4.13.6 İstifadəçi və müdir cavabı (User/Manager Response)

• İstifadəçiyə bildiriş: "Sizin [tarix] tarixli [kanal] əməliyyatınız təhlükəsizlik siyasətinə uyğun olmaya bilər. Zəhmət olmasa izah edin." — ittiham edən ton yoxdur
• İstifadəçi: səbəb seçir (iş tələbi / səhvən / bilmirdim / başqa) + mətn izahat
• Müdirə: "Əməkdaşınızın əməliyyatı üçün iş zərurəti təsdiq edilirmi?" → Bəli/Xeyr + qeyd
• Cavab 3 iş günü ərzində gəlmədikdə eskalasiya
• Nəticə: legitim → istisna təklifi (M12); qeyri-legitim → təlim təyinatı (M01) + HRS təsiri (M02)

4.13.7 Dashboard metrikləri

4.13.8 Səlahiyyətlər

4.13.9 Audit hadisələri

DLP_INCIDENT_INGESTED, DLP_INCIDENT_VIEWED, DLP_INCIDENT_CONTENT_L1_VIEWED, DLP_INCIDENT_CONTENT_L2_REQUESTED, DLP_INCIDENT_CONTENT_L2_APPROVED, DLP_INCIDENT_CONTENT_L2_VIEWED, DLP_INCIDENT_ASSIGNED, DLP_INCIDENT_TRIAGED, DLP_INCIDENT_SEVERITY_CHANGED, DLP_INCIDENT_MARKED_FP, DLP_INCIDENT_ESCALATED, DLP_INCIDENT_RESOLVED, DLP_INCIDENT_CLOSED, DLP_INCIDENT_EXPORTED, DLP_USER_RESPONSE_SUBMITTED, DLP_MANAGER_RESPONSE_SUBMITTED

4.13.10 API

POST /api/v1/dlp/incidents/ingest              # konnektorlar (mTLS + API key)
GET  /api/v1/dlp-incidents?severity=&status=&channel=&department=&from=&to=
GET  /api/v1/dlp-incidents/{id}                # L0
GET  /api/v1/dlp-incidents/{id}/matches        # L1 (maskalanmış)
POST /api/v1/dlp-incidents/{id}/content-access-request   # L2: {justification}
POST /api/v1/dlp-incidents/{id}/content-access-request/{rid}/approve
GET  /api/v1/dlp-incidents/{id}/content        # L2, müddətli token
POST /api/v1/dlp-incidents/{id}/assign
POST /api/v1/dlp-incidents/{id}/triage         # {classification: confirmed|fp|duplicate}
POST /api/v1/dlp-incidents/{id}/notes
POST /api/v1/dlp-incidents/{id}/severity       # {severity, justification}
POST /api/v1/dlp-incidents/{id}/request-user-response
POST /api/v1/dlp-incidents/{id}/user-response
POST /api/v1/dlp-incidents/{id}/manager-response
POST /api/v1/dlp-incidents/{id}/escalate       # → M15 / M05
POST /api/v1/dlp-incidents/{id}/resolve
POST /api/v1/dlp-incidents/{id}/close
POST /api/v1/dlp-incidents/bulk-triage
GET  /api/v1/dlp-incidents/statistics?groupBy=department|channel|dataType|policy
GET  /api/v1/my/dlp-incidents                  # istifadəçi öz hadisələri

4.13.11 UI səhifələri

4.13.12 Qəbul meyarları

1. dlp_analyst heç bir yolla (UI/API) tam məzmuna çata bilmir (403); yalnız maskalanmış nümunə.
2. L2 giriş sorğusu ikinci şəxsin təsdiqi olmadan icazə vermir; giriş 30 dəqiqədən sonra avtomatik bitir.
3. Hər L2 baxışı audit logunda səbəb mətni ilə saxlanılır və məlumat sahibinə bildiriş gedir.
4. Maskalanmış nümunədə heç bir tam FİN/kart nömrəsi görünmür (avtomatlaşdırılmış test: regex axtarışı 0 nəticə).
5. Konnektordan gələn hadisə mTLS + API key olmadan qəbul edilmir (401).
6. Eyni external_id ilə təkrar gələn hadisə dublikat kimi tanınır (idempotency).
7. SLA keçdikdə avtomatik eskalasiya işə düşür və bildiriş gedir.
8. FP işarələnən hadisə qayda tuning backlog-una düşür və qaydanın FP nisbətini yeniləyir.
9. İstifadəçiyə göndərilən bildirişdə ittiham edən dil yoxdur (mətn nəzərdən keçirilib, şablon təsdiqlənib).
10. Hadisə ixracında məzmun deyil, yalnız metadata + maskalanmış uyğunluqlar var.

4.14 M14 — Active Directory və IAM

4.14.1 Məqsəd

Qurumun mövcud kataloq xidmətini platformanın yeganə həqiqət mənbəyi etmək; autentifikasiya, avtorizasiya konteksti, təşkilati struktur və hədəfləmə üçün etibarlı məlumat təmin etmək.

4.14.2 Autentifikasiya axınları

Autentifikasiya axını (OIDC):

Brauzer → ETİMAD Web → (redirect) → Keycloak → (federation) → AD/LDAPS
                                       ↓
                                  MFA (rol tələb edirsə)
                                       ↓
            ← id_token + access_token (JWT, qısa müddətli) ←
ETİMAD API ← Bearer token → token validasiyası (imza, exp, aud, iss)
                          → lokal `user` qeydinin tapılması (SID/objectGUID ilə)
                          → rol və skoup hesablanması (AD qrupları + lokal təyinatlar)
                          → sessiya konteksti

Token siyasəti: access token 15 dəq, refresh token 8 saat (sliding, maks 12 saat), sessiya idle timeout 30 dəq, mütləq timeout 12 saat. İmtiyazlı rollar üçün: access 5 dəq, idle 15 dəq, step-up autentifikasiya (həssas əməliyyatlar üçün yenidən MFA).

4.14.3 Sinxronizasiya

Atribut mapping (konfiqurasiya edilə bilən):

Xüsusi hallar:

Sinxronizasiya hesabatı: hər işdən sonra — yeni, yenilənmiş, deaktiv, silinmiş, xəta sayı; xətaların detalı; administratora bildiriş (xəta varsa).

4.14.4 AD → Rol mapping

role_mappings:
  - ad_group: "CN=IT-Security,OU=Groups,DC=qurum,DC=gov,DC=az"
    roles: [security_incident_analyst, dlp_analyst]
  - ad_group: "CN=Internal-Audit,OU=Groups,..."
    roles: [internal_auditor]
  - ad_attribute: { title: "*müdir*" }          # wildcard
    roles: [department_manager]
  - ad_attribute: { department: "Maliyyə" }
    roles: []                                    # yalnız skoup, rol yox

• Rol AD qrupundan gəlirsə platformada əl ilə silinə bilməz (yalnız AD-də) — istisna: müvəqqəti bloklama (əsaslandırma ilə)
• Lokal təyinatlar (AD-dən asılı olmayan) ayrıca işarələnir və dövri baxış tələb edir (6 ay)
• Rol attestasiyası: 6 ayda bir, hər rol sahibi üçün "bu istifadəçinin bu rolu hələ də lazımdırmı?" → müdir/rol sahibi təsdiqləyir

4.14.5 AD-yə yazma (Write-back) — məhdudlaşdırılmış

• Default: SÖNDÜRÜLÜB. Platforma AD-yə heç nə yazmır.
• Gələcək (Faza 4, opsional, ayrıca təsdiqlə): "yüksək riskli istifadəçini məhdudlaşdırıcı qrupa əlavə et" kimi ssenarilər — ayrıca servis hesabı, ayrıca təsdiq iş axını, tam audit, dərhal geri qaytarma imkanı.
• Yazma aktivləşdirilərsə: yalnız konkret, əvvəlcədən müəyyən edilmiş qruplara, yalnız add/remove member əməliyyatı, heç vaxt delete user və ya atribut dəyişikliyi.

4.14.6 Break-glass administrator

• 2 lokal hesab, parollar möhürlənmiş zərfdə seyfdə (fiziki), hər biri ayrı şəxsdə
• FIDO2 açarı + TOTP (ikisi də tələb olunur)
• Girişdə: dərhal SIEM alarm + SMS/email CISO-ya + dashboard-da görünən banner
• Hər 90 gündə parol rotasiyası və test (prosedur)
• Bütün əməliyyatları xüsusi break_glass_session bayrağı ilə loglanır
• İstifadədən sonra məcburi post-mortem sənədi

4.14.7 Məlumat obyektləri

Organization, OrganizationalUnit, Department, User, UserProfile, Group, GroupMembership, ADConnection, ADSyncJob, ADSyncLog, ADSyncError, AttributeMapping, RoleMapping, Session, MfaEnrollment, ServiceAccount, ApiKey, RoleAttestation

4.14.8 Səlahiyyətlər

Yalnız platform_admin: AD bağlantısı, mapping, sinxronizasiya. security_lead: rol təyinatlarını görmək, attestasiya. Heç kim: servis hesabının parolunu görmək (Vault-da, yalnız yazma).

4.14.9 Audit hadisələri

USER_LOGIN_SUCCESS, USER_LOGIN_FAILED, USER_LOGOUT, SESSION_EXPIRED, SESSION_REVOKED, MFA_ENROLLED, MFA_CHALLENGE_FAILED, MFA_BYPASS_USED, STEP_UP_AUTH_PERFORMED, AD_SYNC_STARTED, AD_SYNC_COMPLETED, AD_SYNC_FAILED, AD_USER_CREATED, AD_USER_UPDATED, AD_USER_DISABLED, AD_USER_DELETED, AD_GROUP_MEMBERSHIP_CHANGED, ROLE_ASSIGNED, ROLE_REVOKED, ROLE_ATTESTATION_COMPLETED, AD_CONNECTION_CONFIGURED, ROLE_MAPPING_CHANGED, BREAK_GLASS_LOGIN, SERVICE_ACCOUNT_CREATED, API_KEY_ISSUED, API_KEY_REVOKED

4.14.10 API

POST /api/v1/auth/login                    # lokal/fallback
POST /api/v1/auth/oidc/callback
POST /api/v1/auth/refresh
POST /api/v1/auth/logout
POST /api/v1/auth/mfa/enroll
POST /api/v1/auth/mfa/verify
POST /api/v1/auth/step-up
GET  /api/v1/auth/me                       # profil + rollar + effektiv icazələr
GET  /api/v1/auth/sessions                 # öz aktiv sessiyalarım
DELETE /api/v1/auth/sessions/{id}
GET  /api/v1/users?department=&role=&enabled=&search=
GET  /api/v1/users/{id}
GET  /api/v1/users/{id}/roles
POST /api/v1/users/{id}/roles              # SoD yoxlanır
DELETE /api/v1/users/{id}/roles/{roleId}
GET  /api/v1/users/{id}/effective-permissions
GET  /api/v1/groups
GET  /api/v1/departments
GET  /api/v1/organizational-units/tree
GET  /api/v1/admin/ad/connections
POST /api/v1/admin/ad/connections
POST /api/v1/admin/ad/connections/{id}/test
POST /api/v1/admin/ad/sync                 # {mode: full|incremental, userId?}
GET  /api/v1/admin/ad/sync-jobs
GET  /api/v1/admin/ad/sync-jobs/{id}/log
GET  /api/v1/admin/ad/attribute-mappings
PUT  /api/v1/admin/ad/attribute-mappings
GET  /api/v1/admin/role-mappings
POST /api/v1/admin/role-attestations/campaign

4.14.11 UI səhifələri

/admin/integrations/ad (bağlantı, test, mapping, cədvəl), /admin/integrations/ad/sync-history (işlər, xətalar), /admin/users (siyahı, filtr, rol), /admin/users/{id} (profil, rollar, effektiv icazələr, sessiyalar, audit), /admin/roles (rol kataloqu, icazə matrisi), /admin/role-mappings, /admin/attestations (rol attestasiya kampaniyaları), /my/profile (öz məlumatı, MFA, sessiyalar, dil).

4.14.12 Qəbul meyarları

1. Sinxronizasiya yalnız LDAPS və ya StartTLS ilə işləyir; açıq LDAP konfiqurasiyası rədd edilir.
2. İstifadəçi identifikasiyası objectGUID ilə aparılır; sAMAccountName dəyişdikdə istifadəçi dublikat yaranmır.
3. AD-də deaktiv edilmiş istifadəçinin aktiv sessiyası ≤ 5 dəqiqə ərzində ləğv olunur.
4. Xidməti hesablar heç bir fişinq kampaniyasına və təlim təyinatına düşmür.
5. 10 000 istifadəçinin tam sinxronizasiyası ≤ 15 dəqiqə çəkir; artımlı sinxronizasiya ≤ 2 dəqiqə.
6. Sinxronizasiya xətası platformanın işini dayandırmır; qismən nəticə tətbiq olunur, xətalar hesabatda.
7. Servis hesabının parolu heç bir log, konfiqurasiya faylı və ya API cavabında görünmür (secret scanning testi).
8. İmtiyazlı rollara MFA olmadan giriş mümkün deyil (403 + step-up tələbi).
9. AD-yə yazma default söndürülüb; aktivləşdirmə konfiqurasiya + ayrıca təsdiq tələb edir.
10. Break-glass girişi dərhal alarm yaradır və dashboard-da 24 saat görünən banner göstərir.
11. Manager dövrü (A→B→A) aşkarlanır və sinxronizasiya xətası kimi hesabatda qeyd olunur.

4.15 M15 — Təhlükəsizlik Hadisələrinin Bildirilməsi

4.15.1 Məqsəd

İşçilərin təhlükəsizlik hadisələrini asan, sürətli və qorxmadan bildirməsini təmin etmək; hadisələrin idarə olunması və SOC prosesləri ilə inteqrasiyası (ISO 27001 A.6.8, A.5.24–A.5.28).

4.15.2 Hadisə kateqoriyaları

4.15.3 Bildirmə forması (istifadəçi üçün — sadəlik prioritetdir)

┌──────────────────────────────────────────────────────┐
│  Təhlükəsizlik hadisəsini bildirin                   │
│  Bildirişiniz üçün təşəkkür edirik. Hadisəni         │
│  bildirmək cəzalandırılmır — əksinə, dəyərlidir.     │
│                                                      │
│  Nə baş verdi?  [böyük ikon seçimi — 9 kateqoriya]  │
│                                                      │
│  Qısa təsvir *  [________________________________]   │
│  Nə vaxt?       [tarix/saat, default: indi]          │
│  Harada?        [ofis/uzaqdan/digər]                 │
│  Fayl/şəkil     [drag-drop]                          │
│  Əlaqə          ( ) Adımla bildirirəm                │
│                 ( ) Anonim bildirmək istəyirəm       │
│                                                      │
│  [ Bildir ]                                          │
└──────────────────────────────────────────────────────┘

• Maksimum 4 məcburi sahə. Texniki terminlərsiz.
• Şübhəli email üçün ayrıca sürətli yol: Outlook düyməsi (M02 ilə eyni infrastruktur) — bir kliklə.
• Anonim bildirmə: istifadəçi ID-si saxlanılmır, is_anonymous=true, əlaqə üçün opsional birdəfəlik kod (istifadəçi saxlayır, statusu yoxlaya bilər)

4.15.4 Hadisə idarəetməsi

• Avtomatik severity təklifi (kateqoriya + açar sözlər + təsnifat)
• Təyinat: növbətçi analitik, kateqoriyaya görə komanda
• SLA: ilk cavab, containment, həll — kateqoriya və severity üzrə
• Eskalasiya: SLA pozulması → komanda rəhbəri → CISO
• Əlaqələndirmə: aktiv, risk, nəzarət tədbiri, DLP hadisəsi, digər hadisələr, tapıntı
• Timeline: bütün fəaliyyətlər xronoloji
• Bildiriş verənə status yeniləməsi (avtomatik) və təşəkkür
• Bağlanma: nəticə, kök səbəb, öyrənilən dərslər, düzəldici tədbir (M17)
• Post-incident review (yüksək/kritik üçün məcburi)

4.15.5 İş axını

Reported → Triage → Assigned → Investigating → Containment
  → Eradication → Recovery → Resolved → Post-Incident Review → Closed
       └─ (dublikat/əsassız) → Closed (No Action)
       └─ (eskalasiya) → Major Incident (ayrıca prosedur, kriz komandası)

4.15.6 SIEM/SOAR/Ticketing inteqrasiyası

4.15.7 Səlahiyyətlər

4.15.8 Audit hadisələri

SECURITY_INCIDENT_REPORTED, SECURITY_INCIDENT_TRIAGED, SECURITY_INCIDENT_ASSIGNED, SECURITY_INCIDENT_SEVERITY_CHANGED, SECURITY_INCIDENT_ESCALATED, SECURITY_INCIDENT_CONTAINED, SECURITY_INCIDENT_RESOLVED, SECURITY_INCIDENT_CLOSED, SECURITY_INCIDENT_REOPENED, SECURITY_INCIDENT_LINKED, SIEM_EVENT_INGESTED, SIEM_EVENT_FORWARDED

4.15.9 API

POST /api/v1/incidents                      # bildirmə (bütün istifadəçilər)
POST /api/v1/incidents/anonymous            # anonim (rate-limited, CAPTCHA opsional)
GET  /api/v1/incidents/status/{trackingCode} # anonim izləmə
GET  /api/v1/my/incidents
GET  /api/v1/incidents?category=&severity=&status=&assignee=
GET  /api/v1/incidents/{id}
POST /api/v1/incidents/{id}/assign
POST /api/v1/incidents/{id}/triage
POST /api/v1/incidents/{id}/notes
POST /api/v1/incidents/{id}/escalate
POST /api/v1/incidents/{id}/resolve
POST /api/v1/incidents/{id}/close
POST /api/v1/incidents/{id}/links
POST /api/v1/incidents/ingest               # SIEM → ETİMAD (mTLS)
POST /api/v1/incidents/{id}/convert-to-phishing-template   # M02

4.15.10 UI səhifələri

/report (böyük, sadə bildirmə forması — hər səhifədən əlçatan "Hadisə bildir" düyməsi header-də), /my/incidents, /incidents (analitik növbəsi), /incidents/{id} (timeline + fəaliyyət paneli + əlaqələr), /incidents/dashboard.

4.15.11 Metriklər

Bildirilən hadisələr (kateqoriya üzrə), bildirmə mənbəyi (əməkdaş/SIEM/DLP/avtomatik), orta ilk cavab müddəti, MTTR, SLA riayəti, təkrar hadisələr, şöbə üzrə bildirmə aktivliyi (müsbət göstərici — çox bildirmə yaxşıdır), anonim bildirmələrin faizi, əsassız/dublikat faizi.

4.15.12 Qəbul meyarları

1. Bildirmə forması 4-dən çox məcburi sahə tələb etmir və ≤ 60 saniyədə doldurula bilir (UAT).
2. Anonim bildirişdə istifadəçi ID-si, IP və brauzer izi saxlanılmır (DB inspeksiyası).
3. Anonim izləmə kodu ilə bildirən statusu görə bilir, lakin sistem onu identifikasiya edə bilmir.
4. Kritik hadisə bildirildikdə ≤ 1 dəqiqə ərzində SOC-a bildiriş gedir (email + SIEM).
5. SIEM-ə göndərilən CEF mesajı standarta uyğundur və test SIEM tərəfindən parse olunur.
6. Şübhəli email bildirişi simulyasiya header-i daşıyırsa avtomatik M02-yə yönləndirilir və hadisə yaradılmır.

4.16 M16 — Dashboard və Hesabatlar

4.16.1 Məqsəd

Hər rola öz qərar səviyyəsinə uyğun, icazəyə görə filtrlənmiş, aktuallığı açıq göstərilən məlumat təqdim etmək.

4.16.2 Employee Dashboard (/)

┌─ Salam, Elnur! ────────────────────────────────────────────────┐
│                                                                │
│  ⚠ DİQQƏT TƏLƏB EDƏN (2)                                       │
│  ┌──────────────────────────┐ ┌──────────────────────────┐    │
│  │ 📚 İnformasiya təhlükə-  │ │ 📄 Parol Siyasəti v3.0   │    │
│  │    sizliyinin əsasları   │ │    ilə tanış olun        │    │
│  │    Son tarix: 3 gün      │ │    Son tarix: 7 gün      │    │
│  │    [ Davam et ]          │ │    [ Oxu ]               │    │
│  └──────────────────────────┘ └──────────────────────────┘    │
│                                                                │
│  ┌─ Mənim təlimlərim ──┐ ┌─ Sertifikatlarım ─┐ ┌─ Mənim ──┐   │
│  │ Tamamlanmış: 4/5    │ │ 3 aktiv sertifikat│ │ risk     │   │
│  │ ▓▓▓▓▓▓▓▓░░ 80%      │ │ [ Bax ]           │ │ göstər.  │   │
│  └─────────────────────┘ └───────────────────┘ │ 🟢 Aşağı │   │
│                                                 │ [İzah]   │   │
│  ┌─ Tapşırıqlarım (1) ─┐ ┌─ Bildirişlərim ───┐ └──────────┘   │
│  └─────────────────────┘ └───────────────────┘                │
│                                                                │
│  [ 🚨 Təhlükəsizlik hadisəsi bildir ]  [ ✉ Şübhəli email ]     │
└────────────────────────────────────────────────────────────────┘

Şəxsi risk göstəricisinin etik təqdimatı (P7):

• Yalnız band göstərilir (Aşağı/Orta/Yüksək), rəqəm opsionaldır (istifadəçi "İzah" ilə görə bilər)
• Müsbət çərçivə: "Riskinizi azaltmaq üçün: ✓ Təlimi tamamlayın ✓ Şübhəli emailləri bildirin"
• Heç bir müqayisə başqaları ilə ("siz 200 nəfərdən 180-cisiniz" — qadağan)
• "Yüksək" band üçün: "Sizə əlavə dəstək təklif olunur" + təlim linki, cəza tonu yoxdur

4.16.3 Security/GRC Dashboard (/dashboard/security)

4.16.4 Executive Dashboard (/dashboard/executive)

Dizayn prinsipi: bir ekran, sürüşdürmə olmadan, 8–10 göstərici, hər biri bir rəqəm + trend oxu + rəng/ikon. Detal yalnız kliklə.

4.16.5 Ümumi dashboard funksiyaları

4.16.6 Hesabat mühərriki

• Hesabat şablonları: əvvəlcədən müəyyən edilmiş 21 hesabat (bax §17)
• Parametrlər: tarix aralığı, şöbə, framework, status, sahib
• Formatlar: PDF (rəsmi tərtibat: gerb, başlıq, təsnifat etiketi, səhifə nömrəsi, generasiya tarixi/istifadəçisi), DOCX (redaktə edilə bilən), XLSX (məlumat + pivot üçün hazır), CSV
• Generasiya: ≤ 5 s sinxron, daha uzunu background job + hazır olduqda bildiriş + yükləmə linki
• Planlaşdırma: cron ifadəsi, alıcılar, format; hesabat özü sübut kimi saxlanıla bilər (M07)
• Hesabat ixracının audit edilməsi: kim, nə vaxt, hansı parametrlərlə, neçə sətir
• Böyük ixrac nəzarəti: > 1000 sətir ixrac səbəb tələb edir (DLP-010)

4.16.7 Məlumat obyektləri

Dashboard, DashboardWidget, UserDashboardPreference, ReportTemplate, ReportDefinition, ReportRun, ReportSchedule, ReportSubscription, MetricSnapshot (gündəlik aqreqatlar — trend üçün)

4.16.8 API

GET  /api/v1/dashboards/employee
GET  /api/v1/dashboards/security?from=&to=&department=
GET  /api/v1/dashboards/executive?from=&to=
GET  /api/v1/dashboards/widgets/{key}/data?params...
PUT  /api/v1/dashboards/preferences
GET  /api/v1/reports/templates
POST /api/v1/reports/run                    # {templateId, params, format}
GET  /api/v1/reports/runs/{id}              # status
GET  /api/v1/reports/runs/{id}/download
GET  /api/v1/reports/schedules
POST /api/v1/reports/schedules
GET  /api/v1/metrics/snapshots?metric=&from=&to=

4.16.9 Qəbul meyarları

1. Dashboard yalnız istifadəçinin icazəsi olan məlumatı göstərir — eyni widget müxtəlif rollarda müxtəlif rəqəm göstərir (test).
2. Hər widget-də məlumatın son yenilənmə vaxtı görünür.
3. Executive dashboard 1920×1080 ekranda sürüşdürmə olmadan yerləşir.
4. Hər qrafikin cədvəl alternativi var və klaviatura ilə əlçatandır.
5. Dashboard yüklənməsi ≤ 2 saniyə (P95), widget-lər paralel və progressiv yüklənir.
6. PDF hesabatda təsnifat etiketi, generasiya tarixi və generasiya edən istifadəçi görünür.
7. > 1000 sətirlik ixrac səbəb tələb edir və audit olunur.
8. Planlaşdırılmış hesabat alıcının icazəsinə görə filtrlənir (icazəsi olmayan məlumat göndərilmir).

4.17 M17 — İş Axını və Tapşırıq Mühərriki

4.17.1 Məqsəd

Bütün modullarda təkrarlanan təsdiq, rəy, tapşırıq və eskalasiya məntiqini bir dəfə realizasiya etmək; qurumun strukturuna görə konfiqurasiya imkanı vermək.

Bu bünövrə modulu Faza 0/1-in birinci işidir. Hər modulun öz təsdiq məntiqini yazması qadağandır.

4.17.2 İş axını mühərriki

Model: deklarativ state machine + qaydalar.

workflow:
  key: policy_approval
  version: 3
  entity_type: Document
  states:
    - { key: draft, initial: true, label_az: "Layihə" }
    - { key: internal_review, label_az: "Daxili rəy" }
    - { key: security_review, label_az: "Təhlükəsizlik rəyi" }
    - { key: legal_review, label_az: "Hüquqi rəy", optional: true }
    - { key: pending_approval, label_az: "Təsdiq gözləyir" }
    - { key: published, final: true, label_az: "Nəşr olunub" }
    - { key: rejected, label_az: "Rədd edilib" }
  transitions:
    - from: draft
      to: internal_review
      action: submit
      allowed_roles: [policy_author, compliance_officer]
      conditions:
        - "entity.title != null && entity.content.length > 200"
      effects:
        - create_tasks: { assignee_rule: reviewers_of(entity), due_days: 5 }
        - notify: { template: review_requested }
    - from: internal_review
      to: security_review
      action: approve
      allowed_roles: [policy_reviewer]
      approval_mode: all          # all | any | quorum(N) | sequential
      sod_check: [SoD-1]
      effects: [...]
    - from: any
      to: draft
      action: request_changes
      allowed_roles: [policy_reviewer, policy_approver]
      requires_comment: true
  escalations:
    - state: pending_approval
      after_days: 5
      action: notify_manager
    - state: pending_approval
      after_days: 10
      action: escalate_to: ciso
  sla:
    internal_review: 5d
    security_review: 3d
    pending_approval: 5d

Təsdiq rejimləri: all (hamısı), any (biri kifayətdir), quorum(N), sequential (ardıcıl), conditional (şərtə görə: məs. risk səviyyəsi yüksəkdirsə əlavə təsdiqçi).

Təsdiqçinin təyin edilməsi (assignee rules): konkret istifadəçi, rol, obyekt sahibi, obyekt sahibinin rəhbəri, departament rəhbəri, AD qrupunun üzvləri, dinamik ifadə (manager_of(entity.owner)), növbə (round-robin).

Delegasiya: istifadəçi məzuniyyət dövrü üçün təsdiq səlahiyyətini başqasına verə bilər (müddətli, audit olunur, SoD yoxlanılır).

4.17.3 Tapşırıq (Task) modeli

4.17.4 Funksiyalar

• Vahid "Mənim tapşırıqlarım" görünüşü — bütün modullardan
• Kanban və cədvəl görünüşü
• Toplu əməliyyatlar (toplu tamamlama, toplu təyinat dəyişikliyi)
• Alt-tapşırıqlar (checklist)
• Asılılıq (A tamamlanmadan B başlaya bilməz)
• Təkrarlanan tapşırıqlar (dövri baxışlar: nəzarət tədbiri baxışı, sübut yeniləməsi, risk baxışı, attestasiya)
• Xatırlatma: platformadaxili + email, konfiqurasiya edilə bilən cədvəl
• Eskalasiya: avtomatik, zəncir üzrə, audit olunur
• SLA izləmə və hesabat
• İş yükü görünüşü (kimdə neçə açıq tapşırıq var — resurs planlaması üçün)

4.17.5 Bildiriş servisi (Notification)

Kanallar: platformadaxili (bell + siyahı), email (SMTP), SIEM (CEF), ticketing (webhook), gələcək: Teams/Slack/SMS.

Şablon idarəetməsi:

• Hər bildiriş növü üçün şablon: mövzu + mətn (HTML + düz mətn)
• Çoxdilli (AZ/EN/RU) — istifadəçinin dil seçiminə görə
• Versiyalaşdırılmış — dəyişiklik audit olunur
• Dəyişənlər: {{user.firstName}}, {{entity.title}}, {{dueDate}}, {{link}}, {{daysRemaining}}
• Önizləmə və test göndərişi

Bildiriş səbəbləri (tam siyahı — §27-də genişləndirilir): Təlim təyin edildi / deadline yaxınlaşır / gecikdi; Siyasət nəşr olundu / tanışlıq tələb olunur / baxış tələb olunur; Sübut tələb olundu / bitir / bitdi; Risk baxışı tələb olunur / emal gecikdi / qəbul bitir; Audit tapıntısı təyin edildi / düzəldici tədbir gecikdi; Təchizatçı yenidən qiymətləndirmə / müqavilə bitir / sertifikat bitir; DLP hadisəsi yarandı / izahat tələb olunur / təsdiq tələb olunur; Təhlükəsizlik hadisəsi eskalasiya olundu; Tapşırıq təyin edildi / gecikdi; Təsdiq gözləyir; Kampaniya başladı/bitdi; AD sinxronizasiya xətası; Sistem xəbərdarlığı.

Bildiriş nəzarəti:

• İstifadəçi tərəfindən kanal seçimi (hansı bildirişi email ilə almaq) — məcburi bildirişlər istisna (təlim deadline, siyasət tanışlığı)
• Toplama (digest): gündəlik/həftəlik xülasə — bildiriş yorğunluğuna qarşı
• Sakit saatlar (iş saatı xaricində göndərməmək — kritik istisna)
• Təkrar bildirişin qarşısının alınması (dedupe)

4.17.6 Məlumat obyektləri

WorkflowDefinition, WorkflowVersion, WorkflowState, WorkflowTransition, WorkflowInstance, WorkflowHistory, Approval, ApprovalStep, Delegation, Task, SubTask, TaskComment, TaskAttachment, TaskDependency, RecurringTaskRule, Notification, NotificationTemplate, NotificationTemplateVersion, NotificationPreference, NotificationDelivery

4.17.7 API

GET  /api/v1/tasks?assignee=me&status=&priority=&overdue=&module=
GET  /api/v1/tasks/{id}
POST /api/v1/tasks
PATCH /api/v1/tasks/{id}
POST /api/v1/tasks/{id}/complete           # {note, evidenceId?}
POST /api/v1/tasks/{id}/reassign
POST /api/v1/tasks/{id}/comments
POST /api/v1/tasks/bulk-complete
GET  /api/v1/tasks/workload?department=
GET  /api/v1/approvals/pending             # mənə gələn təsdiqlər
POST /api/v1/approvals/{id}/decide         # {decision, comment}
GET  /api/v1/delegations
POST /api/v1/delegations                   # {toUserId, from, to, scope}
GET  /api/v1/workflows/definitions
POST /api/v1/workflows/definitions
POST /api/v1/workflows/definitions/{id}/validate
POST /api/v1/workflows/definitions/{id}/publish
GET  /api/v1/workflows/instances/{id}/history
GET  /api/v1/notifications?unread=true
POST /api/v1/notifications/{id}/read
PUT  /api/v1/notifications/preferences
GET  /api/v1/admin/notification-templates
PUT  /api/v1/admin/notification-templates/{id}
POST /api/v1/admin/notification-templates/{id}/test

4.17.8 UI səhifələri

/tasks (Mənim tapşırıqlarım — cədvəl/kanban, filtr, toplu əməliyyat), /tasks/{id}, /approvals (təsdiq növbəsi — bir ekranda sürətli təsdiq: obyektin xülasəsi + Təsdiq/Rədd + şərh), /my/delegations, /admin/workflows (siyahı), /admin/workflows/{id} (vizual state machine redaktoru: qutular + oxlar, hər keçid üçün panel), /admin/notifications/templates, bell menyusu (header-də).

4.17.9 Audit hadisələri

WORKFLOW_DEFINITION_CREATED, WORKFLOW_DEFINITION_PUBLISHED, WORKFLOW_INSTANCE_STARTED, WORKFLOW_TRANSITION, WORKFLOW_INSTANCE_COMPLETED, APPROVAL_REQUESTED, APPROVAL_GRANTED, APPROVAL_REJECTED, APPROVAL_DELEGATED, TASK_CREATED, TASK_ASSIGNED, TASK_REASSIGNED, TASK_COMPLETED, TASK_CANCELLED, TASK_ESCALATED, SLA_BREACHED, DELEGATION_CREATED, DELEGATION_REVOKED, NOTIFICATION_TEMPLATE_CHANGED, NOTIFICATION_SENT, NOTIFICATION_FAILED

4.17.10 Qəbul meyarları

1. İş axını tərifi kod dəyişikliyi olmadan admin panelindən dəyişdirilir; dəyişiklik yeni versiya yaradır.
2. İşləyən (aktiv) instansiyalar köhnə versiyada davam edir; yalnız yeni instansiyalar yeni versiyada başlayır.
3. SoD qaydası pozulan keçid bloklanır (403 + audit).
4. Tapşırıq SLA-nı keçdikdə eskalasiya avtomatik işə düşür (test: saat dəyişdirilir).
5. Delegasiya müddəti bitdikdə avtomatik ləğv olunur.
6. Bildiriş şablonu 3 dildə mövcuddur; istifadəçinin dili olmadıqda AZ-a fallback edir.
7. Eyni hadisə üçün 5 dəqiqə ərzində təkrar bildiriş göndərilmir (dedupe).
8. "Mənim tapşırıqlarım" bütün modullardan gələn tapşırıqları vahid siyahıda göstərir.
9. Email göndərilməsi uğursuz olduqda 3 dəfə yenidən cəhd edilir və nəticə NotificationDelivery-də saxlanılır.

4.18 M18 — Platforma Administrasiyası və Audit İzi

4.18.1 Məqsəd

Konfiqurasiya, istifadəçi/rol idarəetməsi, sistem sağlamlığı və dəyişdirilə bilməyən audit izi.

4.18.2 Funksiyalar

• Təşkilati struktur (organization, OU, department) — AD-dən + əl ilə düzəliş
• Rol və icazə matrisi (§15)
• SoD qaydalarının konfiqurasiyası
• Sistem parametrləri: dil, saat qurşağı, tarix formatı, iş günləri/saatları, təqvim (bayram günləri — deadline hesablaması üçün)
• Branding: loqo, qurum adı, rənglər (məhdud), hesabat başlıqları
• Email/SMTP konfiqurasiyası
• İnteqrasiya konfiqurasiyası (AD, SIEM, ticketing, DLP konnektorları, antivirus)
• Fayl saxlama konfiqurasiyası, kvotalar, retention
• Backup statusu görünüşü
• Sistem sağlamlığı: servis statusu, növbə uzunluğu, disk, DB bağlantıları, son işlər
• Lisenziya/versiya məlumatı
• Feature flags (modulların aktivləşdirilməsi/söndürülməsi)
• Məlumat retention və arxivləşdirmə siyasətləri
• Audit log axtarışı və ixracı

4.18.3 🔒 Audit izi (Audit Trail) — normativ dizayn

Qeyd edilən hadisələr: §16-da tam siyahı. Minimum: autentifikasiya, avtorizasiya rədləri, CRUD, baxış (həssas obyektlər), ixrac, fayl əməliyyatları, icazə/rol dəyişikliyi, təsdiq, konfiqurasiya dəyişikliyi, inteqrasiya əməliyyatları, API girişi, iş axını keçidləri.

Sahələr:

Dəyişməzlik (immutability) — çoxqatlı müdafiə:

Retention: onlayn (sorğu edilə bilən) 24 ay; arxiv 7 il (və ya qurumun normativ tələbinə görə); arxivdən bərpa prosedurla.

Audit loguna giriş:

Audit log axtarışı: aktor, əməliyyat, obyekt tipi/ID, tarix aralığı, IP, nəticə, korrelyasiya ID; tam mətn axtarışı (OpenSearch); saxlanmış sorğular; ixrac (CSV/JSON, imzalanmış).

4.18.4 Məlumat obyektləri

AuditLog, AuditSeal, AuditArchive, SystemConfiguration, FeatureFlag, RetentionPolicy, IntegrationConfig, Holiday, BrandingConfig, SystemHealthCheck, BackgroundJob, JobExecution

4.18.5 API

GET  /api/v1/audit-logs?actor=&action=&objectType=&objectId=&from=&to=&result=&ip=
GET  /api/v1/audit-logs/{id}
GET  /api/v1/audit-logs/export?format=csv|json     # loglanır
GET  /api/v1/audit-logs/integrity-check            # hash zənciri yoxlaması
GET  /api/v1/my/activity                           # öz tarixçəm
GET  /api/v1/admin/configuration
PUT  /api/v1/admin/configuration/{key}
GET  /api/v1/admin/feature-flags
PUT  /api/v1/admin/feature-flags/{key}
GET  /api/v1/admin/health                          # detallı
GET  /api/v1/admin/jobs
POST /api/v1/admin/jobs/{key}/run
GET  /api/v1/admin/retention-policies
PUT  /api/v1/admin/retention-policies/{id}
GET  /health/live                                  # k8s liveness
GET  /health/ready                                 # k8s readiness
GET  /metrics                                      # Prometheus

4.18.6 Qəbul meyarları

1. Audit log sətri heç bir rol, hətta DB administratoru tərəfindən tətbiq vasitəsilə dəyişdirilə/silinə bilmir (test: UPDATE cəhdi → exception).
2. Hash zəncirinin qırılması gündəlik yoxlamada aşkarlanır və kritik alarm yaradır.
3. Audit log-un ixracı özü audit logunda qeyd olunur.
4. Hər kritik hadisə ≤ 60 saniyə ərzində SIEM-ə çatır.
5. İstifadəçi öz fəaliyyət tarixçəsini görə bilir.
6. Audit log-da parol, token, tam FİN, kart nömrəsi kimi həssas dəyərlər maskalanmış şəkildədir (avtomatlaşdırılmış skan).
7. 100 milyon sətirlik audit log-da tarix + aktor filtri ≤ 3 saniyədə nəticə verir (partisiyalaşdırma + indeks).
8. Aylıq arxiv faylı imzalanır və imza yoxlanıla bilir.

5. Modul asılılıq xəritəsi (Module Dependency Map)

5.1 Qatlar

┌─────────────────────────────────────────────────────────────────────┐
│  TƏQDİMAT QATI                                                      │
│  M16 Dashboard & Hesabatlar                                         │
└─────────────────────────────────────────────────────────────────────┘
              ▲            ▲             ▲            ▲
┌─────────────┴────────────┴─────────────┴────────────┴───────────────┐
│  BİZNES MODULLARI                                                   │
│                                                                     │
│  İnsan qatı        GRC qatı              Məlumat qatı               │
│  ┌──────────┐      ┌──────────────┐      ┌──────────────┐           │
│  │ M01 Təlim│◀────▶│ M04 Uyğunluq │◀────▶│ M10 Təsnifat │           │
│  │ M02 Fişinq│     │ M05 Risk     │      │ M11 Discovery│           │
│  └──────────┘      │ M03 Siyasət  │      │ M12 DLP Policy│          │
│       │            │ M06 Audit    │      │ M13 DLP Incident│         │
│       │            │ M07 Sübut    │      └──────────────┘           │
│       │            │ M08 Aktiv    │             │                    │
│       │            │ M09 Təchizatçı│            │                    │
│       │            └──────────────┘             │                    │
│       └──────────▶  M15 Hadisələr  ◀────────────┘                    │
└─────────────────────────────────────────────────────────────────────┘
              ▲            ▲             ▲            ▲
┌─────────────┴────────────┴─────────────┴────────────┴───────────────┐
│  BÜNÖVRƏ (Faza 0/1 — birinci)                                       │
│  M17 İş axını & Tapşırıq & Bildiriş                                 │
│  M14 AD/IAM & RBAC                                                  │
│  M18 Konfiqurasiya & Audit izi                                      │
└─────────────────────────────────────────────────────────────────────┘

5.2 Məlumat axını matrisi

Sətir = mənbə, sütun = istehlakçı. Xanada: ötürülən məlumat.

5.3 Kritik inteqrasiya ssenariləri (uçdan-uca)

S1 — Fişinqdən riskə (§1.2 diaqramının detalı)

1. Kampaniya bitir (M02)
2. Hadisələr aqreqasiya olunur → şöbə üzrə kredensial göndərmə nisbəti = 18%
3. HRS yenidən hesablanır (M02) → 47 istifadəçi "Yüksək" banda keçir
4. Avtomatik: hər birinə mikro-təlim təyin olunur (M01), deadline 14 gün
5. Risk siqnalı işə düşür (M05): "Maliyyə şöbəsində BEC riski" → təklif: ehtimal 3→4
6. Risk meneceri təklifi qəbul edir → qalıq risk 12→16 (Kritik)
7. Risk sahibinə bildiriş (M17) + remediasiya tapşırığı (M17)
8. Nəzarət tədbiri A.6.3-ün effektivliyi yenidən qiymətləndirilir (M04)
9. Kampaniya hesabatı sübut kimi saxlanılır (M07) → A.6.3-ə bağlanır
10. Dashboard-da görünür (M16); Executive-də "İnsan Riski" göstəricisi dəyişir
11. Bütün addımlar audit logunda (M18)

S2 — DLP hadisəsindən uyğunluğa

1. Konnektor hadisə göndərir (M13): Məxfi fayl → xarici email, bloklandı
2. Zənginləşdirmə: AD-dən istifadəçi/şöbə/rəhbər (M14), təsnifat (M10), aktiv (M08)
3. Severity avtomatik: 78 → Yüksək
4. Analitikə təyinat, SLA 4 saat (M17)
5. İstifadəçidən izahat tələb olunur (M13→M17)
6. İzahat: "təchizatçıya müqavilə göndərirdim" → legitim
7. Analitik: istisna təklifi (M12) → təsdiq axını → təsdiqlənmiş partnyor domeni əlavə olunur
8. Eyni zamanda: HRS-ə təsir (hadisə təsdiqləndi, lakin qəsdli deyil → aşağı çəki) (M02)
9. 30 gün ərzində şöbədə 12 oxşar hadisə → risk siqnalı (M05)
10. A.8.12 (Data leakage prevention) nəzarət tədbirinin effektivliyi yenilənir (M04)
11. DLP statistikası sübut kimi (M07) → A.8.12

S3 — Auditdən remediasiyaya

1. Daxili audit planlanır (M06), skoup: A.8.* nəzarət tədbirləri
2. Checklist avtomatik generasiya olunur (M04 → M06)
3. Auditor sübut sorğusu göndərir (M06 → M07 → M17 tapşırıq)
4. Sübut sahibi yükləyir (M07), virus skan, təsdiq
5. Auditor yoxlayır → A.8.12 üçün sübut köhnədir (8 ay) → tapıntı: Minor NC (M06)
6. Tapıntı auditee-yə verilir, SLA 30 gün (M17)
7. Auditee RCA təqdim edir + düzəldici tədbir planı (M06)
8. Tapşırıqlar yaranır (M17), gecikmədə eskalasiya
9. Yeni sübut yüklənir (M07), tapıntıya bağlanır
10. Auditor yoxlayır → bağlanır (SoD-7: icra edən deyil)
11. A.8.12-nin statusu `implemented` → `operating_effectively` (M04)
12. Uyğunluq balı və audit hazırlığı balı artır (M04, M06 → M16)

S4 — AD dəyişikliyindən təyinata

1. İstifadəçi AD-də "İT şöbəsi"ndən "Maliyyə şöbəsi"nə köçürülür
2. Artımlı sinxronizasiya (15 dəq) dəyişikliyi tutur (M14)
3. `USER_DEPARTMENT_CHANGED` hadisəsi domain event kimi yayımlanır
4. M01 dinləyir: köhnə şöbənin rola xas təlimləri ləğv edilmir (tarixçə), yeni şöbənin
   məcburi proqramları təyin olunur ("BEC və ödəniş fırıldağı", 14 gün)
5. M03 dinləyir: Maliyyə şöbəsinə aid siyasətlər üçün tanışlıq tapşırığı yaranır
6. M14: rol mapping yenidən hesablanır — köhnə şöbənin skoupu ləğv olunur
7. M02: gələcək kampaniyalarda yeni şöbə üzrə hədəflənir
8. M05/M08: əgər aktiv/risk sahibi idisə → sahiblik ötürmə tapşırığı yaranır (M17)
9. Audit logunda hamısı `correlation_id` ilə bağlı (M18)

5.4 Texniki asılılıq qaydaları (kod səviyyəsində)

6. Detallı iş axınları (State Machines)

6.1 Siyasətin təsdiqi və tanışlıq

stateDiagram-v2
    [*] --> Draft
    Draft --> InternalReview: submit (müəllif)
    InternalReview --> Draft: request_changes
    InternalReview --> SecurityReview: approve (bütün rəyçilər)
    SecurityReview --> Draft: request_changes
    SecurityReview --> LegalReview: approve
    LegalReview --> Draft: request_changes
    LegalReview --> PendingApproval: approve
    PendingApproval --> Draft: reject
    PendingApproval --> Approved: approve (SoD-1 yoxlanır)
    Approved --> Published: effektiv tarix çatdı (avtomatik)
    Published --> AcknowledgementActive: tanışlıq tələb olunursa
    AcknowledgementActive --> Active: 100% və ya kampaniya bitdi
    Published --> Active: tanışlıq tələb olunmursa
    Active --> UnderPeriodicReview: baxış tarixi (avtomatik)
    UnderPeriodicReview --> Active: dəyişiklik yoxdur (təsdiqlə)
    UnderPeriodicReview --> Draft: yeni versiya
    Active --> Withdrawn: geri çəkilmə (təsdiqlə)
    Active --> Superseded: yeni versiya nəşr olundu
    Withdrawn --> Archived
    Superseded --> Archived
    Archived --> [*]

SLA-lar: InternalReview 5 gün, SecurityReview 3 gün, LegalReview 5 gün, PendingApproval 5 gün. Hər mərhələdə gecikmə → rəhbərə eskalasiya.

6.2 Fişinq kampaniyası

stateDiagram-v2
    [*] --> Draft
    Draft --> ReadyForReview: submit
    ReadyForReview --> SecurityReview: təhlükəsizlik yoxlama siyahısı
    SecurityReview --> Draft: reject
    SecurityReview --> Approved: approve (SoD-10)
    Approved --> Scheduled: schedule
    Scheduled --> Running: başlanğıc vaxtı
    Scheduled --> Approved: unschedule
    Running --> Paused: pause
    Paused --> Running: resume
    Running --> EmergencyStopped: EMERGENCY STOP
    Paused --> EmergencyStopped: EMERGENCY STOP
    Running --> Completed: bütün emaillər göndərildi + izləmə pəncərəsi bitdi
    EmergencyStopped --> Completed: hesabat yaradıldı
    Completed --> ReportIssued: hesabat nəşr olundu
    ReportIssued --> Archived

6.3 Risk həyat dövrü

stateDiagram-v2
    [*] --> Identified
    Identified --> UnderAssessment: qiymətləndirmə başladı
    UnderAssessment --> Assessed: ilkin + qalıq hesablandı
    Assessed --> TreatmentPlanning: emal tələb olunur (iştahadan yuxarı)
    Assessed --> Monitoring: iştaha daxilində
    TreatmentPlanning --> TreatmentInProgress: plan təsdiqləndi
    TreatmentPlanning --> PendingAcceptance: "accept" seçildi
    PendingAcceptance --> Accepted: təsdiqləndi (SoD-2)
    PendingAcceptance --> TreatmentPlanning: rədd edildi
    TreatmentInProgress --> Assessed: emal bitdi, yenidən qiymətləndir
    Accepted --> UnderReview: qəbul müddəti bitdi
    Monitoring --> UnderReview: dövri baxış tarixi
    UnderReview --> Assessed: yenidən qiymətləndirmə
    UnderReview --> Closed: risk aradan qalxdı
    Monitoring --> Closed: risk aradan qalxdı
    Closed --> Reopened: yenidən aktual
    Reopened --> UnderAssessment

6.4 Audit tapıntısı

stateDiagram-v2
    [*] --> Draft
    Draft --> AuditorReview: təqdim
    AuditorReview --> Draft: düzəliş
    AuditorReview --> Issued: rəsmiləşdir (SLA başlayır)
    Issued --> ManagementResponse: auditee cavab verir
    ManagementResponse --> Disputed: auditee etiraz edir
    Disputed --> AuditorReview: yenidən baxış
    Disputed --> Issued: etiraz rədd edildi
    ManagementResponse --> CorrectiveActionPlanned: RCA + plan qəbul edildi
    CorrectiveActionPlanned --> CorrectiveActionInProgress: icra başladı
    CorrectiveActionInProgress --> EvidenceSubmitted: sübut təqdim edildi
    EvidenceSubmitted --> AuditorVerification: auditor yoxlayır (SoD-7)
    AuditorVerification --> Closed: təsdiqləndi
    AuditorVerification --> Reopened: qeyri-kafi
    Reopened --> CorrectiveActionInProgress
    Closed --> EffectivenessReview: 3-6 ay sonra
    EffectivenessReview --> ConfirmedClosed: effektiv
    EffectivenessReview --> Reopened: effektiv deyil
    ConfirmedClosed --> [*]

6.5 DLP hadisəsi

stateDiagram-v2
    [*] --> New: konnektordan qəbul
    New --> Triage: analitik açdı (SLA sayğacı)
    Triage --> ClosedFP: yanlış pozitiv
    Triage --> ClosedDuplicate: dublikat
    Triage --> Investigating: təsdiqləndi
    Investigating --> UserResponseRequired: izahat tələb olunur
    UserResponseRequired --> Investigating: izahat alındı
    UserResponseRequired --> Escalated: cavab yoxdur (3 gün)
    Investigating --> ManagerResponseRequired: müdir təsdiqi
    ManagerResponseRequired --> Investigating: cavab alındı
    Investigating --> Contained: əməliyyat bloklandı/geri alındı
    Investigating --> Escalated: kritik / qəsdli
    Escalated --> SecurityIncident: M15-ə keçid
    Contained --> Resolved: kök səbəb aradan qaldırıldı
    Resolved --> Closed: sənədləşdirildi
    ClosedFP --> [*]
    ClosedDuplicate --> [*]
    Closed --> [*]
    SecurityIncident --> [*]

6.6 Sübutun həyat dövrü

stateDiagram-v2
    [*] --> Draft: yükləndi
    Draft --> MalwareScanning: avtomatik
    MalwareScanning --> Quarantined: zərərli aşkarlandı
    MalwareScanning --> Submitted: təmiz
    Quarantined --> [*]: silindi (alarm)
    Submitted --> UnderReview: rəyçiyə göndərildi
    UnderReview --> Rejected: qeyri-kafi
    Rejected --> Draft
    UnderReview --> Approved: təsdiqləndi (SoD-9)
    Approved --> Active: valid_from çatdı
    Active --> Expiring: valid_until − 30 gün
    Expiring --> Expired: valid_until keçdi
    Expiring --> Renewed: yeni versiya yükləndi
    Renewed --> Draft
    Expired --> Renewed
    Expired --> Archived: retention siyasəti
    Active --> Archived: obyekt arxivləşdirildi

6.7 DLP siyasətinin mərhələli tətbiqi

stateDiagram-v2
    [*] --> Draft
    Draft --> InternalReview: submit
    InternalReview --> SecurityReview
    SecurityReview --> Approved
    Approved --> TestMode: deploy (simulyasiya)
    TestMode --> MonitorMode: ≥2 həftə + statistika qəbul edildi
    MonitorMode --> Tuning: FP > 10%
    Tuning --> MonitorMode: qayda düzəldildi
    MonitorMode --> WarnMode: FP < 10%
    WarnMode --> JustifyMode: ≥2 həftə
    JustifyMode --> PilotEnforce: legitim istifadə istisnaları yaradıldı
    PilotEnforce --> FullEnforce: pilot uğurlu + rəhbərlik təsdiqi
    PilotEnforce --> WarnMode: biznes pozuntusu
    FullEnforce --> Suspended: fövqəladə söndürmə (dual control)
    Suspended --> MonitorMode: bərpa
    FullEnforce --> Retired: siyasət ləğv edildi

6.8 Təlim təyinatı

stateDiagram-v2
    [*] --> Assigned: qayda/kampaniya/əl ilə
    Assigned --> InProgress: istifadəçi başladı
    Assigned --> Overdue: deadline keçdi
    InProgress --> Overdue: deadline keçdi
    InProgress --> ExamPending: dərslər bitdi
    ExamPending --> Passed: bal ≥ keçid
    ExamPending --> Failed: bal < keçid
    Failed --> RetakeAvailable: cooldown bitdi
    RetakeAvailable --> ExamPending
    Failed --> Escalated: maks cəhd tükəndi
    Overdue --> Escalated: +N gün
    Escalated --> InProgress: istifadəçi davam etdi
    Passed --> Completed: sertifikat verildi
    Completed --> [*]

6.9 AD sinxronizasiya axını

┌─────────┐   1. Cədvəl/əl ilə    ┌──────────────┐
│ Scheduler│──────────────────────▶│ AD Sync Job  │
└─────────┘                        └──────┬───────┘
                                          │ 2. LDAPS bind (svc_etimad_ldap, Vault-dan parol)
                                          ▼
                                   ┌──────────────┐
                                   │ AD / LDAP    │
                                   └──────┬───────┘
                    3. Paged search (uSNChanged > lastSync)
                                          ▼
                              ┌───────────────────────┐
                              │ Normalizasiya         │
                              │ • objectGUID → key    │
                              │ • atribut mapping     │
                              │ • nested group açılışı│
                              │ • xidməti hesab filtri│
                              └───────┬───────────────┘
                                      ▼
                        ┌─────────────────────────┐
                        │ Fərq (diff) hesablanması│
                        └───────┬─────────────────┘
              ┌─────────────────┼─────────────────┐
              ▼                 ▼                 ▼
        Yeni istifadəçi    Dəyişiklik       Deaktiv/silinmiş
              │                 │                 │
              ▼                 ▼                 ▼
        ┌──────────────────────────────────────────────┐
        │ Tranzaksiya: upsert + audit log              │
        └───────┬──────────────────────────────────────┘
                ▼  4. Domain event-lər yayımlanır
   ┌────────────────────────────────────────────────────┐
   │ UserCreated / UserDepartmentChanged /              │
   │ UserGroupsChanged / UserDisabled / ManagerChanged  │
   └───┬───────────┬──────────┬──────────┬──────────────┘
       ▼           ▼          ▼          ▼
   M01 təyinat  M03 tanışlıq  M14 rol   M17 sahiblik
                             mapping     ötürmə tapşırığı
                ▼
       5. Sinxronizasiya hesabatı + xəta bildirişi

7. İnformasiya arxitekturası

7.1 Obyekt ierarxiyası

Organization (qurum)
 └─ OrganizationalUnit (idarə/departament ağacı, AD OU-dan)
     └─ Department (şöbə)
         └─ User (əməkdaş)

Framework → Domain → Requirement
                          ↕ ControlMapping
                      Control → ControlAssessment → Evidence
                          ↕
                        Risk → RiskAssessment → RiskTreatment → Task
                          ↕
                       Asset ← DataSet ← DataFlow
                          ↕
                      Vendor → VendorAssessment
                          ↕
                       Audit → AuditFinding → CorrectiveAction → Task
                          ↕
                   Document (Policy/Procedure/...) → PolicyAcknowledgement
                          ↕
              ClassificationLevel → ClassificationAssignment (polimorf)
                          ↕
                   DLPPolicy → DLPRule → DLPIncident
                          ↕
        TrainingProgram → TrainingAssignment → TrainingResult → Certificate
                          ↕
           PhishingCampaign → PhishingEvent → HumanRiskProfile
                          ↕
                  SecurityIncident
                          ↕
        Task / Workflow / Approval / Notification / AuditLog  (universal)

7.2 Universal obyekt əlaqələri (Linking)

Bütün əsas obyektlər bir-birinə polimorf əlaqə cədvəli ilə bağlanır:

object_link (
  id, source_type, source_id, target_type, target_id,
  link_type,        -- 'relates_to' | 'mitigates' | 'evidences' | 'derived_from'
                    -- | 'supersedes' | 'blocks' | 'duplicates' | 'implements'
  created_by, created_at, note
)

Bu, UI-da hər obyekt detalında "Əlaqəli obyektlər" panelini mümkün edir və yeni modul əlavə edildikdə sxem dəyişikliyi tələb etmir.

7.3 Universal axtarış

Vahid axtarış (global search, Ctrl+K): bütün obyekt tipləri üzrə, icazəyə görə filtrlənmiş.

Vacib: İndeksdə məxfi məzmun saxlanılmır — yalnız metadata və icazə verilən mətn. CONFIDENTIAL+ sənədlərin mətni indekslənmir (yalnız başlıq + ID), və ya ayrıca şifrələnmiş indeksdə saxlanılır (konfiqurasiya).

7.4 Naviqasiya taksonomiyası

1. İş (mənim gündəlik işim)      → Ana səhifə, Tapşırıqlar, Təsdiqlər, Bildirişlər
2. İnsan (awareness)              → Təlimlər, Fişinq, İnsan riski
3. İdarəetmə (governance)         → Siyasətlər, Uyğunluq, Risklər, Auditlər, Sübutlar
4. Aktivlər                       → Aktivlər, Təchizatçılar, Məlumat təsnifatı
5. Müdafiə (protection)           → DLP, Təhlükəsizlik hadisələri
6. Məlumat                        → Dashboard, Hesabatlar
7. Sistem                         → Administrasiya, İnteqrasiyalar

8. UI naviqasiyası və səhifə strukturu

8.1 Əsas naviqasiya (rola görə)

Sol yan panel (collapsible), rol əsaslı görünürlük:

Prinsip (P: role-based navigation): istifadəçi görmədiyi modulun menyu bəndini ümumiyyətlə görmür — "icazəniz yoxdur" səhifəsi deyil, menyu bəndi yoxdur. Adi əməkdaş 6 menyu bəndi görür, GRC mütəxəssisi 14.

Üst panel: Qurum loqosu | Qlobal axtarış (Ctrl+K) | Dil seçimi (AZ/EN/RU) | 🚨 Hadisə bildir | 🔔 Bildirişlər (badge) | İstifadəçi menyusu (Profil, Mənim fəaliyyətim, Mənim riskim, Çıxış)

8.2 Səhifə şablonları (Page Patterns)

Bütün modullar 5 səhifə şablonundan istifadə edir — öyrənilmə yükünü minimuma endirir.

Şablon A — Siyahı (List/Index)

┌──────────────────────────────────────────────────────────────────────┐
│ Risklər                                    [+ Yeni risk] [⬇ İxrac]  │
├──────────────────────────────────────────────────────────────────────┤
│ [Saxlanmış görünüş ▾: Mənim risklərim]  [🔍 Axtar...]  [⚙ Sütunlar] │
│ Filtrlər: [Səviyyə ▾] [Status ▾] [Şöbə ▾] [Sahib ▾] [Tarix ▾] [Təmizlə]│
├──────────────────────────────────────────────────────────────────────┤
│ ☐ │ ID ↕ │ Başlıq ↕ │ Kateqoriya │ Sahib │ İlkin │ Qalıq │ Status │⋮│
│ ☐ │RSK-..│ ...      │ ...        │ ...   │🟠 12  │🟡 8   │● Emalda│⋮│
│ ☐ │RSK-..│ ...      │ ...        │ ...   │🔴 20  │🔴 16  │● Yeni  │⋮│
├──────────────────────────────────────────────────────────────────────┤
│ 2 seçilib: [Sahib dəyiş] [Teq əlavə et] [İxrac]                     │
│                                        ◀ 1 2 3 ... 12 ▶  50/səh ▾   │
└──────────────────────────────────────────────────────────────────────┘

Xüsusiyyətlər: server-side pagination/sort/filter, sütun seçimi (istifadəçi başına saxlanılır), saxlanmış görünüşlər (paylaşıla bilən), toplu əməliyyatlar, sətir üzrə ⋮ menyusu, boş vəziyyət (empty state) mesajı + ilk addım təklifi.

Şablon B — Detal (Detail)

┌──────────────────────────────────────────────────────────────────────┐
│ ← Risklər  /  RSK-2026-0014                                          │
│ Maliyyə şöbəsində BEC (Business Email Compromise) riski              │
│ ● Emal edilir   🔴 Qalıq: 16 (Kritik)   Sahib: A.Məmmədova           │
│                              [Redaktə] [Emal planı] [⋮ Digər]        │
├───────────────────────────────────┬──────────────────────────────────┤
│ [Ümumi][Qiymətləndirmə][Emal]     │  Əlaqəli obyektlər               │
│ [Əlaqələr][Tarixçə][Şərhlər]      │  ├ 📋 Nəzarət: CTL-0034, CTL-0056│
│                                    │  ├ 📄 Siyasət: Email təhlükəsiz. │
│  Təsvir                            │  ├ 🖥️ Aktiv: Exchange (AST-0012) │
│  ...                               │  ├ 🎣 Kampaniya: PHC-2026-03     │
│                                    │  ├ 📎 Sübut: 3 fayl              │
│  Təhdid: Sosial mühəndislik        │  └ ✅ Tapşırıq: 2 açıq           │
│  Zəiflik: İşçi məlumatlılığı       │                                  │
│                                    │  Metadata                        │
│  ┌ İlkin ──┐  ┌ Qalıq ──┐         │  Yaradıldı: 12.03.2026           │
│  │ E:4 T:5 │  │ E:4 T:4 │         │  Son baxış: 01.09.2026           │
│  │  = 20   │  │  = 16   │         │  Sonrakı: 01.12.2026 ⚠ 12 gün    │
│  └─────────┘  └─────────┘         │                                  │
└───────────────────────────────────┴──────────────────────────────────┘

Şablon C — Sihirbaz (Wizard)

Çox addımlı yaratma: yuxarıda addım göstəricisi (1─2─3─4), hər addımda validasiya, "Geri/İrəli", son addımda tam baxış, "Layihə kimi saxla" hər addımda. İstifadə: risk qiymətləndirmə, fişinq kampaniyası, DLP qaydası, təchizatçı qiymətləndirməsi, audit planı.

Şablon D — İş axını / Təsdiq (Workflow)

Sol: obyektin xülasəsi (dəyişməz); orta: cari mərhələ + tələb olunan fəaliyyət; sağ: iş axını tarixçəsi (timeline: kim, nə vaxt, nə qərar, şərh). Aşağıda: [Təsdiq et] [Düzəliş istə] [Rədd et] + şərh sahəsi (rədd/düzəliş üçün məcburi).

Şablon E — Dashboard

Grid layout, widget-lər, filtr paneli yuxarıda, hər widget-də: başlıq, məlumat aktuallığı, ⋮ menyu (ixrac, cədvəl kimi göstər, gizlət).

8.3 UX prinsipləri (normativ)

8.4 Dizayn sistemi

• Komponent kitabxanası: Ayrıca paket (@etimad/ui), Storybook ilə sənədləşdirilmiş
• Token-lər: rəng, tipoqrafiya, boşluq, radius, kölgə — CSS custom properties
• Tipoqrafiya: Azərbaycan hərflərinin (ə, ğ, ı, ö, ş, ü, ç) tam dəstəyi — Inter və ya Noto Sans (offline, lokal hostlanmış)
• Rəng palitrası: Neytral əsas + status rəngləri (uğur/xəbərdarlıq/xəta/məlumat) + təsnifat rəngləri (konfiqurasiya edilə bilən); hamısı WCAG AA kontrast yoxlamasından keçmiş
• İkonlar: Tək dəst (Lucide və ya Phosphor), lokal
• Komponentlər (minimum 40): Button, Input, Select, MultiSelect, DatePicker, DateRangePicker, Textarea, RichTextEditor, Checkbox, Radio, Switch, Table (sort/filter/paginate/select), Card, Modal, Drawer, Tabs, Accordion, Badge/Chip, StatusChip, Alert, Toast, Tooltip, Popover, Breadcrumb, Pagination, Stepper, Timeline, EmptyState, Skeleton, ProgressBar, Avatar, FileUpload, FilePreview, SearchBox, FilterPanel, SavedViews, RiskMatrix, HeatMap, Chart (bar/line/donut/sparkline), DataTable, ConfirmDialog, JustificationDialog, RelatedObjectsPanel, WorkflowTimeline, ClassificationBadge

9. Sistem arxitekturası

9.1 C4 Level 1 — Kontekst diaqramı

graph TB
    subgraph "Qurum daxili istifadəçilər"
        EMP[Əməkdaş]
        MGR[Şöbə müdiri]
        GRC[GRC / Təhlükəsizlik mütəxəssisi]
        AUD[Daxili auditor]
        EXE[Rəhbərlik]
        ADM[Platforma administratoru]
    end
    subgraph "Xarici"
        EXT[Xarici auditor]
        VND[Təchizatçı nümayəndəsi]
    end

    ETIMAD[["ETİMAD Platforması<br/>Vahid İT təhlükəsizliyi,<br/>uyğunluq və insan riski<br/>platforması"]]

    AD[(Active Directory /<br/>LDAP)]
    SMTP[Qurum SMTP /<br/>Exchange]
    SIEM[SIEM / SOAR]
    DLPV[DLP məhsulları<br/>endpoint / email / şəbəkə]
    TCK[Ticketing<br/>Jira / ServiceNow / GLPI]
    AV[Antivirus / ICAP]
    HR[HR / Kadr sistemi]
    CMDB[(Mövcud CMDB<br/>opsional)]
    VAULT[Secret Manager<br/>HashiCorp Vault]
    NTP[NTP serveri]

    EMP --> ETIMAD
    MGR --> ETIMAD
    GRC --> ETIMAD
    AUD --> ETIMAD
    EXE --> ETIMAD
    ADM --> ETIMAD
    EXT -.məhdud, müddətli.-> ETIMAD
    VND -.portal, token.-> ETIMAD

    ETIMAD -->|LDAPS oxuma| AD
    ETIMAD -->|SMTP/TLS| SMTP
    ETIMAD -->|syslog CEF / webhook| SIEM
    DLPV -->|hadisə push| ETIMAD
    ETIMAD -->|qayda paketi| DLPV
    ETIMAD <-->|REST| TCK
    ETIMAD -->|ICAP skan| AV
    HR -.CSV/API.-> ETIMAD
    CMDB -.import.-> ETIMAD
    ETIMAD --> VAULT
    ETIMAD --> NTP

9.2 C4 Level 2 — Konteyner diaqramı

graph TB
    subgraph DMZ["DMZ Zonası"]
        RP[Reverse Proxy / WAF<br/>nginx + ModSecurity]
        LAND[Phishing Landing Service<br/>ayrıca, minimal, DB yazma yox]
        VPORT[Vendor Portal<br/>opsional, izolyasiya]
    end

    subgraph APP["Tətbiq Zonası"]
        WEB[Web Frontend<br/>React 19 SPA<br/>statik fayllar]
        API[ETİMAD API<br/>ASP.NET Core 9<br/>Modular Monolith]
        WORKER[Background Worker<br/>Hangfire / özəl]
        SCHED[Scheduler<br/>cron işləri]
        NOTIF[Notification Service<br/>modul]
        REPORT[Report Renderer<br/>PDF/DOCX/XLSX]
        MAILER[Phishing Mail Sender<br/>ayrıca proses, rate-limited]
        SYNC[AD Sync Service<br/>modul/worker]
        GW[DLP Integration Gateway<br/>hadisə qəbulu + qayda paylanması]
    end

    subgraph IAM["Kimlik Zonası"]
        KC[Keycloak<br/>OIDC/SAML IdP]
    end

    subgraph DATA["Məlumat Zonası"]
        PG[(PostgreSQL 16<br/>primary + replica)]
        PGA[(PostgreSQL<br/>audit log<br/>ayrı DB/instans)]
        REDIS[(Redis<br/>cache + sessiya + kilid)]
        MQ[RabbitMQ<br/>mesaj broker]
        OS[(OpenSearch<br/>axtarış + log analitika)]
        MINIO[(MinIO<br/>S3 obyekt saxlama<br/>sübut/media/fayl)]
        VAULT[Vault<br/>secret + KMS]
    end

    subgraph OBS["Müşahidə"]
        PROM[Prometheus]
        GRAF[Grafana]
        LOKI[Loki / OpenSearch]
        TEMPO[Tempo / Jaeger]
    end

    RP --> WEB
    RP --> API
    RP --> LAND
    RP --> VPORT
    WEB --> API
    API --> KC
    API --> PG
    API --> PGA
    API --> REDIS
    API --> MQ
    API --> OS
    API --> MINIO
    API --> VAULT
    WORKER --> PG
    WORKER --> MQ
    WORKER --> MINIO
    LAND -->|yalnız event| MQ
    MAILER --> MQ
    GW --> MQ
    SYNC --> PG
    MQ --> WORKER
    MQ --> NOTIF
    MQ --> GW
    API --> PROM

9.3 Arxitektura qərarı: Modular Monolith (ADR-001)

Qərar: MVP və Faza 1–3 üçün Modular Monolith, ayrılmış yardımçı servislərlə (landing, mail sender, vendor portal).