Integratsiya kalitlari va sirlarni saqlash: kalit qayerda turishi kerak

GitHub ochiq omborlarni doimiy tekshirib turadi. Kod ichidan parol, kalit yoki token topilsa, xizmat egasiga xabar beriladi va u kalitni bekor qilishi mumkin. Bunday avtomatik qidiruv tizimi yaratilgani oʻzi koʻp narsani aytadi: kalitni kodga yozib qoʻyish juda tez-tez uchraydigan xato. Savol esa har bir integratsiyada paydo boʻladi: dastur boshqa tizimga kirishi uchun zarur kalit qayerda turishi kerak?

Sir nima va nega u oddiy parol emas

Integratsiya kaliti dastur uchun beriladigan paroldir. Masalan, onlayn doʻkon buyurtmani ombor tizimiga uzatishi uchun shunday kalit kerak. Odam parolni qoʻlda kiritadi va yozib olmasa ham eslab qoladi, dastur esa kalitni har safar oʻzi yuboradi va uni hech kim koʻrmaydi, shu sababli kalit juda tez unutiladi.

OWASP veb-ilovalar xavfsizligi bilan shugʻullanadigan ochiq tashkilot, u bunday maʼlumotlarni umumiy nom bilan sirlar deb ataydi. Ularga API kalitlari, maʼlumotlar bazasi paroli, serverga ulanish kalitlari va sertifikatlar kiradi. Xavf hammasida bir xil: sirni qoʻlga kiritgan kishini tizim shu dasturning oʻzi deb hisoblaydi va hech narsa soʻramaydi.

Yana bir noqulaylik bor, u ham tahririyat mulohazasi. Kalit bilan kirgan odam jurnalda dastur nomi bilan koʻrinadi, shu sababli hodisadan keyin kim aslida kirganini aniqlash qiyinlashadi va kalit sizib chiqqanini bilish ancha kechikadi.

Kodda va jadvalda saqlash nega xavfli

OWASP qoʻllanmasi muammoni toʻgʻridan-toʻgʻri aytadi: koʻp tashkilotlarda sirlar dastur matni ichiga ochiq yozib qoʻyilgan. Kod esa bir joyda turmaydi, u dasturchilarning kompyuterlariga koʻchiriladi, pudratchiga yuboriladi va barcha oʻzgarishlar tarixi bilan birga saqlanadi.

GitHub hujjati kodning butun tarixini va barcha shoxlarini tekshirishini yozadi. Demak, kalitni keyin koddan oʻchirish yetarli emas, chunki u eski versiyada qolaveradi va tarixni ochgan odam uni baribir topadi. Oʻchirish kalitni yashirmaydi, faqat eng yangi nusxadan olib tashlaydi.

Gipotetik misol. Kichik kompaniya toʻlov xizmatiga ulanish kalitini dasturchiga yozdiradi va kalit dastur matnida turadi. Dasturchi ishdan ketadi, uning kompyuterida esa butun nusxa qoladi, kompaniya bu haqda oylar oʻtib ham bilmaydi, chunki kalit hech qayerda hisobga olinmagan va hech kim uni almashtirishni oʻylamagan.

Zaifliklarning xalqaro roʻyxati CWE bu holatni alohida raqam bilan yuritadi va ikki holatni ajratadi: dastur kirishni kodga yozilgan parol bilan tekshiradi yoki dastur boshqa tizimga kodga yozilgan parol bilan ulanadi. Integratsiya kaliti ikkinchi holatga kiradi. Qarshi chora sifatida CWE sirni kod tashqarisida, shifrlangan va cheklangan huquqli joyda saqlashni, kalitlarni esa vaqt bilan cheklash va muntazam almashtirishni tavsiya qiladi.

Jadval haqida alohida gap: manbalarda jadvalga kalit yozish alohida koʻrilmagan, shu sabab bu tahririyat fikri. Jadvalni koʻra oladigan har bir odam kalitni ham koʻra oladi, nusxa olgan hamkasb, yuklab olingan fayl va yuborilgan xat esa kalitni birga olib ketadi. Jadvalga kirish huquqi shu jadvaldagi kalitga kirish huquqiga aylanadi, kalit esa jadval kimlarga ulashilganini bilmaydi.

Parol oʻrniga token: OAuth gʻoyasi

