Təhlükəsizlik bizdə sonradan əlavə edilmiş bir təbəqə deyil, arxitekturanın mərkəzidir. Verilən izolyasiyası, kimlik ayrımı və idempotent yazma kodun ən alt təbəqəsinə hopdurulmuşdur — bağlana bilən bir parametr deyil, sistemin işləmə tərzidir.
Sətir səviyyəsində izolyasiya
İdempotent yazma
Parametrli sorğu
Loopback izolyasiyası
Verilən izolyasiyası
Sətir səviyyəsində izolyasiya — fail-closed
Hər kirayəçi-əhatəli cədvəldə PostgreSQL Row-Level Security FORCE aktivdir; siyasət hər sətri "tenant_id = current_setting('app.current_tenant')" şərtinə bağlayır.
Tenant context qurulmadan gələn bir sorğu sıfır sətir qaytarır — xəta belə deyil, səssizcə boş. Bir klinikanın verisini başqa bir klinikanın sessiyası ilə görmək arxitektura olaraq mümkünsüzdür.
Çarpaz-kiracı izolyasiya testi davamlı inteqrasiyada (CI) məcburi yaşıldır; qırmızıdırsa kod birləşdirilmir.
Atomik yazma
Transaction-local kimlik, atomik əməliyyat
Kirayəçi kimliyi hər yazma əməliyyatında transaction-un ƏN ƏVVƏLİNDƏ set edilir və yalnız həmin transaction boyunca keçərlidir; bağlantı hovuzuna yapışmır, digər sorğulara sızmır.
Çox-varlıqlı əməliyyatlar (faktura + kalem + ödəniş + stok düşümü) tək bir transaction içində atomikdir: ya hamısı birlikdə yazılır ya da heç biri. Yarımçıq qalmış, ardıcıl olmayan qeyd yaranmır.
Səlahiyyət
Rol əsaslı səlahiyyət (RBAC) serverdə məcbur edilir
Səlahiyyət nəzarəti API səviyyəsində edilir; müştəriyə və ya ön yüzə heç vaxt etibar edilmir. Brauzerdə bir menyunu gizlətmək yalnız görünüşlə əlaqədardır — gerçək qərar serverdədir.
Nüvə (Faz 1) mutasiyaları admin, katib və həkim rollarına görə qorunur. Səlahiyyətsiz bir rol uc nöqtəni çağırsa belə sorğu rədd edilir.
Təkrar qoruması
İdempotent yazma — ikiqat əməliyyat yox
Hər yazma sorğusu bir Idempotency-Key daşır; server tərəfindəki kilid eyni açarla gələn ikinci əməliyyatı əngəlləyir.
Şəbəkə qırıldıqda ya da müştəri eyni sorğunu yenidən göndərdikdə belə ikinci bir tahsilat ya da hesab-faktura yaranmır. Nəticə hər zaman tək və proqnozlaşdırıla biləndir.
Sorğu təhlükəsizliyi
SQL injection mümkünsüz — parametrli sorğu
Bütün verilənlər bazası sorğuları sqlc ilə kompilyasiya zamanında yaradılan, tamamilə parametrli ifadələrdir. Kod bazasında istifadəçi girişi ilə əl ilə string birləşdirərək SQL quran tək bir sətir yoxdur.
Bu, SQL injection hücum sinifini strukturca aradan qaldırır — "filtrləmə" və ya "qaçış" cəhdinə deyil, sorğunun qurulma tərzinə əsaslanır.
Şəbəkə səthi
Loopback izolyasiyası — nüvə kənara bağlı
Nüvə API yalnız 127.0.0.1 (loopback) dinləyir. 0.0.0.0 və ya public bir IP-yə bağlanma cəhdi başlanğıcda rədd edilir; nüvə heç bir halda internetə açılmır.
Tək public səth nazik bir qapıdır (BFF): sessiya, render və CSRF xaricində iş qaydası saxlamır. Brauzer nüvə API-ni heç vaxt birbaşa görə və ünvanlaya bilməz.
Kimlik və sessiya
argon2id parol, opaque sessiya açarı
Parollar sənaye standartı, yaddaş-çətin argon2id ilə hash-lənir; düz və ya zəif hash istifadə edilmir.
Sessiya açarları 32 baytlıq kripto-təsadüfi opaque dəyərlərdir, Redis-də saxlanılır və TTL ilə bitir. Brauzerə yalnız HttpOnly + Secure + SameSite cookie əks olunur; açar JavaScript-ə heç vaxt açılmır.
Audit
Dəyişdirilə bilməyən audit qeydi (append-only)
Vacib əməliyyatlar, onları tetikləyən mutasiya ilə EYNİ transaction içində append-only audit qeydinə yazılır. Əməliyyat geri alınırsa audit qeydi də yazılmır — ikisi ayrıla bilməz.
Audit cədvəlindən UPDATE/DELETE səlahiyyəti alınmışdır; qeydlər sonradan redaktə edilə və ya silinə bilməz. Keçmiş, olduğu kimi qalır.
Məxfilik
Həssas verilən maskalama
TCKN, parol, sessiya açarı və sağlamlıq verisi loglara heç bir şəkildə girmir. Sazlama çıxışlarında belə bu sahələr maskalanır.
Lazım gəldikdə həssas sahələr sütun səviyyəsində şifrələnir. Xüsusi nitelikli sağlamlıq verisi, dizaynın əvvəldən içinə yerləşdirilmiş qaydalarla qorunur.
Pul bütövlüyü
Pul təhlükəsizliyi — numeric, tərs qeyd
Pul hər yerdə numeric(14,2) ilə saxlanılır; float ilə pul hesabı edilmir. Yuvarlaqlaşdırma tək bir nöqtədə, serverdə baş verir — qəpik sürüşməsi ya da yuvarlaqlaşdırma fərqi yaranmır.
Ləğv və qaytarma, qeydi silmək yerinə tərs bir qeyd olaraq işlənir. Cari balans əl ilə yazılmır; daim faktura və ödəniş cəmindən törədilir. Keçmiş pozulmur.
Ötürmə
Ötürmə və brauzer təhlükəsizliyi
Bütün trafik HTTPS/TLS üzərindən daşınır və HSTS açıqdır; brauzer bağlantını yalnız şifrəli olaraq qurur.
Sərt məzmun təhlükəsizliyi siyasəti (CSP) inline script-i əngəlləyir; X-Frame-Options DENY clickjacking-i, X-Content-Type-Options nosniff növ-qarışdırmanı önləyir. Referrer-Policy və Permissions-Policy də tətbiq edilir.
Vacib
Kimlik tier ayrımı + ayrı idarəetmə müstəvisi
Klinika istifadəçisi, xəstə portalı və platforma-operatoru AYRI kimlik tier-ləridir: ayrı başlıq, ayrı sessiya sahəsi. Bir tier-in açarı digərində işləmir — səlahiyyət sərhədləri qəti şəkildə ayrılmışdır.
Platforma və idarəetmə uçları (kirayəçi təminatı, faktura, avtomatlaşdırma/plagin idarəetməsi, API açarı yaradılması) public API-də YER ALMIR.
Bu funksiyalar ayrı, daxili, fərqli kimlik nümunəsinə (xüsusi idarəetmə açarı) sahib bir nəzarət müstəvisində işləyir; kənardan girilə bilməz və kəşf edilə bilməz. Beləliklə hücum səthi əhəmiyyətli şəkildə kiçilir.
NECƏ İŞLƏYİR
Tək transaction, fail-closed izolyasiya
Aşağıdakı konseptual axın, hər yazmanın necə kiracıya kilidləndiyini və idempotent qaldığını göstərir. Yalnız izahat məqsədlidir.
# 1) Tenant kontekst transaction-un ƏN ƏVVƏLİNDƏ qurulur (yalnız bu tx-ə xas)
BEGIN;
SELECT set_config('app.current_tenant', :session_tenant_id, true);
# 2) Idempotency-Key kilidi — eyni açarla ikinci əməliyyat yaranmırSELECT lock_idempotency(:idempotency_key);
# 3) Çox-varlıqlı yazma — hamısı tək tx-də atomikdirINSERT INTO invoices ...; # RLS: tenant_id avtomatik əhatə olunurINSERT INTO payments ...;
INSERT INTO audit_log ...; # append-only, eyni tx
COMMIT;
# Context qurulmasa RLS siyasəti heç bir sətir qaytarmır:SELECT * FROM patients; --> 0 sətir (xəta deyil, səssizcə boş)
Müstəqil yoxlanıla bilən
Ötürmə təhlükəsizliyinin bir hissəsi kənardan müşahidə oluna bilər: bağlantınızdakı HTTPS/TLS sertifikatını, HSTS və məzmun təhlükəsizlik siyasəti kimi cavab təhlükəsizlik başlıqlarını brauzerinizin tərtibatçı alətlərindən özünüz araşdıra bilərsiniz. İddialarımız arxitektura nəzarətlərinə əsaslanır, marketinq cümlələrinə deyil.
Təhlükəsizlik arxitekturası haqqında sualınız var?
Komandamız texniki detalları və uyğunluq tələblərinizi sizinlə danışmaqdan məmnuniyyət duyar.