Internal PKI

Internal PKI в плане Enterprise позволяет создавать корневые и промежуточные центры сертификации, выпускать серверные и клиентские сертификаты, сертификаты подписи кода и электронной почты, применять шаблоны, публиковать списки отзыва (CRL) и экспортировать поддерживаемые форматы с явным контролем доступа.

Используйте Internal PKI, когда организация хочет, чтобы Opfield управлял внутренним доверием для людей, служб, подписи кода или защиты электронной почты. Служба безопасности определяет политику и принимает связанный риск, администраторы PKI управляют центрами сертификации и шаблонами, а владельцы приложений используют выпущенные сертификаты. До подключения рабочих систем проверьте не только выпуск, но и цепочку доверия, назначение, продление, отзыв, резервное копирование и восстановление.

PKI, или инфраструктура открытых ключей, объединяет центры сертификации, сертификаты, закрытые ключи, записи отзыва и правила, по которым системы решают, кому доверять. Корневой центр сертификации является верхней точкой доверия. Промежуточный центр выпускает повседневные сертификаты, чтобы корневой ключ использовался реже и защищался строже.

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

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

Модель доверия

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

Пользовательские центры сертификации Opfield нельзя использовать вместо скрытой системной PKI, Database CA, идентификаторов нод или служб Relay. Эти внутренние области доверия имеют отдельные правила замены ключей и восстановления.

Решения управления

До создания корневого центра согласуйте его область, владельца, срок действия, допустимые назначения сертификатов, контакт для инцидентов и план вывода из эксплуатации. Решите, будет ли корневой ключ создан в Opfield или импортирован, допустим ли его экспорт и какие системы будут проверять списки отзыва сертификатов (CRL). Без этих решений создавать центр сертификации преждевременно.

Используйте отдельные промежуточные центры для существенно разных сред или уровней доверия. Компрометация центра разработки не должна автоматически угрожать рабочей среде, а центр подписи кода не должен быть взаимозаменяем с центром обычных серверных сертификатов. Эти границы должны быть закреплены в шаблонах, а не оставлены на память оператора.

Создайте иерархию центров сертификации

1. Подтвердите право Enterprise и необходимые области PKI.
2. Создайте или импортируйте корневой центр сертификации.
3. Создайте резервные копии PKI_MASTER_KEY и базы данных Opfield отдельными защищёнными процедурами.
4. Создайте промежуточный центр для нужного окружения или организационной границы.
5. Создайте шаблоны серверных и клиентских сертификатов, подписи кода или электронной почты.
6. Выпустите тестовый сертификат и проверьте цепочку, назначение ключа, срок действия и формат экспорта.
7. Опубликуйте CRL и проверьте его доступность до выпуска сертификатов для рабочей среды.

Выпускайте и эксплуатируйте сертификаты

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

Когда Route использует сертификат внутреннего центра сертификации, нода Ingress отдаёт его вместе с промежуточными центрами сертификации, поэтому клиенты, которые доверяют только корневому, могут его проверить.

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

Срок действия, оповещения об истечении и автоматический перевыпуск

Сертификат не может действовать дольше выпустившего его центра сертификации. По умолчанию запрос, срок действия которого закончился бы после окончания срока центра сертификации, отклоняется с ошибкой VALIDITY_EXCEEDS_CA. Задайте clampToCaValidity в REST API, MCP или ассистенте, чтобы сертификат вместо этого заканчивался вместе с центром сертификации; диалог выпуска показывает уведомление и применяет это автоматически. Сертификаты, подписанные по CSR, подчиняются тому же правилу. Конечные сертификаты системных центров сертификации Opfield всегда заканчиваются вместе с ними.

Opfield поднимает оповещения об истечении для пользовательских центров сертификации за 180, 60, 30 и 7 дней (последние два порога берутся из параметров предупреждения и критического порога PKI) и для системных центров сертификации за 730, 365, 180, 60, 30 и 7 дней. У системных центров сертификации в 2.11 нет автоматической смены, а все выпущенные ими сертификаты нод, Relay, управляемых хранилищ и управляемых баз данных перестают работать после их истечения, поэтому планируйте замену при первом оповещении. В оповещении указан владелец сертификата: управляемое хранилище, управляемая база данных, Relay, служба приёма соединений Opfield или нода. Каждый порог срабатывает один раз: закрытое оповещение не возвращается до следующего порога, а продлённый сертификат снова получает оповещения в новом сроке действия.

Сертификат внутренней PKI, связанный как SSL-сертификат или указанный непосредственно в Route, перевыпускается автоматически, если закрытый ключ хранится в Opfield; сертификаты, подписанные по CSR, не перевыпускаются никогда. Для перевыпуска нужно право pki:cert:issue на центр сертификации, как и для ручного выпуска.

Выдавайте pki:ca:edit, чтобы разрешить изменение адресов CRL и издателя, максимального срока действия и OCSP-ответчика центра сертификации, и pki:ca:export — для экспорта центра сертификации вместе с закрытым ключом; оба права можно ограничить одним центром сертификации. pki:ca:view охватывает корневые и промежуточные центры сертификации и тоже ограничивается одним центром.

Центры сертификации, сертификаты и шаблоны сертификатов можно раскладывать по папкам, как Routes и SSL-сертификаты: создавать, переименовывать и упорядочивать папки, перетаскивать между ними элементы и выбирать папку при создании. Папка центров сертификации содержит иерархии целиком: перемещаются только корневые центры, а их промежуточные следуют за ними. Права на папку центров сертификации охватывают каждый корневой центр в ней и его промежуточные, права на папку сертификатов — сертификаты в ней, а папки шаблонов сертификатов только упорядочивают список. См. Поддержка папок по типам ресурсов.

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

Резервное копирование и восстановление

Резервная копия базы данных без PKI_MASTER_KEY не может восстановить зашифрованные закрытые ключи. Копия ключа без базы данных не может восстановить центры сертификации, шаблоны, сертификаты, отзывы и связи аудита. Храните и проверяйте обе части, сохраняя их операционно раздельными.

После восстановления проверьте цепочки центров сертификации, расшифровку, права экспорта сертификатов, публикацию CRL и непрерывность аудита до выпуска новых материалов.

Для операторов: инциденты и вывод из эксплуатации

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

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

Поведение при потере права и удалении

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