- Почему нельзя использовать efs?
- Введение
- Архивирование клиентских сертификатов и ключей вручную
- Буква закона
- Другие особенности нашего решения
- Криптопро | как извлечь сертификат из контейнера закрытого ключа?
- Настройка прозрачного шифрования сетевой папки
- Настройка средства резервного копирования
- Особенности эксплуатации ca на роутерах mikrotik: резервное копирование, экспорт и импорт сертификатов
- Работа с зашифрованной папкой
Почему нельзя использовать efs?
Зачем нужны все эти танцы с бубном и с использованием программы CyberSafe Top Secret? Ведь можно зашифровать с помощью EFS папку H:1C на сервере и наша база данных тоже будет зашифрована.
А теперь самое главное: все правильно, если выполнить прозрачное шифрование папки с базой данных, база данных будет зашифрована, а вот резервные копии — нет. Ведь при использовании EFS все программы на сервере, в том числе и Acronis, будут видеть все файлы зашифрованной с помощью EFS папки расшифрованными.
При использовании CyberSafe другие программы, в том числе и Acronis, видят файлы базы данных изначально зашифрованными. Это очень важно. Думаю, не нужно говорить, что произойдет, если резервная копия попадет в чужие руки. Файлы в резервной копии не будут зашифрованы, следовательно, их сможет прочитать любой желающий.
Введение
Представим, что у нас есть типичное предприятие (рис. 1). Как и во многих подобных организациях, в нашей организации используется всем известная 1С: Предприятие, база данных которой хранится на сервере, изображенном на иллюстрации.
Рис. 1. Схема вымышленного предприятия
Поскольку в базе данных 1С: Предприятие содержится обрабатываемая конфиденциальная информация, необходимо защитить ее от несанкционированного доступа. Для этого мы решили зашифровать базу данных 1C. После шифрования файлы базы данных 1С на сервере будут храниться в зашифрованном состоянии.
Шифрование будет осуществляться средствами программы CyberSafe Top Secret. Понятно, что раз есть данные, то нужно выполнить их резервное копирование. Вот только данные у нас будут не простые, а зашифрованные. Далее в этой статье будет рассказано:
Архивирование клиентских сертификатов и ключей вручную
Архивирование сертификатов при данном подходе выполняется методом экспорта сертификата в файл.
Экспорт цифрового сертификата может быть выполнен в одном из двух форматов:
Для выполнения операции экспорта пользовательского сертификата необходимо подключиться к пользовательскому хранилищу сертификатов.
Первый способ – открыть Microsoft Management Console и добавить в нее оснастку Сертификаты.
Второй, более простой способ добраться до цифровых сертификатов пользователя, – открыть Internet Explorer и в свойствах обозревателя открыть вкладку Содержание.
При нажатии кнопки Сертификаты открывается окно, выводящее несколько вкладок различных типов сертификатов, которые есть у пользователя. В нашем случае нужна первая вкладка Личные.
Выбрав нужный сертификат, нажимаем кнопку Экспорт… и в запустившемся мастере экспорта выбираем формат экспортируемого файла.
На приведенном выше рисунке первые три опции доступны, а вот четвертая опция Файл обмена личной информацией – PKSC #12 (.PFX) является недоступной. Почему?
Потому что первые три опции экспортируют в файл только сам сертификат, а закрытый ключ остается в операционной системе. Четвертая же опция экспортирует сертификат вместе с закрытым ключом и данная операция является критичной с точки зрения безопасности.
Для того, чтобы вы могли экспортировать из системы закрытый ключ, ваш запрос на получение сертификата должен заранее содержать разрешение на экспорт ключа, а шаблон сертификата (это уже настройки самого центра сертификации) должен разрешать такие запросы.
Ваши задачи как системного администратора в данном случае – заранее спланировать возможность экспорта закрытых ключей из клиентской машины (опция Allow private key to be exported на вкладке Request Handling в свойствах шаблона сертификата), а затем обойти все клиентские машины и экспортировать в централизованное хранилище (флешка, общая папка) клиентские сертификаты в формате .pfx.
Организационные и технические вопросы защиты централизованного хранилища фалов .pfx выходят за рамки данной статьи.
Процесс восстановления сертификатов в нашей схеме будет очень простой: после переустановки операционной системы и приложений нужно дважды щелкнуть на сохраненном файле .pfx и импортировать сертификат и закрытый ключ в хранилище.
Буква закона
Используемая нами связка программного обеспечения (программы CyberSafe Top Secret и Acronis Backup & Recovery) выбрана не просто так. Мы реализуем требования законодательства по защите конфиденциальной информации (к которой относятся и персональные данные).
Мы выполняли требования законодательства относительно периодического резервирования обрабатываемых данных, а также их защиты от несанкционированного доступа.
Резервное копирование осуществляется средствами программного комплекса Acronis Backup & Recovery 11 Advanced Server, имеющего сертификат ФСТЭК № 2677 от 16.07.2021.
Защита от несанкционированного доступа реализуется посредством применения программы CyberSafe Top Secret, которая вместе с использованием сертифицированного криптопровайдера КриптоПро CSP и алгоритма ГОСТ для шифрования данных, также считается сертифицированным средством.
Кстати, чтобы ни говорили поклонники TrueCrypt, а использовать ее для защиты персональных данных все равно нельзя, поскольку она не является сертифицированным средством шифрования. Сертификата ФСТЭК у нее нет и никогда не будет. Что же касается, EFS, то она считается сертифицированной только в специальной версии Windows, у которой есть сертификат ФСТЭК.
Если выйти «за рамки» TrueCrypt, то для решения нашей задачи не подойдет не только эта программа, но и любая другая, использующая криптодиски. Даже если эта программа сертифицирована. Ранее мы писали об уязвимостях криптодисков и если поставленную задачу решать посредством криптодисков, то криптодиск нужно защищать средствами операционной системы (сетевой авторизацией), которая не сертифицирована (или у вас сертифицированная версия Windows?).
Кроме того, данные с криптодиска по сети передаются в незашифрованном виде. Для шифрования данных, передаваемых, между клиентом и сервером, на котором «расшарен» криптодиск, нужно настраивать VPN (разумеется, нужно использовать сертифицированное решение).
Другие особенности нашего решения
Итак, вы уже знаете, что при использовании CyberSafe средство резервного копирования будет «видеть» изначально зашифрованные файлы. Это и есть главная особенность нашего решения. Однако нельзя не отметить и другие:
- Шифрование и расшифровка данных происходит на клиенте, а не на сервере — в отличие от EFS, процесс шифрования и расшифрования не происходит на сервере, как уже было отмечено. Следовательно, если злоумышленник получит доступ к серверу, на нем нет ни ПО для шифрования, ни самих ключей. Да, программа CyberSafe Top Secret на сервере не устанавливается. Она нужна только на компьютерах пользователей, которым необходима работа с зашифрованной папкой.
- Шифрование данных при их передаче по сети — EFS, увы, не поддерживает шифрование данных по сети. Это означает, что данные между сервером БД 1С и клиентом передаются в расшифрованном виде. При использовании прозрачного шифрования CyberSafe шифрование и расшифровка происходят на клиентах, то есть на компьютерах пользователей, работающих с 1С. Следовательно, по сети данные передаются в зашифрованном виде.
- Разграничение доступа — с прозрачной сетевой папкой могут работать не все, а только лишь те, чьи сертификаты указаны при шифровании папки — это дополнительный уровень защиты данных. Да, разграничение доступа происходит и на уровне системы — посредством установки прав доступа, но использование сертификатов делает защиту данных еще более надежной.
- Резервное копирование выполняется на сетевое хранилище — зашифровать папку на сетевом хранилище мы не можем (в силу отсутствия поддержки NTFS — жесткий диск на сетевом хранилище отформатирован как ext3), зато мы можем выполнить на него резервное копирование зашифрованной папки средствами Acronis.
- Возможность инкрементного копирования — фанаты программы TrueCrypt могут возразить, мол, можно создать контейнер виртуального зашифрованного диска, «расшарить» его и хранить базу данных 1С в нем (впрочем, недостатки этого решения уже были рассмотрены ранее), а Acronis будет каждый день копировать тот самый файл виртуального жесткого диска. Такой файл может легко занимать несколько гигабайт и каждый день вам придется копировать его полностью, даже если в папке изменился всего один файл размером несколько килобайтов. Использовать такое решение можно, но ни о какой рациональности речи не идет — как по нагрузке системы, так и по использованию дискового пространства. В случае с нашим решением вы можете производить инкрементное резервное копирование, то есть копировать только новые и измененные файлы. Вам не нужно каждый день копировать всю папку. Инкрементное решение экономит дисковое пространство и снижает общую нагрузку на систему, в том числе и на сеть, поскольку используется сетевое хранилище.
Криптопро | как извлечь сертификат из контейнера закрытого ключа?
Как правило, после выпуска сертификата открытого ключа, он помещается в ключевой контейнер, и его можно извлечь из контейнера средствами КриптоПро CSP. Для этого необходимо выполнить следующие действия:
1. Перейти в Панель управления (ПУСК – Панель управления) найдите и запустить КриптоПро CSP.
2. На вкладке сервис выбрать «Просмотреть сертификат в контейнере».
3. Выбрать нужный контейнер и нажать «Далее». Если в контейнере присутствует сертификат, то отобразится информация о нём.
4. Нажать «Свойства». Откроется сам сертификат.
5. Перейти на вкладку «Состав». Нажать кнопку «Копировать в файл».
6. Выбрать варианты: «Нет, не экспортировать закрытый ключ» и «Файл в DER-кодировке X509» (.CER)
7. Указать путь для сохранения файла сертификата.
***При выполнении пункта 3 может появиться информационное сообщение: «В контейнере закрытого ключа не найдены сертификаты». В этом случае, сертификат, скорее всего, был передан пользователю в виде файла.***
***Если при использовании версии КриптоПро CSP 2.0 появляется сообщение: «В контейнере не найдены секретные ключи», то, скорее всего этот контейнер был сгенерирован в КриптоПро CSP 3.0 или выше.***
Настройка прозрачного шифрования сетевой папки
Для большей однозначности назовем наш сервер, на котором хранится база данных 1С, коротко и понятно: SERVER. На логическом диске H: есть папка 1С (H:1C), в которой и хранится база данных 1С. К папке предоставлен общий доступ, сетевой путь выглядит так: \SERVER1C. Эту папку нам и нужно зашифровать.
Программа CyberSafe должна быть установлена на всех компьютерах, которые должны работать с зашифрованной папкой, то есть на компьютере администратора и на компьютере всех пользователей, которые работают с 1C. Запускаем программу CyberSafe Top Secret и переходим в раздел Прозрачное шифрование, нажимаем кнопку Доб. папку и добавляем нашу сетевую папку (рис. 2).
Рис. 2. Программа CyberSafe Top Secret
Нажмите кнопку Применить. Появится окно Прозрачное шифрование, в котором нужно нажать кнопку Да или Да для всех, если вы собираетесь за один раз зашифровать несколько папок. Далее нужно выбрать сертификаты пользователей, которые будут иметь доступ к папке (создать собственный сертификат можно в разделе Личные ключи, импортировать ключи других пользователей — в разделе Все ключи).
Рис. 3. Выбор сертификата
После нажатия кнопки Применить вы увидите предложение добавить ключ администратора, нажмите кнопку Да. Все, папка защищена.
Примечание. В программу CyberSafe Top Secret можно добавить, как пустую папку, так и папку с файлами. Разницы нет. Вы можете зашифровать пустую папку и позже добавить в нее файлы.
Настройка средства резервного копирования
Итак, папка зашифрована. Программа 1С: Предприятие может работать с ней как с самой обычной папкой, если не считать незначительной потери производительности. В качестве средства резервного копирования используется программа Acronis Backup & Recovery, которая установлена на нашем сервере.
Данная программа выбрана не случайно, поскольку Acronis при резервном копировании сохраняет файловые потоки, в которых в них хранится информация о ключах, которыми была зашифрована папка с базой данных 1C. Кроме того, при использовании Acronis даже не нужно завершать процесс 1С, чего требуют некоторые другие средства резервного копирования. Сама настройка Acronis проста — нужно указать, что копируем (рис. 4) и куда копируем (рис. 5).
Рис. 4. Что копируем
Рис. 5. Куда копируем
Обратите внимание, куда именно осуществляется резервное копирование: резервная копия сохраняется на сетевое хранилище D-Link.Если вы не используете Acronis, а другое средство резервного копирования, убедитесь, что оно поддерживает сохранение файловых потоков.
Даже некоторые архиваторы (если не используете ПО для резервного копирования, а создаете резервную копию вручную) поддерживают файловые потоки. Например, в WinRAR при создании архива на вкладке Дополнительно (рис. 6) нужно включить переключатель Сохранять файловые потоки.
Рис. 6. Создание архива
После этого архив с зашифрованной папкой можно распаковать на другом компьютере или на другом жестком диске. При желании такой архив можно передать адресату. Для расшифровки нужно, чтобы сертификат адресата был указан при шифровании папки.
Особенности эксплуатации ca на роутерах mikrotik: резервное копирование, экспорт и импорт сертификатов
Mikrotik предоставляет пользователям достаточно широкие возможности, одна из них – создание на роутере собственного центра сертификации (CA), который позволяет управлять собственной инфраструктурой открытых ключей (PKI). Благодаря этому вы можете выпускать, подписывать и отзывать сертификаты, а также поддерживать доверительные отношения без использования дополнительных технических и программных средств. Это удобно, но эксплуатация CA на базе Mikrotik имеет свои особенности и подводные камни, которые нужно четко представлять и учитывать при выборе такого решения.
Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор – официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.
Коротко напомним, что такое инфраструктура открытых ключей (PKI), это область доверия, где каждый участник может доверять другому участнику, не имея никаких предварительных данных о нем. В основе PKI лежит центр сертификации (CA), авторитет CA неоспорим, а доверие к нему не подвергается сомнению.
При создании CA генерируется ключевая пара из закрытого ключа и корневого сертификата, который содержит открытый ключ. Закрытый ключ является секретным и должен храниться как зеница ока, потому как его компрометация дает возможность злоумышленнику выпускать сертификаты от имени вашего CA, а следовательно, получить доступ к вашей области доверия. Корневой сертификат, наоборот, должен быть широко распространен на узлах вашей области доверия, так как именно он позволяет убедиться в подлинности выпущенных сертификатов.
При этом любой пользователь или узел, располагающий корневым сертификатом, может в любой момент времени убедиться в подлинности предъявленного ему сертификата другого пользователя или узла, а так как доверие к CA не подвергается сомнению, то автоматически возникают доверительные отношения с предъявителем действующего сертификата. Также корневой сертификат содержит адрес CRL – списка отозванных сертификатов, что позволяет дополнительно убедиться, что предъявленный сертификат не был отозван.
Следует понимать, что после того, как CA выпустил сертификат и передал его клиенту, он больше не может его контролировать и в случае компрометации его можно только отозвать. Между тем отозванный сертификат будет успешно проходить проверку подлинности при помощи корневого сертификата и проверить его на отзыв можно только при помощи списка CRL, который должен быть опубликован для общего доступа. Если CRL отсутствует или недоступен, то проверить сертификат на отзыв будет невозможно, а следовательно, такой сертификат будет принят как действительный.
В Mikrotik для работы с сертификатами следует перейти в отдельный раздел – System –Certificates. Прежде всего научимся правильно читать информацию о сертификатах, которая сосредоточена в первой колонке и представлена в виде буквенных флагов:
- А – authority – корневой сертификат при помощи которого мы можем подписывать другие сертификаты
- T – trusted – сертификат с которым установлены доверительные отношения
- L – crl – корневой сертификат содержит адрес списка отозванных сертификатов (CRL)
- I – issued – сертификат, выпущенный центром сертификации расположенном на данном устройстве
- K – private-key – сертификат имеет связанный с ним закрытый ключ
- E – expired – сертификат с истекшим сроком действия
- R – revoked – отозванный сертификат
Таким образом корневой сертификат CA должен иметь флаги KAT или KLAT в зависимости от того, использует ли центр сертификации списки отзыва CRL. Выпущенный данным CA сертификат будет иметь флаг KI, а будучи импортированным на другом узле в присутствии сертификата CA будет иметь флаги KT, а сам корневой сертификат чужого CA – просто T или LT.
Закладка System – Certificates – CRL содержит загруженные списки отзыва для всех сертификатов, имеющих флаг L, кроме корневого сертификата собственного CA. Для работы со списками отзыва следует выполнить некоторые настройки, они расположены в System – Certificates – Settings. Флаг Use CRL включает использование списков отзыва, флаг CRL Download разрешает загрузку списков для сертификатов, содержащих адрес CRL. Если установить первый, но не устанавливать второй, то списки CRL будут работать только для собственного CA.
Еще одна важная опция – место хранения CRL – CRL Store, по умолчанию там стоит вариант хранения в оперативной памяти – ram. Но здесь есть первые подводные камни, объем RAM занимаемый списком рассчитывается по формуле:
4MB 10 * <CRL_size>Таким образом даже самый небольшой список будет занимать от 4 МБ оперативной памяти, что может быть критично для младших моделей с небольшим объемом оперативной памяти, в этом случае значение CRL Store следует изменить на system.
Следующий важный вопрос: а что будет, если роутер с ролью CA выйдет из строя? В таком случае вы полностью потеряете контроль над своей PKI и вам потребуется создать новый CA и перевыпустить все сертификаты. Избежать этого можно только одним образом – созданием резервной копии устройства в бинарном формате. Для этого перейдите в Files и нажмите кнопку Backup, укажите имя файла и обязательно задайте пароль (в противном случае закрытые ключи выгружены в резервную копию не будут).
Либо выполните в терминале:
/system backup save name=backup password=<MY_PASSWORD>Но бинарная копия имеет ряд существенных ограничений, она предназначена для восстановления только на том устройстве, на котором была создана, либо на другом той же модели при окончательном выходе устройства из строя. Это связано с тем, что при восстановлении такой копии будут восстановлены и MAC-адреса, а появление в одной сети двух устройств с одинаковыми MAC-адресами способно привести к серьезным сбоям в ее функционировании. Ну и наконец, вы не сможете восстановить бинарную резервную копию на другой модели роутера.
Этих недостатков лишена копия настроек в текстовом формате, которую можно полностью или частично восстановить на любом устройстве с RouterOS. Для ее создания выполните команду:
/export file=export_cfg
После чего в разделе Files у вас появится файл с указанным именем и расширением .rsc. Но данный файл не содержит ключей и сертификатов и не годится для восстановления CA. Скажем сразу – никаким иным способом, кроме как бинарным бекапом, перенести CA на другой роутер нельзя. Фактически центр сертификации получается в своем роде “одноразовым”, его можно перенести только на точно такое же устройство, в случае апгрейда вам придется создать инфраструктуру PKI заново.
Но значит ли это, что вам не нужно делать резервную копию ключей и сертификатов? Нет. Никогда нельзя исключать внезапный выход роутера из строя, как и невозможность приобрести ему на замену точно такую же модель. А ситуация, когда все работает, хоть и с ограничениями, всегда лучше ситуации, когда не работает ничего.
Несмотря на то, что полноценно восстановить CA на другом узле мы не сможем, но работу служб, использующих сертификаты восстановить можно, хотя и с некоторыми оговорками. В некоторых случаях они могут оказаться существенными, почему так мы покажем ниже.
А пока экспортируем нужные нам ключи и сертификаты. Перейдем в System – Certificates, найдем там корневой сертификат CA и щелкнув на него правой кнопкой мыши выберем Export. Формат не имеет принципиального значения, при выборе PEM вы получите два файла – сертификат и закрытый ключ, при выборе PKCS12 – единственный файл .p12.
Обязательно укажите пароль в поле Export Passphrase, в противном случае закрытые ключи выгружены не будут.
Затем, аналогичным образом, выгружаем сертификаты и ключи для служб, работающих на данном роутере, клиентские и серверные сертификаты, используемые на других узлах, выгружать не имеет смысла. Обратите внимание, так как выгружаемые ключевые пары содержат закрытые ключи, то следует обеспечить их безопасное хранение, особенно закрытого ключа центра сертификации CA.
При переходе на другое устройство вам потребуется загрузить сертификаты и ключевые пары, либо файлы p12 в Files. После чего импортировать их в System – Certificates. Последовательность импорта такова: сначала сертификат, потом закрытый ключ, в случае файла p12 все импортируется за одно действие.
Глядя на статус импортированного корневого сертификата – KLAT – можно подумать, что все хорошо, но увы. Выпущенный этим же CA серверный сертификат импортируется не как KI, а как KT, это означает, что он будет работать, но отозвать мы его никогда не сможем, это же относится и к клиентским сертификатам, почему мы выше и сказали, что экспортировать их бессмысленно.
При этом вы можете продолжать выпускать сертификаты от имени CA и подписывать их корневым сертификатом. Если вы не используете в своей инфраструктуре PKI отзыв сертификатов, то можете продолжать работать. Никаких проблем при этом не возникнет.
А мы тем временем перейдем к спискам отзыва, так как это самое больное место в этой схеме. При создании корневой ключевой пары CA, в момент подписи запрашивается адрес опубликования CRL – СА CRL Host, именно по этому адресу Mikrotik поднимет веб-сервер и опубликует список отозванных сертификатов.
Здесь снова есть подводные камни. Файл списка CRL при каждом изменении меняет свое название на номер итерации, так при первом создании он будет http://192.168.111.1/crl/1.crl, а после следующего отзыва превратиться в http://192.168.111.1/crl/2.crl. Адрес списка CRL содержится в корневом сертификате CA, поэтому, если вы используете несколько узлов, разрешающих доступ по сертификатам выпущенным Mikrotik, то после каждого отзыва вы должны заново экспортировать корневой сертификат СА и распространить его на все узлы вашей области доверия PKI, как минимум на те, которые принимают сертификаты для аутентификации или авторизации.
При переносе ключевой пары CA на другой хост RouterOS прочитает из корневого сертификата адрес CRL и попытается его скачать. Но так как старый роутер заменен новым, с тем же адресом, скачивать ему будет нечего. К сожалению, Mikrotik не позволяет импортировать файл списка CRL, поэтому даже имея его на руках вы не сможете загрузить его в устройство.
Но ведь мы можем выдавать новые сертификаты и можем их отозвать? Можем. Но новый список CRL при этом не формируется, центр сертификации будет продолжать пытаться загрузить список CRL указанный в корневом сертификате, которого в новом роутере не существует.
Таким образом, при переносе ключевой пары CA на новый роутер мы имеем возможность выдавать новые сертификаты, но сразу перестают действовать списки отзыва, т.е. клиенты с отозванными сертификатами снова могут подключиться к серверу, а также теряется возможность отзыва вновь выпущенных сертификатов.
Фактически старый CA перестал существовать, но мы можем продолжать поддерживать работоспособность текущей инфраструктуры PKI, хотя и с ограничениями, и планомерно планировать переход на сертификаты нового CA. Такой сценарий гораздо предпочтительнее, чем полный отказ инфраструктуры.
Как видим, в RouterOS нет возможности полноценно перенести CA на другое устройство, это серьезное ограничение и его следует обязательно учитывать при планировании инфраструктуры, в тоже время, располагая экспортированной ключевой парой CA и собственных сертификатов роутера вы всегда сможете восстановить работоспособность инфраструктуры, хотя и существенными ограничениями.
Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор – официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.
Работа с зашифрованной папкой
Чтобы зашифрованная папка стала доступной, нужно запустить программу CyberSafe Top Secret, выделить папку и нажать кнопку
Включить
. После чего появится окно ввода пароля. Нужно ввести пароль вашего сертификата (если он, конечно, был указан при шифровании папки). По окончанию работы с папкой ее нужно выключить, нажав кнопку
Выключить
Если кто-то попытается открыть файлы, находящиеся в зашифрованной сетевой папке, с другого компьютера (или с компьютера, на котором хранится сама зашифрованная папка), то он обнаружит, что эти файлы зашифрованы.