Обследование контроля доступа к помещению с установленными средствами криптографической защиты

Итак, интеграция двух рассматриваемых систем возможна. Причем, как было показано, она может достигаться использованием разных способов, основываясь на разных принципах. Ниже рассмотрен пример интеграции для сетевых систем. Рисунок 1 — Типовая сетевая система СКУДКонтроллеры СКУД, установленные в местах входа, взаимодействуя со считывателями, управляют замками, принимая решение в случае предъявления идентификатора на их открытие в соответствии со своей базой данных и правилами разрешения доступа. Управление всеми контроллерами производится по командам удаленного сервера СКУД, выполняющего следующие функции: сбор данных о событиях, происходящих на подконтрольных контроллерах СКУД;

ведение архива всех происходящих событий;

учет всей информации о пользователях и правилах разграничения доступа;

ведение базы данных идентификаторов;

непосредственное управление контроллерами СКУД. Рисунок 2 — Типовая сетевая система СЗИ НСДОна выглядит так: на подконтрольных компьютерах установлены модули доверенной загрузки, которые на основании предъявленных аутентифицирующих данных, а также в соответствии с определенными правилами, записанными в их собственной базе данных, принимают решение о разрешении старта компьютера. Далее в операционной системе компьютера запускается программный модуль СЗИ НСД, который осуществляет разграничение доступа работников к информационным ресурсам. Этот модуль взаимодействует также и с сервером управления, выполняющим следующие функции: сбор данных о событиях на подконтрольных объектах;

ведение архива происходящих событий;

учет информации о пользователях и правилах разграничения доступа;

ведение базы идентификаторов;

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

Поэтому может потребоваться выбор другого идентификатора с последующей адаптацией к его применению обеих систем. Кстати, дополнить биометрической аутентификацией можно и СКУД, а не только СЗИ, чтобы пользователь, желая войти в помещение, мог предъявлять и руку. Это позволило бы исключить возможность передачи карт «по дружбе», чтобы кто-то, используя карту коллеги, не мог выйти из комнаты «на минутку», не блокируя свое рабочее место. Интеграция объектов доступа неизбежно потребует модификации алгоритмов работы каждой системы расширением списка атрибутов базы данных (необходимо добавление атрибутов компьютеров, помещений) и изменением правил разграничения доступа (потребуется добавление правил обработки новых атрибутов и согласование их с правилами уже существующими). Что касается объединения баз данных, то оно может производиться или за счет создания общей информационной базы с записями об объектах, необходимых для обеих систем, или расширением каждой базы данных добавлением атрибутов (рис. 3).Рисунок 3 — Обьединение баз данных Вариант, при котором объединяются функции серверов в едином программном продукте, является наиболее трудоемким и самым непредсказуемым по конечному результату. При всей схожести рассматриваемых систем они все-таки значительно отличаются в деталях. Прежде всего, протоколами взаимодействия серверов с конечным оборудованием. Так, например, стандартом взаимодействия сервера СКУД с контроллерами является протокол RS-485 (EIA-485), а компоненты системы СЗИ НСД, как правило, связаны через локальную вычислительную сеть на Ethernet. К тому же протоколы взаимодействия часто бывают проприетарными и закрытыми, да и регулирующие органы также нередко предъявляют к ним различные требования. Немаловажно и то, что понятия и атрибуты, которые использует каждая система, настолько различны, что требуется значительное время для изучения разработчиками смежной предметной области. Еще одним недостатком рассматриваемого подхода является уникальность разработки, в результате чего интеграция даже с другой похожей системой будет, по сути, новой работой без возможности использования уже имеющихся наработок. Уникальность затруднит также и последующее развитие всей системы, так как обновление каждой составляющей ее части будет требовать изменения и объединенного варианта. Но при правильной его реализации можно добиться максимальной степени интеграции, единообразного управления обеими составляющими системами и более тонкого регулирования их взаимодействия. Вариант, при котором разрабатывается специальная технология взаимодействия серверов систем между собой, может позволить в принципе сохранить независимость систем.

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

с равноправным взаимодействием серверов; (рис. 4) Рисунок 4 — Равноправное взаимодействие серверовс взаимодействие серверов, использующим третий (дополнительный) управляющий сервер. (рис.

5)Рисунок 5 — Схема взаимодействия серверов, использующих третий (дополнительный) управляющий сервер

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

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

Заключение

.

Исходными для разработки проекта СКУД являются план и характеристики защищаемого объекта. Объектом является 3-х этажное офисное здание с мансардой. При разработке СКУД для заданного объекта предварительно проводится обследование его плана. Обследование осуществляется: — путем изучения чертежей; - обхода и осмотра объекта: — проведения необходимых измерений. При проведении обследования объекта определяют: количество входов/выходов и их геометрические размеры (площадь, линейные размеры, пропускная способность и т. п.); материал строительных конструкций; количество отдельно стоящих зданий, их этажность; количество открытых площадок; количество отапливаемых и неотапливаемых помещений и их расположение; По результатам обследования определяются — тактические характеристики СКУД; - структура СКУД; - технические характеристики компонентов СКУД; составляется техническое задание на оборудование объекта СКУД.

Список литературы

:Системы контроля и управления доступом Год: 2010 Автор: Ворона В. А., Тихонов

В.А. Жанр: учебное пособие Издательство: Горячая Линия

-&# 160;Телеком ISBN: 978−5-9912−0059−2 Язык: Русский Волковицкий В. Д., Волхонский В. В. Системы контроля и управления доступом.

— СПб.: Экополис и культура, 2003. — 165 с.

Волхонский В. В. Штриховые коды. — СПб: Университет ИТМО, 2015. — 53 с. Руководство по созданию комплексной унифицированной системы обеспечения безопасности музейных учреждений, защиты и сохранности музейных предметов/ А. В.

Богданов, В. В. Волхонский, И. Г. Кузнецова и др.

Ч. II. — СПб.: Инфо-да, 2014. — 264 c. ГОСТ Р 51 241−2008.

Средства и системы контроля и управления доступом. Классификация. Общие технические требования. Методы испытаний. — Введ. 2008;12−17. -.

М.: Стандартинформ. — 34 сИванов М. А. Криптографические методы защиты информации в компьютерных системах и сетях [Электронный ресурс]: учебное пособие /М.А. Иванов, И. В. Чугунков — М.: МИФИ, 2012. — 400 с. — Спицын, В. Г.

Информационная безопасность вычислительной техники [Электронный ресурс]: учебное пособие / В. Г. Спицын — Томск: Эль Контент, 2011 — 148 с. — Р.