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

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

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

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

Тут как-то прямо Avk'а вспоминаешь, с его оффлайном.

В критических местах можно оганизовать свою подсеть

А её вообще можно организовать, в любоых местах. Vpn-рутеры тому пример.

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

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

У связистов на АТС - хотя-бы станционные батареи есть и телефонный коммуникатор ППКОП - при веерном отключении хотя бы может дозвониться до ЦСМ, а кто-нибудь видел хоть когда нибудь у провайдеров не то что физически защищенную трубной проводкой, да еще и закопанную в траншею - линию связи, а хоты бы элементарный резервный источник электропитания питающего сетевой коммутатор?

А если общедоступные каналы не юзать, а вместо того - изолированные?

Вот про это - я и имел :-) !

Только вот нужно основательно всё просчитать что будет дешевле а что будет надежней: - физически защищенная линия связи но с незашифрованным каналом связи; или же - шифрованный канал но по физически незащищенной линии.

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

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

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

А вот возможность работать в нестабильных линиях связи - это вполне можно вменить в задачу СКУДу.

Не комельфо, потому как - на дешевое решение, система с внешним железом уж точно не тянет

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

Т.ч. призыв "вынести за рамки" - почему-то мне сразу навееват анекдот :-( про баню, - у которой раздевалка через дорогу, а это значит что - банщики-парильщики ответственности за сохранность вещей, естественно - не несут.

Имели опыт? Недешевое - это сколько?

К несчастью да сталкивался с обслуживанием системы где - большая часть контроллеров СКУД и сервер с БД - был в производственных помещениях предприятия работающего в 3 смены и расположенного территориально в одном городе спутнике, а остальная часть (одна точка прохода, АРМ-БД "бюро пропусков", УРВ) в Челябинске, так скажем в "белом доме" данного предприятия работающего только в первую смену - и дурнее системы "IP-безопасности" я в своей жизни - не видывал! Причем дороже она была - как минимум на стоимость организации этого самого "шифрованного канала" которая складывается из: - стоимость отдельных серверов по обе стороны VPN, стоимости ОС и необходимого сетевого софта СКУД, услуг провайдера по предоставлению VPN, стоимость трафика и т.д.

Т.ч. призыв "вынести за рамки"

Это не призыв. Это констатация факта.

Вы приходите на объект, и вам предлагают готовые сети. Какие есть.

Не нравится? Заказчик не возражает против прокладки новых, но за свой (т.е. за мой) счет.

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

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

http://www.compel.ru/lib/ne/2012/6/4-kriptografiya-v-otdelnom-bloke-kriptograficheskiy-soprotsessor-semeystva-stm32f4xx/

Один из таких мы используем в своих иделиях "Хранитель-IT" и Радио-IP", обмен информацией с которыми идет не просто по локальным, а по глобальным сетям, где возможность хакинга многократно возрастает.

Цены вполне приемлемы. Конечно, осовоение потребует соответсвующего уровня разработчиков, но Вы справитесь )

Вы приходите на объект, и вам предлагают готовые сети. Какие есть.

Замечательно!

И пусть даже - какие есть готовые сети, не старшно!

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

Но вот когда Вы приходите на сети к Вашем заказчику одним из первых (или когда сеть как раз и начинала строиться именно исходя из Ваших рекомендации и минимальных требований, причем необходимых только для работоспособности Вашей системе), а затем, ваш и так то не очень щедрый, но при этом очень недальновидный заказчик, да еще не дай Бог на пару со своей "жабой" - начинает на эти же самые сети "вешать" ну скажем - трафик от IP-видео, а затем еще - решает воспользоваться какой-либо распределенно-серверной САПР, или - сетевой бухгалтерией - ну там Бесит, а-ли там 1С, при этом решает "сэкономить" деньги "фирмы" и обзаводится - ну скажем серверно-сетевым МайкроСкопОфиси пакетом со всеми МайЭскуельЗапросами к Акцессовской Базе с её коллизиями и транзакциями, а еще в придачу ко всему этому винегрету - обзаводится и серверным Антивирусом, - который мониторинг весь трафик, а по сути - шерстит все диски, всех машин в этой самой VPN сети - исключительно через себя, ну и венцом всего этого ШЗ будет создание ну скажем полного виртуально-облачного делопроизводства на базе какого-либо сервиса от а-ля Яндек ну или от о-ле ГугелЬ - "ДисковЪ"!

- Вот тогда к несчастью :-( правда если к тому времени Вы еще будете обслуживать подобную сетевую СКУД - Вы, как разработчикопроектировщикаустановщикообслуживатель - уже ничего сделать ЗАДНИМ ЧИСЛОМ не сможете, и не сможете Вы по чисто объективным причинам:

- общедоступную КОНТОРСКУЮ сеть - начали пилить и юзать трафик уже после Вас! А это значит и без учета Ваших требований, которые Вы конечно своему заказчику ранее и выдвигали и ставили, и ставили Вы их - не только при инсталляции системы, но и ставили еще даже на уровне проектно-сметной документации - на которую он (Ваш заказчик) и все его последующие после вас инсталляторы-интеграторы ну и конечно же юзеры этой самой шифрованой VPN сети - благополучно "забили".

:-(

PS

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

Один из таких мы используем в своих

лучших в мире шпингалетах! Которые вы можете приобрести на фабрика номер 3, улица Цюрюпы 15, телефон 9-18, факс 4-12, добавочный 03. Самовывоз из Новосибирска.

- Вот тогда к несчастью :-(

Фактически именно в такие сети мы и приходим.

Использование IP - один из плюсов решения СКУД. Можно использовать готовую инфраструктуру.

Ибо рекламировать сетевые решения и требовать прокладки отдельной локальной сети - как-то не очень уместно.

А если надо еще и объединять разные филиалы - вообще выбора нет в том, что использовать (а точнее - сам не знаешь что там используется админами).

Приходим и работаем...

Один из таких мы используем в своих иделиях