Ви додаєте одне вхідне правило для пулу клієнтів VPN, нічого не видаляєте, і сервіс досі доступний з інтернету. Нічого не зламано. У групи безпеки немає ні перевизначення, ні пріоритету, ні остаточної заборони, проти яких вузьке правило могло б перемогти. Кожна група, під'єднана до інстансу, додає свої дозволи до однієї об'єднаної множини, і широке правило, про яке ви забули, досі в цій множині. Зробити інстанс лише-VPN означає перевірити їх усі, а не додати одне краще звучне правило до однієї з них.

Опишіть сервіс, перш ніж писати правило

Почніть із точного призначення, протоколу й порту, а також мережевого інтерфейсу, на якому сервіс справді слухає. Інстанс із кількома інтерфейсами або кількома сервісами на одному порту потребує перевірки для кожного інтерфейсу, бо під'єднані групи можуть відрізнятися. Потім визначте яку адресу джерела цей інтерфейс справді отримує для користувача VPN, а не ту адресу, яку клієнт показує у своєму вікні підключення.

Ці дві адреси розходяться частіше, ніж люди очікують, щойно в гру вступають трансляція та маршрутизація.

Три моделі джерела, три різні правила

За приватного маршрутизованого доступу інстанс отримує пул клієнтів або корпоративний діапазон, залежно від того, як маршрутизується й транслюється шлях. За публічної кінцевої точки, досяжної через корпоративний вихід, інстанс натомість бачить корпоративну адресу NAT, і лише якщо це призначення справді використовує шлях VPN, оскільки розділене тунелювання може залишити його на домашньому з'єднанні. За керованої кінцевої точки Client VPN застосовується задокументована модель зв'язку й цільової мережі, а адреса клієнта береться з налаштованого CIDR клієнта.

Що не працює — це посилання на шлюз VPN як на джерело групи безпеки. Посилання на групи відповідають еластичним мережевим інтерфейсам усередині VPC або з'єднаної мережі, а шлюз, що пересилає пакети, не є одним із них.

Прочитайте об'єднання по всіх під'єднаних групах

Відкрийте інстанс, знайдіть його мережевий інтерфейс і перелічіть кожну під'єднану до нього групу безпеки. Для кожної перевірте кожне правило, що покриває ваш протокол і порт, зокрема широкі діапазони портів і обидві родини адрес. Правило IPv4 з 0.0.0.0/0 не звільняє вас від перевірки ::/0, а правило, що дозволяє весь трафік, повністю приховує питання порту. Лише після цієї інвентаризації ви можете сказати, який чинний дозвіл для сервісу.

Довідник правил AWS описує групи безпеки як такі, що лише дозволяють, і зазначає, що правила всіх під'єднаних груп агрегуються, і це весь механізм, що стоїть за цією невдачею.

Мережеві ACL — це окрема політика без стану з упорядкованими записами дозволу й заборони, і вони оцінюються на підмережі, а не на інстансі.

Не відповідайте стіною заборон

Додавання заборони NACL на всю підмережу, щоб імітувати звичний міжмережевий екран, — неправильний інструмент і ризикований. Записи NACL упорядковані й не мають стану, тому заборона, поставлена вище наявного дозволу, тихо ламає не пов'язаний трафік, зокрема зворотний шлях для сеансів, які ви намагалися зберегти. Виправте широкий дозвіл групи безпеки в тій групі, якій він належить, а потім залиште ACL у спокої, якщо він справді не є частиною проєкту.

Видалення публічної адреси з інстансу — сильніша гарантія, і це також архітектурна зміна з адміністративними та прикладними наслідками, а не галочка в списку дозволів.

Перевіряйте в новому сеансі й зберігайте шлях входу

Перш ніж скасувати будь-який наявний дозвіл, підтвердьте схвалений незалежний адміністративний шлях, бо правило, яке ви збираєтеся видалити, може бути тим, від якого залежить відновлення вашого сеансу. Потім перевірте нове дозволене з'єднання з VPN і нове заборонене з'єднання з авторизованого тестового шляху без VPN. Наявні відстежувані сеанси переживають зміни правил так, що старі відкриті оболонки стають непридатними як доказ приймання.

Нарешті, збережіть власну авторизацію застосунку. Трансльований корпоративний вихід може представляти сотні людей, а мережевий допуск ніколи не ідентифікував окремого користувача чи його пристрій.

Схожі статті