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

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

Исторически так сложилось, что в подавляющем большинстве компаний процесс управления физическим и логическим доступом лежит в руках разных служб. Если физическим доступом управляет, как правило, служба безопасности (СБ) в ее классическом понимании, то за логический доступ отвечает либо служба ИТ, либо, если таковая существует, то служба ИБ. До определенной поры такое разделение полномочий выглядело нормальным и не вызывало никаких сложностей в плане управления. Но, как мы все знаем, развитие технологий не стоит на месте и целесообразность разделения полномочий таким классическим способом оказалась под вопросом.

Предпосылки

Важнейшей предпосылкой к пересмотру классической системы управления доступом послужила двухфакторная аутентификация. Именно благодаря ее победоносному шествию по корпоративному сегменту рынка многие начали задумываться о пересмотре сфер ответственности службы безопасности и ИТ/ИБ. И дело тут было даже не в технологии, а в самих пользователях. В классическом примере реализации системы управления доступом, все сотрудники компании имели по одной уникальной именной карточке с RFID-меткой, которая позволяла им проходить на территорию компании, в различные корпуса и кабинеты. Этот процесс быстро прижился во всех компаниях среднего и крупного сегмента бизнеса и воспринимался как неотъемлемый и обязательный атрибут бизнес-процесса. Но по факту, этот процесс представлял из себя исключительно контроль физического доступа. С развитием же технологии двухфакторной аутентификации, многие компании стали внедрять у себя усиленную аутентификацию при логическом доступе (доступ к информационным системам с использованием токенов или смарт-карт). И вот тут-то свое слово сказали сами пользователи. Увеличения числа обязательных к ношению на работу идентификаторов с одного до двух вызвало определенные проблемы, начиная с увеличения забываемости и утраты, заканчивая банальным неудобством. Стало очевидно, что подобная система не достаточно эффективна.

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

Пересмотр сфер ответственности

Но давайте вернемся к разделению сфер ответственности служб СБ и ИТ/ИБ. С того момента как стало возможно объединение идентификаторов для физического и логического доступа на одном носителе, все чаще начали говорить и об изменении центра ответственности за этот носитель. И в данном вопросе все большее количество мнений склонялось к тому, что целесообразнее всего передать процесс обслуживания и управления жизненным циклом этого носителя в службу ИТ/ИБ. Ведь процесс управления логическим доступом к информационным ресурсам, которым итак занимается служба ИТ/ИБ, на несколько порядков сложнее, нежели процесс управления физическим доступом. Да и СБ просто напросто не обладает необходимыми компетенциями по управлению логическим доступом, тогда как для ИТ/ИБ включение в этот процесс еще и системы физической СКУД (системы контроля и управления доступом) не что иное, как подключение очередного информационного ресурса и раздача определенных прав внутри него.

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

Падение барьеров

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

Первый реальный прорыв в вопросе совмещения систем контроля физического и логического доступа совершили, пожалуй, решения класса IDM (Identity Management). Изначально, идея создания таких решений базировалась на необходимости унификации политик предоставления доступа к различным информационным ресурсам, и на облегчение процесса администрирования учетных записей. Эти системы стали хорошим подспорьем для служб ИТ/ИБ крупных предприятий, где временные издержки на управление доступом к информационным ресурсам очень велики. На заре своего появления и развития в область действия IDM-систем не попадали системы СКУД. Но время не стоит на месте, и как только начал вырисовывать реальный спрос на интеграцию систем СКУД с корпоративными IDM-решениями, так сразу многие производители таких решений начали обозначать такую возможность.

Реализация

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

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

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

Первой в России компанией-разработчиком IDM-решения, которая стала активно продвигать идею совмещения физического и логического доступа, стала компания Avanpost. В начале 2013 года был успешно реализован первый пилотный проект по данной тематике, в результате которого стало очевидно, что подобное совмещение не просто удобно, оно еще и существенно снижает временные издержки и повышает эффективность процесса управления доступом.

Сама реализация этого совмещения, с точки зрения IDM-системы выглядит достаточно стандартно и ничем не отличается от интеграции с, например, какой-нибудь CRM-системой. Ведь IDM управляет всеми целевыми системами посредством коннекторов к ним, не стала исключением и система СКУД. После интеграции в IDM-системе появились дополнительные бизнес-роли для системы СКУД, которые автоматически назначались сотрудникам на основании ролевой модели. Это позволило централизовать процесс выдачи сотрудникам универсальных карт, в результате которого служба ИТ/ИБ самостоятельно подготавливала и выдавала сотрудникам карты, которые использовались как для прохода на территорию, так и для логического доступа к корпоративным информационным ресурсам. СБ же оставило за собой право контроля выданных карт по СКУД, т.о. интересы всех служб были удовлетворены и все остались довольны.

Развитие функционала

Кроме повышения эффективности и удобства управления доступом, в рамках того же пилотного проекта, проявились интересные возможности для расширения функций аутентификации. Дело все в том, что IDM-система способна, основываясь на тех или иных событиях, принимать решения по блокировке/разблокировке учетных записей пользователей. И события эти могут быть совершенно разные – начиная от ухода в отпуск сотрудника, и заканчивая его «не проходом» утром на работу. Именно события формируемые в системе СКУД выглядят потенциально очень интересными, ведь основываясь на этих данных IDM-система сможет предоставлять или блокировать доступ к информационным ресурсам в зависимости от, например, «географического» расположения сотрудника на территории предприятия. Или же блокировать доступ пользователя к информационным ресурсам, если он, фактически, по данным СКУД отсутствует в офисе компании. Мы в компании Avanpost окрестили такое поведение IDM-системы трехфакторной аутентификацией, и в ряде своих проектов, особенно на режимных государственных объектах, такой функционал предлагаем в первую очередь.

Заключение

Как вы видите, развитие технологий сегодня позволяет совмещать в единой системе управление физическим и логическим доступом. Подобное совмещение не только повышает удобство пользования системой и эффективность ее администрирования, но и существенно снижает риск несанкционированного доступа к информации вследствие ошибок и, так называемого, «человеческого фактора». Мы уверены, что будущее систем управления доступа именно за таким совмещением. И приблизить это будущее можете вы – пользователи.

Александр Санин, коммерческий директор компании Аванпост
Директор по безопасности