Muvofiqlik talablari og‘ir SaaS uchun texnologik stek tanlash

SaaS mahsulot banklar, shifoxonalar yoki yirik korxonalarga sotilganda, talablarga muvofiqlik hujjat bo‘lishdan to‘xtab, tizimni shakllantira boshlaydi. Mijozlar xavfsizlik so‘rovnomalarini yuboradi, SOC 2 hisoboti yoki ISO 27001 sertifikatini so‘raydi va shartnomalariga ma’lumotlarni qayta ishlash shartlarini kiritadi. Bozorga qarab mahsulot GDPR, PCI DSS yoki HIPAA talablariga ham javob berishi kerak bo‘lishi mumkin.

Bu standartlarning hech biri qaysi ma’lumotlar bazasi yoki tildan foydalanishni aytmaydi. Ular natijalarni tasvirlaydi: ma’lumotlar himoyalangan, kirish nazorat qilinadi, o‘zgarishlar ko‘rib chiqiladi, hodisalar payqaladi. Siz tanlagan stek bu natijalarni yildan-yilga, ishi sizga shubha bilan qarash bo‘lgan odamlarga ko‘rsatish qanchalik qiyin bo‘lishini belgilaydi.

Muvofiqlik aslida nimani cheklaydi

Qog‘ozbozlikni olib tashlasangiz, talablarning aksariyati bir nechta texnik sohaga to‘g‘ri keladi.

• Ma’lumotlarning joylashuvi. Ba’zi mijozlar yoki qonunlar ma’lumotlar muayyan mintaqada qolishini talab qiladi. GDPR maxsus kafolatlar bo‘lmasa, shaxsiy ma’lumotlarni Yevropa iqtisodiy hududidan tashqariga o‘tkazishni cheklaydi va ko‘p xaridorlar bu savolni chetlab o‘tish uchun shunchaki Yevropa Ittifoqida hosting so‘raydi. Bu bulut mintaqalaringizni, shuningdek zaxira nusxalar, loglar, e-pochta provayderi va qo‘llab-quvvatlash vositalari o‘z nusxalarini qayerda saqlashini belgilaydi.
• Audit izlari. Kim, qachon va qayerdan nima qilganini ko‘rsatishingiz kerak: mahsulotda, infratuzilmada va kodda. Bu yozuvlarni o‘zgartirish qiyin bo‘lishi va ular belgilangan muddat saqlanishi kerak.
• Kirishni boshqarish. Xodimlar faqat o‘z roliga kerakli narsaga, kuchli autentifikatsiya bilan va har bir berilgan huquq qayd etilgan holda kira olishi kerak. Production ma’lumotlariga kirish kamdan-kam, asosli va loglangan bo‘lishi kerak.
• Shifrlash. Uzatishda va saqlashda shifrlangan ma’lumotlar bu boshlang‘ich daraja. Qiyinroq savollar: kalitlarni kim boshqaradi, ular qanday almashtiriladi va ba’zi mijozlarga o‘z kalitlari kerakmi.
• Saqlash va o‘chirish. Ba’zi yozuvlarni yillab saqlashingiz, boshqalarini esa so‘rov bo‘yicha o‘chirishingiz kerak. GDPRdagi o‘chirish huquqi zaxira nusxalar, analitika nusxalari va loglargacha yetib boradi va aksariyat tizimlar aynan shu yerda qiynaladi.

Biror narsani tanlashdan oldin duch kelgan har bir talabni shu sohalarga taqsimlab chiqing. Bu taqsimot keyingi har bir qaror tekshiriladigan ro‘yxatga aylanadi.

Boshqariladigan servislarmi yoki o‘zingiz yuritasizmi

Yirik bulut provayderining boshqariladigan ma’lumotlar bazasi, navbati yoki kalitlar servisi provayderning o‘z sertifikatlari va umumiy mas’uliyat modeli bilan keladi. Provayder jismoniy xavfsizlik, platformaning yangilanishi va ma’lumotlar saqlanishining ishonchliligini isbotlaydi. Siz esa uni qanday sozlaganingiz va unga kim kira olishini isbotlaysiz.

