Прыняцце аддаленага доступу праз VPC патрабуе тэстаў адмовы

Прыёмка аддаленага доступу — гэта табліца чаканых вынікаў, а не здымак экрана працоўнай старонкі. Для кожнай групы запішыце, што павінна атрымацца і што павінна не атрымацца, а затым прагоньце абодва варыянты на спецыяльных тэставых ідэнтычнасцях у кантраляваным акне. Адмовы — гэта тая частка, якая даказвае мяжу; паспяховы ўваход даказвае толькі існаванне тунеля. Усё гэта працуе з ужо абраным прадуктам VPN.

Выкарыстоўвайце асобныя ўліковыя запісы для тэстаў і пазначайце іх так, каб ніхто не прыняў тэставую ідэнтычнасць за сапраўднае выключэнне.

Запішыце мяжу як чаканыя вынікі

Пачніце з роляў, а не з кампанентаў: каму патрэбна якая паслуга, адкуль і з якой ідэнтычнасцю. Вазьміце прыкладную VPC: адна група мае патрэбу ў тэставым асяроддзі праз HTTPS, другая — у прадукцыйнай базе даных, а трэцяя, меншая група, адмініструе сам шлюз. Кожны радок атрымлівае чаканы дазвол і чаканую адмову, уключаючы суседнюю паслугу і суседні ўліковы запіс, якія не павінны працаваць. Гэтая табліца — крытэр прыёмкі, і людзі, якія не праводзяць тэсты, могуць яе прагледзець.

Тэстуйце ўваход у базу даных асобна ад сеткавага шляху. Даступны порт TCP не павінен рабіць паспяховым непацверджаны ўліковы запіс базы даных, а членства ў VPN не павінна ствараць хмарную ролю IAM або даваць адміністрацыйны доступ да API. Гэта тры незалежныя кантролі, і яны адмаўляюць незалежна.

Маршрут — гэта не аўтарызацыя

Маршрут робіць шлях магчымым; ён не дае дазволу. Утрыманне маршруту — слабая замена абмежаванню, якое выконваецца на баку прызначэння, бо кліент заўсёды можа дадаць свой маршрут. Група бяспекі, грант базы даных і ўласная аўтарызацыя праграмы застаюцца кантролямі, якія вырашаюць. Калі тэст нечакана атрымліваецца, глядзіце спачатку на палітыку прызначэння, а не на табліцу маршрутызацыі, якую вы мелі намер даць кліенту.

Вось чаму тэсты адмовы накіраваны на бок сервера: гэтыя вынікі нельга змяніць рэдагаваннем кліента.

Якую крыніцу кантроль фактычна бачыць?

Адрас крыніцы, які ацэньвае кантроль, залежыць ад архітэктуры шлюза. Шлюз, размешчаны на EC2, можа перасылаць маршрутызаваны пул, пераўтвараць яго ў свой адрас або пасля NAT паказваць іншы адрас; кіраваны Client VPN звязваецца з падсеткай і дзейнічае па сваёй мадэлі. Групы бяспекі і сеткавыя ACL бачаць тое, што прыходзіць пасля гэтай апрацоўкі. Праверка правіла з няправільнай здагадкай пра крыніцу — звычайны спосаб пабудаваць мяжу, якая выглядае правільнай і прапускае няправільны трафік.

Супвяжыце кожны вынік з найменшай карыснай падзеяй: ідэнтычнасць і сеанс, рэсурс, аперацыя, час і рашэнне. Выклік API у CloudTrail, запіс патоку VPC і журнал сеансу VPN адказваюць на розныя пытанні, і ні адзін з іх сам па сабе не з'яўляецца аўдытам праграмы.

Адклічце ідэнтычнасць і праверце яе зноў

Уключыце адкліканне ў тую ж табліцу. Выдаліце тэставую ідэнтычнасць, пацвердзіце, што новы сеанс адхілены, а затым асобна пацвердзіце, як абыходзяцца з існуючымі сеансамі, бо гэта розныя паводзіны з рознымі ўладальнікамі. Праверце, што адбываецца пасля перазапуску або замены шлюза, каб дададзенае ўручную выключэнне не знікла моўчкі і не вярнулася шырэйшым. Мяжа, якая трымаецца толькі да наступнага разгортвання, — не мяжа.

Нішто з гэтага не замяняе працу па ўстараненні ўразлівасцей, аднаўленні або жыццёвым цыкле ўліковых даных. Гэта робіць вузкія абяцанні вымернымі: патрэбныя людзі дасягаюць патрэбных паслуг, а суседнія маршруты, уліковыя запісы і паверхні кіравання застаюцца па-за грантам.

Трымайце табліцу разам з разгортваннем і паўтарайце яе пры змене шлюза. Тэсты танныя; здагадкі за імі — не.