Ortaq subdomenlər, iki giriş: hansı qeydləri kim görür?

Klinika A və Klinika B bir kod bazasını, iki subdomeni və ofis ilə VPN ziyarətçilərinin qarışığını paylaşır. Şəbəkə komandaları adətən iki girişi ayrıca qurur və bu normaldır, tətbiq bunu etmədiyi müddətcə. Aşağıdakı yoxlamalar tətbiqin içində olmalı və sorğunun hansı qapıdan gəldiyindən asılı olmayaraq eyni cür davranmalıdır.

Birinci: host adı yalnız kirayəçini adlandırır

Sorğu olunan host adını administratorun saxladığı xəritə ilə həll edin və bilinməyən hər şeyi rədd edin. Xam başlıq yerinə freymvorkun təsdiqlənmiş host dəyərindən istifadə edin ki, hazırlanmış Host axtarış açarını yeritməsin. Uğurlu uyğunluq koda hansı kirayəçi konfiqurasiyasının və brendinqin yüklənəcəyini deyir. Amma çağıranın həmin kirayəçinin məlumatlarını görə biləcəyi barədə heç nə demir. Bu ikinci sualı ayrı girişli ayrı funksiyada saxlayın.

Bir host adı axtarışından həm konteksti, həm də icazəni qaytaran ortaq köməkçi funksiya xətanın başlanğıcıdır.

İkinci: üzvlük sessiyadan gəlir

Təsdiqlənmiş istifadəçinin aktiv üzvlüklərini tapın və onları birinci yoxlamadan çıxan kirayəçi ilə müqayisə edin. Hər iki klinikaya aid olan istifadəçi keçid edə bilər, lakin bu keçid URL-dən çıxarılan nəticə deyil, sorğu kontekstində qeyd olunan açıq hərəkət olmalıdır. Bir klinikaya aid olub digərini sorğulayan istifadəçi rədd edilir, yükləmələr və API çağırışları da daxil olmaqla.

Mənfi halı qeyd identifikatorunu və kirayəçi parametrini dəyişməklə yoxlayın. Dəyişikliklərdən hər hansı biri məlumat qaytarırsa, əhatə dairəsi təsdiqlənmiş üzvlükdən deyil, sorğudan oxunur.

Kuki əhatəsi və tək giriş hesabın harada təqdim oluna biləcəyini müəyyən edir. Hesabın nəyi oxuya biləcəyini isə müəyyən etmir.

Üçüncü: şəbəkə şəxs haqqında heç nə sübut etmir

VPN şlüzü tuneli, açıq icazə siyahısı isə ünvan diapazonunu təsdiqləyir. Heç biri şəxsi identifikasiya etmir. NAT çox sayda istifadəçini bir mənbə ünvanında birləşdirir, ofis diapazonu da binadakı hər kəs üçün eynisini edir. Hər ikisini nəql faktı kimi qəbul edin və avtorizasiyanı tətbiqdə saxlayın, ya da kimliyi açıq şəkildə təsdiqləyən və buna uyğun nəzərdən keçirilən inteqrasiyada.

DNS üçüncü nəql faktıdır. Şəxsi cavab şəxsi marşrut tələb edir, açıq ön tərəf isə dəstəklənən mənşə yolu tələb edir. Onların heç biri icazə daşımır.

Divardan asılacaq bir cümlə: şəbəkə sorğunun necə gəldiyini, tətbiq isə nəyi oxuya biləcəyini qərar verir.

Dördüncü: matrisi iki girişdə də işə salın

Nəzarət olunan hesablarla A-nı A-da, B-ni B-də, A-nı B-də, bilinməyən host adını və üzvlüyü olmayan təsdiqlənmiş hesabı yoxlayın. Dördüncü və beşinci bağlı şəkildə uğursuz olmalı, heç vaxt defolt kirayəçiyə qayıtmamalıdır. Eyni matrisi VPN girişindən də işə salın, hər hesab üçün bir sessiya qabı ilə:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

Sonra icazə siyahısında bir girişi dəyişin və yenidən işə salın. Dəyişən nəticə şəbəkə nəzarətinin avtorizasiya qərarı verdiyini bildirir.

Ön tərəfdə hər hansı dəyişiklikdən sonra matrisi təkrarlayın, çünki yoxlamanı atlayan ikinci kod yolu bu sərhədin aşınmasının ən geniş yayılmış yoludur. Gözlənilən nəticə darıxdırıcıdır: hər giriş eyni cavabları verir.