С какой версии windows стало возможным создать замкнутую программную среду для пользователей
Обновлено: 30.06.2024
Ещё не так давно Windows была обречена. Разработчики покупали оборудование Apple, и каждый доклад на технических конференциях освещался сотнями светящихся логотипов Apple. В этом нет ничего удивительного: под капотом macOS является производной от BSD-Unix, что позволяло разработчикам быстро устанавливать на своих ноутбуках те же наборы инструментов, что и на их серверах или в облаке. В случае отсутствия нужных приложений, разработчики могли установить виртуальную машину Parallels Desktop и запускать нужные приложения для Windows, как если бы они были частью рабочего стола macOS.
Разработчики – первопроходцы. Куда бы они ни пошли, все в конечном итоге последуют за ними. Пришло время для Windows измениться, предоставив среду, ориентированную на разработчиков, без изменения способа использования ПК всеми остальными. Это было сложной задачей для Microsoft, но компания прошла долгий путь к ее решению. Теперь разработчики снова покупают ПК, и эти светящиеся яблоки больше не доминируют в конференц-залах.
Смена Windows, оборудования и программного обеспечения
Как это произошло и, что более важно, как это произошло так быстро? Частично эта история связана с переходом Microsoft на аппаратное обеспечение при пониманием того, что сочетание аппаратного и программного обеспечения Apple было большой причиной ее успеха. Это привело к появлению линейки устройств Surface с высококачественным дисплеем формата 4:3, а также с удобными для разработчиков высококачественными устройствами Surface Book и Surface Laptop, которые поставляются с мощными процессорами и видеокартами, большим объемом памяти, а так же с отзывчивой клавиатурой.
Поскольку разработчики подолгу сидят за экранами, создание правильного оборудования было первым шагом на этом пути. Теперь Windows должна была стать лидером среди операционных систем, привлекательных для разработчиков. Так переход от Windows 8 с сенсорным управлением к гибридной среде Windows 10 стал большим стимулом для перемен. Новая операционная система сохранила функции мультитача и планшета Windows 8, но объединила их со знакомым меню и окнами Windows 7.
Хотя оборудование Surface помогло вернуть разработчиков, модель Windows 10 «Windows как услуга» с двумя выпусками в год позволила Microsoft быстрее реагировать на запросы разработчиков, чем в более ранних версиях Windows. В то же время компания начала отделять SDK и инструменты разработчиков от монолита Windows, заменяя редкие обновления более последовательным циклом выпуска и более быстрым исправлением ошибок.
Терминал – дорога к разработчикам
По большей части это связано с тем, что Microsoft давно описывает как «движение туда, где находятся разработчики». Это означало переосмысление кода, который старше Windows, рефакторинг того, как компания делает документацию, и выход за рамки традиционных ограничений и соперничества, которые ограничивали Windows одним способом работы.
Одним из ключевых достижений является разработка нового терминала – Windows Terminal. Заменив старый cmd.exe, новый терминал использует современный подход к командной строке, используя уроки, извлеченные из Linux и кроссплатформенных приложений терминалов. Windows Terminal можно установить и из магазина Microsoft Store и из репозитория GitHub. Последние сборки поддерживают многопанельные представления в окне, полноцветную поддержку, а также поддержку окон с несколькими вкладками, поэтому вы можете работать с несколькими терминалами одновременно.
Новый терминал от Microsoft упрощает разработчикам работу в Windows или, например, с удаленными серверами при использовании недавно добавленной в Windows встроенной поддержки SSH для безопасных подключений (одна из первых функций Windows, которая зависит от проекта с открытым исходным кодом). Поскольку Windows Terminal поддерживает 24-битный цвет и стандартные соединения ANSI, вы можете перейти из знакомой командной строки Windows прямо к удаленной системе Linux без изменения контекста и с полной поддержкой всех функций терминала Linux.
Linux в Windows
Одновременно с запуском терминала с открытым исходным кодом Microsoft представила вторую итерацию своей подсистемы Windows для Linux (WSL 2). Первоначальный WSL 1 был разработан для обеспечения эмулируемой среды Linux с использованием набора инструментов для преобразования системных вызовов Linux в вызовы Windows, что позволяло запускать код в Windows. Идея заключалась в том, чтобы ключевые элементы цепочки инструментов Linux могли работать в Windows, что в свою очередь предоставит разработчикам возможность работать со знакомыми инструментами и тестовым кодом, не покидая своего ПК.
WSL оказался очень популярным инструментом среди разработчиков, тем более Apple поменяла способ поддержки UNIX в macOS.Сосредоточившись на облачных моделях разработки, таких как контейнеры, Microsoft превратила Windows в портал для разработчиков.
Во втором выпуске WSL использовался другой подход, основанный на низкоуровневом гипервизоре Microsoft Krypton. Являясь частью семейства Hyper-V, Krypton тесно связан с ядром Windows, что позволяет лучше распределять ресурсы между хостом и виртуализированной ОС. Krypton также используется для обеспечения безопасности на основе виртуализации в Windows 10, запускает изолированную тестовую среду Windows Sandbox и режим Application Guard в браузере Microsoft Edge.
С WSL 2 компания Microsoft теперь поставляет собственное ядро Linux и упрощает поддержку контейнеров Linux в Windows. Реализация Docker для Windows теперь основана на WSL 2, что упрощает создание и тестирование контейнеров Linux в Windows перед их развертыванием в Kubernetes в облаке. С контейнером, работающим в Windows, вы можете использовать режим удаленного редактирования Visual Studio Code для работы с кодом внутри контейнера, что дает вам бесшовную среду разработки с редактором и отладчиком внутри контейнера и графическим интерфейсом пользователя, работающим внутри Windows.
Комбинация популярного редактора и конвергентной кроссплатформенной среды разработки оказалась именно тем, чего не хватало в Windows для разработчиков. Вдохновленные линейкой устройств Surface, поставщики оборудования, такие как Dell, Lenovo и Razer, начали поставлять ориентированные на разработчиков ноутбуки, которые дополнили изменения в Windows и предоставили как индивидуальным, так и корпоративным разработчикам доступ к выбору оборудования.
Воспользуйтесь скриптом для установки инструментов с помощью Winget
Остальные изменения менее очевидны. Microsoft работает над улучшением установки приложений и инструментов с намерением предоставить скрипты для установки всего набора инструментов. Вы, конечно, можете использовать сторонний установщик, например, Chocolatey, но Microsoft экспериментирует с двумя собственными подобными инструментами.
Первый инструмент – интеграция командной строки Windows с магазином Microsoft Store. Просто введите «python», и Windows предложит установить популярный язык программирования из Microsoft Store. Добиться подобного удалось благодаря сотрудничеству между проектом Python с открытым исходным кодом и разработчиками командой командной строки Windows и магазином Microsoft Store.
Компания Microsoft сейчас разрабатывает инструмент установки, управляемый из командной строки. Winget работает с размещенным на GitHub репозиторием манифестов пакетов, которые ссылаются на загружаемые установщики. Манифест содержит подробную информацию о приложении с управлением версиями и поддержкой различных установщиков, которые поддерживают разные архитектуры процессоров.
Добавление удобных для разработчиков настроек и функций в Windows
Другие удобные для разработчиков функции появляются в надстройках, таких как набор утилит Microsoft PowerToys. С помощью PowerToys вы можете настроить опцию Fancy Zones для управления макетами экрана, добавить поддержку предварительного просмотра изображений SVG в проводнике, изменить размер изображений и настроить средство запуска приложений на основе поиска. Power Toys – это проект с открытым исходным кодом, в который регулярно добавляются новые функции – одна из последних – это список комбинаций клавиш Windows, который идеально подходит для разработчиков.
Обеспечение хорошего взаимодействия с разработчиками не является задачей какой-либо одной группы в Microsoft или в Windows. Это требует согласования множества различных движущихся частей, поэтому наблюдение за работой Microsoft по охвату этого и других аспектов взаимодействия с разработчиками Windows и разработчиками инструментов является важным событием. Поскольку собственные инструменты разработчиков Windows претерпевают серьезные изменения, следующие несколько месяцев должны стать очень интересными для разработчиков, как тех, кто использует Windows, так и тех, кто создает для Windows.
Следует иметь в виду, что режим автоматического добавления исполняемых модулей в список ЗПС часто добавляет не все возможные приложения. Поэтому администраторам безопасности можно рекомендовать список разрешенных к запуску программ создавать вручную. Делается это, например, для ресурсов Documents and Settings, Program Files, WINDOWS и ряда специальных программ.
Механизм замкнутой программной среды (ЗПС) надежно защищает систему от запуска пользователем несанкционированных приложений. Так, в случае несанкционированного создания пользователем исполняемого файла в разрешенном каталоге, например, в папке «C:\WINDOWS», он не будет входить в список ЗПС. Подменить исполняемый файл, разрешенный к запуску, также невозможно, так как для каждого исполняемого модуля из списка ЗПС вычисляется контрольный эталон по одному из пяти алгоритмов (CRC7, ЭЦП, ХЭШ, имитов ставка, полное совпадение).
Другая полезная особенность реализации замкнутой программной среды (ЗПС) в СЗИ НСД - это возможности автоматизированного построения списка разрешенных для запуска программ. В СЗИ Secret Net это сделано несколькими способами. Во-первых, может использоваться информация из системного реестра Windows, сохраненная службой Installer: какие файлы были записаны на жесткий диск и какие добавления внесены в реестр при установке приложения. Во-вторых, за основу может быть взят программный ярлык приложения: анализируется, какой исполняемый файл запускается этим ярлыком, какие вызовы динамических библиотек DLL и других программных модулей содержатся в исполняемом коде этого файла.
реализована политика "запрещено все, что явно не разрешено";
используется указание полных путей к файлам (позволяет предотвратить запуск одноименных программ с ГМД, CD-ROM или сетевого диска);
запрет модификации (злоумышленник не сможет изменить существующую программу или подменить ее);
автоматизированная процедура построения списка разрешенных для запуска программ (наличие "мягкого режима" замкнутой программной среды).
Механизм замкнутой программной среды на этапе ввода в эксплуатацию может применяться в "мягком" режиме работы. Данный режим позволяет автоматизировать процедуру построения списка разрешенных для запуска программ. При "мягком" режиме пользователю разрешен запуск программ, не входящих в список замкнутой программной среды. При этом в системном журнале запуск программ, не входящих в список замкнутой программной среды, регистрируется как событие НСД. Система Secret Net анализирует записи журнала регистрации и автоматически составляет список всех программ, которые запускал пользователь.
9) Охарактеризуйте способ защиты пароля при создании доверенного канала при вводе пароля в систему (требовать нажатие клавиш Ctrl+Alt+Delete при входе в систему).
Справочник
Этот параметр безопасности определяет, нажав клавиши CTRL + ALT + DEL необходима ли прежде чем пользователь может войти в систему.
Если этот параметр политики включен на устройстве, пользователь должен нажать сочетание клавиш CTRL + ALT + DEL для входа на необязателен. Нет необходимости нажмите сочетание клавиш CTRL + ALT + DEL оставляет уязвимыми для атак, которые пытаются перехватить паролей пользователей. Требование сочетание клавиш CTRL + ALT + DEL, прежде чем пользователи выполняют вход гарантирует, что пользователи взаимодействуют доверенным каналом при вводе паролей.
Если эта политика отключена, любой пользователь, необходимо нажать сочетание клавиш CTRL + ALT + DEL перед входом в операционной системе Windows (если они используют смарт-карты для входа в систему).
Рекомендации
· Рекомендуется устанавливать Отключить требование сочетание клавиш CTRL + ALT + DEL для входа в систему не настроено.
Уязвимость
Этот параметр упрощает для пользователей с некоторыми типами физических нарушениями для входа на устройствах под управлением операционной системы Windows. Тем не менее если пользователи не обязаны нажмите сочетание клавиш CTRL + ALT + DEL, они являются уязвимыми для атак, которые пытаются перехватить паролей. Если требуется сочетание клавиш CTRL + ALT + DEL перед входом, доверенным каналом передаются паролей пользователей.
Если этот параметр включен, злоумышленник может установить вредоносное ПО, которое выглядит как стандартный входа в систему поле в операционной системе Windows и записывать пароль пользователя. Злоумышленник будет войти на учетную запись с любой уровнем привилегий у этого пользователя.
Противодействие
Отключить Интерактивный вход в систему: не требовать нажатия CTRL + ALT + DEL параметр.
Упрощать реальный мир, чтобы потом успешно разрабатывать всякие теории для мира вымышленного – нормальный процесс для всех наук. У физиков целый набор таких артефактов: идеальный газ, материальная точка, абсолютно твердое тело, несжимаемая жидкость и пр.
И что самое характерное – работает! Уравнение Менделеева-Клапейрона прекрасно описывает вполне реальный газ, а классическая механика великолепно справляется с расчетом движения тел различного масштаба (пока этот масштаб не уходит в микромир или наоборот – в область действия общей теории относительности).
По-умному такой процесс называется моделирование методом редуцирования – т.е. мы максимально упрощаем реальную систему, получаем математическую модель, которая позволяет прогнозировать поведение системы, а потом оказывается, что и реальная система удовлетворяет выявленным закономерностям.
Подобный подход применяется и в сфере информационной безопасности. Сегодня мы посмотрим на один из таких артефактов – изолированную программную среду и как эта среда позволяет решать задачи обеспечения ИБ в реальных системах.
2. Как моделирование безопасности стало наукой
Но начнем мы с истории вопроса: в 70-ые годы прошлого века произошло одно крайне важное событие для сферы информационной безопасности: министерство обороны США купило компьютер. Примерно такой:
Компьютер Honeywell-6080. Девушка на фото то ли для привлечения внимания, то ли для масштаба…
Поскольку это были времена, когда деревья были маленькими, а компьютеры большими – у Министерства обороны США хватило денег (или места) только на один такой компьютер. Естественно, на нем предполагалось обрабатывать какие-то секретные данные министерства, но в это же время уже появился предвестник Интернета – ARPANET, и сотрудникам министерства очень хотелось не только работать с секретными данными, но и постить котиков…
В результате возникла задача: нужно сделать так, чтобы на большом компьютере можно было обрабатывать информацию как секретную, так и несекретную. При этом среда должна быть многопользовательской, а среди пользователей будут не только сотрудники министерства, но и всякие штатские из ARPANET’а (а штатским, как известно, доверия нет).
Так и появился Project No. 522B – научно-исследовательский проект, задачей которого было… Ну, судя по результатам этого проекта, его задачей было создать дисциплину «Теоретические основы компьютерной безопасности» – практически все концепции, используемые в защитных мерах современных программных продуктах, были описаны в отчетах по проекту 522B.
Скриншоты оригинальных отчетов по проекту 522B: монитор ссылок (монитор безопасности), домены безопасности и матрица доступа – лишь малая часть теоретических концепций, разработанных за время проекта
Можно отдельную статью написать (и, если будет интересно – обязательно напишу!) про результаты исследований проекта 522B, а также про легендарных личностей мира информационной безопасности, которые в нем участвовали. Но нас интересует лишь только конкретное направление: субъектно-объектная модель целостности компьютерной системы.
3. Субъектно-объектная модель целостности компьютерной системы простыми словами
Итак, мы уже определились, что для успешного построения теоретической модели системы, в которой можно просто решить задачу обеспечения безопасности, надо исходную систему как-то упростить.
Такое упрощение нашли быстро: будем рассматривать всю систему как совокупность субъектов (т.е. активных сущностей, например, процессов) и объектов (т.е. пассивных сущностей, например, файлов данных). Субъекты будут как-то взаимодействовать с объектами, т.е. осуществлять доступ (или создавать информационный поток). Все варианты доступа (некоторое множество P) мы разделим на санкционированный доступ (PL) и несанкционированный доступ (PN).
Однако, это слишком уж упрощенная модель… Давайте попробуем сделать ее немного ближе к реальности:
1. Субъекты могут появляться и пропадать – ведь в компьютерных системах могут запускаться и останавливаться различные процессы. При этом субъект не может взяться из ниоткуда – в реальной системе есть некоторые данные, из которых создается субъект (исполняемый файл, скрипт и пр.), т.е. в начале всегда будет какой-то объект.
2. На поведение субъекта могут влиять объекты. Например, если объект – это конфигурация процесса.
3. Объекты могут меняться (зачем-то же субъекты получают к ним доступ? Вот и будем считать, что для того, чтобы что-то поменять).
4. За реализацией политики разграничения доступа (т.е. за тем, что доступ принадлежит PL) также должен следить специальный субъект (который мы назовем монитором безопасности).
5. И у монитора безопасности тоже есть связанные объекты, которые влияют на его работу – те, что содержат описание PL.
Ну и чтобы совсем усложнить жизнь, давайте также отметим, что доступ субъекта S к объекту O в момент времени t1 и момент времени t2, это, вообще говоря, два разных доступа – потому что за прошедшее с момента t1 время и субъект S, и объект O могли поменяться. А это значит, что наше множество P уже так запросто не описать – оно содержит бесконечное число элементов!
В моменты t1 и t2 субъект S1 получает доступ к объекту O2, но это уже совсем другой субъект и совсем другой объект…
Как же в таком хаосе гарантировать, что доступы будут только из PL, если теперь даже непонятно, как это PL описать?
Давайте для начала посмотрим внимательнее на объекты, которые влияют на поведение субъекта (т.е. те самые аналоги исполняемого файла, конфигурационных файлов и пр.). Пусть у нас есть всего 2 субъекта, и мы знаем все объекты, которые влияют на поведение этих субъектов. Такие объекты называют ассоциированными с субъектом.
Если мы можем гарантировать, что каждый субъект не может получить доступ (или создать информационный поток) к ассоциированным объектам своего соседа, то мы назовем такие субъекты корректными друг относительно друга. А если наборы ассоциированных объектов этих субъектов между собой не пересекаются, то мы их назовем абсолютно корректными друг относительно друга:
С этим определением мы можем сформулировать критерий гарантированного выполнения политики доступа в системе: если в начальный момент времени все субъекты абсолютно корректны друг относительно друга, и они могут осуществлять доступы (формировать потоки) только из PL, то и дальше с течением времени они смогут осуществлять доступы только из PL. Такой набор субъектов как раз и называют абсолютно изолированным множеством субъектов.
Казалось бы, вот и решение задачи! Но не тут-то было… Ведь по сути это означает, что у нас, например, в многопользовательской системе каждый пользователь работает за своим изолированным компьютером, который не может общаться с компьютером соседа. Хорошая многопользовательская система получается – весь обмен информацией возможен только через пользователей…
Не буду мучить дальнейшими математически-акробатическими номерами, а перейду сразу к более конструктивному варианту утверждения, позволяющего реализовать изолированную программную среду в реальной жизни, а не только в бурной фантазии безопасника-теоретика.
Давайте введем в нашей модели еще одну функцию безопасности: пусть создание нового субъекта S из объекта O возможно только, если объект O не менялся с начального момента времени (это называется «порождение субъекта с контролем целостности»). Это маленькое дополнение сильно меняет ситуацию:
Цепочка сломалась на том, что изменение объекта O1 в момент времени t1 уже не позволило создать измененный субъект S1
Самое важное изменение в том, что теперь у нас гарантировано конечное количество вариантов субъектов в системе, сколько бы времени она не работала. Ведь создать мы можем субъекты только из какого-то фиксированного, конечного множества объектов.
И, казалось бы, такая мелочь дает нам уже понятный алгоритм действий.
Мы можем описать множество PL для всех субъектов и всех объектов так, чтобы обеспечить свойство корректности субъектов друг относительно друга (важно, что не идет речи об абсолютной корректности, а значит субъекты могут порождаться из одного и того же объекта). Это множество конечно – так как конечно количество объектов в начальный момент, а также конечно множество создаваемых субъектов. А дальше мы можем быть уверены, что с течением времени ничего не изменится: не появится какого-то нового субъекта, который сможет обойти ограничения монитора безопасности и переписать нашу политику, так как действует порождение с контролем целостности.
Осталось убедиться, что этот подход действительно можно перевести с языка математического в функции реальной системы и сохранить полученное свойство безопасности системы. Давайте этим и займемся.
4. Изолированная программная среда в реальной жизни
Для начала решим (спустя полвека) задачу Министерства обороны США: Чтобы обеспечить безопасную работу пользователей за их единственным большим компьютером, необходимо реализовать:
1. Расширение ОС, которое будет контролировать целостность исполняемого файла перед запуском ПО. Если целостность нарушена – ничего запускаться не будет.
2. Политику разграничения доступа (например, в виде матрицы доступа), где будет прописано какое ПО к каким файлам может получать доступ (в первую очередь на запись, так как основная проблема, с которой мы боремся – это изменение алгоритма работы системы, который позволит нарушить политику безопасности системы). Причем в первую очередь нас интересуют исполняемые файлы ПО (и компоненты ядра ОС), а также всевозможные файлы данных, влияющих на алгоритм работы ПО.
Но это, когда компьютер один. Сложнее, когда у нас современная система, состоящая из множества компонентов, связанных между собой посредством локальной сети. Да, тут можно проявить железную волю и настроить не только локальное разграничение доступа, но и сетевое с помощью механизмов типа опций CIPSO протокола IP (к слову, и про это можно рассказать подробнее, если тема интересна…), но в гетерогенной среде это технически нереализуемо.
Поэтому давайте введем технические ограничения реальной системы, а затем посмотрим, как они бьются с теорией касательно изолированной программной среды:
1. Мы можем контролировать целостность субъектов. Однако не всегда есть возможность предотвратить создание субъекта, если целостность нарушена (как остановить загрузку ПО коммутатора, если мы обнаружили изменение его сохраненной конфигурации?).
2. Мы не всегда можем управлять доступом отдельных процессов к объектам. Тот же пример с коммутатором: во встроенном ПО коммутатора функционируют различные процессы, которые обращаются к различным объектам (файлам, отдельным записям, специальным объектам типа CAM-таблиц и пр.). Но штатного механизма задать какую-то матрицу доступа для этих субъектов и объектов у коммутатора нет.
3. Мы не можем управлять доступом субъектов к объектам, которые расположены на разных сетевых узлах. Точнее, теоретически это возможно – замкнуть все взаимодействие на межсетевой экран с мощной инспекцией прикладного трафика, прописать жесткую политику взаимодействия, которая будет аналогом матрицы доступа… Но на практике так делать никто не будет – от такого МЭ потребуются невероятные вычислительные ресурсы, а от его администратора – невероятная усидчивость, чтобы все это настроить.
Что же можно сделать с учетом перечисленных ограничений?
Во-первых, не надо отказываться от контроля целостности – исполняемые файлы, файлы конфигурацией (или более сложные объекты – базы данных, ключи реестра или объекты LDAP каталога) можно контролировать, в том числе, удаленно по сети.
Во-вторых, надо рассматривать взаимодействие в такой системе на двух уровнях «детализации»: когда субъекты и объекты – это сами сетевые узлы и когда это процессы и объекты внутри конкретного узла. «Контроль целостности» сетевого узла в таком случае – это неизменность состава узлов и неизменность каких-то сетевых параметров этих узлов (адрес, имя, список открытых портов и пр.).
В-третьих, матрицу доступа субъектов и объектов в масштабах сети мы можем заменить на наблюдение за сетевыми потоками (которые в данном случае аналогичны потокам между субъектами и объектами в модели): если исходить из предположения, что в начальный момент времени (который может быть совсем не моментом, а вполне себе протяженным интервалом) в системе все доступы (потоки) соответствуют множеству PL, мы можем их запомнить и считать нарушением обнаружение потока, который не попал в сформированное на начальном этапе множество. Единственное, надо понимать, что такое предположение корректно только для систем, работающих постоянно по одному и тому же алгоритму (ну или очень похожему) – по этой причине, модель изолированной программной среды хорошо подходит для всевозможных киберфизических систем, но она же будет крайне плохо применима в обычной «офисной» сети, где все может меняться каждую минуту.
Двухуровневая субъектно-объектная модель. На первом уровне рассматриваются потоки информации между сетевыми узлами, на втором - взаимодействие процессов внутри сетевого узла
Что же получается в итоге? Реализация изолированной программной среды – хороший способ обеспечения безопасности различных киберфизических систем (где, какая удача, как раз целостность является одним из наиболее важнейших свойств информации).
Изолированную программную среду для такой системы можно обеспечить путем корректной настройки механизмов безопасности отдельных узлов сети, а также с помощью выделенного устройства, которое должно уметь:
1. Вести каталог сетевых объектов и их сетевых параметров.
2. Отслеживать объекты (т.е. конфигурации, исполняемые файлы и пр.) на предмет их модификации. В частности, конфигурации мониторов безопасности отдельных устройств.
3. Контролировать схему информационных потоков между узлами сети и сигнализировать при обнаружении неизвестного потока (так как с большой вероятностью это поток из множества PN).
И вот мы получили перечень основных функций ICS Asset Management решений. Как говорится: «Совпадение? Не думаю!»:-)
Функции решений ICS Asset Management по версии Dale Peterson
Сегодня на рынке представлено достаточно много решений класса ICS Asset Management и Detection, но базовые функции у всех примерно одинаковые. А вы теперь знаете почему…
Механизм замкнутой программной среды позволяет определить для любого пользователя компьютера индивидуальный перечень программного обеспечения, разрешенного для использования. Система защиты контролирует и обеспечивает запрет использования следующих ресурсов:
· файлы запуска программ и библиотек, не входящие в перечень разрешенных для запуска и не удовлетворяющие определенным условиям;
Сценарий (называемый также "скрипт") представляет собой последовательность исполняемых команд и/или действий в текстовом виде. Система Secret Net 6 контролирует выполнение сценариев, созданных по технологии Active Scripts.
Попытки запуска неразрешенных ресурсов фиксируются как события НСД в журнале Secret Net.
На этапе настройки механизма составляется список ресурсов, разрешенных для запуска и выполнения. Список может быть сформирован автоматически на основании сведений об установленных на компьютере программах или по записям журналов, содержащих сведения о запусках программ, библиотек и сценариев. Также предусмотрена возможность ручного формирования списка. Для файлов, входящих в список, можно включить режим контроля целостности. По этой причине механизм замкнутой программной среды и механизм контроля целостности используют единую модель данных.
Механизм замкнутой программной среды не осуществляет блокировку запускаемых программ, библиотек и сценариев в следующих случаях:
· при наличии у пользователя привилегии "Замкнутая программная среда: Не действует" (по умолчанию привилегия предоставлена администраторам компьютера) — контроль запускаемых пользователем ресурсов не осуществляется;
· при включенном "мягком" режиме работы подсистемы замкнутой программной среды — в этом режиме контролируются попытки запуска программ, библиотек и сценариев, но разрешается использование любого ПО. Этот режим обычно используется на этапе настройки механизма.
Для формирования списков исполняемых файлов используется программа "Контроль программ и данных".
Примечание
Читайте также: