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