Bunday taqsimot odatda muvofiqlik talablari og‘ir mahsulot uchun boshqariladigan servislar foydasiga ishlaydi. O‘zingiz yuritadigan har bir komponent taqdim etishingiz kerak bo‘lgan dalillarni ko‘paytiradi: yangilanishlar yozuvlari, zaxira nusxalarni sinash, zaifliklarni skanerlash, kirish huquqlarini ko‘rib chiqish. Kichik jamoa o‘zi yuritadigan ma’lumotlar bazasiga yaxshi qaralayotganini isbotlashga kutilmagan darajada ko‘p vaqt sarflashi mumkin.

Ba’zi narsalarni o‘zingiz yuritish uchun sabablar bor. Mijoz o‘z serverlarida (on-premises) yoki faqat o‘zi uchun alohida (single-tenant) o‘rnatishni talab qilishi mumkin. Boshqariladigan servis sizga kerakli mintaqada bo‘lmasligi mumkin. HIPAA uchun provayder business associate agreement (BAA) imzolashi kerak va uning katalogidagi hamma servislar ham bu kelishuv bilan qamrab olinmaydi, shuning uchun tanlashdan oldin ro‘yxatni tekshiring. Karta ma’lumotlari bo‘yicha odatiy maslahat ularni to‘lov provayderining o‘z maydonlari (hosted fields) yoki tokenizatsiya yordamida tizimlaringizdan butunlay chetda saqlash, bu PCI DSS qamrovini stekning kichik bir qismigacha qisqartiradi.

Standart holatda boshqariladigan servisni tanlang, o‘zingiz yuritishni esa faqat talab majbur qilgan joyda qo‘llang.

Zerikarli, yaxshi qo‘llab-quvvatlanadigan vositalarni tanlang

Auditorlar va korxonalarning xavfsizlik jamoalari o‘zlari taniydigan texnologiyalar bilan o‘zini qulayroq his qiladi, besh yildan keyin tizimni qo‘llab-quvvatlaydigan muhandislar ham shunday. Muvofiqlik talablari og‘ir mahsulot uchun zerikarlilik afzallikdir.

Har bir komponent uchun foydali tekshiruvlar:

• U keng qo‘llaniladimi, faol rivojlantiriladimi va xavfsizlik bo‘yicha ogohlantirishlar e’lon qiladimi?
• U sizga kerakli nazorat choralarini o‘zida qo‘llab-quvvatlaydimi: shifrlash, batafsil ruxsatlar, audit loglari, yagona kirish (single sign-on)?
• Uni biladigan odamlarni yollay olasizmi?
• Agar yetkazib beruvchisi bo‘lsa, u o‘zining muvofiqlik hisobotlarini e’lon qiladimi?

Keng tarqalgan relatsion ma’lumotlar bazasi, xavfsizlik tarixi uzoq bo‘lgan mashhur til va freymvork hamda yirik bulut provayderi bu tekshiruvlarning aksariyatidan o‘tadi. Qiziqarli ma’lumotlar modeliga ega yangi ma’lumotlar bazasi mahsulot uchun to‘g‘ri tanlov bo‘lishi mumkin, lekin bu vaziyatda unga qiziqishdan kuchliroq sabab kerak.

Komponentlar sonini kam tuting. Har bir qo‘shimcha servis hujjatlashtirilishi kerak bo‘lgan yana bir ma’lumotlar oqimi, baholanishi kerak bo‘lgan yana bir yetkazib beruvchi va shaxsiy ma’lumotlar sizib chiqishi mumkin bo‘lgan yana bir joy.

Loglash va dalillarni birinchi kundan quring

Auditning katta qismi dalil so‘rashdan iborat: o‘tgan chorakdagi kirish huquqlari ko‘rib chiqilganini, shu o‘zgarish tasdiqlanganini, anavi hodisadagi ogohlantirishni ko‘rsating. Dalillarni oddiy ish jarayonida o‘z-o‘zidan yig‘adigan jamoalar auditdan xotirjam o‘tadi. Ularni bir hafta oldin qo‘lda yig‘adigan jamoalar esa bunday o‘tmaydi.

Tizimni boshidanoq dalillar uchun loyihalang:

