Создать резервные копии всех центров сертификации цс eset

Обновлено: 05.07.2024

Разговор о центре сертификации логично начать с PKI — инфраструктуры открытых ключей. Находим определение в Википедии: «PKI — набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей». Так что к PKI стоит относиться именно как к инфраструктуре, в состав которой входят те или иные компоненты.

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

В качестве сущности может выступать пользователь, устройство или что угодно ещё, что можно ассоциировать с тем или иным ключом (процесс, программа, производитель и т. д.). Вот примеры задач, для которых обычно используется PKI:

создание сертификатов для привязки публичного ключа к сущности;
безопасное хранение сертификатов в репозитории (англ. repository — хранилище);
отзыв сертификата (отметка, что сертификату нельзя доверять).

В систему PKI обычно входят:

Центр сертификации (англ. Certificate Authority (CA)), которому будет посвящена основная часть этой статьи. Он непосредственно работает с сертификатом — выписывает, хранит, проверяет подлинность. Центр сертификации не следует путать с удостоверяющим центром. Также отдельно рассматривается «корневой центр сертификации» — сторона, чья честность неоспорима, а открытый ключ широко известен.
Регистрационный центр (англ. Registration Authority (RA)). Согласно Википедии, «удостоверяющий центр доверяет регистрационному проверку информации о субъекте». Поэтому часто регистрационный центр полностью или частично объединяют с CA.
Сертификат (англ. Certificate) — публичный ключ и идентификаторы сущности, имеющие подпись центра сертификации. В качестве идентификатора может выступать электронная почта пользователя. Если ЦС подписывает набор данных, который состоит из имени пользователя, его публичного ключа и электронной почты, то он как бы гарантирует, что эти данные подлинные. Далее под термином «сертификат» мы будем понимать сертификат стандарта X.509.
Certificate Signing Request (CSR). По сути это запрос на подпись сертификата. В запросе обычно указывается сущность, её параметры и публичный ключ.
Certificate Revocation List (CRL), он же список отзывов, или отозванных сертификатов. По этому списку ЦС ведёт учёт «плохих» сертификатов. И если такой сертификат используется, то ЦС не подтвердит к нему доверие. Чаще всего причина — утрата ключей сертификата.

Для базового понимания структуры PKI этого списка достаточно. Теперь рассмотрим, как всё это применяется.

Центры сертификации: как они используются

Задача центра сертификации — подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи. Логику работы ЦС, как правило, можно описать тезисом «никто не доверяет друг другу, но все доверяют ЦС».

Допустим, условная сущность Аlice имеет сертификат, подписанный ЦС Comp, а сущность Bob пытается проверить подлинность этого сертификата. Проверка будет успешной, если Bob и Alice доверяют одному и тому же ЦС. Для решения такой проблемы в ОС Alice и ОС Bob установлено множество сертификатов различных ЦС.

Рассмотрим, как браузер реагирует на разные сертификаты. У Firefox, например, для идентификации есть такой набор сертификатов ЦС:

Если открыть подробности, то можно увидеть почему:

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

Если открыть дополнительные сведения (что я всегда советую делать), то можно подробнее узнать о проблеме. Здесь видно, что на сайте установлен самоподписанный сертификат, то есть не подписанный каким-либо другим сертификатам. Его подлинность нельзя проверить, и соединение считается недоверенным.

А вот пример для сайта, у которого истёк срок действия сертификата:

Как проверяется доверие на практике?

Для каждого сертификата в соответствии с его назначением определяется хранилище в системе — туда его можно установить вручную. Например, есть хранилище доверенных сертификатов: если поместить в него сертификат, то система будет доверять ему.

В Windows сертификаты можно просмотреть через оснастку certmgr.msc:

Если поместить сертификат в хранилище «Доверенные корневые центры сертификации», то такому центру система будет доверять. А поскольку это хранилище корневых центров сертификации, система потом будет доверять и всем объектам, которые подписаны этим сертификатом.