Kalit muammosining mashhur yechimi bor: dasturga parol emas, cheklangan ruxsatnoma beriladi. Bu gʻoya OAuth 2.0 standartida yozilgan va uni IETF 2012 yil oktyabrda eʼlon qilgan. Standart toʻrtta ishtirokchini ajratadi: resurs egasi, resursni saqlovchi server, mijoz dastur va ruxsat beruvchi server.

Oddiy tilda misol keltiramiz. Siz hisob-kitob dasturiga bank maʼlumotlarini koʻrishga ruxsat berasiz, lekin parolni dasturga bermaysiz: uni bankning ruxsat beruvchi serveri tekshiradi. Dastur esa token oladi va faqat ruxsat etilgan narsani koʻra oladi. Standartda aynan shunday yozilgan: dastur foydalanuvchining parolini koʻrmaydi, uning oʻrniga ruxsatnoma oladi.

Tokenning uchta xususiyati amalda muhim. Birinchisi ruxsat doirasi, chunki server soʻralganidan kamini ham berishi mumkin. Ikkinchisi muddat: token umri serverda belgilanadi va javobda koʻrsatiladi. Uchinchisi yangilash tokeni, uni berish ixtiyoriy va u faqat yangi token olish uchun ishlatiladi, maʼlumotli serverga esa yuborilmaydi.

Bundan amaliy xulosa chiqadi, bu tahririyat mulohazasi. Token oʻgʻirlansa, zarar doira va muddat bilan cheklangan boʻladi va ruxsatnomani bekor qilish mumkin, odamning parolini integratsiyaga berib qoʻysangiz, bu chegaralarni yoʻqotasiz. Hamma xizmat OAuth ni qoʻllamaydi, oddiy API kalit beradigan xizmatlar uchun esa quyidagi qoidalar kuchida qoladi.

Sirlar bir joyda, huquq esa tor boʻlishi kerak

OWASP birinchi navbatda sirlarni boshqarishning bitta izchil usulini talab qiladi. Sabab amaliy: usullar qancha koʻp boʻlsa, hodisa paytida shuncha koʻp hujjatni qayta oʻqish kerak boʻladi. Ikkinchi talab bor: har bir sirni kim oʻqishi va yangilashi mumkinligi alohida cheklanadi, yaʼni muhandisning hamma sirga kirishi shart emas. Uchinchisi shu: sirdan kim va qachon foydalangani jurnalga yoziladi.

Qoʻllanma qisqa muddatli sirlarni afzal koʻradi, chunki ilovani qayta ishga tushirish oʻgʻirlangan kalitni bekor qilmaydi va muddati tugaydigan kalit ishonchliroq. Yana bir qoida: shifrlash kaliti shifrlangan sirning yonida turmasligi kerak, aks holda shifrlashdan foyda qolmaydi.

Gipotetik hisob-kitob. Kompaniyada uchta integratsiya bor: sayt, toʻlov xizmati va yetkazib berish xizmati. Agar uchalasi bitta kalit bilan ishlasa, bitta sizib chiqish uchala ulanishni bir vaqtda toʻxtatishni talab qiladi. Har biriga alohida kalit berilsa, faqat shu ulanish almashtiriladi va qolgan ikkitasi ishlashda davom etadi.

No-code platformalarda ham xuddi shunday. n8n avtomatlashtirish platformasi ulanish maʼlumotlarini bazaga shifrlab saqlaydi, shifrlash kaliti esa birinchi ishga tushirishda yaratiladi va platforma sozlamalari papkasida turadi, xohlasangiz oʻz kalitingizni ham berishingiz mumkin. Baza ham shu serverda tursa, serverga kirgan odam ikkalasini ham olishi mumkin, OWASP esa kalitni shifrlangan sirning yonida saqlamaslikni tavsiya qiladi.

Shu sababli n8n sirlarni tashqi omborda saqlash imkonini beradi. Qoʻllab-quvvatlanadigan xizmatlar orasida HashiCorp Vault, AWS, Azure va Google Cloud sirlar omborlari bor. Ulanish maydoniga sirning oʻzi emas, ombordagi nomga havola yoziladi, hujjatga koʻra bu imkoniyat tashkilotlar uchun moʻljallangan alohida nashrda beriladi.

Kalit ish jarayonining qayerlarida yashirinib qoladi

Kalit faqat kod va jadvalda emas, dastur ishga tushadigan va yangilanadigan joylarda ham qolib ketadi. OWASP avtomatik yigʻish va joylashtirish tizimini ishlab chiqarish muhiti kabi himoyalashni tavsiya qiladi. Kalitlar bu yerda ham eng kam kerakli huquq bilan beriladi, keng imkoniyatli bitta katta kalit oʻrniga esa bir nechta kichik kalit ishlatiladi.

