Общий CA, отдельные двери: одна служба на файл допуска

Сертификат, который проверяется по общему удостоверяющему центру, прошёл проверку доверия, а не проверку членства. Эти два решения часто смешивают, потому что оба происходят при подключении, и смешение остаётся незаметным, пока в службу не допустят того, кому там быть не следует. Решение — не второй центр; это второе решение, принимаемое для каждой службы и записываемое там, где его читает демон. Держите два решения раздельно, и большая часть путаницы в этой области исчезнет.

Доверенная цепочка ничего не говорит о членстве в службе

Две службы могут принимать одну и ту же издающую иерархию и при этом иметь разные составы пользователей. Один ноутбук принадлежит первой и не должен попадать во вторую, тогда как другие клиенты той же иерархии действительно относятся туда. Удаление центра из этой службы заблокировало бы всех, кто пользуется ею законно, поэтому работа состоит в допуске, а не в доверии.

Полезно представить два замка на одной двери. Сертификат открывает внешний замок, а решение для службы открывает внутренний; ни один не заменяет другой. Служба только с внешним замком вовсе не обеспечивает членство, она лишь аутентифицирует. Запишите оба решения, прежде чем что-либо менять, потому что политику, которая существует только в виде работающего соединения, невозможно проверить аудитом. Дальше речь о внутреннем замке.

Превратите необязательные переопределения в шлюз допуска

Каталог клиентской конфигурации обычно служит удобством: файлы в нём переопределяют настройки названных клиентов, а клиент без файла просто работает со значениями сервера по умолчанию. Одна директива превращает это удобство в шлюз, так что отсутствие файла означает отказ в соединении.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

Общественная сборка OpenVPN 2.6 ccd-exclusive документирует на своей странице руководства именно это условие, а поиск названного файла зависит от фактической личности клиента. Другие сборки и серверы под управлением продуктов могут отличаться, поэтому проверьте установленную версию, прежде чем полагаться на ту же семантику в другом месте.

Считайте приведённый путь примером и проверяйте фактически развёрнутую схему, а не создавайте каталог, выдуманный руководством. Оставьте существующие проверки сертификатов, проверки личности сервера и аутентификацию учётной записи точно такими, какими они были, потому что фрагмент добавляет условие и ничего не убирает. Подготовьте изменение до эксплуатации, поскольку отказ, поднятый в неправильном месте, выглядит как сбой сертификата и направляет расследование к центру. Затем убедитесь, что строка журнала для отклонённого клиента называет отсутствующий файл конфигурации, а не цепочку.

Один каталог на службу, а не один общий список

Членство принадлежит службе, которая его обеспечивает, поэтому каждая служба держит свой каталог и свои файлы. Направление двух служб на один список заставляет их делить членство независимо от того, кто этого хотел, и возникшее изменение трудно проследить до решения. Общий центр может оставаться общим; файлы допуска — нет. Их раздельность означает также, что ошибка в одной службе не может молча расширить другую.

Запись DEFAULT — это случай, который вводит людей в заблуждение. Она даёт резервные настройки, когда названный файл не найден, но это не тот названный файл, которого требует шлюз, поэтому сама по себе она не может допустить клиента. Проверьте клиента, у которого вообще нет записи, и убедитесь в отказе; если такой клиент допускается, значит применяется резерв, и ccd-exclusive в этом экземпляре не действует.

Фактическая личность решает, какой файл читается

Поиск использует личность, под которой клиент действительно аутентифицировался, обычно это общее имя сертификата. Там, где сервер также проверяет имя пользователя и пароль и отображает это имя в общее имя, файл должен соответствовать аутентифицированному имени пользователя. Несовпадение оставляет каталог, полный правдоподобных имён файлов, которые никогда не выбираются.

Чтение — вторая половина. Демон обычно сбрасывает привилегии после запуска, поэтому урезанной учётной записи нужен доступ на чтение каталога и каждой записи в нём. Клиенты не должны иметь возможности создавать собственную запись через любой путь с правом записи, потому что допуск по самообслуживанию полностью обесценивает механизм. Проверьте права монтирования и совместного доступа, а не только режим файла, поскольку каталог, закрытый для одной учётной записи, может быть открыт для другой. Затем убедитесь, какую учётную запись действительно использует работающий процесс, а не какую упоминает unit-файл. Эти две совпадают только тогда, когда ничто другое их не меняло.

Наблюдайте отказ, допуск и отзыв по отдельности

Попробуйте личность, которая принадлежит службе, и убедитесь, что она подключается. Попробуйте действительный сертификат без записи и убедитесь, что в нём отказано. Попробуйте личность, допущенную в другую службу, и убедитесь, что здесь она не допускается. Записывайте экземпляр службы и фактическую личность рядом с каждым результатом, потому что результат без этого контекста никто другой не воспроизведёт.

Отзыв допуска — отдельная операция от отзыва сертификата. Правка файла допуска убирает право на одну службу, тогда как личность остаётся действительной везде в остальном, а скомпрометированный ключ требует реакции организации по отзыву. Заранее решите, что произойдёт с уже установленными сеансами, поскольку ни правка каталога, ни список отзыва сами их не завершают.

Допуск — это тоже лишь первый шлюз. Присоединение к службе ничего не говорит о подсетях, базах данных или интерфейсах управления за ней, и эта политика ресурсов должна быть написана и проверена отдельно.