Требование к достаточности набора механизмов применительно к условиям использования средства защиты

Вопросы практической реализации

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

В данной работе мы остановимся на исследовании проблемы обеспечения достаточности набора механизмов в средстве защиты, применительно к условиям его использования. Своевременность задуматься на эту тему (актуальность исследуемого вопроса) диктуется современными тенденциями развития средств вычислительной техники. В частности, при построении современных универсальных системных средств (которые находят широкое использование в корпоративных приложениях), как правило, разработчики пытаются обеспечить их максимальную универсальность, с целью расширить область практического использования (что является важнейшим потребительских свойством универсальных ОС). Это мы видим на примере реализации современных ОС семейства Windows, например, в части расширения возможностей работы с устройствами. Однако при использовании универсального системного средства при обработке конфиденциальной информации на предприятии (т.е. в корпоративных приложениях), большинство подобных свойств остаются невостребованными. Вместе с тем, подобная универсализация кардинально меняет требования к средству защиты информации, т.к. при этом потенциально изменяются условия использования системного средства – появляются новые "каналы" утечки информации. В качестве иллюстрации предлагаемого нами в работе подхода, направленного на выполнение требований к достаточности набора механизмов защиты, рассмотрим решение, реализованное и апробированное в Комплексной системе защиты информации (КСЗИ) "Панцирь-К" для ОС Windows 2000/XP/2003 (разработка ЗАО "НПП "Информационные технологии в бизнесе", сертификат ФСТЭК №1144 от 17.01.2006).

Требования нормативных документов

Требования к корректности реализации механизмов защиты сформулированы в действующем сегодня нормативном документе (Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации). Например, в части реализации разграничительной политики доступа к объектам файловой системы, для средств, предназначенных для защиты конфиденциальной информации (5 класс СВТ), данные требования формулируются следующим образом:

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

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

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

Заметим, данные требования (данный нормативный документ) используются при сертификации средств защиты, с целью проверки корректности реализации заявляемых в средстве механизмов защиты. Естественно, что чем более полно (чем однозначнее) будут сформулированы данные требования, тем эффективнее будут и средства защиты.

Требования к достаточности – полноте набора механизмов защиты применительно к условиям использования сформулированы в действующем сегодня нормативном документе (Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации).

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

В части защиты конфиденциальной информации это требования к классу АС 1Г.

Применительно к вопросам реализации разграничительной политики доступа к ресурсам достаточно остановиться на следующем всеобъемлющем требовании:

• Должен осуществляться контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа.

В порядке замечания отметим, что требования к иным группам АС (2 и 3) в современных условиях теряют свою актуальность. Это обусловлено тем, что в современных системах (например, ОС Windows и Unix) всегда должны быть заведены, по крайней мере, две учетные записи – администратора и пользователя, права доступа к ресурсам для которых принципиально различаются (работа пользователя под учетной записью администратора принципиально недопустима, если мы говорим о защите информации, т.к. именно на разделении их привилегий строится вся защита современных ОС).

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

Продолжим свои исследования на простом примере. Поясним суть требования: "Есть ресурс – к нему должен контролироваться доступ, не контролируется доступ – не должно быть ресурса". Например, нет контроля доступа к реестру ОС (этот ресурс всегда присутствует в системе), средство не самодостаточно – необходимо дополнительное средство, реализующее подобный контроль. Или нет контроля доступа к сетевым ресурсам, например, к хостам, средство не самодостаточно для защиты компьютеров в сети – необходимо дополнительное средство, реализующее подобный контроль, либо следует использовать данное средство исключительно для защиты автономных компьютеров.

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

Тому, кто когда-либо касался вопросов аттестации, сразу на ум приходит решение, состоящее в использовании организационных мер (у нас почему-то, если набор механизмов защиты недостаточен, вспоминают об организационных мерах). Очевидно, что никакие организационные меры здесь не применимы (если мы пытаемся решить задачу защиты не формально – на бумаге). Да и требования к организационным мерам вполне однозначно определено в нормативном документе. Для АС класса 1Г данные требования состоят в следующем:

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

С учетом всего сказанного, можем сделать крайне важный вывод.

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

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

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

Применение данного механизма защиты позволяет сформулировать следующее общее правило выполнения требования к достаточности, механизмов, применительно к условиям использования средства защиты:

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

Видим, что при использовании данного правила нет каких-либо неоднозначностей в части определения возможности использования СЗИ от НСД в конкретных приложениях, а также оценки достаточности СЗИ от НСД для данных приложений. Кроме того, вполне однозначно (без выдумывания каких-то организационных мер) определяются и пути выполнения требований к достаточности.

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

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

Однако, вернемся к нашему исследованию.

Требования к корректности механизма управления монтированием (подключением/отключением) ресурсов (устройств).

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

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

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

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

А как иначе маркировать внешний накопитель и при этом быть уверенным, что именно он используется для хранения конфиденциальных данных (не будем забывать, что на сегодняшний день именно угроза хищения данных санкционированным пользователем, доминирует, т.е. рассматривается в качестве наиболее вероятной)?

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

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

Реализация механизма управления монтированием (подключением/отключением) устройств.

Реализация одного и того же механизма защиты различными коллективами разработчиков может сильно различаться. Мы не будем пытаться здесь сравнивать свои подходы к реализации данного механизма с решениями иных производителей (в конечном счете, это дело потребителя СЗИ от НСД). Мы просто приведем в качестве примера краткое описание того, как реализован данный механизм в Комплексной системе защиты информации (КСЗИ) "Панцирь-К" для ОС Windows 2000/XP/2003.

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

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

Механизм защиты реализован программно, в виде системного драйвера (здесь, как в иных механизма защиты КСЗИ, не используются возможности встроенных в ОС механизмов защиты), имеет собственный интерфейс, для доступа к которому администратору необходимо авторизоваться.

Интерфейс механизма защиты представлен на рис.2.

Для настройки механизма защиты, как ранее отмечали, сначала администратору следует выбрать контролируемые классы устройств (рис. 2). В результате этого механизмом защиты будет контролироваться подключение устройств только входящих в выбранные классы. Затем для каждого контролируемого класса устройств следует задать политику, (рис. 3), а для каждого устройства задать разрешение/запрет его подключения (рис. 4). Заданные настройки отобразятся в окне интерфейса (рис. 2).

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

Как отмечалось ранее, в общем случае (для реализации требований к индуктивности модели безопасности, что обеспечивает корректность реализации механизма защиты) необходимо использовать разрешительную политику. При этом подключение иного устройства, кроме заданных администратором, становится невозможным. Т.е., если для класса устройств "Установить разрешительную политику" (рис.3), то подключить к системе можно будет только те устройства данного контролируемого класса, для которых будет установлено "Разрешить подключение устройства" (рис.4).

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

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

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

Наличие серийного номера устройства и собственно номер можно узнать из интерфейса, выбрав для соответствующего устройства закладку "Информация" (рис.5). Справочная информация, представляемая по устройству, и вид ее представления проиллюстрированы на рис.6.

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