Yana ikki joyga eʼtibor kerak. Dasturga sozlama sifatida berilgan kalit xato hisobotlarida yoki dastur holatining nusxasida paydo boʻlishi mumkin, shuning uchun qoʻllanma kalitni fayl yoki ishga tushish paytida olinadigan manba orqali berishni afzal koʻradi. Kalit tarmoq orqali ochiq matn koʻrinishida yuborilmaydi, buning uchun shifrlangan ulanish ishlatiladi.

Almashtirish va muddat

OWASP sirlarni muntazam almashtirishni tavsiya qiladi, maqsad esa oʻgʻirlangan kalit faqat qisqa vaqt ishlashi. Imkon boʻlsa, almashtirish avtomatlashtiriladi, sirga amal qilish muddati ham qoʻyiladi, ilova esa uning hali kuchda ekanini tekshiradi.

Bu yerda oddiy mulohaza bor, u tahririyatniki. Kalitni almashtirish uchun kodni oʻzgartirib, qaytadan joylashtirish kerak boʻlsa, bu ish yillar davomida qoldiriladi, kalit tashqarida turganda esa almashtirish bir joyda va bir necha daqiqada bajariladi. Almashtirish oson boʻlsa, uni hamma qiladi.

Almashtirish tartibi ham muhim, bu ham tahririyat fikri. Avval yangi kalit yaratiladi va dasturga beriladi, dastur yangi kalit bilan ishlayotganiga ishonch hosil qilinadi, shundan keyingina eskisi oʻchiriladi. Aks holda integratsiya almashtirish paytida toʻxtab qoladi va odamlar keyingi safar kalitni almashtirmaslik uchun bahona topadi.

Kalit sizib chiqsa: ketma-ket qadamlar

Sizib chiqish holati uchun OWASP aniq tartib beradi:

1. Sirni darhol bekor qiling.
2. Uni avtomatik jarayon orqali yangisiga almashtiring.
3. Eskisini ochiq qolgan joylardan, yaʼni koddan va jurnallardan olib tashlang.
4. Kim sirga qachon kirganini yozib qoʻying.

GitHub hujjati ham shu tartibni takrorlaydi: avval kalitni almashtiring. Sirni kod tarixidan tozalash uzoq vaqt oladi va kalit allaqachon bekor qilingan boʻlsa, koʻpincha shart emas. Yaʼni sizib chiqqan kalit uchun tozalash emas, bekor qilish birinchi oʻrinda turadi.

Gipotetik holat. Hamkasb umumiy jadvaldan eski integratsiya kalitini topdi va uni rahbarga yubordi. Bu yerda ikki yoʻl bor: jadvaldan kalitni jimgina oʻchirish yoki kalitni almashtirib, kim jadvalni koʻrganini aniqlash. Birinchi yoʻl tinch koʻrinadi, lekin kalit allaqachon kimdadir qolgan boʻlishi mumkin, shu sabab ikkinchi yoʻl toʻgʻri.

Amalda nima qilish mumkin

Quyidagi qadamlar manbalardagi mantiqdan chiqarilgan tahririyat xulosasi, tayyor protokol emas.

1. Barcha kalit va parollarning roʻyxatini tuzing: qaysi dastur, qaysi tizim, kim egasi, qachon berilgan.
2. Kodda, jadvalda, xabarlar tarixida va hujjatlarda yotgan kalitlarni toping va almashtiring: eski nusxa qayerdadir qolgan boʻlishi mumkin.
3. Har bir integratsiyaga alohida kalit bering va uning huquqini ishiga qarab cheklang.
4. Kalitlarni bitta tashqi joyda saqlang, unga kirishni kam odamga bering va kim oʻqiganini yozib boring.
5. Almashtirish sanasini belgilang. Kalit sizib chiqsa kim bekor qilishini va kim almashtirishini oldindan yozib qoʻying.

Kichik kompaniyada maxsus ombor boʻlmasligi mumkin va bu mutlaqo normal. U holda ham ikki talab qoladi: kalit kod va jadvaldan tashqarida turishi kerak va kim qachon almashtirishini bilish kerak. Murakkab vositalarni keyin ulash mumkin, tartib esa kalit berilgan kundanoq kerak.