İki faktorlu autentifikasiya ilə virtual VPN şlüzü üçün qəbul yoxlamaları
Şlüzü mərhələ-mərhələ sübut edin: qeydiyyat, giriş, rədd, ləğv və bərpa — hər biri sınaqdan əvvəl yazılmış sənəd və keçid şərti ilə.
Satıcılar bu cihazı virtual və iki faktorlu qabiliyyətli kimi təsvir edir, lakin bu sözlərin heç biri alışı həll edən suallara cavab vermir. Hansı hipervisor obrazı dəstəklənir, hansı müştərilər qeydiyyatdan keçə bilər, ikinci faktorun həqiqətən nəyi sübut etdiyi və kimlik provayderi sıradan çıxanda nə baş verdiyi hələ açıqdır. Bunları məşq zamanı işlədə biləcəyiniz qəbul mərhələlərinə çevirin, qərar isə məlumat vərəqinin nə qədər inandırıcı olmasından asılı olmaqdan çıxsın. Aşağıdakı vərəq həmin sübutlar üçün bir quruluşdur, məhsul reytinqi deyil.
Təchizatçının bu yerləşdirmə ilə bağlı təsdiqləməli olduğu şeylər
Yerləşdirməni bir səhifəyə sıxışdırmaqla başlayın: hipervisor və ya bulud, qonaq arxitekturası, dəstəklənən obraz və cihazın gözlədiyi interfeyslər. İstifadəçiləri də əlavə edin: əməliyyat sistemləri, cihazların idarə olunub-olunmadığı və qeydiyyatla girişin necə işləməli olduğu. Sonra xüsusi giriş: tətbiqlər və prefikslər, DNS tənzimi, qayıdış yolları və ümumi internet çıxışının təklifin hissəsi olub-olmadığı.
Əməliyyatlar da eyni səhifəyə aiddir: qutunu kim saxlayır, yeniləmələr hardan gəlir, qeydlər hara gedir, konfiqurasiya necə qorunur və biznesin həqiqətən razılaşdığı bərpa hədəfi nədir. Təchizatçıdan proqramın virtual maşında işləməsini deyil, məhz bu birləşməni təsdiqləməsini istəyin. Kimlik provayderi və ya lisenziya xidməti kimi xarici asılılıqları görünən saxlayın, çünki onlar cihazla birlikdə göndərilsə də, göndərilməsə də yerləşdirmənin hissəsidir. Adı çəkilmiş asılılığı olmayan yerləşdirmə səhifəsi adətən naməlum asılılığı olan yerləşdirmə səhifəsidir.
İkinci faktorun həqiqətən ikinci faktor olduğunu sübut edin
Autentifikatoru və yoxlama axınını adlandırın, hər addımın hansı şəxsiyyəti təsdiqlədiyini deyin. Ard-arda iki parol tələbi ikinci faktor deyil, parol üstəgəl birdəfəlik kod isə xidmətə bağlanmış kriptoqrafik autentifikatordan fərqli bir iddiadır. Qutunun üzərindəki etiketi deyil, aldığınız axını yazın.
Fişinqə davamlılıq ayrı bir xüsusiyyətdir və NIST autentifikator təlimatı bunu belə qəbul edir: istifadəçinin ötürməyə aldadıla biləcəyi kod çoxfaktorlu autentifikasiyanı ödəyir, lakin həmin əlavə şərti yerinə yetirmir. Əgər sizin üçün vacibdirsə, xüsusiyyəti açıq şəkildə tələb edin. Sonra istifadəçilərinizin həqiqətən işlətdiyi müştəri növündən nümayiş tələb edin: qeydiyyat, rədd edilmiş və ya vaxtı keçmiş çağırış, itirilmiş autentifikatordan sonra bərpa və digərləri qoşulmuş qalarkən bir istifadəçinin ləğvi. Şlüzün şəxsiyyət yoxlamasını əhatədə saxlayın, çünki hər şlüzə güvənən müştəri problemi həll etmək əvəzinə yerini dəyişmiş olur.
Heç nəyi sındırmazdan əvvəl keçid şərtini yazın
Aşağıdakı cədvəl vərəqin təchizatçı ilə təmasdan sonra qalan hissəsidir, çünki hər sətir zəmanət əvəzinə sənəd tələb edir. Keçid şərtini məşqdan əvvəl doldurun və sübutsuz sətri uğursuz sətir sayın. Beş mərhələ şlüzün nə etməli olduğunu əhatə edir.
| Acceptance stage | Evidence to keep | Pass condition |
|---|---|---|
| Enrolment | Enrolment record with the device type and the identity used | A new device enrols once, and nobody else can enrol it afterwards |
| Sign-in with the second factor | Session record naming both factors and the gateway identity that was checked | The session carries the expected identity and the gateway certificate validated |
| Denial of an unapproved destination | Log line from the control that refused the flow, with the policy name | The flow is refused and the refusal is attributable to one control |
| Revocation of one user | Revocation timestamp and the sessions that survived it | The named user is out and unaffected users keep working |
| Restore from configuration backup | Restored version plus a probe of a revoked identity | The revision matches the backup and revoked identities stay revoked |
Qeydiyyat birinci gəlir, çünki sonrakı hər şey ondan asılıdır: qeydiyyatdan keçə bilməyən cihaz sınaqdan keçirilə bilməz. Giriş qeydiyyatdan ayrı mərhələdir, rədd isə vərəqlərin çoxunun unutduğu mərhələdir, çünki hamını qəbul edən şlüzün kimisə rədd etdiyi sübut olunmayıb. Ləğv və bərpa əməliyyat riskinin çoxunu daşıyır və hər ikisini nüsxədə məşq etmək ucuzdur.
Canlı şlüzdə deyil, nüsxədə məşq edin
Dağıdıcı mərhələləri platformanın nüsxəsində, dəstəklənən yerləşdirmə proseduruna əməl edərək işlədin və hər sübutu tarixi və konfiqurasiya versiyası ilə saxlayın. Yenidən başlatma sətri konsoldan yenidən başlatma ilə cavablandırılmır, bərpa sətri isə konfiqurasiyanın eksportu ilə cavablandırılmır. Hansı vəziyyətin öz-özünə qayıtdığını və nəyin yenidən qoşulmalı olduğunu qeyd edin, çünki əməliyyat komandasının miras aldığı fərq elə budur. Məşq həm də bərpanı fasilə izah etmədən ölçmək üçün yeganə şansdır.
Hər sınaq anında kimlik provayderinin vəziyyətini qeyd edin, çünki sağlam provayderə qarşı sınanmış fasilə sətri vərəqin iddia etdiyinin əksini sübut edir. Eyni məşqda iki rəyçi fərqli şeylər tutur, ikincisi adətən sübutu idarə panelinin ekran şəkli olan sətri tapır. Həmin sübutu layihənin adını daşıyan qovluqda deyil, aid olduğu sətrin yanında saxlayın.
Komandanızın işlədəcəyi yükü ölçün
Normal həftəyə bənzəyən bir yük üzərində razılaşın, sonra onu yerləşdirməyi planlaşdırdığınız yerdə ölçün: eyni vaxtlılıq, trafik qarışığı və komandanın həqiqətən malik olduğu texniki xidmət pəncərəsi. Elan olunmuş ötürmə qabiliyyəti rəqəmi laboratoriya şərtini təsvir edir və istifadəçiləriniz haqqında heç nə demir. Bərpanı plana görə deyil, bərpa hədəfinə görə ölçün.
Vərəq hər mərhələnin sənədi və hər sənədin tarixi olduqda bitmiş sayılır. Kiminsə saxladığı cihaz, hər sətir üçün sübutla, ən uzun işarələnmiş qutular siyahısından fərqli bir alışdır.