Окончание. Начало: Как защищать конфиденциальную информацию и персональные данные в современных условиях?

4. Задача противодействия инсайдерским атакам. Способ решения.

Возвращаясь к рис.3, видим, что, прежде всего, для потребителей средств защиты сегодня актуально решение задачи защиты от утечки данных. Посмотрим, как отреагировал «рынок» на подобную потребность. Появился целый класс достаточно простых в реализации решений, основанных на использовании механизмов контроля исходящей с защищаемого компьютера информации, в том числе, и контентного контроля. Это решения сродни сигнатурным анализаторам, о которых поговорим далее, эффектны (на «красочных» примерах можно проиллюстрировать их роль в решении задач защиты информации) и просты в использовании (не требуют какой-либо квалификации от администратора), но мало эффективны, а во многом, просто бесполезны (о подобных решениях уже много сказано, не будем здесь более подробно останавливаться на их рассмотрении).

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

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

Заметим, что и какой-либо контроль-то исходящей информации имеет смысл только при условии регламентирования информационных потоков обмена конфиденциальной информации в АС предприятия, а что иначе контролировать, если не определено, что запрещено?

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

Формирование режимов обработки категорированной информации состоит в подключении соответствующего набора ресурсов при обработке информации каждого уровня конфиденциальности.

Изолирование режимов обработки категорированной информации состоит в противодействии любой возможности изменения режима обработки (санкционированного набора ресурсов) информации каждого уровня конфиденциальности.

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

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

Рассматриваемый подход к реализации защиты от инсайдерских атак состоит в реализации разделительной политики доступа к ресурсам, проиллюстрированной на рис.5. 

 1.jpg

Рис.5. Иллюстрация рассматриваемого подхода к реализации защиты от инсайдерских атак

По сути, реализовав данный подход, мы получаем реализацию управления потоками конфиденциальной информации в АС предприятия.

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

- субъект может читать объект, только если иерархическая классификация в классификационном уровне субъекта не меньше, чем иерархическая классификация в классификационном уровне объекта, и иерархические категории вклассификационном уровне субъекта включают в себя все иерархические категории вклассификационном уровне объекта;

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

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

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

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

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

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

Ролевая модель компьютерной безопасности в КСЗИ « Панцирь» реализуется следующим образом:

·               для каждого пользователя создается число учетных записей по числу его ролей;

·               для каждой учетной записи определяются файловые объекты (папки), в которых будет храниться информация, обрабатываемая в рамках реализации роли;

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

·               изолируется возможность обмена информацией между учетными записями различных ролей (в КСЗИ реализуется механизмом разделения между учетными записями файловых объектов, не разделяемых системой и приложениями, механизмом разделения буфера обмена – в ОС Windows буфер обмена принадлежит не учетной записи, а «рабочему столу» - не разделяется системой при многопользовательском режиме, например, при запуске программы по правой кнопке «мыши» под другой учетной записью).

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

 image019.jpg

Рис. 6. Интерфейс механизма переназначения путей к каталогам

Данный механизм защиты КСЗИ позволяет разделить любую папку между учетными записями. При этом для каждой учетной записи создается собственная папка, в которую для нее перенаправляются обращения, осуществляемые под данной учетной записью к исходной неразделяемой системой, либо приложением, папке. Исходная же папка становится «виртуальной», к ней невозможно обратиться ни под одной учетной записью.

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

Замечание. С целью упрощения задачи администрирования средства защиты (с учетом увеличения числа настроек пропорционально количеству ролей одного пользователя), в КСЗИ « Панцирь» принципиально изменен (по сравнению с реализацией в современных ОС) подход к построению интерфейсов настройки механизмов защиты – права доступа назначаются пользователям, а не присваиваются объектам, минимизировано число атрибутов доступа (многие из которых устанавливаются системой автоматически), исключена сущность «Владения», как таковая и т.д.

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

 image021.jpg

Рис.7. Интерфейс настройки разграничений прав доступа пользователей к объектам файловой системы 

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

Замечание. Как видно из рис.7, такой сложный механизм защиты, как замкнутость программной среды, задается несколькими записями в интерфейсе (пользователю User1 здесь разрешен запуск программ только из каталогов Windows и Program Files, которые ему запрещено модифицировать – не разрешены для записи).

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

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

5. Задача противодействия внешним угрозам и защита системных ресурсов. Способы решения.

5.1.         Защита от атак на уязвимости приложений.

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

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

Для иллюстрации сказанного, приведем, например, известную укрупненную классификацию вирусных атак:

1."Вредные программы" (трояны и т.п.). Отдельные программы, которые выполняют те или иные деструктивные/несанкционированные действия.

2. «Вирусы». Программы, обычно не имеющие собственного исполняемого модуля и "живущие" (как правило, заражение осуществляется по средством их присоединения к исполняемому файлу) внутри другого файлового объекта или части физического носителя.

3. «Черви». Разновидность 1,2,4, использующая сетевые возможности для заражения.

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

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

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

Ø    Критичные процессы. К ним мы отнесем две группы процессов: к процессам первой группы отнесем те, которые запускаются в системе с привилегированными правами, например, под учетной записью System, для которой механизмы защиты ОС не реализуют разграничительную политику доступа к ресурсам в полном объеме, к процессам второй группы те, которые наиболее вероятно могут быть подвержены атакам, например, это сетевые службы. Атаки на процессы первой группы наиболее критичны, что связано с возможностью расширения привилегий, в пределе – получения полного управления системой, атаки на процессы второй группы наиболее вероятны.

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

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

