Доступ к VPN для сервисной учётной записи: сертификат или общий логин
Сравните сертификат машины и сохранённый пароль для необслуживаемого доступа к VPN и поместите настоящий предел прав в политику, которая выполняется после входа.
Почти любую необслуживаемую схему VPN покрывают два решения: общий человеческий логин, хранимый в скрипте, или сертификат машины, привязанный к хосту. Они ломаются в разных местах, и это важнее скорости настройки. Сохранённый пароль ломается, когда владелец его меняет или увольняется; сертификат ломается, когда истекает срок или когда хост пересобирают без ключа. Три условия решают, какую цену вы можете нести, и ни одно решение ничего не ограничивает, пока это не сделает политика авторизации.
Начинайте с задачи, а не с учётной записи
Задача задаёт границу: какие назначения, какие службы, в какие часы, как долго может идти сеанс. Маршрут туннеля — только половина этой границы. Шлюз решает, разрешён ли сеанс; ресурс за ним решает, что сеанс может делать. Сначала напишите список с назначенным владельцем, потому что обе схемы идентичности должны его удовлетворять.
Держите аутентификацию и авторизацию раздельно, пока записываете. Аутентификация отвечает, кто подключается; авторизация отвечает, куда сеанс может попасть потом. RADIUS передаёт вторую часть как атрибуты вроде Filter-Id, Framed-IP-Address, Session-Timeout и Class, и шлюз добавляет их после успешного входа. Схема, которая меняет вход и оставляет авторизацию как есть, ничего не ограничила.
Общий человеческий логин: пароль становится границей
Повторное использование человеческой учётной записи — самый быстрый путь и тот, что стареет хуже всего. Учётные данные — это пароль, поэтому он попадает в скрипт, файл окружения и конфигурацию планировщика, и каждую копию нужно менять. Когда владелец меняет его в пятницу, задача падает при следующем запуске, и никто не смотрит.
MFA — место, где эта схема обычно рушится. Скрипт не может ответить на push-запрос, поэтому учётную запись исключают из политики, а это ровно та учётная запись, которую выбрал бы злоумышленник. Исключения, обходы для доверенных мест и послабления для отдельных учётных записей множатся, и ни одно из них не видно следующему, кто читает настройки клиента.
Атрибуция — вторая цена. Каждый сеанс в журнале шлюза несёт одно и то же имя пользователя, поэтому ночную синхронизацию нельзя отличить от работы человека, который её написал, а отзыв задачи означает отзыв этого человека.
Сертификат машины: идентичность, привязанная к хосту
Сертификат меняет вопрос с того, что знает учётная запись, на то, чем является хост. При EAP-TLS клиент предъявляет сертификат и доказывает владение соответствующим закрытым ключом; сервер политики сопоставляет субъект или учётную запись компьютера с группой и применяет политику этой группы. Ни запроса, ни общего секрета в текстовом файле.
Создаваемая граница уже, чем ожидают. Сертификат аутентифицирует хост, а не задачу, и любой с правами root или локального администратора может использовать этот ключ на этом хосте. Держите ключ там, где платформа его защищает: неэкспортируемым в хранилище сертификатов Windows, с поддержкой TPM там, где профиль это позволяет, или файлом 0600 во владении root в Linux. Компрометация хоста — это компрометация учётных данных.
Истечение срока — повторяющийся отказ. Сертификат, который истекает в воскресенье, останавливает задачу в воскресенье, и шлюз обычно сообщает общую ошибку аутентификации вместо того, чтобы назвать дату. Проверяйте даты с хоста задачи в рамках регламента:
openssl x509 -in client.pem -noout -subject -issuer -dates
ipsec listcertsДля отзыва нужен путь, который шлюз проверяет. OpenVPN читает CRL через опцию crl-verify, а strongSwan зависит от CRL или OCSP в зависимости от того, как построен профиль подключения. Если не подключено ни то, ни другое, удаление хоста означает ожидание истечения сертификата.
Три условия, которые решают между ними
Сравнивайте с той платформой, которая у вас есть, а не с эталонной схемой.
Первое условие: может ли шлюз авторизовать идентичность машины? Если он только сопоставляет имя пользователя RADIUS с пользователем каталога, сертификат аутентифицирует хост и затем застревает на авторизации. Второе условие: нужен ли задаче доступ к ресурсам, который несёт только пользовательская учётная запись, например подключённый общий ресурс или лицензия на место? Тогда идентичность машины не заменит её, и честный ответ — выделенная учётная запись с ограниченной политикой. Третье условие: кто может сменить учётные данные без участия человека? Автоматическая регистрация делает сертификаты дешёвыми в обслуживании; пароль, известный одному человеку, — нет.
| Constraint | Machine certificate | Dedicated user account with stored secret |
|---|---|---|
| Unattended login | Private key proof, no prompt | Only if the account is exempted from MFA |
| Resource expects a user identity | Works only when the resource accepts computer accounts | Matches the access a person would have |
| Rotation | Re-enrollment, often automated | Secret change plus redeploy of every copy |
| Revocation speed | Tied to CRL or OCSP refresh | Disable the account, immediate |
Читайте таблицу как список цен, а не как рейтинг. Столбец сохранённого секрета выигрывает в скорости отзыва и в совместимости с ресурсами, которые понимают только пользовательские учётные записи; столбец сертификата выигрывает в ротации и в том, что не ослабляет MFA ради работы скрипта.
Поместите предел в политику, после аутентификации
Какую бы идентичность вы ни выбрали, предел прав принадлежит политике, которая выполняется после аутентификации. В NPS сетевые политики оцениваются по порядку, и первая политика, совпавшая со всеми условиями, применяет свои параметры, поэтому широкая политика, стоящая выше узкой, решает результат, что бы ни предъявил клиент. Microsoft описывает модель условий и параметров в обзоре политик NPS.
Дайте задаче собственную группу или условие политики на основе того, что несёт идентичность машины: шаблон сертификата, идентификатор вызывающей станции или адрес из выделенного пула. Затем ограничьте сеанс атрибутами: Filter-Id для роли, к которой его сопоставляет шлюз, короткий Session-Timeout, чтобы зависшая задача проходила аутентификацию заново вместо удержания сеанса днями, и Framed-IP-Address из пула, который вы фильтруете межсетевым экраном на другой стороне. Авторизация приложения остаётся отдельной: туннель к серверу баз данных не даёт права читать таблицу внутри него.
Проверяйте отказы, потом планируйте удаление
Работающий доступ ничего не доказывает о минимальных правах. Вместо этого проверяйте отказы: подключитесь с идентичностью задачи и потянитесь к назначению вне списка, откройте второй одновременный сеанс, если шлюз должен разрешать только один, и повторите вход после отзыва учётных данных.
Затем подтвердите тот же сеанс в двух местах. Журнал шлюза показывает идентичность, которая прошла аутентификацию; журнал сервера политики показывает, какая политика совпала и какие атрибуты она вернула. В OpenVPN сервер записывает общее имя сертификата, а ipsec statusall в strongSwan печатает установленный туннель с используемой идентичностью. Если два журнала расходятся насчёт идентичности, политика совпадает не с тем, что вы предполагаете.
Удаление — часть схемы, а не уборочный спринт. Запишите всё, что нужно удалить (сертификат или учётную запись, членство в группе, сетевую политику, запись в пуле, правило межсетевого экрана на цели), и прогоните это один раз, пока задачу легко пересобрать.
Если вы начинаете сегодня, работайте в таком порядке: напишите список ресурсов, выберите идентичность по трём условиям, поместите предел в политику и отработайте один отказ до запуска задачи в работу.