В ОС Ubuntu Linux сертификаты хранятся в каталоге /etc/ssl/cetrs. Причём часть из них — ссылки на другой объект:

Разворачиваем собственный ЦС

Чтобы лучше понять все процессы, лежащие в основе PKI, рассмотрим на практике развёртывание небольшого ЦС на виртуальной машине под управлением Ubuntu 18 (без выхода в глобальную сеть). Мы не будем жёстко придерживаться правил и стандартов выдачи сертификатов — просто разберём работу с ними.

Начальные настройки

Сперва заполним файл /root/.rnd, который используется как источник начальных случайных значений в генераторе псевдослучайных чисел OpenSSL. Суть использования этого файла описана на сайте OpenSSL. Нам надо заполнить свой файл случайными данными, как вариант — скопировав из /dev/urandom 32768 байт в файл .rnd таким образом:

Далее создадим сертификат для CA:

Опции для сертификата берутся из файла /etc/ssl/openssl.cnf. Сам файл довольно большой, мы не будем приводить здесь его содержимое. В реальности стоит создать свой конфигурационный файл с необходимыми опциями и блоками — и использовать его для генерации сертификатов.

На выходе получим два файла: ключ и сертификат.

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

Далее на основе полученного сертификата (напомним, что это сертификат корневого CA) можно сгенерировать сертификат для сервера. Вначале генерируем закрытый ключ для сервера:

Теперь используем этот ключ для генерации запроса на выдачу сертификата (CSR):

Отметим, что данные, которые вы вводите в поля, должны совпадать со значениями в тех полях, что указывались при создании сертификата корневого сервера. Теперь возьмём корневой сертификат CA и запрос — и сгенерируем на их основе сертификат для сервера:

Должно получиться 5 файлов.

Файл server.req можно удалить — а при необходимости создать заново. Теперь надо перенастроить веб-сервер для работы с сертификатами.

Настройка Apache 2 для использования сертификатов

Переходим в каталог /etc/apache2:

Создаём каталог для хранения сертификатов:

Включаем модуль SSL для веб-сервера. Тестирование проводилось на ОС Ubuntu Linux, поэтому модуль достаточно просто включить:

Аналогично нужно включить поддержку заголовков:

Теперь создадим конфигурационный файл для модуля SSL. Пример содержимого для него можно взять на Syslink.pl. Команды такие:

Сам файл будет содержать следующие параметры (чтобы было проще работать, мы отключили заголовки Strict-Transport-Securrity, X-Frame-Options и X-Content-Type-Options):

Далее созданный конфиг надо активировать:

Теперь переходим в каталог /etc/apache2/sites-available:

И делаем на всякий случай резервные копии всех хранящихся там файлов:

Теперь ещё раз проверяем подключённые модули headers и SSL:

Далее нам надо перенести созданные сертификаты (сертификат CA и сертификат сервера) в каталог /etc/ssl/certs, а ключ сертификата сервера — в каталог /etc/ssl/private:

Далее откроем конфиг сайта (/etc/apache2/sites-available/000-default-ssl.conf) и добавим туда следующие опции:

Теперь перезагружаем веб-сервер:

Проверяем доступность сайта:

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

У полученного файла не забываем сменить атрибуты на 555:

Теперь откроем в браузере менеджер сертификатов и импортируем полученную цепочку (кнопка Import):

Далее можно просмотреть сертификаты и настроить доверие — вдруг что-то упущено:

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

Сейчас время настроить аутентификацию для клиентов.

Настройка аутентификации клиентов

Веб-сервер Apache поддерживает аутентификацию клиента. Это значит, что мы можем выписать клиенту сертификат SSL, а сервер сможет его проверить. Если у пользователя не будет сертификата — аутентификация не пройдёт. Для активации такой возможности надо добавить в конфиг default-ssl.conf такие опции:

После этого к сайту сможет подключиться только тот пользователь, сертификат которого:

установлен в браузере, если клиентом является браузер, — тогда сертификат будет предъявлен при подключении к серверу;
подписан сертификатом доверенного УЦ.

