Что происходит на практике
Client Hello – клиент начинает общение с сервером отсылая информацию о предпочитаемой версии протокола TLS, набора поддерживаемых шифров (Cipher Spec), и случайного простого числа (client random), необходимого в дальнейшем для генерации общего ключа симметричного шифрования.
Что такое Cipher Spec? В процессе установки соединения, клиент и сервер должны договориться о: какой алгоритм использовать для обмена ключами (например, RSA – Риверт-Шамир-Адлеман, DH – Диффи-Хеллмана, ECDH – Диффи-Хеллмана на эллиптических кривых, и др.), какой алгоритм использовать для шифрования данных (AES – Advanced Encryption Standard, 3DES – Tripple Data Encryption Algorithm, и др.), какую криптографическую хэш-функцию использовать для генерации Message Authentication Code (SHA-256, SHA-384, SHA-512 – Secure Hash Algorithm с соответствующей длиной строки в битах с хэшем, и др.).
Что такое Message Authentication Code или MAC? Это хэш, сгенерированный с использованием выбранной криптографической хэш-функции и разделяемого ключа, который добавляется сзади к сообщению. Перед отправкой данных отправитель вычисляет MAC для них, а получатель перед обработкой вычисляет MAC для принятого сообщения и сравнивает его с MAC этого принятого сообщения. Предназначен для проверки целостности, то есть что сообщение не было изменено при его передаче.
Server Hello – сервер отвечает выбранной версией протокола и выбранным из предложенного набора шифром, которые будут непосредственно использоваться, своим случайным простым числом (server random) и идентификатором сессии.
Для чего нужен идентификатор сессии? Как мы посмотрим далее, процесс установления TLS соединения затратен по времени и ресурсам. Предусмотрен механизм возобновления соединения с помощью отправки клиентом этого идентификатора. Если сервер тоже все еще хранит соответствующие настройки, то клиент и сервер смогут продолжить общение использую ранее выбранные алгоритмы и ключи.
Certificate – сервер отправляет свой сертификат, а клиент производит проверку подписи удостоверяющего центра, проверку доверия к удостоверяющему центру, проверку указанного домена сайта с фактическим, срока действия, проверяет не был ли сертификат отозван.
Что представляет из себя сертификат? Сертификат – это открытый ключ и другая информация о его владельце, а также Электронная Цифровая Подпись (ЭЦП) доверенного центра.
Как работает ЭЦП? При создании ЭЦП хэш данных, которые подписываются, шифруется закрытым ключом, в отличие от обычного ассиметричного шифрования, где зашифровка выполняется открытым ключом. Таким образом, если вам удалось расшифровать открытым ключом хэш, и он оказался идентичен хэшу из данных, – вы можете быть уверены что: подпись была сделана именно владельцем приватного ключа, открытый ключ которого вы используете; данные, которые были подписаны, не изменились с момента подписания.
Но как удостовериться, что открытый ключ принадлежит не злоумышленнику? Существуют корневые удостоверяющие центры (Root Certificate Authority или просто CA – Certificate Authority), которым доверяют все участники обмена информацией. Если в цепочке подписания сертификата сервера есть подпись корневого CA (мы можем проверить ее с помощью открытого ключа CA), то мы можем ему доверять. При этом сертификаты (открытые ключи) корневых CA распространяются посредством включения их в операционную систему или браузер поставщиками. Также стоит отметить, что сертификат может быть подписан сертификатом, который подписан в свою очередь другим сертификатом – это цепочка подписания.
Кем подписан сертификат корневого CA? А никем, нет инстанции выше корневого CA. Сертификат (открытый ключ) в этом случае подписан собственным закрытым ключом. Такие сертификаты называют самоподписанные (sefl-signed).
Server Key Exchange – этот этап происходит не всегда, только если необходимы дополнительные данные для создания симметричного ключа при выбранном алгоритме. Например, при обмене ключами RSA этот шаг пропускается и для обмена общим ключ передается от клиента серверу зашифрованным открытым ключом сервера из его сертификата. Однако в этой статье рассмотрим более надежный алгоритм Диффи-Хеллмана. Сервер отправляет числа p (большое простое число) и g (может быть маленьким), а также рассчитанное число Ys=gслучайно выбранное сервером числоmod p, где mod – это операция нахождения остатка от деления. В свою очередь клиент также рассчитывает Yc=gслучайно выбранное клиентом числоmod p. После этого сервер считает Ycслучайно выбранное сервером числоmod p, а клиент Ysслучайно выбранное клиентом числоmod p, в результате чего у клиента и сервера получается одинаковое число. Разберем на примере:
Server Hello Done – сервер сообщает, что начальный этап установки соединения завершен
Client Key Exchange – как было уже сказано выше, когда сервер передал числа p, g, Ys в Server Key Echange, клиент передает свое число Yc в Client Key Exchange. Вычисленное в конце общее одинаковое число используется для создания pre-master secret – предварительного разделяемого ключа. На основании client random, server random и pre-master secret псевдослучайная функция выдает симметричный ключ и ключ вычисления MAC. Таким образом клиент и сервер имеют все необходимое для начала обмена полезной информацией.
Change Cipher Spec – клиент говорит серверу, что он готов перейти на защищенное соединение.
Finished – клиент зашифровывает симметричным ключом первое сообщение с MAC.
Change Cipher Spec – сервер проверяет сообщение Finished от клиента и отправляет в ответ свою готовность к защищенному соединению.
Finished – аналогично клиенту, сервер отправляет тестовое зашифрованное сообщение
После этого соединение считается установленным, и происходит передача полезной информации
close_notify – служебное сообщение, которое одна сторона отправляет другой, как уведомление о том, что считаетсоединение разорванным и не будет принимать больше сообщения. Другая сторона в ответ обязана послать аналогичное сообщение close_notify.
The bat! и сертификаты
При настройке почтового сервера возникла проблема с сертификатами.
Тестовый сертификат от
RapidSSL
работал без проблем со всеми почтовыми клиентами (это исключение, т.к. остальные триальные PositiveSSL, GlobalSign, EssentialSSL не хотели работать с The Bat!).
Когда купили сертификат на год и подключили к dovecot и exim, то возникли проблемы в The Bat!.
1. При попытке отправить или принять почту возникает ошибка: “Сервер не представил корневой сертификат в сессии и соответствующий корневой сертификат не найден в адресной книге. Это соединение не может быть секретным. Пожалуйста, свяжитесь с администратором Вашего сервера“. В журнале аналогичная запись: “Недействительный сертификат сервера (Поставщик цепочки этого S/MIME сертификата не найден)”.
Проблема НЕ в поставщиках, а в настройках сервера. Вместе с сертификатом нашего домена нужно выдавать всю цепочку сертификатов (промежуточные CA и корневой CA). Это должно решить проблему нехватки корневого сертификата.
Решение:
1.1. Открываем полученный сертификат (*.crt) в Windows:
1.2. Выбираем в списке промежуточный сертификат RapidSSL CA и нажимаем Просмотр сертификата:
1.3. Нажимаем Копировать в файл.
Выбираем формат Base64 (это текстовый вариант, только расширение другое – *.cer).
Затем нажимаем Далее и сохраняем файл.
1.4. С полученным сертификатом нужно повторить шаги 1.1-1.3.
В моем случае я сохранил сертификат корневого CA – GeoTrust Global CA.
1.5.1. Итак у нас получилось два новых файла: для RapidSSL CA и для GeoTrust Global CA.
Для dovecot и exim мы объединим все три сертифкаты (ключая mail.globalclubbing.com) в один файл mail.globalclubbing.com.all.crt:
—–BEGIN CERTIFICATE—–
MIIE5TCCA82gAwIBAgICdPEwDQYJKoZIhvcNAQEFBQAwPDELMAkGA1UEBhMCVVMx
…
4HfgZX56IUcP
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
MIID1TCCAr2gAwIBAgIDAjbRMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
…
LEL2TxyJeN4mTvVvk0wVaydWTQBUbHq3tw==
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
MIIDVDCCAjygAwIBAgIDAjRWMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
…
5fEWCRE11azbJHFwLJhWC9kXtNHjUStedejV0NxPNO3CBWaAocvmMw==
—–END CERTIFICATE—–
1.5.2 Этот файл нужно подсунуть exim таким образом:
MAIN_TLS_CERTIFICATE = CONFDIR/mail.globalclubbing.com.all.crt
А для dovecot другим:
ssl_cert_file = /etc/ssl/certs/mail.globalclubbing.com.all.crt
1.6.1 В случае с apache, нужно делать два файла.
Сертификат нашего домена mail.globalclubbing.com.crt:
—–BEGIN CERTIFICATE—–
MIIE5TCCA82gAwIBAgICdPEwDQYJKoZIhvcNAQEFBQAwPDELMAkGA1UEBhMCVVMx
…
4HfgZX56IUcP
—–END CERTIFICATE—–
И mail.globalclubbing.com.ca.crt, который содержит только CA.
—–BEGIN CERTIFICATE—–
MIID1TCCAr2gAwIBAgIDAjbRMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
…
LEL2TxyJeN4mTvVvk0wVaydWTQBUbHq3tw==
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
MIIDVDCCAjygAwIBAgIDAjRWMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT
…
5fEWCRE11azbJHFwLJhWC9kXtNHjUStedejV0NxPNO3CBWaAocvmMw==
—–END CERTIFICATE—–
1.6.2. И подключать через:
SSLCertificateFile /etc/ssl/certs/mail.globalclubbing.com.crt
SSLCertificateChainFile /etc/ssl/certs/mail.globalclubbing.com.ca.crt
2. Однако на этом проблема не заканчивается – The Bat! может заупрямиться и ответить: “Нет доверия к корневому S/MIME сертификату центра сертификации, поскольку его нет в адресной книге доверенных корневых центров сертификации”. В журнале аналогичная запись: “Недействительный сертификат сервера (Нет доверия к корневому S/MIME сертификату центра сертификации, поскольку его нет в адресной книге доверенных корневых центров сертификации.)”.
Дело в том, что в адресных книгах The Bat! (RootCA и IntermediateCA) могут отсутствовать указанные нами сертификаты (промежуточные CA и корневой CA).
В этом случае достаточно добавить сертификат с помощью кнопки “Добавить к доверенным”.
Кстати, есть способ проверить корректность настройки сертификатов для apache, exim (465 порт) и dovecot (995, 993 порты).
Новый порядок аттестации объектов информатизации: разбираем положения свежего документа от фстэк россии
Новый порядок аттестации объектов информатизации: разбираем положения свежего документа от ФСТЭК России
Новый Порядок организации и проведения работ по аттестации объектов информатизации будет способствовать обеспечению реальной безопасности ИС.
Андрей Семенов, заместитель руководителя отдела compliance и аттестации Дирекции по интеграции компании «Ростелеком-Солар»
10 августа Министерство юстиции РФ утвердило новый приказ ФСТЭК России от 29 апреля 2021 г. № 77 «Порядок организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну». Как ясно из названия, он определяет порядок работ по аттестации объектов информатизации, а также требования к процессам, форме и содержанию документов, разрабатываемых при организации и проведении этих работ. Кроме основного нововведения – реестровой модели ведения аттестатов соответствия, данный документ содержит ряд интересных или неоднозначных положений, которые мы хотим подсветить в нашем обзоре. Разберем интересные моменты по порядку.
1. Порядок организации и проведения работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну
Формально изменились требования, на соответствие которым проводятся аттестационные испытания – если раньше это была аттестация на соответствие «требованиям безопасности информации», то теперь стало «требованиям о защите информации».
2. Порядок применяется для аттестации объектов информатизации с 1 сентября 2021 года.
Все работы по аттестации, которые будут выполняться начиная с этой даты, должны проходить в соответствии с новым Порядком. Важно, что это касается даже тех работ, которые будут проводиться в рамках уже ранее заключенных контрактов.
3. Настоящий Порядок определяет состав и содержание работ по аттестации объектов информатизации на соответствие требованиям о защите информации ограниченного доступа, не составляющей государственную тайну.
Здесь ситуация аналогична той, что была с приказом ФСТЭК России от 11 февраля 2021 года № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», когда из области регулирования выпадает та защищаемая информация, которая является общедоступной. Формально государственная информационная система (далее – ГИС), обрабатывающая защищаемую общедоступную информацию, в область регулирования данного Порядка не попадает. А если ГИС одновременно не является и информационной системой общего пользования (на основании приказа ФСБ России и ФСТЭК России от 31 августа 2021 г. № 416/489 «Об утверждении Требований о защите информации, содержащейся в информационных системах общего пользования»), то защиту информации в ней регулирует только федеральный закон «Об информации, информационных технологиях и о защите информации» от 27.07.2006 № 149-ФЗ.
4. Аттестация объектов информатизации на соответствие требованиям о защите информации (далее – аттестация) осуществляется федеральными органами государственной власти, органами государственной власти субъектов Российской Федерации, органами местного самоуправления, организациями, которым на праве собственности или ином законном основании принадлежат объекты информатизации, а также лицами, заключившими контракт на создание объектов информатизации, или лицами, осуществляющими эксплуатацию объектов информатизации (далее – владельцы объектов информатизации).
Здесь стоит обратить внимание на то, что аттестовывать объекты информатизации теперь имеют право и эксплуатирующие их организации – их в явном виде включили в состав владельцев объектов информатизации.
5. Аттестация объекта информатизации проводится на этапе его создания или развития (модернизации) и предусматривает проведение комплекса организационных и технических мероприятий и работ (аттестационных испытаний).
С одной стороны, положение очевидное. Но на практике нам приходилось сталкиваться с ситуацией, когда заказчик заявлял о необходимости аттестационных мероприятий для информационных систем, выведенных из эксплуатации. Теперь явно названы этапы жизненного цикла ИС, на которых эти испытания требуются.
6. По решению руководителя федерального органа государственной власти, органа государственной власти субъекта Российской Федерации, органа местного самоуправления аттестация принадлежащих этому органу объектов информатизации проводится в соответствии с настоящим Порядком структурным подразделением (работниками), ответственными за защиту информации.
Это нововведение позволяет перечисленным выше органам власти при выполнении ряда условий самостоятельно аттестовывать свои объекты информатизации без наличия лицензии ФСТЭК России на ТЗКИ. Вероятно, это обусловлено необходимостью выполнения положений Постановления Правительства РФ от 6 июля 2021 года № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации». Оно запрещает ввод систем в эксплуатацию без действующего аттестата соответствия.
7. Для проведения аттестационных испытаний органом по аттестации из числа своих работников назначается аттестационная комиссия в составе руководителя комиссии и не менее двух экспертов, обладающих знаниями и навыками в области технической защиты конфиденциальной информации и аттестации объектов информатизации.
Появился четкий ответ на вопрос о минимальном количестве участников аттестационной комиссии – не менее трех.
8. При назначении экспертов органа по аттестации должна быть обеспечена их независимость от владельца объекта информатизации с целью исключения возможности влияния владельца аттестуемого объекта информатизации на результаты аттестационных испытаний, проведенных экспертами органа по аттестации.
Отметим, что под органом по аттестации Порядок подразумевает «организацию, имеющую лицензию на осуществление деятельности по технической защите конфиденциальной информации (с правом проведения работ и оказания услуг по аттестационным испытаниям и аттестации на соответствие требованиям о защите информации)». Следовательно, под это определение не подпадают органы власти, решившие самостоятельно аттестовывать свои объекты информатизации.
Еще один важный вопрос пока остается открытым. Он касается критериев определения независимости экспертов органа по аттестации от владельца объекта информатизации: может ли теперь коммерческая организация аттестовывать свои объекты информатизации и объекты информатизации головной компании? Раньше это было явно разрешено при условии, что «аттестатор» не проектировал и не внедрял СОИБ аттестуемого объекта информатизации.
9. Для проведения работ по аттестации владелец объекта информатизации в качестве исходных данных представляет в орган по аттестации копии ряда документов, включая «документы, содержащие результаты анализа уязвимостей объекта информатизации и приемочных испытаний системы защиты информации объекта информатизации (в случае проведения анализа и испытаний в ходе создания объекта информатизации).
Новый документ однозначно определил ответственного за предоставление результатов инструментального сканирования. Это не орган по аттестации, проводящий испытания, а именно владелец аттестуемого объекта информатизации.
10. По решению владельца объекта информатизации указанные в настоящем пункте копии документов представляются в орган по аттестации в виде электронных документов.
Раньше орган по аттестации, как правило, принимал только бумажные варианты утвержденных документов (с подписью и печатью организации). Теперь же допустимо предоставлять их в электронном виде. Пока остался открытым вопрос о форме их заверения: требуется ли она и если да, то в каком виде? Будет ли достаточно пересылки с авторизованного почтового ящика или понадобится электронная подпись того или иного вида?
11. Аттестационные испытания включают следующие мероприятия и работы:
…
б) проверку наличия и согласования с ФСТЭК России … модели угроз безопасности информации, технического задания на создание (развитие, модернизацию) объекта информатизации или частного технического задания на создание (развитие, модернизацию) объекта информатизации (только для государственных информационных систем).
Тут Порядок ужесточает имеющиеся ранее требования – необходимо будет согласовать с регулятором оба документа сразу. В Постановлении Правительства РФ от 6 июля 2021 года № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» есть требование в обязательном порядке согласовывать или модель угроз безопасности информации, или техническое задание: «Техническое задание на создание системы и (или) модель угроз безопасности информации согласуются с федеральным органом исполнительной власти в области обеспечения безопасности и федеральным органом исполнительной власти, уполномоченным в области противодействия техническим разведкам и технической защиты информации, в пределах их полномочий в части, касающейся выполнения установленных требований о защите информации». Постановление Правительства имеет больший приоритет, чем приказ ФОИВ. Поэтому ждем пояснений регулятора.
12. Заключение и протоколы в течение 5 рабочих дней после утверждения органом по аттестации направляются владельцу объекта информатизации.
Определен крайний срок, в течение которого необходимо выслать аттестационную документацию владельцу объекта информатизации.
13. По результатам устранения недостатков орган по аттестации повторно оформляет заключение, в которое наряду со сведениями, указанными в пункте 18 настоящего Порядка, включаются сведения об устранении владельцем объекта информатизации всех выявленных недостатков, а также делается вывод о возможности выдачи аттестата соответствия требованиям по защите информации на объект информатизации.
В ряде случаев в номенклатуре аттестационных документов в явном виде появляется дополнительный. Как он будет называться – заключение № 2, повторное заключение?
14. Владелец объекта информатизации в случае несогласия с выявленными органом по аттестации недостатками и выводами, содержащимися в заключении и протоколах, направляет в течение 5 рабочих дней с момента получения заключения и протоколов письменное обращение с обоснованием такого несогласия в ФСТЭК России.
В документе ничего не говорится о возможности «претензионной работы» между владельцем объекта информатизации и органом по аттестации – возможно только обращение владельца объекта информатизации в ФСТЭК России. Явного запрета на урегулирование споров между владельцем объекта информатизации и органом по аттестации нет. Но, учитывая, что у владельца объекта информатизации имеется всего пять дней, чтобы обратиться к регулятору в случае неуспешных переговоров с органом по аттестации, вряд ли вообще получится их провести.
15. ФСТЭК России (территориальный орган ФСТЭК России) в течение 10 календарных дней с даты получения обращения проводит оценку документов.
При осуществлении «арбитражной» работы регулятор не предусмотрел «пауз» на длительные праздничные дни (например, новогодние или майские праздники) и оперирует календарными, а не рабочими днями – это не может не радовать.
16. Орган по аттестации в течение 5 рабочих дней после подписания аттестата соответствия представляет в ФСТЭК России (территориальный орган ФСТЭК России) в электронном виде копии следующих документов:
а) аттестата соответствия объекта информатизации;
б) технического паспорта на объект информатизации;
в) акта классификации системы (сети), акта категорирования значимого объекта;
г) программы и методик аттестационных испытаний объекта информатизации;
д) заключения и протоколов.
В договорах и ПМИ нужно аккуратно подходить к определению даты подписания аттестата соответствия. Особенноесли есть необходимость иметь запас по времени на обработку, утверждение и отправку документации при наличии
бюрократических
многоэтапных, требующих различных согласований процедур внутри органа по аттестации.
Напомним, что максимальная длительность работ по аттестации согласно положениям рассматриваемого Порядка не может превышать четырех месяцев.
17. ФСТЭК России (территориальный орган ФСТЭК России) в течение 3 рабочих дней со дня получения от органа по аттестации документов, предусмотренных пунктом 27 настоящего Порядка, вносит сведения об аттестованном объекте информатизации в реестр аттестованных объектов информатизации.
Самое важное новшество: вводится реестровая (централизованная) система учета выданных аттестатов соответствия на ИС. Будет очень хорошо, если этот реестр (выписка из реестра) станет общедоступным, чтобы была возможность проверить наличие и действительность аттестатов соответствия в отношении интересующих объектов информатизации.
18. ФСТЭК России (территориальный орган ФСТЭК России) после внесения сведений об аттестованном объекте информатизации в реестр аттестованных объектов информатизации проводит экспертно-документальную оценку документов, представленных органом по аттестации в соответствии с пунктом 27 настоящего Порядка.
Регулятор не только требует предоставлять документы по аттестованной ИС, но и будет анализировать их на предмет корректности. Очевидно, что это вызвано желанием ФСТЭК России улучшить качество проводимых органами по аттестации испытаний, что не может не радовать.
19. Аттестат соответствия выдается на весь срок эксплуатации объекта информатизации.
Согласно новому Порядку это касается всех типов объектов информатизации – ГИС, ИСПДн, КИИ, АСУ ТП, ЗП, ИСОП. Раньше бессрочный аттестат соответствия был только у ГИС на основании приказа ФСТЭК России от 11 февраля 2021 года № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах». Срок действия аттестатов соответствия других типов объектов информатизации регламентировал ГОСТ РО 0043-003-2021 «Защита информации. Аттестация объектов информатизации. Общие положения», и он составлял не более трех лет.
20. Протоколы контроля защиты информации на аттестованном объекте информатизации не реже одного раза в два года предоставляются владельцем объекта информатизации в ФСТЭК России (территориальный орган ФСТЭК России).
Проводить контроль уровня защиты на аттестованном объекте информатизации будет нужно не реже чем раз в два года. Раньше это требовалось делать ежегодно согласно ГОСТ РО 0043-003-2021 «Защита информации. Аттестация объектов информатизации. Общие положения».
21. В случае развития (модернизации) объекта информатизации, в ходе которого изменена конфигурация (параметры настройки) программных, программно-технических средств и средств защиты информации, исключены программные, программно-технические средства и средства защиты информации, дополнительно включены аналогичных средств или заменены на аналогичные средства проводятся дополнительные аттестационные испытания…
В случае развития (модернизации) объекта информатизации, приводящего к повышению класса защищенности (уровня защищенности, категории значимости) объекта информатизации и (или) к изменению архитектуры системы защиты информации объекта информатизации в части изменения видов и типов программных, программно-технических средств и средств защиты информации, изменения структуры системы защиты информации, состава и мест расположения объекта информации и его компонентов, проводится повторная аттестация…
В явном виде определены критерии, при выполнении которых проводятся дополнительные аттестационные испытания или повторная аттестация. Остается открытым вопрос: требуется ли при проведении повторной аттестации изменять номер и дату выдачи первоначального аттестата соответствия?
22. Действие аттестата соответствия приостанавливается ФСТЭК России (территориальным органом ФСТЭК России) в случае…
Действие аттестата соответствия прекращается ФСТЭК России (территориальным органом ФСТЭК России) в случае…
Регулятор забрал себе полномочия по приостановлению и прекращению действия аттестата соответствия. Раньше они были у органа по аттестации согласно ГОСТ РО 0043-003-2021 «Защита информации. Аттестация объектов информатизации. Общие положения». Хотя в явном виде запрет на приостановление и прекращение действия аттестата соответствия органом по аттестации в Порядке отсутствует, допустимо ли это и каков будет порядок – вопрос пока открытый.
23. В случае утраты аттестата соответствия владелец объекта информатизации вправе обратиться в орган по аттестации с заявлением о выдаче дубликата аттестата соответствия.
Появилась новая возможность – выдача дубликата аттестата соответствия. Из интересного: орган по аттестации не имеет права выдать его копию. По крайней мере, в новом Порядке о таком варианте ничего не говорится. Нужно учитывать, что согласно нормам делопроизводства при выдаче копии документа сохраняются номер и дата выдачи оригинального документа, а вот дубликат документа должен иметь новые реквизиты. Найдет ли этот момент отражение в реестре аттестатов ФСТЭК России – вопрос открытый.
24. Орган по аттестации ежегодно не позднее 1 февраля года, следующего за отчетным, представляет в управление ФСТЭК России по федеральному округу, на территории которого расположен орган по аттестации, сведения об аттестованных им объектах информатизации, содержащие наименование объекта информатизации, адрес места его размещения, наименование владельца объекта информатизации, реквизиты выданного аттестата соответствия.
Еще один из центральных моментов нового Порядка: орган по аттестации будет обязан ежегодно информировать ФСТЭК о проведенных аттестациях. Раньше такой обязанности у него не было (мы не говорим сейчас про аттестационные мероприятия в области государственной тайны). Теперь недобросовестные органы по аттестации не смогут из небытия предъявить аттестаты соответствия на якобы ранее аттестованные ИС. Вероятно, эта норма введена ФСТЭК России, чтобы повысить качество проводимых аттестаций и обеспечить исполнение Постановления Правительства РФ от 6 июля 2021 года № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» в той части, которая касается аттестации.
25. Из Приложения № 1 исключена необходимость указания в техническом паспорте границ контролируемой зоны, линий связи и питания, выходящих за границы контролируемой зоны, а также инвентарных (учетных, серийных) номеров ОТСС и ВТСС, номера лицензий ПО.
Это положение позволяет заменять СВТ на однотипные и обновлять лицензии на ПО без корректировки технического паспорта. Такая норма соотносится с бессрочным сроком действия аттестата соответствия и выполнением необходимых процедур на всех этапах жизненного цикла ИС.
Это нововведение говорит о том, что ФСТЭК не настаивает на обязательном выполнении требований о защите ИС, не обрабатывающих информацию, содержащую сведения, составляющие государственную тайну, от ПЭМИН, что раньше и обуславливало необходимость отображать границы контролируемых зон и проводные линии.
В качестве ретроспективной информации: документ с названием «Технический паспорт» в российских ГОСТах отсутствует, а вот форму и содержание документа с названием «Паспорт» определяет ГОСТ 34.201-89 «Виды, комплектность и обозначения документов при создании автоматизированных систем».
26. Приложение № 4, определяющее форму аттестата соответствия объекта информатизации, вводит фиксированный формат номера аттестата соответствия.
Раньше каждый орган по аттестации сам определял формат номера аттестата соответствия. Текущий формат фиксирует в номере: <номер лицензии ФСТЭК России на деятельность по технической защите информации, выданной органу по аттестации> | <номер аттестованного объекта информатизации в системе учета органа по аттестации> | <год выдачи аттестата соответствия>. Это позволит сделать номер аттестата соответствия достаточно информативным.
Нераскрытой остается неопределенность с <номером аттестованного объекта информатизации в системе учета органа по аттестации> – должен он в обязательном порядке быть сквозным (00001, 00002, 00003) или допускается произвольное, но неповторяемое назначение номеров (00024, 01121, 00001)?
27. Приложение № 4, определяющее форму аттестата соответствия объекта информатизации, при эксплуатации аттестованного объекта информатизации не допускает проводить обработку информации в случае обнаружения инцидента безопасности.
Пока не очень понятно, как реализовать это на практике – например, если инцидентом является компрометация пароля в ИС непрерывного цикла или даже просто попытка его подбора. Также это положение противоречит принципу PDCA и бессрочности аттестатов соответствия.
Будем надеяться, что данное Приложение определяет всего лишь форму (как и указано на его титуле), а не строгое указание по содержанию и данный момент возможно будет исключить из перечня ограничений на эксплуатацию ИС.
Новый Порядок организации и проведения работ по аттестации объектов информатизации, на наш взгляд, будет способствовать обеспечению реальной безопасности ИС. Но при этом в документе есть ряд нераскрытых моментов, а также положений, которые невыполнимы в реальных условиях эксплуатации.
При внесении изменений в нормативные правовые акты мы часто видим в заключении об оценке фактического воздействия НПА, что нововведения «не несут дополнительных финансовых затрат». Это не всегда соответствует действительности. В данном случае можно утверждать, что новые положения предложенного Порядка действительно не несут значительных дополнительных затрат по сравнению с ранее имеющимися требованиями.
Главное, чтобы последующие редакции документа учитывали и исправляли недостатки предыдущих, а сам он использовался как инструмент упорядочивания и улучшения ситуации с аттестацией объектов информатизации, а не наказания и запугивания.
***
В качестве бонуса расскажем, при каких условиях новый Порядок позволит эксплуатировать ГИС даже без аттестата соответствия (пусть и не на постоянной основе).
Существует три случая, при которых возможно запретить (временно или постоянно) эксплуатацию ГИС:
1) вновь созданная ГИС не введена в промышленную эксплуатацию (не проведены успешные аттестационные испытания);
2) действие аттестата соответствия приостановлено;
3) действие аттестата соответствия прекращено.
Первый вариант не рассматриваем – он очевиден и вопросов не вызывает.
А далее, как говорят фокусники, следите за руками.
Пункт 42 гласит: «В случае прекращения действия аттестата соответствия владелец объекта информатизации прекращает эксплуатацию объекта информатизации, если действие аттестата соответствия ранее не было приостановлено».
То есть на этапе прекращения действия аттестата соответствия требование о прекращении эксплуатации объекта информатизации не распространяется на случай, если ранеедействие аттестата соответствия было приостановлено.
А есть ли варианты, при которых можно прийти к вышеописанному состоянию – действие аттестата соответствия было приостановлено – и при этом ГИС находилась бы в эксплуатации на законных основаниях? Давайте посмотрим.
В пункте 37 говорится, что в случае приостановления действия аттестата соответствия владелец объекта информатизации прекращает эксплуатацию объекта информатизации или по согласованию ФСТЭК России принимает меры, исключающие возможность возникновения угроз безопасности информации».
Если на этапе приостановления действия аттестата соответствия ГИС согласовать с ФСТЭК России и принять меры, исключающие возможность возникновения угроз безопасности информации, то даже последующее прекращение действия аттестата соответствия формально не потребует прекращения ее дальнейшей эксплуатации.
Можно предположить, что озвученная возможность связана с необходимостью в ряде случаев продолжать эксплуатацию критичных ИС (например, ИС непрерывного цикла, обеспечивающих критичные функции, или социально значимых систем), даже если в них в определенный момент не соблюдаются все требования безопасности информации.
Не стоит также упускать из виду, что согласно положениям данного Порядка «действие аттестата соответствия может быть приостановлено на срок не более 90 календарных дней».
Осталось получить практику согласования с ФСТЭК России мер, исключающих возможность возникновения угроз безопасности информации, их условия и ограничения. Вполне возможно, что реализовать эти меры будет сложнее, чем «переаттестоваться» заново и лайфхак окажется сугубо теоретическим.
Откуда берутся сертификаты?
Еще совсем недавно было всего 2 способа заполучить X.509 сертификат, но времена меняются и с недавнего времени есть и третий путь.
- Создать свой собственный сертификат и самому же его подписать. Плюсы — это бесплатно, минусы — сертификат будет принят лишь вами и, в лучшем случае, вашей организацией.
- Приобрести сертификат в УЦ. Это будет стоить денег в зависимости от различных его характеристик и возможностей, указанных выше.
- Получить бесплатный сертификат LetsEncrypt, доступны только самые простые DV сертификаты.
Для первого сценария достаточно пары команд и чтобы 2 раза не вставать создадим сертификат с алгоритмом эллиптических кривых. Первым шагом нужно создать закрытый ключ. Считается, что шифрование с алгоритмом эллиптических кривых дает больший выхлоп, если измерять в тактах CPU, либо байтах длины ключа. Поддержка ECC не определена однозначно в TLS < 1.2.
openssl ecparam -name secp521r1 -genkey -param_enc explicit -out private-key.pemДалее, создает CSR — запрос на подписание сертификата.
openssl req -new -sha256 -key private.key -out server.csr -days 730И подписываем.
openssl x509 -req -sha256 -days 365 -in server.csr -signkey private.key -out public.crtРезультат можно посмотреть командой:
openssl x509 -text -noout -in public.crtOpenssl имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:
openssl -help
openssl x509 -help
openssl s_client -helpРовно то же самое можно сделать с помощью java утилиты keytool.
keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048Следует серия вопросов, чтобы было чем запомнить поля owner и issuer
What is your first and last name?
What is the name of your organizational unit?
What is the name of your organization?
What is the name of your City or Locality?
What is the name of your State or Province?
What is the two-letter country code for this unit?
Is CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU correct?Конвертируем связку ключей из проприетарного формата в PKCS12.
keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.jks -deststoretype pkcs12Смотрим на результат:
Alias name: selfsigned
Creation date: 20.01.2021
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Issuer: CN=Johnnie Walker, OU=Unknown, O=Unknown, L=Moscow, ST=Moscow, C=RU
Serial number: 1f170cb9
Valid from: Sat Jan 20 18:33:42 MSK 2021 until: Tue Jan 15 18:33:42 MSK 2021
Certificate fingerprints:
MD5: B3:E9:92:87:13:71:2D:36:60:AD:B5:1F:24:16:51:05
SHA1: 26:08:39:19:31:53:C5:43:1E:ED:2E:78:36:43:54:9B:EA:D4:EF:9A
SHA256: FD:42:C9:6D:F6:2A:F1:A3:BC:24:EA:34:DC:12:02:69:86:39:F1:FC:1B:64:07:FD:E1:02:57:64:D1:55:02:3D
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 30 95 58 E3 9E 76 1D FB 92 44 9D 95 47 94 E4 97 0.X..v...D..G...
0010: C8 1E F1 92 ....
]
]Значению ObjectId: 2.5.29.14 соответствует определение ASN.1, согласно RFC 3280 оно всегда non-critical. Точно так же можно узнать смысл и возможные значения других ObjectId, которые присутствуют в сертификате X.509.
subjectKeyIdentifier EXTENSION ::= {
SYNTAX SubjectKeyIdentifier
IDENTIFIED BY id-ce-subjectKeyIdentifier
}
SubjectKeyIdentifier ::= KeyIdentifierСпециальная настройка промежуточных и выдающих ca
На начальном этапе настройки для промежуточного CA (SUBCA) и выдающего CA (ISSUING) действия совпадают с настройкой корневого CA. Первое отличие заключается в том, что при выборе типа CA указывается Stand-alone subordinate (отдельный подчиненный) и Enterprise subordinate (корпоративный подчиненный) соответственно.
Поскольку промежуточный CA не будет подключен к локальной сети, добавление корневого сертификата в системное хранилище сертификатов необходимо будет выполнить вручную. Копию корневого сертификата можно скопировать через флэш-накопитель с одного из AIA (ISSINGCertEnroll или ROOTCA CertConfig).
Откройте оснастку Certificates и выберите режим управления сертификатами для локального компьютера. Раскройте дерево контейнера так, чтобы можно было добраться до контейнера Certificates, вложенного в Trusted Root Certification Authorities. Щелкните правой кнопкой мыши на контейнере Certificates и выберите в контекстном меню All Tasks пункт Import.
Для подчиненных и выдающих CA необходимо будет сформировать запрос на сертификацию, который будет обрабатываться родительским CA. После копирования установочных файлов на сервер мастер выдает на экран страницу запроса сертификата CA Certificate Request Page, приведенную на экране 3.
Поскольку корневой и подчиненный CA в нашем случае отключены от локальной сети, передать запрос непосредственно на CA невозможно, так что следует выбрать сохранение запроса в файл Save the request to a file и ввести имя файла на флэш-накопителе. Мастер сохранит запрос в текстовом файле. Для завершения настройки серверов SUBCA и ISSUING нужно выполнить следующие шаги:
- Вставить флэш-накопитель в сервер CA родительского уровня. С помощью утилиты Certreq (Certificate Request), расположенной в папке system32, передать запрос сертификации на CA. Запустить командный интерпретатор cmd.exe и, в зависимости от уровня CA, выполнить одну из приведенных ниже команд. Для SUBCA:
CERTREQ -config "ROOTCAHP Root CA" a:SubCA.req
Для ISSUING выполните
CERTREQ -config "SUBCAHP Subordinate CA" a:IssueCA.reqключ -config указывает утилите, CA какого уровня следует использовать. Имя слева от обратной косой черты указывает имя сервера, а справа – имя CA. После выполнения команд будет выдан идентификатор запроса (Request ID number), который следует сохранить (запомнить).
- Открыть оснастку Certificate Authority на CA родительского уровня. В ней будут представлены четыре контейнера: отозванные сертификаты Revoked Certificates, выданные сертификаты Issued Certificates, отложенные запросы Pending Requests и отвергнутые запросы Failed Requests. Выберите контейнер отложенных запросов Pending Request – в нем вы увидите запрос, сформированный CERTREQ. Если было сформировано несколько запросов, то для определения нужного запроса следует воспользоваться сохраненным значением, определенным в пункте 1. Щелкните правой кнопкой мыши на запросе и в меню Tasks выберите Issue, после чего закройте MMC.
- Запустить командный интерпретатор cmd.exe и, в зависимости от уровня CA, выполнить одну из приведенных ниже команд. Для SUBCA:
CERTREQ -retrieve -config "ROOTCAHP Root CA" 2
a:SubCA.crt a:chain.p7bДля ISSUING, введите
CERTREQ -retrieve -config "SUBCAHP Subordinate CA"
4 a:SubCA.crt a:chain.p7bКлюч -retrieve сообщает утилите о необходимости загрузить и сохранить выданный сертификат с информацией о цепочке сертификации в файлы. В приведенном выше примере номера запросов, сохраненные из пункта 1, – это 2 и 4. После номеров запроса указываются имена файлов – файл, в котором будет сохранен сертификат, и файл для сохранения информации о цепочке сертификации. Для файлов сертификатов необходимо использовать расширение .crt, а для цепочек сертификации – .p7b. Для завершения сертификации перенесите эти файлы на CA.
- Запустить оснастку Certificate Authority, щелкнуть Tools, выбрать Install CA Sertificate и в диалоговом окне открыть сохраненный на флэш-накопителе файл chain.p7b. Поскольку сервер SUBCA отключен от локальной сети, попытка проверки файла CRL будет неудачной, при этом система выдаст запрос на продолжение сертификации. Нажмите OK. Теперь в иерархии Certificate Authority появится красный флажок вместо красной точки.
Установка выдающего CA завершена. При установке промежуточного CA придется выполнить почти те же самые действия, что и для корневого CA. Потребуется отредактировать реестр для настройки срока действия сертификата, скопировать CRL и сертификат в папку общего доступа CertEnroll и обновить адреса CDP и AIA таким образом, чтобы они указывали на доступный Web-сервер и AD для доступа к этим ресурсам.
Эти шаги совпадают с теми, которые были выполнены для специальной настройки корневого CA. Просто необходимо заменить информацию о промежуточном CA информацией о корневом CA. Теперь иерархия CA полностью сформирована и можно начинать обработку запросов сертификации.
Я надеюсь, что эта статья поможет читателям разобраться с вопросами реализации простой иерархии CA, которая может использоваться, например, для организации цифровой подписи электронной почты. Формирование собственного центра сертификации — это нетривиальная задача.
Необходимо разобраться, каким образом устанавливаются службы CA, применяемые для генерации цифровых сертификатов, а также наборов политик и процедур, управляющих использованием технологии CA в организации. Необходимо изучить отношения между СА, сами сертификаты, назначение инструментов, таких как CRL и CDP, и можно начинать формировать и эксплуатировать собственный CA.