Получить подпись в аккредитованном УЦ
Это когда организация обращается во внешний УЦ за квалифицированной электронной подписью для документооборота с государством и контрагентами. Своей инфраструктуры не требуется.
Проектирование и консалтинг
Проектирование PKI и удостоверяющего центра
Проектируем инфраструктуру открытых ключей и собственный удостоверяющий центр организации: архитектуру выпуска и проверки сертификатов, защиту корневых ключей, регламенты и интеграцию с вашими системами. От модели угроз до готового к внедрению проекта.
Работаем на отечественной криптографии и обладаем лицензией ФСБ России на деятельность в области шифрования. PKI — фундамент, на котором держатся электронная подпись, аутентификация и защищённый обмен: ошибка в его проектировании обходится дороже всего.
Прежде всего
Сначала о терминах: чтобы говорить об одном и том же
Вокруг PKI много путаницы, и из-за неё заказывают не то, что нужно. Коротко разведём понятия.
PKI (инфраструктура открытых ключей) — это вся система: центры, выпускающие сертификаты, регламенты, средства защиты ключей, порядок проверки и отзыва. PKI отвечает на вопрос, как в организации в принципе устроено доверие к электронным подписям и сертификатам.
Удостоверяющий центр (УЦ) — ядро PKI: то, что выпускает и обслуживает сертификаты. Бывает разным по назначению.
Важное различие, которое чаще всего и путают:
Построить собственный УЦ
Это когда организации нужен свой центр выпуска сертификатов: для аутентификации сотрудников и устройств, внутреннего документооборота, защищённого доступа, подписи в своих системах. Вот это мы и проектируем.
Когда обращаются
Когда нужен собственный УЦ и PKI
- Нужно выдавать сертификаты сотрудникам и устройствам в большом количестве — внешний УЦ на каждую выдачу неудобен и дорог
- Требуется аутентификация по сертификатам вместо паролей: вход в рабочие станции и домен, VPN, корпоративный Wi-Fi (802.1X), доступ к внутренним порталам
- Нужна подпись во внутренних системах: согласование документов, юридически значимый внутренний документооборот, подпись в прикладных системах и на портале
- Нужны сертификаты для устройств и сервисов: серверы, сетевое оборудование, служебные сервисы, машина-машина (mTLS)
- Строится защищённый обмен между подразделениями, филиалами, информационными системами
- Требуется контроль над всем жизненным циклом сертификатов внутри организации
- Есть требования к аутентификации и подписи в ГИС, КИИ, отраслевых системах
- Идёт импортозамещение: нужно уйти с иностранной PKI на отечественную криптографию
- Действующий УЦ морально устарел, не масштабируется или не соответствует требованиям
Этапы проекта
Что входит в проектирование
Обследование и сбор требований
Разбираемся, для чего нужен УЦ: кому и какие сертификаты выпускать, в каком объёме, для каких систем, под какие требования. Оцениваем действующую инфраструктуру, если УЦ уже есть.
Модель угроз и требования безопасности
Разрабатываем модель угроз для инфраструктуры и определяем требования к защите — в первую очередь к защите ключей УЦ, компрометация которых обрушивает доверие ко всем выпущенным сертификатам.
Архитектура PKI
Проектируем структуру: корневой и подчинённые УЦ, иерархия доверия, точки регистрации, размещение компонентов, отказоустойчивость. Определяем, что работает в защищённом контуре, что доступно пользователям.
Защита ключевой информации
Проектируем защиту корневых и промежуточных ключей: аппаратные модули безопасности (HSM), церемония генерации корневого ключа, порядок хранения, резервирования и доступа. Это ядро всего проекта.
Регламенты и документация
Разрабатываем регламент УЦ, политику применения сертификатов, порядок выпуска, отзыва и обновления, регламент реагирования на компрометацию, ролевую модель и разделение полномочий.
Интеграция
Проектируем интеграцию с каталогом (Active Directory и аналоги), с системами, потребляющими сертификаты, со средствами электронной подписи, токенами и смарт-картами.
План внедрения
Готовим план развёртывания, миграции с действующей PKI, если она есть, и ввода в эксплуатацию без нарушения работающих сервисов.
Центральная задача
Защита ключей — то, ради чего всё и проектируется
В любом проекте УЦ есть одна точка, компрометация которой обесценивает всё остальное: закрытый ключ корневого центра. Тот, кто им завладел, может выпускать сертификаты от имени вашей организации, и доверие ко всей системе рушится.
Поэтому защита ключей — не одна из задач, а центральная. В проекте мы прорабатываем:
Аппаратное хранение
Корневой ключ живёт в аппаратном модуле безопасности (HSM), а не в файле на сервере, и не покидает его.
Церемонию генерации
Порядок создания корневого ключа с участием нескольких доверенных лиц, разделением секрета и документированием.
Разделение полномочий
Ни один человек единолично не может выпустить сертификат от корня или получить полный контроль над УЦ.
Изоляцию корневого УЦ
Корневой центр по возможности выведен из сети и включается только для обслуживания подчинённых.
Резервирование и восстановление
Порядок восстановления работы УЦ без риска для ключей.
Регламент на случай компрометации
Что делать, если худшее всё же произошло.
Технологии
На отечественной криптографии
PKI — это область, где криптография не абстракция, а основа. Проектируем на сертифицированных отечественных средствах:
Средства УЦ на базе ГОСТрешения, реализующие российские криптографические алгоритмы
Криптопровайдеры и СКЗИКриптоПро, ViPNet и другие сертифицированные средства
Аппаратные носители и токеныРутокен, JaCarta и аналоги для хранения ключей пользователей
Аппаратные модули безопасности (HSM)для защиты ключей УЦ; подбираем модель с учётом сертификации ФСБ и совместимости со средствами УЦ
Подготовка
Что нужно для старта работ
Цель: для чего нужен УЦ — аутентификация, подпись, защищённый обмен, всё вместе
Масштаб: сколько сертификатов, каким субъектам (сотрудники, устройства, системы), какая динамика
Перечень систем, которые будут потреблять сертификаты
Сведения о действующей PKI или УЦ, если они есть, — для проектирования миграции
Применимые требования: ГИС, КИИ, отраслевые, корпоративные
Сведения об инфраструктуре: каталог, домены, средства защиты
Ограничения: бюджет, сроки, площадки, требования к отказоустойчивости
Этапы работы
Как проходит работа
Обследование и требования
Изучаем задачи, инфраструктуру и применимые требования, фиксируем цели УЦ.
Модель угроз и концепция
Разрабатываем модель угроз и согласуем концепцию: архитектуру, состав средств, подход к защите ключей.
Проектирование
Готовим проектные решения: архитектуру, защиту ключей, регламенты, схему интеграции, план внедрения.
Согласование
Проходим проект с вами, при необходимости — с регулятором. Дорабатываем по замечаниям.
Передача проекта
Передаём готовый комплект: проектную документацию, регламенты, план внедрения. При необходимости переходим к внедрению.
Результат
Что вы получаете
01
Модель угроз для инфраструктуры PKI и УЦ
02
Архитектуру PKI: иерархию центров, размещение компонентов, схему доверия
03
Проектные решения по защите ключей: HSM, церемония генерации, разделение полномочий
04
Регламент УЦ и политику применения сертификатов
05
Порядок выпуска, отзыва, обновления сертификатов и реагирования на компрометацию
06
Ролевую модель и разделение полномочий
07
Схему интеграции с каталогом, системами и средствами подписи
08
Спецификацию средств с учётом требований к сертификации
09
План внедрения и миграции с действующей PKI
10
Обоснование решений для согласования с регулятором, если требуется
Стандарты
На что опираемся
Требования и рекомендации ФСБ Россиик средствам удостоверяющих центров и средствам криптографической защиты
Требования ФСТЭК Россиик защите информации в системах, где применяется PKI
Российские криптографические стандарты (ГОСТ)как основа применяемых алгоритмов
Требования к вашим системамГИС, КИИ, отраслевые и корпоративные
Сроки
Сроки и стоимость
Зависят от масштаба и сложности инфраструктуры. На объём влияет:
Масштаб УЦ: число субъектов и сертификатов, динамика выпуска
Архитектура: один центр или иерархия, число площадок, требования к отказоустойчивости
Уровень защиты ключей: программные средства или HSM, изоляция корневого УЦ
Необходимость миграции с действующей PKI
Число систем для интеграции
Нужно ли согласование с регулятором
Почему мы
Почему АйЭсТи
- 15 лет на рынке информационной безопасности
- 2 000+ реализованных проектов
- Офисы в Самаре, Оренбурге, Нижнем Новгороде и Москве
- Лицензии ФСТЭК и ФСБ, включая лицензию ФСБ на разработку, производство и распространение шифровальных (криптографических) средств и услуги в области шифрования информации — PKI это профильная для нас область
- Проектируем и строим удостоверяющие центры, а не только консультируем: у нас отдельная услуга по созданию и модернизации УЦ, и за проектированием при необходимости следует внедрение
- Работаем на отечественной криптографии и с сертифицированными средствами
- Партнёрство с ключевыми российскими вендорами криптографии и аппаратных носителей
- Проектируем с прицелом на согласование с регулятором, а не только на работоспособность
Вопросы
Частые вопросы
Чем это отличается от получения электронной подписи в аккредитованном УЦ?
Аккредитованный УЦ выдаёт вам готовую подпись для документооборота с государством и контрагентами — своей инфраструктуры не нужно. Мы проектируем собственный УЦ организации: для аутентификации, внутренней подписи и защищённого обмена внутри вашей экосистемы. Это разные задачи.
Нам обязательно нужен HSM? Это дорого.
Не всегда, но для корневого ключа настоятельно рекомендуется: именно его компрометация обрушивает доверие ко всей системе. Мы подбираем уровень защиты под реальные риски: где-то оправдан HSM, где-то достаточно других мер. Решение обосновываем, а не навязываем.
Можно ли перейти с иностранной PKI на отечественную без остановки сервисов?
Да, это одна из частых задач. Миграцию проектируем поэтапно, с периодом сосуществования старой и новой инфраструктуры, чтобы сервисы аутентификации и подписи не прерывались.
Вы только проектируете или можете и построить?
И то, и другое. Проектирование — отдельная услуга, но у нас есть и создание удостоверяющих центров. Можно заказать проект и внедрить его самостоятельно, а можно передать нам весь цикл.
Будут ли сертификаты нашего УЦ доверенными за пределами организации?
Сертификаты собственного (корпоративного) УЦ по умолчанию доверены внутри вашей инфраструктуры — там, где вы распространили корневой сертификат. Для доверия во внешних системах нужны отдельные механизмы, и это мы учитываем на этапе проектирования, исходя из того, где сертификаты будут применяться. Если задача — юридически значимый обмен с государством и контрагентами, это область квалифицированной подписи из аккредитованного УЦ, а не корпоративной PKI.
Наш УЦ уже есть, но устарел. Поможете?
Да. Обследуем действующую инфраструктуру, определим, что модернизировать, а что заменить, и спроектируем переход с сохранением работающих сервисов.
Начать проект
Обсудить проект PKI
Расскажите о задаче — для чего нужен УЦ, какой масштаб, есть ли действующая инфраструктура, под какие требования. Проведём обследование и предложим архитектуру и план.