Сначала сгенерируем сертификат для клиента. Первым делом создаём ключ:

Затем на основе ключа сгенерируем CSR:

Теперь на базе запроса сгенерируем сам сертификат:

И импортируем сертификат в формате p12:

В итоге у нас должен получиться файл client.p12. Нужно поменять права на файл, иначе сертификат не импортируется:

Теперь можно импортировать его в браузер по аналогии с корневыми сертификатами:

После импорта должно получиться примерно так:

После этого перезапускаем веб-сервер и возвращаемся на сайт. Видим окно выбора сертификата того пользователя, которого мы импортировали в браузер:

После выбора сертификата пользователя можно успешно зайти на сайт:

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

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

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

Напоследок предлагаю ряд полезных материалов для изучения:

Источники, которые использовались при подготовке статьи:

Хотите в подробностях изучить работу центров сертификации и другие вопросы информационной безопасности? Тогда приглашаем вас на факультет GeekUniversity!

Резервное копирование является неотъемлемой частью программной стратегии аварийного восстановления. С помощью функции резервного копирования базы данных можно выполнить резервное копирование базы данных ESET PROTECT и сохранить в корневой папке в MySQL файл резервной копии с именем era-backup.sql .

Альтернативой созданию резервной копии базы данных является создание моментальных снимков виртуальной машины. Это позволит полностью сохранить виртуальное устройство ESET PROTECT со всеми его параметрами, а также базу данных ESET PROTECT. Однако если вы восстанавливаете моментальный снимок виртуальной машины, необходимо выполнить задачу Сброс после восстановления с моментального снимка .

Рекомендуется почаще выполнять резервное копирование базы данных ESET PROTECT и сохранять файл резервной копии во внешнем хранилище. Это важно, поскольку в случае аварии полная копия базы данных ESET PROTECT будет храниться в другом месте (не локально на виртуальном устройстве ESET PROTECT). Например, если ваше виртуальное устройство ESET PROTECT перестанет работать, будет удалено или недоступно по другим причинам. Имея резервную копию базы данных ESET PROTECT, вы сможете восстановить виртуальное устройство ESET PROTECT, вернув его к тому состоянию, в котором оно находилось незадолго до аварии. Подробные сведения об этой процедуре см. в разделе Аварийное восстановление виртуального устройства ESET PROTECT.

1. Включите режим управления . Для этого введите пароль и дважды нажмите клавишу ВВОД . Выберите команду Резервное копирование базы данных с помощью клавиш со стрелками и нажмите клавишу ВВОД .

2. Прежде чем начнется резервное копирование базы данных, отобразится запрос на ввод пароля root базы данных.

Если вы не помните пароль root базы данных, измените его и запустите резервное копирование базы данных снова.

В зависимости от размера базы данных этот процесс может занимать от нескольких секунд до нескольких часов.

Файл резервной копии базы данных сохраняется в эту папку: /root/era-backup.sql

С помощью диспетчера файлов Webmin загрузите файл резервной копии в безопасное расположение.

В этот статье я рассмотрю проблемы обеспечения информационной безопасности для Удостоверяющего Центра на примере КриптоПро УЦ.

Удостоверяющий Центр (УЦ) выполняет следующие функции:

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

Центр сертификации предназначен для формирования сертификатов открытых ключей пользователей и администраторов УЦ, списков отозванных сертификатов, хранения эталонной базы сертификатов и списков отозванных сертификатов.

Центр Регистрации предназначен для хранения регистрационных данных пользователей, запросов на сертификаты и сертификатов пользователей, для предоставления интерфейса взаимодействия пользователей с УЦ.

АРМ администратора ЦР предназначен для выполнения организационно-технических мероприятий, связанных с регистрацией пользователей, формированием служебных ключей и сертификатов пользователей и управлением Центром регистрации.

АРМ разбора конфликтных ситуаций предназначен для выполнения организационно-технических мероприятий, связанных с подтверждением подлинности ЭЦП в электронных документах и определением статуса сертификатов открытых ключей пользователей, а также связанных с подтверждением подлинности ЭЦП уполномоченного лица УЦ в изготовленных им сертификатах открытых ключей.