Таким образом, угрозу атаки, может нести в себе собственно процесс, а причин подобных угроз множество. В подтверждение сказанному немного статистики (за 1 квартал 2008 года, см. рис.8, рис.9).

 image023.jpg

Рис.8

 image024.jpg

Рис. 9

Всего исправлено 505 уязвимостей (57.58%), исправления отсутствуют для 350 уязвимостей (39.91%), для 14 уязвимостей производители опубликовали инструкции по устранению и 8 уязвимостей устранены частично.

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

Для защиты информации от недекларируемых (не описанных в документации) возможностей приложений – ошибки и закладки, теоретически могут использоваться антивирусные средства защиты, широко сегодня представленные на «рынке». Большинство из них базируется на основе методов сигнатурного, либо эвристического анализа. Об эффективности подобных решений уже сказано не мало. Но, чтобы лучше это прочувствовать, приведем небольшую аналогию. Контроль наличия в ПО недекларируемых возможностей осуществляется путем анализа исходных текстов программы (так называемый, контроль на наличие НДВ), продолжительность которого, как правило, составляет несколько месяцев. При этом заметим, что и в результате проведения подобного контроля (по крайней мере, за понятное время), никто не даст гарантий того, что НДВ в ПО отсутствуют. А здесь, в реальном масштабе времени по какому-то конечному списку сигнатур! Наверное, для защиты домашнего компьютера подобный подход оправдан (лучше что-то, чем ничего), но мы говорим о корпоративных приложениях – о защите конфиденциальной информации и персональных данных!

Решение задачи защиты механизмами КСЗИ «Панцирь»:

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

Интерфейс настройки механизма КСЗИ, реализующего разграничения прав доступа процессов к файловым объектам, представлен на рис.10.

 image025.jpg

Рис.10. Интерфейс настройки разграничений прав доступа процессов к объектам файловой системы 

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

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

1.   Операционная система - Microsoft Windows XP;

2.   Рассматриваемые офисные приложения – Microsoft Office Word 2003, Microsoft Office Excel 2003, Microsoft Office Outlook 2003;

3.   Операционная система установлена на диске F;

4.   Все приложения инсталлированы в каталог F:\Program files;

5.   Обработка информации осуществляется под учетной записью User 1;

6.   Для хранения обрабатываемых данных пользователем используется каталог F:\OOD1.

К защищаемым системным ресурсам в данных предположениях, в первую очередь, следует отнести каталоги F:\Windows и F:\Program files и объект реестра HKEY_LOCAL_MACHINE.

Пример единой разграничительной политики доступа процессов к системных ресурсам (обеспечивающей корректное их функционирование) для наиболее часто используемых офисных приложений: Microsoft Office Word 2003, Microsoft Office Excel 2003, Microsoft Office Outlook 2003, приведен в табл.1.

Таблица 1
Единые разграничения к системным ресурсам для процессов офисных приложений
 

Файловые ресурсы
Разрешенные для чтения
Разрешенные для записи и чтения
Разрешенные для выполнения
F:\DOCUMENTS AND SETTINGS\
ALL USERS\
APPLICATION DATA\
MICROSOFT\
OFFICE\
DATA\
OPA11.BAK
 
F:\XP\*
 
F:\PROGRAM FILES\*
F:\DOCUMENTS AND SETTINGS\USER1\*
 
F:\DOCUMENTS AND SETTINGS\ALL USERS\APPLICATION DATA\MICROSOFT\OFFICE\
DATA\OPA11.DAT
 
 
F:\XP\*
 
F:\PROGRAM FILES\*
 
Ресурсы реестра
Запрещенные для чтения
Разрешенные для записи и чтения
-                
 
                             HKCU\*
 

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

5.2. Защита от атак на уязвимости ОС.

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

image027.jpg

Рис. 11

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

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

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

Решение задачи защиты механизмами КСЗИ «Панцирь»:

·               Предотвращение возможности компрометации системы достигается реализацией разграничительной политики доступа к системным файловым объектам и к объектам реестра для процессов (см. выше). КСЗИ предоставляется возможность задавать разграничения для процессов совместные с правами доступа пользователя (по «И»), либо эксклюзивные («по «ИЛИ»). Таким образом, учетной записи System можно запретить право модификации системного диска, а нескольким системным процессам (5-7 для различных ОС), например, winlogon, svhost и др. данное право доступа разрешить. В результате система будет корректно функционировать, несанкционированно изменить систему и ее настройки становится невозможно даже с системными правами. То же относится и к объектам реестра ОС;

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

Интерфейс настройки механизма КСЗИ, реализующего контроль сервисов олицетворения, представлен на рис.12.

image029.jpg

Рис. 12. Интерфейс настройки механизма проверки олицетворения субъектов доступа

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

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

Для рассмотрения данного примера настройки, напомним, что системным процессом winlogon осуществляется регистрация входа нового пользователя в систему. При регистрации нового пользователя, потоки, запускаемые процессом winlogon (с правами System), олицетворяют себя с правами регистрируемого пользователя. Как следствие, если разрешить для процесса winlogon олицетворение System с определенными учетными записями (см. рис.12), то вход в систему станет возможен только под этими учетными записями, вне зависимости от того, какие еще (санкционировано, либо нет) учетные записи заведены в системе.

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

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