• Kod sifatidagi infratuzilma (infrastructure as code). Muhitdagi har bir o‘zgarish ko‘rib chiqilgan pull request orqali o‘tadi, shuning uchun tarixning o‘zi o‘zgarishlar jurnaliga aylanadi.
• Himoyalangan branchlar va majburiy ko‘rib chiqish. Repozitoriy hech qanday kod ikkinchi odam tasdiqlamasdan productionga yetib bormaganini ko‘rsatadi.
• Markaziy, faqat qo‘shiladigan loglar. Ilova, infratuzilma va kirish loglari yozish huquqi cheklangan va saqlash muddati belgilangan bitta joyga oqib boradi.
• Mahsulotdagi audit hodisalari. Xavfsizlik uchun muhim harakatlarni (tizimga kirishlar, ruxsatlar o‘zgarishi, eksportlar, o‘chirishlar) mahsulotning o‘zida mijozlarga ko‘rsatsa bo‘ladigan tuzilgan shaklda qayd eting.
• Xodimlar uchun yagona kirish. Har bir ichki vosita uchun bitta identifikator ishga olish, ishdan bo‘shatish va kirish huquqlarini ko‘rib chiqishni qidiruvga emas, bitta so‘rovga aylantiradi.

Iloji boricha shaxsiy ma’lumotlarni loglarga tushirmang. E-pochta manzillari va tokenlarga to‘la log ma’lumotlar bazangizning zaifroq himoyalangan va o‘z saqlash muammosiga ega ikkinchi nusxasiga aylanadi.

Stekni o‘zgartirsa bo‘ladigan holda saqlang

Qonunlar o‘zgaradi, mijozlar yangi talablar keltiradi, katta bitim esa siz hali xizmat ko‘rsatmaydigan mintaqa bilan kelishi mumkin. Stek bunga qayta yozishsiz moslasha olishi kerak.

Bir nechta odat yordam beradi:

• Mintaqa va tenantni kodga singdirilgan taxminlar emas, konfiguratsiya deb biling, shunda yangi o‘rnatish shunchaki yangi qiymatlar to‘plami bo‘ladi.
• Ilova bilan o‘zgarishi ehtimoli eng yuqori servislar, masalan, e-pochta, fayl ombori va identifikatsiya o‘rtasiga o‘z kodingizdan yupqa qatlam qo‘ying. Shunda yetkazib beruvchini almashtirish faqat bitta modulga ta’sir qiladi.
• Ma’lumotlarni erta tasniflang. Qaysi maydonlar shaxsiy, maxfiy yoki tartibga solinadigan ekanini bilsangiz, shifrlash, saqlash va joylashuv qoidalarini hamma narsaga emas, har bir maydonga alohida qo‘llay olasiz.
• Har bir muhim qarorni va uning ortidagi talabni yozib qo‘ying. Standart o‘zgarganda u qaysi qarorlarga ta’sir qilishini ko‘rasiz.

Hech kim so‘ramagan o‘zgarishlar uchun abstraksiyalar qurishdan saqlaning. Maqsad har qanday o‘zgarishni mumkin qilish emas, ehtimoliy o‘zgarishlarni arzon qilish.

Qayerdan boshlash kerak

Kelgusi bir-ikki yilda mijozlaringiz so‘raydigan standartlarni ro‘yxatga oling va ularning talablarini joylashuv, audit, kirish, shifrlash va saqlash sohalariga taqsimlang. Kerakli mintaqalarda standart holatda yirik provayderning boshqariladigan servislarini tanlang, to‘lov ma’lumotlarini tizimlaringizdan tashqarida saqlang va xavfsizlik nazorati o‘zida bo‘lgan keng tarqalgan vositalarni tanlang. Kod sifatidagi infratuzilma, ko‘rib chiqiladigan o‘zgarishlar, markaziy loglar va xodimlar uchun yagona kirishni birinchi relizdan keyin emas, undan oldin sozlang.

Buni erta to‘g‘ri qilish mahsulotni o‘z-o‘zidan muvofiq qilmaydi: siyosatlar, o‘qitish va jarayonlar baribir muhim. Lekin bu birinchi korporativ so‘rovnoma kelganda javoblar tizimda allaqachon mavjud bo‘lishini anglatadi.