Hamkorning VPN orqali HSM ga kirishi: kalit operatsiyalarini belgilang

Hamkor tomonida kimdir bitta belgilangan kalit bilan hujjatga imzo chekishi kerak, va so'rov tarmoq masalasi sifatida keladi: ular HSM ga yetib borishi kerak. Bu gapni marshrutlash muammosi emas, balki aniqlanmagan xizmat shartnomasining belgisi deb qabul qiling, chunki qurilmaga yetib boradigan tunnel o'z-o'zidan hech narsa bermaydi. So'rov orqasida uchta darvoza bor: yetib borish, HSM identifikatori va kalit siyosati, va har birini boshqa joyda boshqa jamoa boshqaradi. Ularni birma-bir yozib chiqing, aks holda sertifikat haqidagi suhbat qiyinroq bo'lgani uchun marshrut berib qo'yasiz.

Aniq vaziyatni ko'z oldingizda tuting: hamkor imzo uchun tasdiqlangan hujjatni bitta nomlangan kalit bilan topshiradi, boshqa hech narsa bilan emas. Quyidagi barchasi shu bitta gapdan kelib chiqadi.

Yetib borish, identifikator va kalit siyosati uchta darvoza

VPN konsentratori kim tunnel ochishi va qaysi manzillarga tegishi mumkinligini hal qiladi. HSM unga taqdim etilgan qaysi foydalanuvchi yozuvi kira olishini o'zi hal qiladi. So'ngra kalit siyosati bu foydalanuvchi yozuvi bitta aniq kalit bilan nima qila olishini hal qiladi. Birinchi darvozadan o'tish qolgan ikkitasini aynan qanday bo'lsa shunday qoldiradi, shuning uchun muvaffaqiyatli qo'l berish juda kam narsani isbotlaydi va shuning uchun hamkor qurilmaga yetib borib ham har bir operatsiyada muvaffaqiyatsizlikka uchrashi mumkin.

Talablarni yozishdan oldin har bir darvozaga egasini tayinlang. Ikkinchisining egasi bo'lmasa, odatiy natija keng HSM administratori identifikatorining berilishi bo'ladi, chunki ishlaydigan yagona hisob ma'lumoti shu.

Birinchi darvoza: hamkorga beriladigan tarmoq yo'li

Tasdiqlangan mijoz yoki xizmatni, unga kerak bo'lgan manzilni, va bu xizmat tinglaydigan protokol va portni ayting. So'ngra VPN tomondan kirishni shu juftlikka ikki yo'nalishda cheklang, qaytish yo'lini ham qo'shib, shunda siyosat hamkorga o'qib berish mumkin bo'lgan gapga aylanadi. Shlyuz boshqaruvi, HSM boshqaruv interfeyslari va aloqasi bo'lmagan ichki tizimlar oddiy hamkor kirishidan tashqarida turishi kerak, faqat standart marshrutdan tashqarida emas.

Ajratilgan segment bu o'tishlarni ko'rinadigan qiladi, lekin segment nomi hech narsani majburlamaydi. Trafik siz o'ylagan nazorat orqali o'tishi kerak. Hamkordan ulanishni qabul qilish ham hamkordagi har bir mashina ishonchli degan bayonot emas.

Ikkinchi darvoza: HSM oldida aslida nima autentifikatsiya qilinadi

VPN identifikatori va HSM identifikatori qo'llab-quvvatlanadigan integratsiya ularni ataylab birlashtirmasa, alohida obyektlardir. PKCS#11 mijozi bilan ilova hamkor xostining biror joyida saqlangan hisob ma'lumoti bilan slotga kiradi, va HSM aynan shu kirishni baholaydi.

AWS CloudHSM foydali namuna, chunki uning hujjatlari ikkalasini alohida tutadi: HSM foydalanuvchilari IAM foydalanuvchilaridan farq qiladi, va foydalanuvchi turi hisob nima qila olishini belgilaydi. Kripto ofitseri foydalanuvchilar va kalitlarni boshqaradi, lekin kriptografik operatsiyalarni bajaradigan identifikator u emas, kripto foydalanuvchisi esa kalitlarni boshqara olmasa ham ulardan foydalana oladi. Bu bo'linish boshqa yetkazib beruvchining qurilmasida ham siz xohlagan shakldir, u yerda rollar nomlari boshqacha bo'ladi.

Qanday identifikator bersangiz ham, u keyinchalik kerak bo'ladigan tafsilot darajasida olib tashlanadigan va bog'lanadigan bo'lishi kerak. Bir necha hamkor bo'ylab bitta umumiy operatsion hisob ma'lumoti ikkalasi ham eng muhim bo'lgan hodisada cheklash va javobgarlikni qiyinlashtiradi.

Uchinchi darvoza: qaysi kalit va qaysi operatsiya

Imzolash, shifrni ochish, kalit yaratish, kalitni o'rash va foydalanuvchilar boshqaruvi alohida ruxsatlardir va ularni alohida sanab o'tish kerak. PKCS#11 atamalarida CKA_SENSITIVE va CKA_EXTRACTABLE kabi atributlar kalit materiali moduldan foydalanish mumkin bo'lgan shaklda chiqa olishini tasvirlaydi, va ular qurilmaga emas, har bir kalitga o'rnatiladi. Hardware so'zidan yoki tunnel borligidan eksport qilinmasligini taxmin qilish o'rniga kalitdagi haqiqiy siyosatni o'qing.

So'ngra biznes tasdiqini toping. Agar faqat tasdiqlangan hujjatlarga imzo chekish mumkin bo'lsa, so'rov HSM ga yetib borishidan oldin qaysi komponent bu tasdiqni o'rnatadi? Ruxsat etilgan so'rovni qabul qiladigan kriptografik interfeys hujjat ko'rib chiqilganini bilmaydi, shuning uchun bu tekshiruv uning oldidagi xizmatga tegishli.

Ruxsat etilgan mijoz buzib kirilgan bo'lsa, u shaxsiy kalitni hech qachon chiqarmasdan ham hisob ma'lumoti qonuniy ruxsat bergan operatsiyalardan suiiste'mol qilishi mumkin. Shuning uchun saqlangan kalit materialini himoya qilish va kalitdan foydalanishni nazorat qilish ikki qabul sharti, bitta emas.

Rad etishlar qabul sinovining bir qismidir

Ruxsat etilgan imzo so'rovini qabul qiling, va rad etishlarni ham qabul qiling: ruxsat etilmagan identifikator, aloqasi bo'lmagan kalit va hamkor yo'lidan kelgan boshqaruv operatsiyasi. Qo'ng'iroq qiluvchini, operatsiyani, kalit identifikatorini, vaqtni va natijani yozib oling, shaxsiy kalit materiali, hisob ma'lumotlari va hujjat mazmunini umumiy diagnostika jurnallaridan tashqarida saqlang.

Hamkorning chiqishi, hamkor tomonida gumon qilingan buzilish, va siyosat o'zgarishlari hamda tiklanish uchun egasini tayinlang. Marshrutni o'zgartirish allaqachon buzilgan bo'lishi mumkin bo'lgan xostga ishonchni tiklamaydi, shuning uchun bekor qilish HSM identifikatoriga ham yetib borishi kerak.

Tugallangan VPN qo'l berish o'sha yozuvga tegishli. U HSM ga xos bitta natijaning o'rnini bosa olmaydi.