Все криптографические средства защиты по российскому законодательству должны иметь сертификаты ФСБ России. КриптоПро УЦ не исключение – есть действующий сертификат на КС2. КС2 означает защиту в соответствии с типом нарушителя Н2, что подтверждает защиту от нарушителя, имеющего постоянный и/или разовый доступ в контролируемую зону (КЗ), но не имеющего ни одного идентификатора доступа.

В продукте КриптоПро УЦ используются криптопровайдер КриптоПро CSP и средство аутентификации и шифрования КриптоПро TLS . КриптоПро CSP служит для генерации ключевой информации, шифрования и дешифрования , путем вызова соответствующих функций CryptoAPI приложениями. КриптоПро CSP может работать на прикладном уровне модели OSI и позволяет защищать данные поддерживаемых его приложений.

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

Требования информационной безопасности для УЦ разработаны ФСБ России. В нормативно-технических документах на КриптоПро УЦ (формуляр, ТУ) указано, что для сохранения сертификации все компоненты УЦ необходимо устанавливать за межсетевым экраном 4 класса по классификации ФСБ России. Так как данный документ является ДСП, удостовериться в этих требованиях не представляется возможным и остается верить в их целесообразность.

Все компоненты, за исключением АРМ для КД, целесообразно разместить в специально отведенной сети ( DMZ УЦ), АРМ для КД можно выносить в любое место, при обеспечении необходимых мер ИБ. Это удобно для создания удаленного рабочего места для генерации ключей. В этом случае для защиты удаленного АРМ потребуется использовать дополнительный межсетевой экран.

В настоящее время сертифицированными по линии ФСБ России есть только два межсетевых экрана: АПКШ «Континент» и ViPNet « Coordinator ». Оба продукта имеют одинаковые сертификаты ФСБ России, имеют схожий функционал, отличаются только в нюансах исполнения и использования, тем самым являясь прямыми конкурентами друг другу.

В документации на УЦ есть требование о необходимости использования на всех компонентах УЦ электронных замков доступа типа Соболь или Аккорд в качестве средства предотвращения несанкционированного доступа. Данные электронные замки являются программно-аппаратными комплексами, выполненными в виде PCI карт и устанавливаемые в серверы и/или персональные компьютеры.

Электронные замки обеспечивают доверенную загрузку, путем получения управления после отработки стандартного ПО BIOS . Загрузка ОС может выполняться как после предъявления идентификатора и пароля, так и после предъявления съемного носителя и кода доступа (двухфакторная идентификация). В качестве съемного носителя чаще всего используются токены eToken ( Aladdin ) или ruToken (Актив). Электронный замок имеет функции по контролю целостности файлов, который производится с использованием криптографического алгоритма ГОСТ Р 34.11-94 путем сравнения результата хэш-функции с исходным значением.

В документации на УЦ нет четких требований необходимости антивирусных средств, однако если всё-таки исходить из необходимости ИБ, то антивирусные средства необходимы. Поэтому имеет смысл на каждый компонент УЦ установить антивирус. К сертифицированным ФСТЭК России антивирусным средствам относятся: российские антивирусы Касперского и Dr . Web , белорусский антивирус VBA 32, а также антивирус иностранной разработки Eset NOD 32.

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

В документации есть типовая схема реализации УЦ, согласно которой предлагается создание резервных копий ЦС и ЦР. Однако если следовать принципам ИБ, то имеет смысл регулярно создавать резервные копии всех компонентов. Резервное копирование может быть как логическим, то есть на уровне файловой системы, так и физическим, то есть на уровне секторов жестких дисков. Пример логического средства – Microsoft NT Backup . Пример физических средств – Symantec Ghost , российский аналог Acronis True Image , свободный аналог PING ( Partimage Is Not Ghost ).

