Bizda xavfsizlik keyinchalik qo‘shilgan qatlam emas, arxitekturaning markazidir. Ma’lumot izolyatsiyasi, identifikatsiya ajratilishi va idempotent yozuv kodning eng quyi qatlamiga singdirilgan — o‘chirib bo‘ladigan sozlama emas, tizimning ishlash uslubidir.
Qator darajasidagi izolyatsiya
Idempotent yozuv
Parametrli so‘rov
Loopback izolyatsiyasi
Ma’lumot izolyatsiyasi
Qator darajasidagi izolyatsiya — fail-closed
Har bir ijarachiga bogʻliq jadvalda PostgreSQL Row-Level Security FORCE yoqilgan; siyosat har bir qatorni "tenant_id = current_setting('app.current_tenant')" shartiga bogʻlaydi.
Tenant kontekst o‘rnatilmasdan kelgan so‘rov nol qator qaytaradi — hatto xato ham emas, jimgina bo‘sh. Bir klinika ma’lumotini boshqa klinika sessiyasi bilan ko‘rish arxitektura jihatidan imkonsiz.
Cross-ijarachi izolyatsiya testi uzluksiz integratsiyada (CI) majburiy yashil; qizil bo‘lsa kod birlashtirilmaydi.
Atomik yozuv
Transaction-local identifikatsiya, atomik amal
Ijarachi identifikatori har bir yozish amalida transaction'ning ENG BOSHIDA oʻrnatiladi va faqat oʻsha transaction davomida amal qiladi; ulanish hovuziga yopishmaydi, boshqa soʻrovlarga sizib chiqmaydi.
Ko‘p-obyektli amallar (hisob-faktura + qator + to‘lov + stok kamayishi) bitta transaction ichida atomik: yoki hammasi birga yoziladi, yoki hech biri. Chala qolgan, nomuvofiq yozuv yuzaga kelmaydi.
Vakolat
Rol asosidagi vakolat (RBAC) serverda ta’minlanadi
Vakolat nazorati API qatlamida amalga oshiriladi; mijozga yoki old tomonga hech qachon ishonilmaydi. Brauzerda menyuni yashirish faqat ko‘rinishga oid — haqiqiy qaror serverda.
Yadro (Faz 1) mutatsiyalari admin, kotib va shifokor rollariga ko‘ra himoyalangan. Vakolatsiz rol so‘nggi nuqtani chaqirsa ham so‘rov rad etiladi.
Takrordan himoya
Idempotent yozuv — ikki marta amal yo‘q
Har bir yozuv so‘rovi Idempotency-Key olib yuradi; server tomonidagi qulf bir xil kalit bilan kelgan ikkinchi amalni bloklaydi.
Tarmoq uzilganda yoki mijoz bir xil so‘rovni qayta yuborganda ham ikkinchi undirish yoki hisob-faktura yaratilmaydi. Natija har doim yagona va bashoratli bo‘ladi.
So‘rov xavfsizligi
SQL injection imkonsiz — parametrli so‘rov
Barcha ma’lumotlar bazasi so‘rovlari sqlc bilan kompilyatsiya vaqtida ishlab chiqarilgan, to‘liq parametrlangan ifodalardir. Kod bazasida foydalanuvchi kiritmasi bilan qo‘lda string birlashtirib SQL quradigan bitta ham qator yo‘q.
Bu SQL injection hujum sinfini tuzilmaviy tarzda yo‘q qiladi — "filtrlash" yoki "qochirish" harakatiga emas, so‘rovning tuzilish shakliga tayanadi.
Tarmoq yuzasi
Loopback izolyatsiyasi — yadro tashqariga yopiq
Asosiy API faqat 127.0.0.1 (loopback) tinglaydi. 0.0.0.0 yoki public IP'ga bogʻlanish urinishi boshlanishidayoq rad etiladi; asosiy tizim hech qanday holatda internetga ochilmaydi.
Yagona public yuza ingichka eshikdir (BFF): sessiya, render va CSRF'dan tashqari biznes qoidalarini saqlamaydi. Brauzer asosiy API'ni hech qachon bevosita koʻra olmaydi, unga murojaat qila olmaydi.
Identifikatsiya va sessiya
argon2id parol, opaque sessiya kaliti
Parollar soha standarti boʻlgan, xotira-talab argon2id yordamida hash'lanadi; ochiq yoki zaif hash ishlatilmaydi.
Sessiya kalitlari 32 baytli kripto-tasodifiy opaque qiymatlar boʻlib, Redis'da saqlanadi va TTL bilan muddati tugaydi. Brauzerga faqat HttpOnly + Secure + SameSite cookie aks etadi; kalit JavaScript'ga hech qachon ochilmaydi.
Muhim amallar, ularni ishga tushiradigan mutatsiya bilan BIR XIL transaction ichida append-only audit yozuviga yoziladi. Amal qaytarilsa audit yozuvi ham yozilmaydi — ikkisi ajralmas.
Audit jadvalidan UPDATE/DELETE huquqi olib tashlangan; yozuvlar keyinchalik tahrirlab yoki o‘chirib bo‘lmaydi. O‘tmish o‘z holicha qoladi.
Maxfiylik
Nozik ma’lumotni niqoblash
TCKN, parol, sessiya kaliti va sog‘liq ma’lumoti loglarga hech qanday shaklda kirmaydi. Nosozliklarni tuzatish chiqishlarida ham bu maydonlar niqoblanadi.
Kerak bo‘lganda nozik maydonlar ustun darajasida shifrlanadi. Maxsus toifadagi sog‘liq ma’lumoti dizaynga boshidan joylashtirilgan qoidalar bilan himoyalanadi.
Pul yaxlitligi
Pul xavfsizligi — numeric, teskari yozuv
Pul hamma joyda numeric(14,2) bilan saqlanadi; float bilan pul hisobi qilinmaydi. Yaxlitlash bitta nuqtada, serverda amalga oshadi — tiyin siljishi yoki yaxlitlash farqi yuzaga kelmaydi.
Bekor qilish va qaytarish yozuvni o‘chirish o‘rniga teskari yozuv sifatida qayd etiladi. Balans qo‘lda yozilmaydi; doim hisob-faktura va to‘lov yig‘indisidan hosil qilinadi. O‘tmish buzilmaydi.
Uzatish
Uzatish va brauzer xavfsizligi
Barcha trafik HTTPS/TLS orqali uzatiladi va HSTS yoqilgan; brauzer ulanishni faqat shifrlangan holda o‘rnatadi.
Qatʼiy kontent xavfsizlik siyosati (CSP) inline script'ni bloklaydi; X-Frame-Options DENY clickjacking'ni, X-Content-Type-Options nosniff tur-chalkashligini oldini oladi. Referrer-Policy va Permissions-Policy ham qoʻllaniladi.
Muhim
Identifikatsiya darajasi ajratilishi + alohida boshqaruv tekisligi
Klinika foydalanuvchisi, bemor portali va platforma-operatori ALOHIDA identifikatsiya tier'laridir: alohida sarlavha, alohida sessiya maydoni. Bir tier'ning kaliti boshqasida ishlamaydi — vakolat chegaralari qatʼiy ajratilgan.
Platforma va boshqaruv uchlari (ijarachi taʼminlash, hisob-kitob, avtomatlashtirish/plagin boshqaruvi, API kalit yaratish) public API'da MAVJUD EMAS.
Bu funksiyalar alohida, ichki, boshqacha identifikatsiya andozasiga (maxsus boshqaruv kaliti) ega bo‘lgan boshqaruv tekisligida ishlaydi; tashqaridan kirib bo‘lmaydi va aniqlab bo‘lmaydi. Shu tariqa hujum yuzasi sezilarli darajada kichrayadi.
QANDAY ISHLAYDI
Yagona transaction, fail-closed izolyatsiya
Quyidagi kontseptual oqim har bir yozuvning ijarachiga qanday qulflanishini va idempotent qolishini ko‘rsatadi. Faqat tushuntirish maqsadida.
# 1) Tenant konteksti transaction'ning ENG BOSHIDA oʻrnatiladi (faqat shu tx'ga xos)
BEGIN;
SELECT set_config('app.current_tenant', :session_tenant_id, true);
# 2) Idempotency-Key qulfi — bir xil kalit bilan ikkinchi amal yaratilmaydiSELECT lock_idempotency(:idempotency_key);
# 3) Koʻp-obyektli yozish — hammasi bitta tx'da atomikINSERT INTO invoices ...; # RLS: tenant_id avtomatik qamraladiINSERT INTO payments ...;
INSERT INTO audit_log ...; # append-only, bir xil tx
COMMIT;
# Kontekst o‘rnatilmasa RLS siyosati hech qanday qatorni qaytarmaydi:SELECT * FROM patients; --> 0 qator (xato emas, jimgina bo‘sh)
Mustaqil tekshirilishi mumkin
Uzatish xavfsizligining bir qismini tashqaridan kuzatish mumkin: ulanishingizdagi HTTPS/TLS sertifikatini, HSTS va kontent xavfsizlik siyosati kabi javob xavfsizlik sarlavhalarini brauzeringizning dasturchi vositalari orqali o‘zingiz tekshirishingiz mumkin. Da’volarimiz marketing gaplarga emas, arxitektura nazoratlariga asoslanadi.
Xavfsizlik arxitekturasi haqida savolingiz bormi?
Jamoamiz texnik tafsilotlar va muvofiqlik talablaringizni siz bilan muhokama qilishdan mamnun.