Актуальные задачи СКУД. 2014 год.

Предлагаю "оторваться" от мелочей и посмотреть на фундаментальные проблемы СКУД.

Обсуждение темы "12 слабых мест в СКУД" зашло (на мой личный, ессно, взгляд) в тупик, и дальнейшее ее развитие требует отдельной темы.

Постановка вопроса не верна принципе!

СКУД - это система, комплекс, состоящий из многих отдельных элементов (физических, программных, архитектурных).

Призыв найти "слабые места в СКУД" надо рассматривать как попытку найти недостаток в самой идеологии СКУД, а не в ее отдельно взятых элементах.

Попытка выдать ограничения отдельных решений (та же проблема клонирования) как недостаток системы - это профанация проблемы.

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

Вот утрированное, но любопытное отражение реалий: http://www.youtube.com/watch?v=fB2b-lTjCQA

Там, где задача ставится не "вообще безопасность" (или "вообще СКУД") мгновенно реализуются очень простые и очень эффективные меры.

Предлагаю изменить формулировку темы на, например, такую: актуальные проблемы СКУД.

Меняются технологии, меняются тенденции. Как это сказывается на область нашей работы?

Вот некоторые из таких проблем:

1. уход в локальные сети выдвинул требования шифрования данных. Как их шифровать? Ответ уже известен: известными методами, алгоритмам и протоколам (SSH, SSL и т.п.). Но вот какая интересная штука проявляется: микроконтроллеры, используемые в контроллерах СКУД, не в состоянии обеспечить шифрование/дешифрование в реальном масштабе времени. Что думаете по этому поводу, коллеги? Эх моей предпосылки следует целый ряд не очень приятных выводов:

• сегодня разработка оборудования на уровне ядра 51 (или PIC) бессмыслена. Эти изделия не обеспечат нужной производительности.
• проблему шифрования можно решить локально (т.е. в рамках софт-оборудование конкретного производителя. Алгоритм они не расскажут никому! Ключи шифрования не дадут никому!). Завтрашний день все равно потребует выработку и соблюдение стандартов. Т.о., попытка сделать "свое" шифрование не имеет смысла (а тут на форуме уже озвучены решения с уникальным секретным алгоритмом шифрования).

1. унификация протоколов обмена и управления. Мы подключаем любой принтер к любому компоьютеру с практически любой ОС и печатаем документы. Почему же контроллеры СКУД (а можно смотреть и шире - другок оборудование ОС) работают только со своим "фирменным" софтом? Можно ли унифицировать протоколы обмена с тем, чтобы в рамка одной системы можно было использовать оборудование разных производителей? Хочу отметить, что в Word'е (или Excel, или даже в любом браузере), например, мы нигде не прописываем с каким принтером ему работать придется. Так что решения на основе "укажите тип используемого оборудования в настройках" - тупик. (Хотя когда-то тот же AutoCAD требовал указать тип используемого плоттера. И если нужного плоттера не было, то результат нельзя было распечатать...)
2. другая сторона унификации протоколов обмена связана с оборотом данных. Очевидно же, что СКУДу как системе нет разницы что использовать в качестве идентификатора: код карты ли, данные от штрих-кода ли, шаблон отпечатка пальца ли, набор данных в защищенной области памяти (респект avk). Но комбинированных систем что-то маловато... Всяк кулик, похоже, сидеть в своем болоте.

микроконтроллеры, используемые в контроллерах СКУД, не в состоянии обеспечить шифрование/дешифрование в реальном масштабе времени.

Что мешает более быстродействующие микроконтроллеры выбирать или ставить сопроцессоры, как во времена 386-х?

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

Попытка выдать ограничения отдельных решений (та же проблема клонирования) как недостаток системы - это профанация проблемы.

Т.о. взаимоисключающие параграфы detected :-))).

Что мешает более быстродействующие микроконтроллеры выбирать или ставить сопроцессоры, как во времена 386-х?

Мешает цена вопроса (и проблемы сбыта с такой ценой).

Андрей!

А может, стоит сделать пару шагов назад?

Может, стоит определиться, какую задачу/какие задачи должен решать СКУД?

- Повышение уровня безопасности на объекте?

- Учет рабочего времени?

- Оптимизация бизнес-коммуникаций?

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

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

И еще, совсем уж не в тему, но коль речь зашла о СКУД, может быть, кто-то подскажет РЕАЛЬНО РАБОТАЮЩУЮ систему получения актуальной информации в виде ответов на вопросы, которые мне задали в Facebook относительно российского рынка СКУД:

"1. что за оборудование используется

2. какие требования от заказчиков

3. требования от монтажников

4. определить топ -5 поставщиков и производителей".

(скопировал как есть)

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

Т.о. взаимоисключающие параграфы detected :-))).

Противоречий в моих тезисах нет.

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

Попробую изменить название темы.

Может, стоит определиться, какую задачу/какие задачи должен решать СКУД?

Вот и вернулись к истокам.

Мой ответ такой:

Обеспечить проход пользователей в соответствии с таблицей правил прохода есть основная задача СКУД!

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

Правила прохода - набор условий, определяемых владельцем объекта.

Все. Безопасность, учет, оптимизация... Это все может присутсвовать, но не входит в задачу СКУД.

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

Реально работающая система должна дать ответ на вопрос о квалификации монтажников? и о топе производителей???

Может, Вы вопрос неверно сформулировали?

Может, стоит определиться, какую задачу/какие задачи должен решать СКУД?

ИМХО: - Контроль в реальном масштабе времени и как следствие возможность оперативного предотвращение несанкционированного доступа (педальку хасть и шлюз закрылся), - всё же остальное к безопасности как к таковой - не имеет никакого отношения.

Как не должна работаnm СКУД - но так работает повсеместно:

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

А так, должно быть везде:

В Златоусте сотрудники вневедомственной охраны задержали мужчину, который ограбил ювелирный салон. Налётчик попросил примерить цепочку и хотел с украшением скрыться. Однако не мог и предположить, что входная дверь блокируется кнопкой. Хронология событий – в сюжете Евгения Янурова.

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

Именно так оно и есть - надежность любой системы всегда определяется самым слабым звеном этой самой системы.

Остается только выяснить - что в нынешней системе СКУД - будет являться слабым звеном!?

Тут вот возник вопрос о необходимости шифрования, ну и с этим - удорожание систем.

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

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

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

Вот и получается что: - если даже создать более или менее дешевую систему с неким шифрованием то, - из-за использования относительно ДЕШЕВОГО, но не надежного ОБЩЕДОСТУПНОГО канала связи - придется (для обеспечения живучести системы) использовать еще какие-либо дополнительный(-ые) канал(-ы) связи работающие на другом физическом уровне и\или - выдумывать некие способы урезанного функционирования системы (ОГРАНИЧЕНИЯ доступа - без какого-либо удаленного контроля и тем более управления) - с её не продолжительным функционированием в режиме автономного офф-лайна.

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

Получается, что независимо от причин шифрование необходимо, что я и назвал актуальной текущей задачей.

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

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

Полагаю, что система должна учитывать нестабильность линий связи.

Это не сложно реализовать.

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