![](https://habrastorage.org/getpro/habr/post_images/0ef/3d7/29c/0ef3d729c666322a9743d7281670983d.jpg)
Рассказываем, как мы внедрили в дата-центре систему электронной регистрации посещений с биометрическими технологиями: зачем она понадобилась, почему мы снова разрабатывали собственное решение и какие преимущества получили.
Вход и выход
Доступ посетителей в коммерческий ЦОД – важный момент организации работы объекта. Политика безопасности дата-центра требует точного учета посещений и отслеживания динамики.
Несколько лет назад мы в Linxdatacenter решили перевести полностью в цифровой вид всю статистику посещений нашего ЦОДа в Санкт-Петербурге. Мы отказались от традиционной регистрации доступа – а именно от заполнения журнала посещений, ведения бумажного архива и предъявления документов при каждом визите.
Наши технические специалисты за 4 месяца разработали систему электронной регистрации посещений в сочетании с биометрическими технологиями контроля доступа. Основной задачей было создать современный инструмент, отвечающий нашим требованиям безопасности и в то же время удобный для посетителей.
Система обеспечила полную прозрачность картины визитов в ЦОД. Кто, когда и куда получал доступ в дата-центр, включая серверные стойки, – вся эта информация стала доступна мгновенно по запросу. Статистика посещения выгружается из системы в несколько кликов – отчеты для клиентов и аудиторов сертифицирующих организаций стало готовить куда проще.
Отправная точка
На первом этапе было разработано решение, которое позволило вносить все необходимые данные на планшете при входе в ЦОД.
Авторизация происходила путем ввода персональных данных посетителя. Далее планшет обменивался данными с компьютером на посту охраны по выделенному защищенному каналу связи. После чего выписывался пропуск.
Система учитывала два основных типа запроса: заявка на временный доступ (однократное посещение) и заявка на постоянный доступ. Организационные процедуры для этих типов заявок в ЦОД существенно отличаются:
- В заявке на временный доступ указывается имя и компания посетителя, а также контактное лицо, которое должно сопровождать его на протяжении всего визита в ЦОД.
- Постоянный доступ позволяет посетителю самостоятельно перемещаться внутри ЦОДа (например, это важно для специалистов заказчиков, которые регулярно приезжают для работы с оборудованием в дата-центре). Такой уровень доступа требует от человека прохождения вводного инструктажа по охране труда и подписания с Linxdatacenter соглашения о передаче персональных и биометрических данных (скан отпечатка пальца, фотография), а также подразумевает получение всего необходимого пакета документов о правилах работы в ЦОДе на электронную почту.
При оформлении постоянного доступа необходимость в дальнейшем каждый раз заполнять заявку и подтверждать личность документами полностью отпадает, достаточно приложить палец для авторизации на входе.
![](https://habrastorage.org/getpro/habr/post_images/fe1/cba/b3f/fe1cbab3f5d29cbb1ef21869665aa702.jpg)
Перемен!
Платформа, на которой мы развернули первую версию системы, – это конструктор Jotform. Решение используется для создания опросов, мы самостоятельно дорабатывали его под систему регистрации.
Однако со временем в процессе эксплуатации выявились некоторые «узкие места» и точки для дальнейшего развития решения.
Первая сложность – Jotform не был «допилен» под формат планшета, и формы для заполнения после перезагрузки страницы часто «плыли» по размерам, выходя за пределы экрана, или наоборот, сворачивлись. Это создавало массу неудобств при регистрации.
Не было и мобильного приложения, приходилось разворачивать интерфейс системы на планшете в формате «киоска». Однако это ограничение сыграло на руку – в режиме «киоска» приложение нельзя свернуть или закрыть на планшете без допуска уровня «Администратор», что и позволило нам использовать обычный пользовательский планшет как терминал регистрации для доступа в ЦОД.
В процессе тестирования начали всплывать множественные баги. Многочисленные апдейты платформы приводили к зависаниям и сбоям решения. Особенно часто это происходило в моменты, когда апдейты охватывали те модули, на которых была развернута функциональность нашего механизма регистрации. Например, заполненные посетителями анкеты не отправлялись на пункт охраны, терялись и т.д.
Бесперебойная работа системы регистрации крайне важна, поскольку сервисом ежедневно пользуются и сотрудники, и клиенты. А на периоды «зависания» весь процесс приходилось возвращать в 100% бумажный формат, что было недопустимым архаизмом, приводило к ошибкам и в целом выглядело как огромный шаг назад.
В какой-то момент Jotform выпустил мобильную версию, но этот апгрейд не решал всех наших задач. Так, нам приходилось «скрещивать» одни формы с другими между собой, например, для задач обучения и вводного инструктажа по принципу теста.
Даже при использовании платной версии требовалась дополнительная расширенная лицензия уровня Pro для всех наших задач по допуску. Итоговое соотношение «цена/качество» оказалось далеким от оптимального – мы получали дорогостоящую избыточную функциональность, которая все равно требовала значительных доработок с нашей стороны.
Версия 2.0, или «Сделай сам»
Проанализировав ситуацию, мы пришли к выводу, что самый простой и надежный выход – создать собственное решение и перенести функциональную часть системы на виртуальную машину в собственном облаке.
Мы сами написали софт для форм на React, развернули все это, используя Kubernetes, в продуктиве на своих мощностях и получили в итоге собственную, независимую от сторонних разработчиков систему регистрации доступа в ЦОД.
![](https://habrastorage.org/webt/ft/4m/pz/ft4mpzfe4dpvhp-re0nsvbrz76w.png)
В новой версии мы доработали форму для удобного оформления постоянных пропусков. При заполнении формы на доступ в ЦОД клиент может перейти в другое приложение, пройти экспресс-обучение по правилам нахождения в ЦОД и тестирование, а затем вернуться обратно «в периметр» формы на планшете и завершить регистрацию. Причем сам посетитель этого перемещения между приложениями не замечает!
Проект реализовали достаточно оперативно: создание базовой формы для допуска в ЦОД и ее развертывание в продуктивной среде заняли всего месяц. С момента запуска и до сегодняшнего дня мы не зарегистрировали ни одного сбоя и тем более «падения» системы, и спаслись от мелких неприятностей вроде несовпадения интерфейса с размерами экрана.
Вжух – и готово
В течение месяца после развертывания мы перенесли на собственную платформу все нужные нам в работе формы:
- Доступ в ЦОД,
- Заявка на производство работ,
- Вводный инструктаж.
![](https://habrastorage.org/webt/sp/9s/gs/sp9sgs2oopd6alnugiqbkisgak8.png)
Так выглядит форма для заявки на производство работ в дата-центре.
Система развернута в нашем облаке в Санкт-Петербурге. Мы полностью контролируем работу ВМ, все ИТ-ресурсы зарезервированы, и это дает нам уверенность, что система не сломается и не потеряет данные при любых сценариях.
Софт для системы развернут в Docker-контейнере в собственном репозитории дата-центра – это значительно упрощает настройку системы при добавлении новых функций, редактировании уже существующих возможностей, а также в перспективе сделает более легким обновление, масштабирование и т.д.
Система требует минимального объема ИТ-ресурсов ЦОДа, при этом полностью отвечает нашим требованиям в плане функциональности и надежности.
Что сейчас и что дальше?
В целом процедура допуска осталась прежней: заполняется электронная форма заявки, далее данные посетителей «улетают» на пост охраны (ФИО, компания, должность, цель визита, сопровождающее лицо в ЦОДе и т.д.), происходит сверка со списками и принимается решение о допуске.
![](https://habrastorage.org/webt/4k/z9/2b/4kz92b6fdj733m-larrlxanpnlo.png)
![](https://habrastorage.org/webt/hn/bf/ka/hnbfkajxuxfuwwzok7rvqzcdsla.png)
Что еще может система? Любые задачи по аналитике в исторической перспективе, а также мониторинг. Некоторые клиенты запрашивают отчеты для внутренних целей контроля персонала. Мы с помощью данной системы отслеживаем периоды максимальной посещаемости, что позволяет нам более эффективно планировать работы в ЦОДе.
В планах на будущее – перевод в систему всех существующих чек-листов – например, процесса подготовки новой стойки. В дата-центре есть регламентированная последовательность шагов по подготовке стойки для клиента. Подробно расписывается, что именно и в каком порядке нужно сделать перед запуском – требования по электропитанию, сколько ПДУ и патч-панелей для коммутации подвести, какие заглушки снять, устанавливать ли СКУД, видеонаблюдение и т.д. Сейчас все это реализуется в рамках бумажного документооборота и частично на электронной платформе, но процессы компании уже созрели для полной миграции сопровождения и контроля таких задач в цифровой формат и веб-интерфейс.
В этом направлении и будет развиваться далее наше решение, охватывая новые бэк-офис процессы и задачи.