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

Эти сертификаты имеют срок годности, они выпускаются не на 100 лет (технически это возможно, но по понятным причинам вариант не пользуется популярностью), а обычно на год. И частенько они просрочиваются — срок сертификата подходит к концу, об этом забывают и пропускают его смену, что приводит к потере денег или времени. Боль, на самом деле, повсеместная, и немногие пытаются успешно с ней бороться. У нас это получилось, и мы хотим поведать вам о нашем пути, который еще не закончен.

Как мы работали до внедрения единой системы управления сертификатами 

У нас в QIWI была похожая боль. Весь обмен с партнерами ведется с использованием сертификатов, а ещё есть сертификаты для связи с ЦБ и другими организациями (Госуслугами, и так далее), соответственно, этих сертификатов очень много, за ними надо следить. Сейчас в нашей системе их более 16500.

Раньше каждый продукт и каждая команда сами пытались следить за своими сертификатами в формате «Кто во что горазд», поэтому иногда эти сертификаты просто-напросто протухали, и никто этого не замечал. В итоге мы не могли нормально взаимодействовать с нашими партнерами до момента замены сертификата. А чтобы его выпустить - приходилось “попрыгать”, причем иногда достаточно долго. :-( . 

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

Начали мы со своей собственной разработки: сделали приложение с базой данных, которая хранила информацию о сертификатах, принимала её из разных источников, в которых у нас лежат сертификаты, агрегировала всё. А затем позволяла ставить какие‑то триггеры и оповещения — писать в трекер задач, в ту же Jira, чтобы об этих сертификатах вовремя вспоминали и производили их замену. Первая версия системы была написана достаточно быстро и не отличалась большой гибкостью в плане настроек эскалации и обработки данных по сертификатам. Многие настройки были зашиты в коде самой системы, и для их изменения и добавления приходилось отвлекать разработку. Соответственно, с системой было не очень удобно работать, но как первый шаг она была очень хороша.

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

Как мы думали, наверняка проблема с сертификатами есть не только у нас, и кто‑то уже писал подобное в виде коробочного решения.

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

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

В итоге мы нашли такое решение.

Что у нас сейчас

Выбрали мы систему CMDBuild. Это open‑source система — конструктор, который позволяет нам создать свою базу для учета любых активов. Все это дело при желании и необходимости кастомизируется и настраивается достаточно легко, наши специалисты очень быстро разобрались и приступили к донастройке коробочного решения.

В итоге мы перевезли из старого приложения сертификаты, настройки эскалации и механизмы обработки информации о сертификатах в CMDB. Также мы реализовали дополнительный сервис — CMDB‑интегратор, написан у нас в компании как дополнение к cmdb. Он производит обработку данных, входящих и хранящихся в CMDB, и на основе этих данных осуществляет процессы эскалации. Ещё в его задачи входит предоставление API для загрузки данных о сертификатах из источников и их обработка.

Вот как всё выглядит с точки зрения архитектуры:

1. CMDB является хранилищем, причем хранилищем как сертификатов, так и настроек;

2. CMDB‑интегратор на основе этих настроек всю информацию обрабатывает.

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

Делать она это может различными методами, например, мы можем совершенно спокойно отправлять уведомления нашим партнерам о том, что у них сертификат помирает, причем можно настроить письмо как в плане отправки по времени (например, автоматом рассылать за N дней до окончания срока действия сертификата), так и в плане контента — в письмо можно подставлять любые данные из текущего сертификата и любой текст.

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

Эскалация в тикеты, кстати, тоже полностью настраиваемая, можно настроить:

• тип тикета,

• проект,

• текст, который прилетит в тикет.

Система также умеет подтягивать информацию по клиенту из внутренней CRM‑системы компании, так как данные по сертификату мы получаем не совсем полные, знаем лишь, что это за сертификат, но не всегда понимаем, к какому партнеру он относится. Система по данным внутри сертификата может обратиться в CRM и получить оттуда информацию о партнере, которому принадлежит этот сертификат. Это дало нам возможность выдавать в тикетах более полную информацию. То есть подразделениям, которые обрабатывают смену сертификата, не надо залезать в основной процессинг или в CRM‑систему и искать партнера, к которому надо постучаться, чтобы он выпустил новый сертификат — вся информация уже есть в тикете.

Информация по сертификату в CMDB:

Тикет на смену сертификата:

Сертификаты в большинстве своем у нас лежат на серверах в хранилищах сертификатов. Так что наши специалисты написали скрипты и приложения, которые собирают все эти сертификаты из мест хранения и отправляют к нам. На момент написания поста у нас более 16 500 сертификатов в базе.

Что получили и что дальше

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

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

Теперь у нас все очень хорошо. После введения этой системы мы получили очень приятную статистику:число каких‑то внезапных замен, когда нам нужно обновить сертификат в течение суток, сократилось до пары раз в год. Но это, скорее не проблема того, что сервис плохо отработал, а проблема любой большой компании — не всегда удается донести информацию до всех. Но мы работаем и в этом направлении и проводим регулярные активности по рекламе нашего сервиса внутри QIWI.

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

Но, как вы понимаете, сделать только систему — это лишь половина пути. И, соответственно, мы сделали еще и процесс, который позволяет нам вовремя производить смены сертификатов:

1. Первичная эскалация идет в подразделения, которые занимаются сменой этого сертификата.

2. Для контроля, чтобы что‑то не повисло, по каждому типу сертификатов за 5 дней ставится тикет в дежурную смену вида «Ребята, что‑то здесь не так, если этот тикет по смене сертификата еще не закрыт». Мы это делаем для того, чтобы дежурная смена потрясла нужное подразделение и подтолкнула его к тому, чтобы быстрее сменить сертификат.

3. Еще 2–3 дня идет эскалация в руководство подразделений, которые занимаются сменой сертификатов.

4. Мне как менеджеру изменений подсвечивается, что у нас сертификат скоро просрочится, а по нему какое‑то затишье. Не к добру это. Здесь идет более ощутимая пропинговка с нашей стороны, чтобы этот сертификат сменили.

Последний пункт уже стал редкостью, но иногда всё же бывает.

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

В ближайшем будущем мы хотим сделать интерфейс для загрузки сертификатов (интерфейс cmdb слишком перегружен). Сейчас это все уже есть в виде API, и если ребятам надо загружать сертификаты, то они делают либо какое‑то приложение, либо какой‑то скрипт, который нам грузит это. А хочется сделать интерфейс, чтобы человек мог просто руками набрать минимум информации и отправить ее нам. Ну и, конечно, хочется затащить как можно больше сертификатов в эту систему, и чтобы об этой системе знала вся компания. Но это — уже всего лишь вопрос времени :)