VPC uzaq girişini qəbul etmək üçün rədd testləri lazımdır

Uzaq giriş üçün qəbul, işləyən səhifənin ekran görüntüsü deyil, gözlənilən nəticələr cədvəlidir. Hər qrup üçün nəyin uğurlu olmalı və nəyin uğursuz olmalı olduğunu yazın, sonra ikisini də nəzarət olunan pəncərədə ayrılmış test kimlikləri ilə işə salın. Rəddlər sərhədi sübut edən hissədir; uğurlu giriş yalnız tunelin mövcud olduğunu sübut edir. Bütün bunlar artıq seçilmiş VPN məhsulu ilə işləyir.

Testlər üçün ayrı hesablardan istifadə edin və onları elə adlandırın ki, heç kim test kimliyini real istisna ilə səhv salmasın.

Sərhədi gözlənilən nəticələr kimi yazın

Komponentlərdən deyil, rollardan başlayın: kim hansı xidmətə, haradan və hansı kimliklə ehtiyac duyur. Nümunəvi VPC götürün: bir qrup HTTPS üzərindən staging mühitinə ehtiyac duyur, digəri istehsal verilənlər bazasına, üçüncü və daha kiçik qrup isə şlüzün özünü idarə edir. Hər sətir gözlənilən icazə və gözlənilən rədd alır, o cümlədən işləməməli olan qonşu xidmət və qonşu hesab. Bu cədvəl qəbul meyarıdır və testləri keçirməyən insanlar onu nəzərdən keçirə bilər.

Verilənlər bazasına girişi şəbəkə yolundan ayrı sınaqdan keçirin. Əlçatan TCP portu təsdiqlənməmiş verilənlər bazası hesabını uğurlu etməməlidir və VPN üzvlüyü bulud IAM rolu yaratmamalı və ya inzibati API girişi verməməlidir. Bunlar üç müstəqil nəzarətdir və onlar müstəqil şəkildə uğursuz olur.

Marşrut icazə deyil

Marşrut yolu mümkün edir; icazə vermir. Marşrutu geri saxlamaq təyinat yerində tətbiq olunan məhdudiyyətin zəif əvəzidir, çünki müştəri həmişə öz marşrutunu əlavə edə bilər. Təhlükəsizlik qrupu, verilənlər bazası icazəsi və tətbiqin öz avtorizasiyası qərar verən nəzarətlər olaraq qalır. Test gözlənilmədən uğurlu olduqda, əvvəlcə müştərinin sahib olmasını istədiyiniz marşrut cədvəlinə deyil, təyinat yerinin siyasətinə baxın.

Bu da rədd testlərinin nə üçün server tərəfini hədəf aldığını izah edir: bu nəticələri müştərini redaktə etməklə dəyişmək mümkün deyil.

Nəzarət əslində hansı mənbəyi görür?

Nəzarətin qiymətləndirdiyi mənbə ünvanı şlüz arxitekturasından asılıdır. EC2-də yerləşən şlüz yönləndirilmiş hovuzu ötürə, öz ünvanına çevirə və ya NAT-dan sonra fərqli ünvan təqdim edə bilər; idarə olunan Client VPN subnetə qoşulur və öz modelinə uyğun işləyir. Təhlükəsizlik qrupları və şəbəkə ACL-ləri bu emaldan sonra gələn hər şeyi görür. Qaydanı yanlış mənbə fərziyyəsi ilə yoxlamaq, düzgün görünən və yanlış trafiki keçirən sərhəd qurmağın geniş yayılmış yoludur.

Hər nəticəni ən kiçik faydalı hadisə ilə əlaqələndirin: kimlik və sessiya, resurs, əməliyyat, vaxt və qərar. CloudTrail API çağırışı, VPC axın qeydi və VPN sessiya jurnalı fərqli suallara cavab verir və heç biri tək başına tətbiq auditi deyil.

Kimliyi ləğv edin və yenidən sınaqdan keçirin

Ləğvetməni də eyni cədvələ daxil edin. Test kimliyini silin, yeni sessiyanın rədd edildiyini təsdiqləyin, sonra mövcud sessiyalara necə baxıldığını ayrıca təsdiqləyin, çünki bunlar fərqli sahibləri olan fərqli davranışlardır. Şlüz yenidən başladıldıqdan və ya dəyişdirildikdən sonra nə baş verdiyini yoxlayın ki, əl ilə əlavə edilmiş istisna səssizcə yox olmasın və ya daha geniş qayıtmasın. Yalnız növbəti yerləşdirməyə qədər davam edən sərhəd sərhəd deyil.

Bunların heç biri yamaq, bərpa və ya etimad məlumatlarının həyat dövrü işini əvəz etmir. Bu, daha dar bir vədi ölçülə bilən edir: düzgün insanlar düzgün xidmətlərə çatır, yaxınlıqdakı marşrutlar, hesablar və idarəetmə səthləri isə icazədən kənarda qalır.

Cədvəli yerləşdirmə ilə birlikdə saxlayın və şlüz dəyişdikdə yenidən işə salın. Testlər ucuzdur; onların arxasındakı fərziyyələr isə deyil.