Аўтэнтыфікацыя AWS Client VPN: дазволы IAM не з’яўляюцца спосабам уваходу
Дазволы кансолі не аўтэнтыфікуюць тунель. Параўнайце метады сертыфіката, AD і SAML, а затым паглядзіце, калі перанакіраванне порта праз SSM падыходзіць для адной прыватнай базы даных.
Калі даць карыстальніку дазвол ствараць канцавы пункт AWS Client VPN або апісваць яго, гэта не дазволіць яму падключыцца да яго. Гэта два розныя віды ідэнтычнасці: IAM кіруе выклікамі AWS API, а канцавы пункт прымае толькі тыя метады аўтэнтыфікацыі кліента, якія на ім наладжаны. Таму карыстальнік можа мець шырокія правы ў кансолі і пры гэтым не мець нічога, што можа прадставіць кліент VPN. Вызначце, якому метаду давярае канцавы пункт, а затым вырашыце, ці поўны тунель — правільная форма для доступу, які вы даяце.
Ідэнтычнасць API — гэта не ідэнтычнасць тунеля
Калі хтосьці кажа «роля IAM далучана, дык чаму VPN усё яшчэ не працуе», адказ звычайна такі: ні адзін крок у патоку злучэння не чытае гэтую ролю. Кліент прадстаўляе сертыфікат, імя і пароль AD або сцвярджэнне SAML. Канцавы пункт правярае адно з гэтага, а затым прызначае адрас.
IAM па-ранейшаму важны, проста пазней і ў іншым месцы: стварэнне канцавога пункта, далучэнне падсетак, публікацыя маршрутаў і напісанне правілаў аўтарызацыі — гэта дзеянні API. Трымайце гэтыя дазволы ў межах тых аператараў, якім яны патрэбны, замест таго каб даваць кожнаму карыстальніку магчымасць перапісваць правілы доступу канцавога пункта.
Выбірайце з метадаў, якія падтрымлівае канцавы пункт
AWS Client VPN прымае ўзаемную аўтэнтыфікацыю на аснове сертыфіката, аўтэнтыфікацыю Active Directory і федэратыўную аўтэнтыфікацыю на аснове SAML. Сертыфікат сервера патрабуецца незалежна ад таго, які метад кліента вы абярэце, а канфігурацыя, якая спалучае метады, патрабуе поспеху абодвух, а не аднаго.
| Client method | What the user presents | Where the work sits |
|---|---|---|
| Mutual certificate | A client certificate the endpoint trusts | Certificate authority, issuing and revoking per user |
| Active Directory | Domain credentials | Directory reachable from the endpoint's VPC |
| SAML federation | An assertion from an identity provider | IdP application, attribute mapping, client support |
Сертыфікаты — самыя танныя ў разгортванні і самыя схільныя да памылак у маштабе, бо кожнаму карыстальніку патрэбныя ўліковыя даныя, а кожны сыход патрабуе адклікання. Аўтэнтыфікацыя праз каталог пераносіць гэты жыццёвы цыкл у існуючую сістэму. Федэрацыя пераносіць яго ў пастаўшчыка ідэнтычнасці і дадае крок у браўзары да кліента.
Прачытайце ўласную канфігурацыю канцавога пункта, перш чым адладжваць кліент. Калі ўзаемная аўтэнтыфікацыя ўключана разам з метадам на аснове карыстальніка, кліент з сапраўдным сертыфікатам, але без уліковага запісу ў каталозе, усё роўна пацерпіць няўдачу, і памылка звычайна выглядае як агульная праблема рукапаціскання.
Федэрацыя — гэта не перадача ключоў доступу
Налада SAML не перадае ў тунель ключы доступу IAM або токен прынятай ролі. Пастаўшчык ідэнтычнасці аўтэнтыфікуе чалавека, вяртае сцвярджэнне, і канцавы пункт прымае яго ў межах даверу, які вы наладзілі. Атрыманая сесія — гэта сесія VPN, а не сесія AWS API.
Гэтае адрозненне вырашае, хто што можа дыягнаставаць. Праблемы IdP паказваюцца як памылка браўзара або кліента яшчэ да з’яўлення тунеля, а праблемы тунеля — пасля паспяховага сцвярджэння. Спытайцеся, на што з двух вы глядзіце, перш чым адкрываць любую з кансолей.
Пасля ўваходу маршруты і аўтарызацыя ўсё яшчэ вырашаюць
Аўтэнтыфікацыя дае сесіі адрас; яна не дае сесіі пункт прызначэння. Маршруты канцавога пункта кажуць кліенту, у якія падсеткі адпраўляць, правілы аўтарызацыі вырашаюць, якія карыстальнікі могуць дасягнуць якіх з гэтых падсетак, а групы бяспекі плюс уласныя дазволы цэлі вырашаюць астатняе.
Вось чаму карыстальнік, які паспяхова аўтэнтыфікаваўся, усё яшчэ можа не дасягнуць базы даных. Праверце сувязь табліцы маршрутаў для падсеткі, правіла аўтарызацыі для групы карыстальніка і групу бяспекі на цэлі менавіта ў гэтым парадку, бо кожнае дае свой тып тайм-аўту.
Для адной прыватнай базы даных параўнайце з перанакіраваннем порта
Калі рэальная задача — адно ўзгодненае злучэнне з адной прыватнай базай даных, поўны сеткавы тунель — гэта выбар, а не патрабаванне. AWS Systems Manager Session Manager можа адкрыць сесію перанакіравання порта да кіраванага вузла праз IAM, і гэты вузел дасягае базы даных у прыватнай сетцы. Карыстальнік ніколі не атрымлівае адрас VPC. Кіраваны вузел становіцца адзіным хастом, які можа дасягнуць порта базы даных, і звычайна гэта менавіта тое, чаго патрабаваў агляд бяспекі. Тады карыстальнікам патрэбны лакальны кліент і каманда сесіі, а не профіль VPN.
Камрпраміс — гэта аб’ём супраць перадумоў. Перанакіраванне порта патрабуе агента SSM на кіраваным вузле, сеткавай дасяжнасці ад гэтага вузла да базы даных, плагіна Session Manager на машыне карыстальніка і дазволу запусціць менавіта гэтую сесію. Гэта не маршрут у кожную падсетку, і яно не будзе перадаваць адвольныя пратаколы так, як гэта робіць тунель.
У любым выпадку пакіньце ўласную ідэнтычнасць базы даных на месцы. Праверка TLS і аўтэнтыфікацыя базы даных не знікаюць таму, што шлях быў аўтарызаваны IAM, і ўзгодненая сесія нічога не кажа пра тое, якія табліцы карыстальнік можа чытаць.
Выбірайце па аб’ёме і жыццёвым цыкле: тунель, калі многім карыстальнікам патрэбна шмат пунктаў прызначэння і вы можаце весці жыццёвы цыкл сертыфікатаў або каталога; сесію перанакіравання, калі некалькім людзям патрэбна адна служба і вы не хочаце раздаваць сеткавыя адрасы. У любым выпадку запішыце метад аўтэнтыфікацыі, правіла аўтарызацыі і ўваход у базу даных як тры асобныя факты, бо яны адмаўляюць асобна.