Если система имеет доступ в сеть Интернет, то необходимо обеспечить анализ защищенности. Лучше всего включить функции обновления ПО на всех компонентах УЦ, за исключением ЦС. ЦС лучше обновлять вручную, по аналогии с антивирусом. Для анализа защищенности в корпоративной сети организации устанавливается сервер анализа безопасности, с которого и производится анализ. Лучшим из российских средств защиты информации является MaxPatrol , который успешно конкурирует с иностранными средствами, от McAfee и Nessus .

Анализу подвергаются все средства, кроме ЦС, так как ЦС не входит в корпоративную сеть и/или DMZ , доступ к нему разрешен только для ЦР, а также ЦС является высококритичным ресурсом.

Если система имеет доступ в сеть Интернет, то необходимо также обеспечить функции по обнаружению вторжений. Данные функции присутствуют в антивирусе Касперского в виде IDS подсистемы. Номинальные функции по обнаружению вторжений присутствуют в МСЭ ViPNet Coordinator .

Однако для реальной безопасности имеет смысл использовать специализированное средство обнаружения вторжений, установленное «наверху», до межсетевого экрана УЦ. Примерами хороших средств IDS являются Cisco IPS 4200, StoneGate IPS .

Функции разграничения доступа присутствуют в каждом компоненте УЦ. Более того в УЦ используется ролевая модель разграничения прав доступа.

Дополнительно для обеспечения безопасности на всех компонентах УЦ важным является отсутствие административных привилегий при осуществлении доступа. Это достигается использованием штатных механизмов дискреционного типа доступа ОС Microsoft Windows .

В документации на УЦ есть требование «Удостоверяющий Центр обязан синхронизировать по времени все программные и технические средства обеспечения деятельности по предназначению». Имеет смысл иметь в организации сервер, который является эталонным источником времени. С этим сервером и должны синхронизироваться все компоненты, за исключением ЦС. ЦС же должен синхронизироваться только с ЦР.

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

Миграция центра сертификации Microsoft на новый сервер

Сервер Windows Server 2008 R2 c установленной ролью Active Directory Certificate Service и наличием аппаратных проблем)

Новый сервер Windows Server 2012 R2.

Перенос сервиса сертификации Active Directory на Windows Server 2012 R2.

Для начала подготовим резервную копию текущего центра сертификации. Для этого в оснастке Certificate Authority через

все задачи выбираем Архивация ЦС

Указываем архивирование всех элементов ЦС и путь для резервной копии

Для защиты закрытого ключа и файла сертификата центра сертификации указываем пароль

Архивация центра сертификации выполнена

Кроме базы данных центра сертификации Microsoft необходимо выгрузить и настройки, которые хранятся в реестре.

Для этого нужно выгрузить ветку

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc

Итог должен выглядеть так:

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

Продолжим, установим cлужбу сертификатов Active Directory c необходимыми компонентами. Та этом вопросе останавливаться долго не будем, полагаю тут все просто:

Выбор необходимых ролей

Непосредственно процесс установки

На следующем шаге указываем какие роли мы будем настраивать

В следующем окне выбираем “Корневой ЦС” в качестве типа ЦС и нажмите “Далее” для продолжения.

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

На этом этапе указываем путь к выгруженному сертификату со старого центра сертификации и пароль указанный при экспорте к нему.

После импорта то мы увидим наш сертификат

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

Итоговая проверка всех указанных выше параметров для настройки

Процесс настройки завершен.

Выбираем элементы, и указываем путь к папке в которую произведен экспорт

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

Восстановление завершено. Осталось только восстановить параметры, которые хранятся в реестре. Для этого как раз мы и экспортировали ветку реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc

Для импорта открываем фай и добавляем его в реестр. Появится предупреждающее окно. Нажмите “Да” для восстановления ключа реестра.

Осталось проверить работу нового центра сертификации. Как видим, все выданные сертификаты перенесены.

Новый Web сервер работает выдачи сертификатов работает.

Итог: Сервис сертификации Active Directory успешно перенесен на новый сервер, при этом как мы видели, произошла и миграции в рамках операционной системы 2008R2 -> 2012R2.

Читайте также: