Вы находитесь в разделе Типовых решений систем безопасности
Часть 12. общие вопросы построения системы защиты информацииВ предыдущих частях работы мы рассмотрели, пожалуй, наиболее важные задачи, принципы и механизмы защиты информации, которые могут использоваться с целью обеспечения компьютерной безопасности. В части завершения публикуемого цикла работ, логичным будет рассмотреть важнейшие общие вопросы обеспечения компьютерной безопасности – требования к построению и к комплексированию механизмов защиты в единую систему (ранее мы обосновывали тезис, что никакой, даже идеально исполненный механизм защиты, в отдельности не позволит обеспечить какой-либо приемлемый уровень компьютерной безопасности). Обсуждение данной проблемы, на наш взгляд, принимает в современных условиях особую актуальность, т.к. в ближайшее время предполагается переход на новые принципы определения требований к средствам защиты, в том числе к их построению и комплексированию, что находит, как своих сторонников, так противников. Вопросы построения и комплексирования механизмов защиты – это ключевые вопросы обеспечения компьютерной информации. Дело в том, что их недостаточность, либо некорректность исполнения механизмов приводит к уязвимости защиты, избыточность – к дополнительным затратам, как к затратам вычислительных ресурсов, так и к финансовым затратам потребителя. Видим, что по своей сути – здесь налицо многокритериальная оптимизационная задача и, в зависимости от того, какой критерий мы выберем доминирующим, получим принципиально различающиеся решения. Естественно, что в подобных условиях подходы к комплексированию механизмов защиты должны быть жестко формализованы (определены соответствующими нормативными документами), в противном случае, на СПРОС обеспечить защиту при минимальных затратах, получим ПРЕДЛОЖЕНИЕ (спрос всегда рождает предложение) подобных некачественных (с точки зрения обеспечения компьютерной безопасности), но недорогих для потребителя решений (например, использовать только встроенные механизмы ОС, а все их недостатки учесть организационными мерами). На сегодняшний день практически одновременно действуют (формализованы) два подхода к решению проблемы построения и комплексирования механизмов в системе защиты: один подход состоит в жестком задании требований к механизмам защиты и к их набору в системе, применительно к уровню конфиденциальности обрабатываемой информации и к условиям ее обработки (это требования к защищенности СВТ и АС), альтернативный подход состоит в разработке и в утверждении подобных требований (критериев), применительно к условиям использования защищаемого объекта информатизации, на основе анализа, так называемого, поля угроз . Видим, что это совершенно полярные по своей сути подходы (в части жесткости регламентации требований), как следствие, каждый из них имеет свои достоинства и недостатки, естественно, своих сторонников и противников. Однако, к сожалению, в большой мере обсуждение достоинств и недостатков существующих альтернативных подходов сегодня сводится не к техническим, а к организационным вопросам (см., например, ). При этом не лишним будет заметить, что на основании публикаций из открытых источников, можем сделать вывод, что с компьютерной безопасностью не все здорово, ни у нас (где до сих пор применялся первый подход), ни за рубежом (где широко используется второй подход). Поэтому можем сделать вывод, что технические аспекты рассматриваемой проблемы актуальны и по сей день, поэтому их мы и предлагаем обсудить в данной работе. При этом сразу оговоримся, что ни в коей мере не сравнение существующих подходов является целью нашего исследования – мы попытаемся, учтя полученный опыт и сделанные в предыдущих работах выводы, в большой мере абстрагируясь от существующих подходов, рассмотреть технические аспекты задания требований к построению и к комплексированию механизмов защиты. Прежде всего, на основании сделанных в предыдущих работах выводов, сформулируем основные взаимосвязанные посылы, которые будем учитывать далее. Посыл 1 Бесперспективность какой-либо осмысленной формализованной оценки (на наш взгляд, она невозможна в принципе) уровня эффективности защиты (либо уровня защищенности). Текущее состояние защищенности системы может иметь одно из двух состояний: полностью защищена, либо полностью незащищена, что проиллюстрировано на рис. Переход системы из одного состояние в другое осуществляется при обнаружении хотя бы одной уязвимости защиты. Для дальнейшего изложения материала, буквально в двух словах, определимся с тем, что мы понимаем под такими терминами, как уязвимость, угроза и атака. Под уязвимостью системы защиты нами понимается такое ее свойство (недостаток), которое может быть использовано злоумышленником для осуществления несанкционированного доступа (НСД) к информации. При этом любая уязвимость системы защиты несет в себе угрозу осуществления злоумышленником НСД к информации, посредством реализации атаки на уязвимость в системе защиты. Таким образом, именно уязвимость системы защиты – это признак системы, а наличие (отсутствие) известных уязвимостей (говорим известных, так как уязвимости присутствуют всегда, о чем мы говорили в предыдущих работах) является характеристикой защищенности (текущего состояния защищенности) системы. Следствия:
 Выводы:
Посыл 2 Уязвимости системы защиты на основании анализа их проявления в системе, могут быть классифицированы следующим образом:
Следуя сформулированному выше выводу, что основным требованием к системе защиты является отсутствие на момент создания (выхода в свет) системы защиты в ней обнаруженных уязвимостей, и на основании приведенной классификации возможных уязвимостей системы, можем сформулировать следующие основополагающие требования к системе защиты:
Посыл 3 Основополагающим требованием к системе защиты, обусловливающим принципиальную возможность ее использования в современных условиях (защита конфиденциальной информации на предприятии), является следующее требование к индуктивности реализуемой ею модели безопасности: Основу обеспечения компьютерной безопасности должна составлять реализация системой защиты индуктивной модели безопасности (напомним, что под индуктивностью понимается следующее свойство модели безопасности – система, единожды установленная в безопасное состояние, не должна изменять своего состояния в процессе функционирования). Поясним данное ключевое свойство модели защиты, рассмотрим к чему приводит невыполнение сформулированного выше требования. С этой целью соотнесем такие категории, как Владелец и Собственник информации. Применительно к исследуемому вопросу, будем говорить, что собственник – это лицо (не обязательно физическое), которому принадлежит информация, владелец – лицо, получающее информацию от собственника во временное владение, с целью ее обработки вычислительным средством. Очевидно, что если говорить об использовании компьютера в домашних целях, то пользователь, работающий на персональном компьютере, как правило, одновременно является и собственником, и владельцем информации, как следствие, он должен иметь право назначать (изменять) правила доступа к обрабатываемой им информации. Заметим, что именно такая схема исторически сложилась и широко используется встроенными механизмами защиты ОС. Однако такая схема не годится при обработке информации на предприятии. Рассмотрим, чем это обусловлено. Здесь, как правило, Собственник и Владелец (в данном случае предприятие, от лица которого уже пользователь, получающий информацию во временное владение, для ее обработки) различные лица. Пользователь в рамках своих служебных обязанностей с использованием вычислительного средства осуществляет обработку информации, предоставленной собственником, как следствие, должен осуществлять действия с этой информацией только в рамках правил, установленных собственником. Доверенным лицом собственника должен выступать выделенный субъект (администрация, служба безопасности и т.д., на практике, как правило, это администратор безопасности), в задачи которого входит назначать (изменять) правила разграничения доступа к информации в соответствии с политикой безопасности, формируемой на основании требований к ее обработке, определяемых собственником информации. Индуктивность модели безопасности при этом достигается тем, что только администратор безопасности может изменять свойства системы защиты в процессе ее функционирования (пользователю, обрабатывающему информацию, подобная возможность не предоставляется), как следствие, он от лица Собственника в полной мере может отвечать перед Владельцем за сохранность информации. При невыполнении системой защиты требований к индуктивности модели безопасности, как таковая, нивелируется роль ответственного за сохранность информации лица, т.к. ответственность здесь распределяется между всеми пользователями. В данных же предположениях вести речь о какой-либо защите информации, в том числе об ответственности за ее сохранность, уже не приходится. Из требования к индуктивности модели безопасности, как следствие, вытекает и еще одно важное требование к системе защиты, используемой в современных условиях: Защищенной может являться только многопользовательская система, в которой одновременно обрабатывается и (или) хранится информация разных уровней конфиденциальности, при этом не все пользователи имеют право доступа ко всей информации. Наличие данного требования обусловлено тем, что индуктивность модели безопасности достигается только в том случае, когда администратор системы защиты и пользователь, обрабатывающий информацию на компьютере – это различные лица, а с учетом различия решаемых ими функциональных задач, как следствие, они должны обладать различными правами доступа к информации. В качестве замечания отметим, что данное требование может выполняться только АС первой группы, включающей многопользовательские АС, в которых одновременно обрабатывается и (или) хранится информация разных уровней конфиденциальности. Не все пользователи имеют право доступа ко всей информации АС. Группа содержит пять классов - 1Д, 1Г, 1В, 1Б и 1А. Посыл 4 Сформулированные ранее требования к системе защиты практически не взаимосвязаны, т.к. характеризуют совершенно различные аспекты ее построения. В связи с этим, будем говорить, что система защиты может быть охарактеризована следующей совокупностью требований, которые нам далее следует рассматривать:
Итак, выше мы сформулировали набор основополагающих требований, которые могут быть (а в идеале, по нашему мнению, должны быть) разработаны и стать обязательными для разработчика при создании и комплексировании механизмов защиты в системе. Важный вывод, который мы сделали, это взаимная независимость данных требований, т.е. выполнение (невыполнение) требований одной группы никоим образом не должно изменять требований другой группы. Теперь рассмотрим возможные подходы к формированию требований каждой группы. Требования к корректности реализации механизмов защиты Принципиальным при составлении требований данной группы является выполнение следующей совокупности условий:
Возможности и подходы к реализации данных условий проиллюстрируем на примере. Рассмотрим механизм избирательного контроля доступа к ресурсам, частично требования к корректности реализации которого нами рассматривались в первой и третьей частях работы. Выполнение условия структурированности механизмов защиты достигается тем, что при разработке требований необходимо предусмотреть различные варианты применения механизма (здесь мы забегаем немного вперед). Это файловые объекты, устройства и носители информации, сетевые объекты и т.д. Для каждого из этих применений должны быть сформулированы требования (в большой мере они будут повторяться) к корректности реализации, что позволит далее учитывать условия применения системы. Например, если в системе отсутствуют устройства ввода, система автономна (не в сети) воспользуемся требованиями к реализации контроля доступа к файловым объектам (к ним можно отнести и реестр ОC, если в ней присутствует подобная архитектурная компонента). Решили подключить устройства ввода – у нас есть требования к корректности реализации соответствующего механизма защиты и т.д. В качестве замечания отметим, что не следует бояться, что подобных механизмов (при необходимой их структуризации) будет очень много – ну, два, три десятка (посмотрите, например, сколько в сумме механизмов защиты, обязательных для исполнения, регламентируется документом – десяток). Теперь относительно задания требований, как отмечалось, они должны формализовать основополагающие теоретические принципы построения механизмов защиты. На примере покажем, что мы имели в виду, опять же на примере избирательного контроля доступа к ресурсам. К подобным требованиям здесь можно отнести:
Видим, что основополагающие требования к механизму защиты, сформулированные в подобном виде, абсолютно индифферентны к особенностям приложений системы защиты, чем обеспечивается статичность данных требований (их не понадобится видоизменять с изменением особенностей приложений системы защиты). А вот уже применительно к конкретным особенностям, которые могут меняться со временем, именно разработчик и должен обосновать свои решения и доказать, что сформулированные основополагающие требования к корректности реализации механизма защиты выполнены им в полном объеме. Прокомментируем сказанное, для чего пойдем от обратного. Рассмотрим, почему в данных предположениях, на наш взгляд, можно считать, что механизм избирательного контроля доступа, например, ОС Windows XP, реализован некорректно (не будем детально исследовать данный механизм, остановимся лишь на некоторых примерах):
В качестве замечания отметим, что серьезного обоснования технических решений, принятых при реализации системы защиты разработчиками, нам практически не встречалось. В документации на систему данные решения приводятся де-факто, как единственно верные (а порассуждать здесь есть о чем). Вместе с тем, требования к подобному обоснованию существуют, например, в документе для СВТ пятого класса защищенности присутствуют следующие требования к гарантии проектирования - на начальном этапе проектирования СВТ должна быть построена модель защиты. Модель должна включать в себя ПРД к объектам и не противоречивые правила изменения ПРД. Нужно ли расширять данные требования – это вопрос. Дело в том, что разработчик, которому есть, что сказать, и без всяких требований будет заинтересован в том, чтобы довести до сведения потребителя информацию о новых потребительских свойствах созданной им системы защиты (заставлять его это делать не нужно). Разработчик же, которому нечего сказать, все равно ничего не скажет, т.к. нечего. Таким образом, принципиальным при разработке требований данной группы является то, что рассматривается как таковой механизм защиты, условия же возможного его применения учитываются лишь в части структуризации при его представлении. Только такой подход, на наш взгляд, позволяет говорить о корректности реализации механизмов, анализ же возможных угроз здесь ни при чем – данными требованиями определяются общие условия, при реализации которых механизм не несет в себе уязвимостей (еще раз уточним, не в части ошибок программирования). Проиллюстрируем сказанное простым примером. Для этого рассмотрим требования к механизму идентификации и аутентификации, задаваемые в соответствующем нормативном документе . Для пятого класса защищенности средства вычислительной техники (СВТ) требования к данному механизму формулируются следующим образом:
Как следствие, можем заключить, что концептуально подход, предполагающий различный набор требований к корректности систем защиты, применяемых в различных приложениях (например, для защиты конфиденциальной информации и сведений, отнесенных к государственной тайне) неверен. Требования к корректности реализации механизма едины (он либо уязвим, либо нет) для всех приложений систем защиты информации. Таким образом, по нашему мнению, рассмотренная группа требований является ключевой и обязательной для исполнения. Если по условиям применения системы защиты, система должна включать какой-либо механизм, этот механизм должен быть реализован корректно – не нести в себе уязвимости. Заметим, что невыполнение данных требований не может нести в себе возможность исключения требований из обязательных, посредством использования каких-либо организационных мер - в этой части организационные меры неприменимы! Естественно этот тезис оправдан в том случае, если нашей конечной целью является обеспечение высокого уровня защищенности – в этих предположениях речь идет о том, что система защиты должна соответствовать требованиям, а не требования должны соответствовать системе защиты! Требования к комплексированию механизмов защиты Совокупность данных требований формулирует уже условия применения системы защиты. Целесообразность учета подобных требований заключается в том, что условия практического использования систем защиты могут существенно различаться. Действительно, защищаемый компьютер может находиться в сети, а может работать автономно, в сети это может быть рабочая станция, либо сервер, к нему могут быть подключены, либо нет внешние устройства и т.д., компьютеры могут использоваться для обработки различной по уровню конфиденциальности информации и др. Конечно, система защиты, реализующая всю совокупность механизмов защиты, обеспечивающая все возможные условия ее использования, если и реализуема в принципе, то уж явно в некоторых частных случаях использования нерациональна. Таким образом, данной группой требований решается задача формирования в каждом конкретном случае использования системы защиты необходимого (полного в части обеспечения компьютерной безопасности при заданных условиях использования) набора механизмов защиты, которые должны быть реализованы на основании требований, рассмотренных выше. Рассмотрим основные принципы, которые, на наш взгляд, могут быть положены в основу формирования требований данной группы:
Требования данной группы могут формулироваться в каждом конкретном случае использования системы защиты. При этом необходимо понимать, что, вообще говоря, подобных вариантов использования системы не так много, поэтому через некоторый промежуток времени мы можем получить совокупность наборов требований второй группы, покрывающих большую часть вариантов приложений системы защиты. Теперь рассмотрим, что же мы получаем, вводя, в качестве, на наш взгляд, обязательных, две рассмотренные группы требований: требований к корректности реализации механизмов защиты и требований к комплексированию механизмов защиты. При использовании предложенного подхода, мы получаем компромиссное решение по использованию альтернативных подходов к решению проблемы построения и комплексирования механизмов в системе защиты, рассмотрены в начале работы, чем, надеемся, примиряем сторонников и противников и сторонников обоих подходов. При этом из обоих подходов мы берем их лучшие свойства - из первого подхода мы берем жесткое задание требований к механизмам защиты (в нашем случае, требований к корректности реализации механизмов), из второго подхода – возможность реализации системы защиты, применительно к условиям ее использования, т.е. возможность оптимизации функциональных возможностей системы защиты. Заметим, что выше нами была определена и основная задача организационных мер (что позволяет их также формализовать) – обеспечить невозможность изменения условий применения системы защиты, учтенных при формировании требований к системе при ее реализации. Требования к обеспечению необходимого уровня доверия потребителя системы защиты к ее разработчику Пожалуй, это наиболее сложный для возможности формализации вопрос. При этом отметим, что достаточно важный, т.к. ошибки программирования могут вносить уязвимости, в той же (если не в большей) мере, что и некорректность реализации механизмов защиты. Во второй части работы мы провели небольшой анализ, в результате которого показали, что, например, современные ОС Windows с учетом статистики их уязвимостей (характеризующей качество разработки) никак нельзя считать защищенными – здесь, на наш взгляд, обеспечить приемлемый уровень защиты возможно лишь при использовании резервирующих свойств добавочных средств защиты. Сегодня основным подходом, реализуемым с целью повышения уровня доверия потребителя к средству защиты, является анализ исходных кодов системы на наличие недекларируемых (не описанных в документации) возможностей (НДВ). Сразу оговоримся, что под НДВ мы здесь будем понимать ошибки программирования, оставив в покое закладки (с ошибками бы разобраться). Наверное, данный подход имеет право на жизнь, при анализе систем небольшого объема, например, средств добавочной защиты с ограниченным функционалом (по крайней мере, хуже от такого анализа система не станет, правда повысится, и значительно, ее цена для конечного потребителя, т.к. анализ на НДВ это весьма затратное мероприятие для разработчика). Рассмотрим, какие проблемы связаны с реализацией подобного подхода. Кто хоть раз в жизни занимался программированием, знает, что разработать программу и разобраться в чужой программе (при наличии исходных кодов), это сопоставимые по сложности задачи. Соответственно, если средний срок разработки добавочной системы защиты 2 года, то примерно столько же может потребоваться и для серьезного анализа ее исходных кодов на НДВ, но через два года система может быть уже не востребована. Сокращение же сроков анализа, естественно не может не сказаться на его качестве. Если же касаться анализа на НДВ сложных систем, например, ОС, то это, на наш взгляд, вообще бесперспективное занятие! В среднем сегодня только переход на новую версию ОС, например, Windows, составляет 2 – 3 года, что, кстати говоря, безумно мало и приводит к такому, как имеем, количеству ошибок (а ведь при этом максимально используются все наработки – исходные коды предыдущих версий). С учетом этого, сколько же тогда составляет срок разработки современной ОС – минимум 8 – 10 лет, сколько же времени потребуется для анализа ее кодов на НДВ (уже выйдет несколько новых версий). Если же говорить о возможности какой-либо эффективной автоматизации подобного контроля, то и возможность эффективного решения этой задачи вызывает определенные сомнения. Заметим, что в отсутствии ошибок больше всех заинтересован разработчик. Если бы рассматриваемая задача была бы принципиально решена, то первыми бы полученными результатами воспользовались разработчики ПО, и мы, как потребители, сразу бы это почувствовали. Таким образом, имеем явное противоречие, с одной стороны, чем больше объем кода системы, тем выше вероятность нахождения в нем ошибок, т.е. тем более востребован контроль на НДВ с целью повышения доверия к системе, с другой стороны, чем больше объем кода, тем менее значим результат подобного контроля в разумные сроки, т.к. тем менее детально может быть осуществлен анализ системы. Другая проблема – это собственно результата контроля, приводит ли он действительно к повышению доверия к системе. Что, в конечном счете, волнует конечного потребителя – есть ли в системе ошибки, сколько их, насколько эти ошибки критичны? Но на эти вопросы проведение контроля на НДВ не может дать ответ в принципе. Что можно утверждать в результате проведения контроля на НДВ – контроль проведен, но это не результат, в результате контроля выявлено и разработчиком исправлено столько-то ошибок – это уж тем более не результат – если выявлено много ошибок, то это хорошо или плохо, сколько их осталось? Поясним нашу мысль. Много найденных ошибок, с одной стороны, хорошо – система стала лучше, с другой стороны, плохо – что же это за система, в которой много ошибок – это дает основание предположить, что много ошибок в системе еще осталось, т.к. качество программирования оставляет желать лучшего. Таким образом, может быть, сам по себе, подход к повышению доверия к системе защиты, основанный на анализе исходных кодов системы на наличие НДВ, и не плох, но объективные сложности его реализации, на наш взгляд, весьма ограничивают возможность его эффективного использования на практике. Но есть ли альтернатива данному подходу? Что же тогда делать для повышения доверия потребителей к разработчику системы защиты (так как именно он, в конечном счете, отвечает за ошибки в ПО), как следствие, к системе. Как определить, задать, а уж тем более, формализовать подобные требования. На наш взгляд, решение данной проблемы состоит в разработке группы требований к качеству тестирования системы защиты разработчиком (ведь именно разработчик должен быть самым заинтересованным лицом в повышении качества разработки системы, причем очевидно, что лучше, чем разработчик, естественно, что при выполнении определенных требований, никто систему протестировать не сможет), и в контроле выполнения данных требований при создании системы. Заметим, что здесь не надо ничего придумывать. Подобные требования сформулированы и в существующих нормативных документах. Например, следуя документу , рассматриваемые требования к СВТ пятого класса защищенности выглядят следующим образом - в СВТ пятого класса защищенности должны тестироваться:
Другими словами, выдвигаются требования к тому, что тестированию разработчиком должны подвергаться основные механизмы защиты информации, реализованные в системе. Также сформулированы требования и к тестовой документации, которая должна быть в наличии у разработчика, состоящие в данном случае в следующем: должно быть представлено описание тестов и испытаний, которым подвергалось СВТ (в соответствии с требованиями, представленными выше), и результатов тестирования. Таким образом, уже в существующих нормативных документах требования данной группы присутствуют, причем и к тому, что должно быть протестировано, и к тому, что в качестве результатов тестирования должно быть представлено разработчиком для возможного анализа качества выполненных работ по тестированию средства защиты – что же еще нужно? Однако видим, что нигде в документе не формализованы требования к тому, как проводить тестирование, не определены критерии к необходимости и к достаточности объема проводимых работ по тестированию системы защиты, не сформулированы требования к тестам, к способам проведения испытаний и т.д. Другими словами, как таковые, отсутствуют формализованные параметры оценки качества испытаний системы защиты, проведенных разработчиком, как следствие, по существу мы не имеем и возможности оценки уровня доверия. А ведь проблема тестирования программного продукта составляет отдельную область научных знаний, где многие из рассмотренных вопросов давно нашли решение. Таким образом, на наш взгляд, данная группа требований должна содержать в себе формализованные требования и параметры оценки качества проведения тестирования средства защиты разработчиком (возможно с использованием некоторых утвержденных инструментальных средств). Выполнение разработчиком этих требований, которые, естественно, должны быть известны потребителю, в полном объеме и должно обеспечивать требуемый уровень доверия потребителя к разработанной системе защиты. Возможно здесь имеет смысл ввести несколько уровней доверия, отнесение средства к которым может осуществляться на основании выполнения требований, сформулированных для соответствующего уровня. На наш взгляд, выполнение требований данной группы, как и требований групп, рассмотренных ранее, также должно быть обязательным для разработчика средства защиты. Теперь, в двух словах, остановимся на закладках в ПО (сознательно внесенных в программное средство НДВ разработчиком). Наверное, не стоит строить иллюзий, относительно возможности обнаружения закладки в ПО в разумные сроки (это задача на порядки сложнее, чем поиск ошибок, о котором мы говорили ранее). Поэтому, наверное, имело бы смыл ограничить возможность применения средств зарубежного производства в критичных приложениях обработки информации, ну а добавочные средства защиты здесь априори должны быть отечественные. Кроме того, наверное, здесь следовало бы рекомендовать к использованию технологии, призванные противодействовать атакам, использующим ошибки и закладки в ПО, пример подобной технологии и принципов ее реализации был нами рассмотрен в восьмой и в девятой частях работы. В заключение отметим, что представленные в работе предложения, описывающие лишь один из возможных подходов к решению рассматриваемой задачи, авторами приведены в порядке обсуждения. Читайте далее:  Народный нановидеосервер Факторы успеха в сфере беспроводного видеонаблюдения Шз–революция В великобритании собираются использовать видеонаблюдение для выявления мусорящих курильщиков Аналитики пытаются остановить похитителей велосипедов при помощи видеонаблюдения Народный нановидеосервер iii Предложения к гост р 51558-2008 Кадровая безопасность ,часть 1, Видеосервер domination на выставке в уфе Стандарт сжатия видеоизображения h.264. новые возможности в области охранного видеонаблюдения Выбор оптоволоконных передатчиков видеосигнала Ссtv-аксессуары для преобразования аналоговых сигналов в цифровые Новые ip-камеры vn-c10u компании jvc для видеоконференций и видеонаблюдения Чувствительность видеокамер ,минимальная освещенность, Новый экономичный мультиплексор-видеорегистратор dvmre ezt kalatel на 4, 10 и 16 телекамер
|
