Comments 29
В статье рассматривается уведомления от файлов сертификатов, расположенных в общей папке, в то же время мне видится логичным использовать скрипты на самих машинах, потому что вот прям обязать получивших сертификаты ими сразу делиться с некой "службой централизованного хранения" в виде техпода или кого еще видится малореализуемой. Другими словами: наверняка можно сделать всё тоже самое, но для локального компьютера с пользовательскими же сертификатами? В этом случае каким бы образом сертификат не попал на компьютер, уведомления кому надо придут. Да, уведомления тогда надо вывести на какой-то сервер для защиты бота, но это, кмк, не сильно сложно.
Ну тут видите, опять же... у всех по-разному. В моей практике, во всех организациях, в которых я находился - сертификаты пользователей всегда проходили через безопасников. Потому что и в ЭДО их нужно передать, и в какой-нибудь ЕИС загрузить, и куча-куча разных примеров, почему сертификат всегда будет у ИБшника. Так что у меня это как раз наоборот - не бывает такого, что пользователь сам себе сделал ключики, сам установил их себе, во все ИС и так далее. Но, опять же, допускаю, что где-то и так, как вы говорите.
И тут конечно проще складывать сертификаты в общее хранилище, чем на каждый компьютер распространять скрипт... иначе ещё нужно будет продумать, откуда он будет читать сертификаты. Единственное, что мне видится, это из хранилища сертификатов в реестре и тогда нужно, чтобы пользак обязательно его туда положил, и периодически чистил оттуда старые, иначе уведомлений будет масса, скажем, если у вас 100 компьютеров пользователей, и у каждого в хранилище будут ещё и старые сертификаты - придётся просить их вычищать всё или самому бегать...
Ну и самый главный вопрос - нужно будет передать данные от компьютера пользователя на сервер, на котором будет скрипт с уведомлениями от бота (чтобы не слить ID бота на пользовательские компы) - тут можем получить узкое место в виде самой сети и небольшой минус в виде нужды в сервере - хотя это минусы маленькие и некритичные, но...
В итоге возвращаемся к тому, что у каждого своя специфика, поэтому я и выложил код, который можно уже под свои нужды подрихтавать =)
Вполне обычная ситуация. Как вы знаете, сейчас всем подряд не выпускают КСКПЭП на юриков. Поэтому у нас примерно 30 процентов сотрудников самостоятельно выпускали себе КСКПЭП. Просто их потом присоединяли к организации в ЛК Госуслуг со своими сертификатами и необходимыми правами.
Соглашусь с вами, но опять же, несколько оговорок. Тут многое зависит от позиции руководства компании. Если сотрудники должны получить сертификат для того, чтобы выполнять рабочие обязанности, они могут "наныть" :), о том, что они некомпетентны в этом вопросе и им должны поспособствовать в отделе ИБ. Ну и управления фед. казначейства до сих пор выдают сертификаты на должностных лиц (для всех бюджетных организаций), так что тут тоже всё через ИБ. Или даже если сами, то установить и настроить систему для работы с ключами, на моей практике, почти никто сам не может
В целом, похожий опыт можно получить с Uptime Kuma, но, конечно, не для КСКПЭП — по крайней мере, не из коробки. У него есть обширный API, так что, думаю, даже это можно реализовать на его базе. Всё основное там уже есть, включая уведомления в множество сервисов.
Всё прекрасно, но есть одна неточность. Вы постоянно пишете про срок действия сертификата, а имеете ввиду срок действия ключа. Это две разные вещи. И они задаются при создании ключа, или при сертификации ключа.
Чаще всего срок действия ключа устанавливают равным 15 месяцам, реже - 3 года, ещё реже другие сроки. А срок действия сертификата этого же ключа обычно от 10 до 15 лет. И пользователь может пользоваться своим ключом в течение срока действия КЛЮЧА. Дольше уже нет. Срок действия сертификата используется не для этого.
Спасибо за уточнение! Крепко подумаю над ним, дополнительно почитаю информацию
Или, буду признателен, если у вас есть ссылка на литературу по данному вопросу
Это частая неточность в терминологии. И даже люди, которые считают, что могут писать разъясняющие статьи, сильно путаются. Ради интереса решила поискать ответ на такой вопрос: "что такое срок действия ключа и сертификата". Первая же ссылка ведёт на такую путаницу в терминах, что разобраться действительно невозможно. Путают сертификат, ключ и подпись по тексту. Самое грамотное объяснение нашлось на официальном сайте Центробанка в разделе АУЦ. Там и термины есть, и пояснение, что это за звери такие, и даже зачем они нужны и для чего используются.
Ну, или надо читать учебники по СКЗИ. Но статьи в интернете - с большой осторожностью.
Да на первых же страницах эксплуатационной документации к СКЗИ (например, КриптоПро CSP) всё прекрасно раскрыто
В личном диалоге с пользователем Ada_VV мне так и не удалось выяснить, где конкретно (документ, страница, ссылка) говорится о том, что в сертификате, в поле NotAfter указывается не срок действия сертификата, а срок действия открытого ключа. И что срок действия сертификата, на самом деле - от 10 до 15 лет (где его можно посмотреть? 63-Федеральный закон об электронной подписи запрещает выпускать КСКПЭП сроком более 15 месяцев. Для проверки валидности ЭП с большим сроком давности должен использоваться специально разработанный для этого протокол TSP).
В документе ЖТЯИ.00101-01 95 01-ЛУ КриптоПро CSP Версия 5.0 КС1 1-Base Правила пользования в разделе 3.6 перечислены максимальные сроки, которые назначаются ключам. Но мы проверяем конкретные поля в сертификате, а за поля сертификата ответственен 795 приказ ФСБ, и как раз там говорится следующее:
Поле validity имеет тип Validity и содержит даты начала и окончания действия квалифицированного сертификата. Тип Validity описывается следующим образом: ... notAfter Time } ...
То есть дата, которую считывает мой скрипт - это именно дата окончания действия сертификата.
Всё прекрасно, но есть одна неточность. Вы постоянно пишете про срок действия сертификата, а имеете ввиду срок действия ключа.
Именно срок действия сертификата я и пытаюсь отследить.
С 1 сентября 2024 года в 795 приказ ФСБ вступила в силу поправка о том, что теперь в сертификате должна указываться дата окончания (и начала действия) соответствующего ему закрытого ключа (не открытого!). Эта дата включается через новое некритическое поле privateKeyUsagePeriod
Дополнение privateKeyUsagePeriod определяет срок действия ключа ЭП, соответствующего уникальному ключу проверки ЭП, содержащемуся в данном квалифицированном сертификате.
Мой скрипт НЕ считывает срок закрытого ключа (и в тексте статьи к этому нет никаких противоречий, потому что цели такой не было), но не исключаю, что я допишу скрипт, чтобы по условию наличия этого поля он сообщал и о сроке закрытого ключа. Но пока не вижу явных противоречий и неточностей
Поле Validity сертификата означает именно срок действия сертификата, о чем ясно сказано в RFC .
Какие-то дополнительные "сроки действия" (ключа или чего-либо иного) вполне могут определяться регламентами выпуска каких-то конкретных сертификатов и указываться в дополнительных полях, но с общепринятой терминологией автор обращается совершенно правильно.
Вы рассказываете о некотором количестве серверов под своим контролем. Вы все важные показатели мониторите подобными самописными скриптами? Не задумывались о централизованной системе мониторинга?
Но скрипт ведь мониторит не только TLS сертификаты для серверов. Так-то строго говоря можно и под SIEM написать плагин. Замес статьи-то про дефолтные возможности винды, без дополнительных серверов и сервисов
Как вариант, если раскиданы по инфраструктуре Zabbix-агенты переделать скрипт, чтобы он "сканировал" на предмет нахождения всех сертификатов на хосте. А потом это всё свести в красивый дашборд.
Ну конкретно в моём кейсе такое вряд ли будет удобнее чем то, что есть сейчас. Во-первых, я так понимаю, нужно будет на каждую тачку скрипт раскидать? Что для меня уже не очень... вместо того, чтобы скрипт работал на одной тачке - кидать его на всю инфраструктуру. Во-вторых, а если сотрудник в отпуске/на больничном и его компьютер продолжительно время в отключке - результатов от скрипта не будет? Или что-то со скриптом произошло на конкретной машине/машинах, а ты будешь думать, что там просто сертификаты не истекают. Проще уж на одной машине скрипт контролировать, чем на всём парке. В-третьих, бывают очень часто ситуации, что один ключик используется на разных машинах. В таком случае, с каждой машины об одном и том же сертификате (в случае его истечения) будет валиться спам из однотипных уведомлений с разных машин.
Ну, в общем, не знаю... мне вряд ли подойдёт этот способ, но если для вас этот способ лучше - попробуйте переписать скрипт для Zabbix и поделитесь результатами работы, я буду рад почитать)
А передавать данные в эту систему мониторинга будет тот же самый скрипт, поскольку "из коробки" всё многообразие сертификатов в организации никакая система мониторить не сможет.
(вспоминая довольно многочисленные статьи про мониторинг этих самых сроков)
Мне одному кажется, что правильный способ - это при генерации закидывать дату в какой-нибудь календарь, с которым уже и интегрируются все нужные оповещалки через то, чего душа просит? Да даже и про мониторинге - смысл напрямую в транспорт доставки оповещений лезть?
Я путём календаря с самого начала хотел пойти... потом понял, что это дополнительное место ошибки, когда можно в вихре рабочего потока случайно записать сертификат не на ту дату и никогда больше не узнать о его окончании. Решил отдать это на откуп скрипта, пусть сам считывает поле даты, а я в это не лезу)
Но вообще да, вариантов масса, я же в статье говорил. У каждого свои желания, возможности. Мне подходит мой вариант, но все вольны сделать так, как больше подходит им :)
есть RFC, но по факту кто во что горазд, даже с тем же CN, в который запрещено писать адрес домена, если этот домен записывается в SAN
Смотрите, был стандарт: fqdn писать в CN. Потом появился упомянутый вами RFC. В итоге старый софт опирается на CN. Новый софт, следующий RFC, должен брать fqdn из SAN. Чтобы обеспечить совместимость сервера со старым и новым ПО fqdn из CN нужно продублировать в SAN. То, что софт должен читать только одно из двух полей, совершенно не говорит, что нельзя записывать в серт оба поля.
Есть новый софт от Kaspersky, для которого я выпускал очередные ключи и сделал это как полагается, через SAN, не указывая FQDN в поле CN (мы ведь уже достаточно давно его не должны там указывать, а на дворе был 2024 год). Продукт отказался съедать сертификат, пока он не увидит адрес домена в CN.
Зачем/почему?
Как поведёт себя ваш скрипт, если в пути окажется $ (например, скрытая шара) или год будет в квадратных скобках?
На счёт скрытой шары немного не понял. Если у вашего ПК (на котором работает скрипт) есть сетевая доступность до ресурса, будь он скрытым (скрытым где? В проводнике? Это лишь атрибут проводника), вы всё равно имеете к нему доступ и можете попасть напрямую, указав полный путь в адресной строке, например. Но не уверен, что вы именно это имели ввиду в вопросе.
На счёт года в скобках... - год чего? Дни до истечения сертификата отправляются в телегу в днях, скобки там отлично работают.
Если скобки, вы имеете ввиду, будут в дате окончания сертификата, то они там не будут, потому что поле NotAfter не допускает наличия скобок в сертификате, а мы читаем именно это поле. Но, если бы была такая проблема, я бы сначала привёл два формата даты к какому-то единому, а потом уже сравнивал их между собой и вычислял результат. В общем, как в математике :)
Если в Windows в конце имени расшаренной папки указать $, то она не будет отображаться в сетевом окружении и попасть туда можно только зная её имя (ну не совсем :) Это имелось в виду.
Аа, это те ресурсы, которые по умолчанию расшарены и в управлении компьютером перечислены.
Ну тут мой ответ принципиально не меняется. Мы ведь не через сетевое окружение в него попадаем, а через Set-Location \\localhost\C$ в PowerShell. Попробуйте зайти - зайдёт ведь?)
Да, конкретно со скрытой шарой проблем нет ($ в конце строки или перед \). Проблемы появляются, если доллар в средине имени. Что, конечно, гораздо более редкая ситуация.
Если встречается такой нестандартный случай и нет варианта переименовать директорию, то можно использовать знак ` перед спецсимволом в середине названия, например вот так переходит: Set-Location "C:\contr`$tryke"
Отслеживание сроков действия сертификатов безопасности (TLS, КСКПЭП) с помощью PowerShell