Удостоверяване в 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, а одобрената сесия не казва нищо за това кои таблици може да чете потребителят.
Избирайте по обхват и жизнен цикъл: тунел, когато много потребители се нуждаят от много дестинации и можете да управлявате жизнения цикъл на сертификати или директория; сесия за пренасочване, когато няколко души се нуждаят от една услуга и предпочитате да не раздавате мрежови адреси. Във всеки случай запишете метода за удостоверяване, правилото за оторизация и входа в базата данни като три отделни факта, защото те се провалят поотделно.