Сущность и улучшение системы защиты информации

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

Еще одно преимущество использования VLAN -- это упрощение сетевого администрирования. Особенно это касается таких задач, как добавление к сети новых элементов, их перемещение и удаление. Например, при переезде какого-либо пользователя VLAN в другое помещение, пусть даже находящееся на другом этаже или в другом здании предприятия, сетевому администратору нет необходимости перекоммутировать кабели. Ему нужно всего лишь со своего рабочего места соответствующим образом настроить сетевое оборудование. Кроме того, в некоторых реализациях VLAN контроль над перемещениями членов VLAN может осуществляться автоматически, не требуя вмешательства администратора. Операции по созданию новых логических групп пользователей, добавлению новых членов в группы сетевой администратор также может осуществлять по сети, не сходя со своего рабочего места. Все это существенно экономит рабочее время администратора, которое может быть использовано на решение других не менее важных задач/39/.

Таким образом, все рассмотренные СЗИ, в комплексе, обеспечивают информационную безопасность АСОД ФГУП «Ростехинвентаризация - Федеральное БТИ».

1.4 Определение требований по защите информации от несанкционированного доступа для АСОД ФГУП «Ростехинвентаризация - Федеральное БТИ»

Теперь необходимо проанализировать систему информационной безопасности ФГУП на соответствия требованиям выставляемым АС класса защищенности от НСД. Для этого необходимо сопоставить СЗИ, используемые на предприятии, с требованиями к подсистемам СЗИ АС от НСД. Более наглядно это будет выглядеть в виде таблицы (таблица 2.5).

Таблица 2.5 - Анализ системы информационно безопасности на ФГУП

Подсистемы и требования	СЗИ	Компетентность
1. подсистема управления доступом 1.1. Идентификация, проверка подлинности и контроль доступа субъектов в систему:	АD	Удовлетворяет в полной мере
К терминалам, ЭВМ, каналам связи, внешним устройствам ЭВМ;	АD, Firewаll, Брандмауэр	Удовлетворяет в полной мере
К программам;	АD, Электронные ключи	Удовлетворяет в полной мере
К томам, каталогам, файлам, записям, полям записей.	АD	Проблемы с наследованием прав доступа
1.2. Управление потоками информации	АD, VPN, VLАN, Firewаll, Брандмауэр	+
2. Подсистема регистрации и учета 2.1. регистрация и учет: входа/выхода субъектов доступа в/из системы (узла сети);	АD, SERVER 2003	+
Выдачи печатных (графических) выходных документов;	АD, SERVER 2003	+
Запуска/завершения программ процессов (заданий, задач);	АD, SERVER 2003	+
Доступа программ субъектов доступа к защищаемым файлам, включая их создание и удаление, передачу по линиям и каналам связи;	АD, SERVER 2003	+
Доступа программ субъектов доступа к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ, программам, томам, каталогам, файлам, записям, полям записей;	АD, SERVER 2003	+
Изменения полномочий субъектов доступа	АD, SERVER 2003	+
2.2. Учет носителей информации	SERVER 2003	+
2.3. Очистка (обнуление, обезличивание) освобождаемых областей оперативной памяти ЭВМ и внешних накопителей	SERVER 2003	+
3. Подсистема обеспечения целостности 3.1. Обеспечение целостности программных средств и обрабатываемой информации	Средства ОС	+
3.2. Физическая охрана средств вычислительной техники и носителей информации	Пропускной режим, Механические замки, Охранная сигнализация	+
3.3. Наличие администратора (службы) защиты информации в автоматизированной системе обработки данных	Присутствует	+
3.4. Периодическое тестирование средств защиты информации несанкционированного доступа	Отсутствует	-
3.5. Наличие средств восстановления средств защиты информации несанкционированного доступа	Архивирование	+
3.6. Использование сертифицированных средств защиты	Все средства сертифицированы	+

После рассмотрения удовлетворения требований к АСОД ФГУП от несанкционированного доступа, можно однозначно сказать, что требования выставляемые АС данного класса не удовлетворяются в полной мере, а именно:

1. Уязвимость в подсистеме управления доступом. Контроль доступа субъектов к томам, каталогам, файлам, записям, полям записей, проходит не корректно. Проблемы наследования прав доступа к томам, каталогам, файлам, записям, при создании сетевой папки на файловом сервере конкретного работника АС.

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

Из всего выше представленного можно сделать вывод, что система информационной безопасности не соответствует требованиям ГТК, по защите информации от несанкционированного доступа, в полной мере для предприятия данного типа. Таким образом, система информационной безопасности ФГУП нуждается в модернизации.

2.5 Определение подхода к повышению уровня защиты АСОД ФГУП «Ростехинвентаризация - Федеральное БТИ» на основе модернизации ПО разграничения доступа

В предыдущем пункте были выявлены следующие несоответствия требованиям ГТК для системы информационно безопасности АСОД ФГУП:

1. В подсистеме обеспечения целостности: отсутствие периодического тестирования средств защиты информации от несанкционированного доступа.

2. В подсистеме управления доступом: контроль доступа субъектов к томам, каталогам, файлам, записям, полям записей осуществляется не соответствующим образом.

Таким образом, возникла необходимость модернизации системы информационной безопасности предприятия.

Первый недостаток системы не так существенен, для его решения достаточно установить надлежащее ПО для тестирования СЗИ.

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

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

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

Что бы избежать подобного рода событий необходимо проверять права доступа на каждый каталог на файловом сервере и исправлять несоответствия. Если этих каталогов не больше 10 то этот процесс займет не значительное время, приблизительно один рабочий день, но если их количество около 100, то данный процесс займет большое количество времени. К тому же назначение прав необходимо проводить во время отсутствия запросов к ресурсам, т.е. наилучшим временем является нерабочее время. Поэтому средствами ОС в данном случае не обойтись. Из всего этого возникает необходимость в разработке программного средства обеспечивающего автоматическое разграничение прав доступа пользователей и групп к ресурсам файлового сервера. Необходимо так же учесть что все сотрудники состоят в групповых политиках АD.

3. Модернизация программных СЗИ ФГУП «Ростехинвентаризация - Федеральное БТИ» для разграничения доступа

Во второй главе, в соответствии с руководящем документом ГТК, был выявлен основной недостаток системы информационной безопасности ФГУП, которым является неудовлетворительная работа подсистемы управления доступом. А именно некорректность наследования прав доступа пользователей и групп к сетевым ресурсам. В результате чего было принято решение о модернизации системы информационной безопасности предприятия. Суть модернизации заключается в разработке программного средства, которое обеспечит разграничение доступа пользователям и группа, состоящих в групповых политиках АD, на сетевые ресурсы данных пользователей. Но для разработки программного продукта необходимо сначала разработать модель разграничения доступа пользователей и групп к сетевым ресурсам.

3.1 Разработка модели разграничения доступа

В настоящее время существует большое количество моделей разграничения доступа, но наибольшую популярность получили две - дискреционный, или избирательный (discretionary access control, DAC), и мандатный, или полномочный доступ (mandatory access control, MAC). Надо заметить, что вторая модель стала развитием первой/38/.

Дискреционный контроль доступа позволяет субъектам определять права доступа к объектам при условии наличия прав собственности на данные объекты. Данный подход обеспечивает гибкость и динамичность в изменении полномочий. При всей наглядности и гибкости возможных настроек разграничительной политики доступа к ресурсам, матричным моделям присущи серьезные недостатки. Основной из них - это излишне детализированный уровень описания отношений субъектов и объектов. Из-за этого усложняется процедура администрирования системы защиты. Причем это происходит как при задании настроек, так и при поддержании их в актуальном состоянии при включении в схему разграничения доступа новых субъектов и объектов. Как следствие, усложнение администрирования может приводить к возникновению ошибок, росту количества уязвимостей и увеличению возможностей доступа к информации со стороны внешних и внутренних нарушителей. Существенным недостатком дискреционных моделей, реализованных в АС, следует указать и то, что в ходе функционирования структура АС изменяется таким образом, что субъекты и объекты могут меняться местами. Так, информационные системы рассматривались ранее как объект управления, в то время как человек-пользователь являлся субъектом управления. Но при включении человека в информационную систему его роли разделились на исполнительную и управляющую. Человек-исполнитель теперь является объектом управления, а человек с ролью управления является субъектом управления АС.

С целью устранения недостатков матричных моделей были разработаны так называемые многоуровневые модели защиты, классическими примерами которых являются модель конечных состояний Белла и Ла-Падулы, а также решетчатая модель Д. Деннинга. Многоуровневые модели предполагают формализацию процедуры назначения прав доступа посредством использования, так называемых меток конфиденциальности или мандатов L, назначаемых субъектам и объектам доступа . Метки доступа субъекта L() определяются в соответствии с уровнем допуска лица к информации, а для объекта доступа L() - признаками конфиденциальности информации.

Все возможные уровни допуска L четко определены и упорядочены по возрастанию секретности. Действуют два основных правила:

1. Пользователь может читать только объекты с уровнем допуска не выше его собственного:

O ? L () ? L () (3.1)

2. Пользователь может изменять только те объекты, уровень допуска которых не ниже его собственного:

O ? L () ? L () (3.2)

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

Рисунок 3.1 - Cхема мандатного доступа субъектов к объектам АС

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

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

Требования к принципам разграничения доступа

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

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

Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов).

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

Право изменять ПРД, должно быть предоставлено выделенным субъектам (например, администрации, службе безопасности).

Должны быть предусмотрены средства управления, ограничивающие распространение прав на доступ.

КСЗ должен содержать механизм, претворяющий в жизнь дискретизационные ПРД, как для явных действий пользователя, так и для скрытых. Под "явными" здесь подразумеваются действия, осуществляемые с использованием системных средств, а под "скрытыми" -- иные действия, в том числе с использованием собственных программ работы с устройствами/17/.

Модель дискреционного доступа

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

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

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

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

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

1. Система представляется совокупностью пяти наборов (множеств):

- множества пользователей U;

- множества ресурсов R;

- множества состояний S;

- множества установленных полномочий A;

- множества операций E .

2. Область безопасности представляется декартовым произведением:

A Ч U Ч E Ч R Ч S (3.3)

3. Пользователи подают запросы на доступ к ресурсам, осуществление которых переводит систему в новое состояние. Запросы на доступ представляются четырехмерными кортежами

q = (u, e, R', s), (3.4)

где u ? U, e ? E, s? S, R' ? R (R'- требуемый набор ресурсов).

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

4. Процесс организации доступа алгоритмически описывается следующим образом.

4.1. Определить из U те группы пользователей, к которым принадлежит u. Затем выбрать из A те спецификации, которым соответствуют выделенные группы пользователей. Этот набор полномочий F(u) определяет привилегию пользователя u.

4.2. Определить из множества A набор полномочий P =F(e), которые устанавливают e как основную операцию. Набор полномочий P =F(e) определяет привилегию операции e.

4.3. Определить из множества A набор полномочий P =F(R'), разрешающих доступ к набору ресурсов R'. Набор полномочий P =F(R') определяет привилегию ресурсов R'.

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

D(q) = F(u) ? F(e) ? F(R' ) .

4.4. Убедиться, что запрашиваемый набор ресурсов R' полностью содержится в домене запроса D(q), т. е. любой r из набора R' хотя бы один раз присутствует среди элементов D(q).

4.5. Осуществить разбиение D(q) на эквивалентные классы так, чтобы в один класс попадали полномочия (элементы D(q)), когда они специфицируют один и тот же ресурс r из набора R'.

В каждом классе произвести операцию логического ИЛИ элементов D(q) с учетом типа операции e.

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

4.6. Вычислить условие фактического доступа (EAC), соответствующее запросу q , через операции логического ИЛИ по элементам полномочий F(u, q) и запрашиваемым ресурсам r из набора R', и получить тем самым набор R'' - набор фактически доступных по запросу ресурсов.

4.7. Оценить EAC и принять решение о доступе:

- разрешить доступ, если R'' и R' полностью перекрываются;

- отказать в доступе в противном случае/25/.

Разработка модели разграничения доступа для ФГУП

Для АСОД ФГУП характерна дискреционная модель разграничения доступа, соответственно необходимо разработать дискреционный принцип разграничения доступа для АСОД.

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

Рисунок 3.2 - Структура каталогов на сервере

Пользователи на предприятии объединены в группы, для удобства администрирования. Группы пользователей образованы согласно занимаемым ими должностям. На рисунке 3.3 представлена структура должностей ФГУП. Каждая из должностей имеет свои категории прав и свое множество ресурсов (каталогов) на которые распространяются соответствующие им категории прав. Таким образом, разграничение доступа должно проводиться с учетом возможностей на выполнение тех или иных операций с ресурсами в АСОД для каждой должности, и пользователя (сотрудника) имеющего данную должность.

Рисунок 3.3 - Структура должностей предприятия

Рассмотрев структуру каталогов и структуру должностей, можно приступить к созданию модели разграничения доступа. На рисунке 3.4 представлена модель разграничения доступа для ФГУП. Данная модель полностью отражает права доступа на ресурсы расположенные на файловом сервере для групп и пользователей. Согласно модели пользователи (П) группы 1 (Гр1) имеет доступ на запись только к собственным каталогам (Кn). Пользователи входящие в Гр2 (начальники отделов) помимо прав на запись собственных каталогов, имеют права доступ на чтение каталогов пользователей работающих в отделе. Пользователи состоящие в Гр3 (директор) так же как и пользователи Гр1 имеют права доступа на запись в собственный каталог и права доступа на чтение всех каталогов находящихся на файловом сервере.

Результат разграничения доступа записывается, т.е. производит изменения, в списки доступа АСL, которые в свою очередь представляет прямоугольную матрицу (таблицу), строки которой соответствуют субъектам доступа, столбцы объектам доступа, а в ячейках записываются разрешенные операции соответствующего субъекта над соответствующим объектом (таблица 3.1).

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

Таблица 3.1 - Матрица права доступа

	Объекты доступа
Субъекты доступа				…		…
		r	r	…	w		r
		w	r	…	r	…	w
		…	…	…	….	…	…
		r	w	…	r	…	w
		…	…	…	….	…	…
		w	e	…	w	…	r

Рисунок 3.4 - Модель разграничения доступа для ФГУП

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

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

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

n - запрет на доступ;

r - возможность чтения ресурса;

w - возможность записи ресурса и дальнейшего его чтения;

с - возможность выполнения вех возможных операций над ресурсами, без возможности изменения свойств доступа к ресурсу;

f - возможность выполнения вех возможных операций над ресурсами, с возможности изменения свойств доступа к ресурсу.

Но каждая категория прав m включает в себя более низкую категорию:

Так же необходимо отметить, что системный администратор имеет самую высокую категорию прав доступа - f.

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

k - множество групп;

l - множество пользователей;

m - множество ресурсов (каталогов);

n - множество категорий прав доступа;

o -имя системного администратора в АС.

1. Необходимо получить список групп k и пользователей l, входящих в эти группы.

{; } (3.5)

Такие что:

(3.6)

2. Определение администратора o АС из всех пользователей l:

(3.7)

Для администратора o, права доступа n всегда «f».

таким образом, производим объединение множества пользователей и групп, в которых состоят первые, и имя администратора с правами «f»:

{; = {; } (3.8)

3. Теперь необходимо определить категории прав доступа, т.е. поставить в соответствие группам пользователей соответствующие категории прав доступа n. Для этого производится назначение соответствующей группе пользователей соответствующие категории прав доступа. Мы уже имеем список групп k, теперь определяем для каждого соответствующие категории прав :

(3.9)

4. Теперь необходимо определить каталоги, принадлежащие группам. Для этого производим поиск каталогов, принадлежащих i группе, следующим образом:

Для каждого пользователя определяем каталоги принадлежащие ему:

 (3.10)

И записываются во временный файл К.

После этого из полученного списка выбираем первый путь каталога , разбиваем его путь на части:

(3.11)

Далее а,b,c, присваивается номер категории прав доступа:

а=1

b=2

c=3

Если группе соответствует категория прав и i = 1, то производим поиск по а, если i = 2, то поиск по b, если i = 3 то поиск по с, т.е. в переменной х присваиваем значение а или b или с:

(3.12)

Все полученный результаты дописываем во временный файл К.

5. Организуем полученные результаты

(3.13)

После получения выражения вида (3.13) мы имеем все необходимы данные для назначения прав доступа пользователям k на ресурсы m.

6. Производим запись прав доступа n на каталоги m для пользователей k в таблицу доступа АCL, средствами встроенной утилиты cаcls.exe.

3.2 Определение требований к программе разграничения доступа

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

1. Работа в среде ОС Windows.

2. Высокий уровень надежности назначения прав доступа.

3. Непрерывность работы.

4. Простота в использование.

5. Использование минимальных ресурсов компьютера.

6. Возможность конфигурирования.

7. Минимальные затраты на разработку.

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

3.3 Разработка алгоритма программы

Для начала необходимо определить перечень функций, которые будет выполнять программный продукт.

1. Установка прав доступа на каталоги, в которых располагаются ресурсы.

2. Проверка появления новых каталогов, по расписанию, в данном случае речь идет о каталогах сотрудников.

3. Динамическое получение пользователей и групп из АD, т.к. аутентификация пользователей происходит через АD.

В соответствии с функциями был разработан алгоритм программного средства управления доступом, который представлен на рисунке 3.5.

Согласно разработанному алгоритму, программное средство работает следующим образом: сначала устанавливается время запуска программы, после чего программа ожидает значения установленного времени, как только значение становится заданному, программа производит запрос списка каталогов, расположенных на файловом сервере. При первом запуске создается файл содержащий список каталогов на сервере. Содержимого данного файла сравнивается с полученным результатом запроса, в случае появления новых каталогов, производится добавление в файл списка каталогов. Далее осуществляется запрос к АD, для получения списка пользователей и групп. После этого производится сопоставление каталогов и пользователей. Результат сопоставления записывается в отдельный файл. Используя результаты сопоставления, записанные в отдельный файл, производится редактирование списков АСL.

Более подробно рассмотрим процесс сопоставления и назначения прав пользователям и группа.

Процесс сопоставления прав пользователям и группам осуществляется согласно модели разграничения прав доступа. Алгоритм данного процесса представлен на рисунке 3.6.

Сначала производится загрузка полученных списков групп «k» и пользователей «l». Таким образом, что каждому пользователь «l» входи в группу «k», т.е. записывается в виде массива:

группа1; пользователь 1;

группа1; пользователь 2;

группа1; пользователь n-1;

группа2; пользователь n;

группа2; пользователь n+1;

группа m; пользователь x.

Потом среди пользователей определяется администратор, имя этого пользователя записывается в отдельную переменную «о», и так же переменной «р» присваивается права доступа «f», что определяет этому пользователю полный доступ на все ресурсы сервера.



Рисунок 3.5 - Алгоритм программного средства назначения прав доступа

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

группа1; пользователь 1; администратор ; «f» ;

группа1; пользователь 2; администратор ; «f» ;

группа1; пользователь n-1; администратор ; «f» ;

группа2; пользователь n; администратор ; «f» ;

группа2; пользователь n+1; администратор ; «f» ;

группа m; пользователь x; администратор ; «f» ;

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

Рисунок 3.6 - Алгоритм разграничения прав доступа

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

группа1; пользователь 1; путь 1; администратор; «f»;

группа1; пользователь 2; путь 2; администратор; «f»;

группа1; пользователь n-1; путь n-1; администратор; «f»;

группа2; пользователь n; путь n; администратор; «f»;

группа2; пользователь n+1; путь n+1; администратор; «f»;

группа m; пользователь x; путь x; администратор; «f»;

Затем пути разбиваются на уровни вложенности каталогов:

Х:/а/b/c/…

Каждому уровню вложенности соответствует права на доступ для конкретной группы, т.е. в рассматриваемом предприятии существует 3 группы: директор, начальник отдела, сотрудник (смотрите рисунок 3.2). В зависимости от этого пользователь, состоящий в определенной группе, имеет ряд прав на собственный каталог и другие каталоги, не принадлежащие ему, конечно кроме пользователей являющимися рядовыми сотрудниками. Соответственно независимо от прав на свой каталог, две первые группы имеют права на каталоги, уровни, вложенности которых соответствуют их группе, т.е. у первой группы есть права на каталоги уровень вложенности которых равен «а», и все каталоги ниже этого уровня, второй группе «b» и все каталоги ниже, но в зависимости от отдела. Для начальника все просто, пользователь являющийся начальником имеет права на корневой каталог, а вот для начальников отдела не все так просто, в их полномочия должны входить права на каталоги принадлежащие отделу, начальником которого является пользователь. поэтому производится дополнительная выборка каталогов, на которые имеют права доступа пользователи состоящие в группе начальники отдела. Для этого из пути принадлежащего пользователю, предварительно разбитого на уровни вложенности, в переменную «х» записывается значение уровня вложенности «b» и производится поиск вхождения «х» в список всех каталогов. Теперь мы знаем пути к каталогам, которые находятся в юрисдикции начальников отделов. Теперь осталась только дописать эти пути в массив, путем добавления новой строки в массив и еще дописать соответствующие права доступа для групп:

группа1; пользователь 1; каталог 1; права 1; администратор; «f»;

группа2; пользователь 2; каталог 1; права 2; администратор; «f»;

группа2; пользователь 2; каталог 2; права 2; администратор; «f»;

группа2; пользователь 3; каталог 3; права 2; администратор; «f»;

группа2; пользователь n-1; каталог n-1; права 2; администратор; «f»;

группа2; пользователь n; каталог n; права 2; администратор; «f»;

группа2; пользователь n+1; каталог n+1; права 2; администратор; «f»;

группа 3; пользователь x; каталог x; права 3; администратор; «f»;

Теперь сопоставив пользователей, каталоги, и права пользователей на каталоги, можно приступа к применению прав доступа. Для этого используется алгоритм применения прав доступа представленный на рисунке 3.7.

Применение прав осуществляется с помощью программы сасls.exe. данная программа встроена в ОС Microsoft Windows. Синтаксис данной программы имеет следующий вид:

cacls имя_файла [/t] [/e] [/c] [/g пользователь: разрешение] [/r пользователь [...]] [/p пользователь: разрешение [...]] [/d пользователь [...]]



Рисунок 3.7 - Алгоритм применения прав пользователям

Параметры

имя_файла

Обязательный параметр. Вывод избирательных таблиц управления доступом (DACL) указанных файлов.

/t

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

/e

Редактирование избирательной таблицы управления доступом (ACL) вместо ее замены.

/c

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

/g пользователь: разрешение

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

Если пользователи являются доменными пользователями, то необходимо указать домен в котором состоит пользователь. Для этого параметр пользователь записывается в виде:

домен/пользователей.

3.4 Выбор среды программирования

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

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

К основным характеристикам современных средств разработки программного обеспечения относят:

- поддержка как процедурного, так и объектно-ориентированного
стилей программирования;

- наличие "визуальных" средств разработки интерфейса;

- обеспечение доступа к базе данных;

- использование различных методов "визуализации" как модели данных, так и самих данных;

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

Основным критерием выбора среды программирования и языка программирования, является то что разрабатываемая программная среда будет работать в операционной среде Windows, что достаточно облегчает выбор.

Программное средство должно выполнять разграничение доступа с высоким уровнем надежности, а наиболее лучший способ для этого установка прав доступа на уровне файловой системы. На файловом сервере используется ОС Windows Server 2003, у данной ОС файловая система NTFS. Для назначения прав на уровне NTFS в ОС предусмотрена программа, для просмотра и изменения разрешений прав доступа к файлам и каталогам, cаcls.exe.

С помощью cacls.exe можно установить все параметры безопасности для файловой системы, доступ к которым осуществляется из командной строки (CMD) в проводнике (с этой целью cacls.exe отображает и изменяет списки управления доступом (ACL) файлов). Для создания списка последовательных команд в CMD используются пакетные или batch файлы.

Пакетные или batch файлы это обычные текстовые файлы, содержащие наборы команд интерпретатора и имеющие расширение bat или cmd (cmd работают только в ОС семейства NT). Редактировать такие файлы можно при помощи блокнота или любого другого текстового редактора.

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

Наиболее подходящим для данной задачи являются Windows Scripting Host.

Windows Scripting Host (WSH) - новый, независимый от языка скрипт-хост для Win9x и NT, позволяет строить аналоги ВАТ-файлов на Visual Basic Scripting Edition, JScript и других скриптовых языках, например, Active Perl или Python.

Раньше единственным поддерживаемым Windows скриптовым языком был командный язык DOS. Но его возможности довольно бедны по сравнению с VBScript и JScript. Хотя командный язык DOS по прежнему поддерживается, современные ActiveX-скрипты позволяют решать более сложные задачи.

Cкрипт может принимать решения на основе использования полноценных операторов If/Else. Сценарий может выполнять один набор команд, если данное условие истинно, или другой набор, если условие ложно.

Другое свойство Windows Scripting Host заключается в том, что скрипты могут исполняться вне браузера. Достаточно кликнуть по файлу с текстом скрипта или ввести его название в командной строке, чтобы запустить его на исполнение. Windows Scripting Host не требователен к памяти и прекрасно годится для автоматизации Windows. Что вполне удовлетворяет требованиям к разрабатываемому программному средству.

VBScript и JScript уже встроены в ОС Windows, что позволяет сэкономить на среде разработки программного средства.

По сравнению с различными программистскими изысками писать скрипты для Windows Scripting Host относительно просто. Средой для разработки скриптов является обычный текстовый редактор. После написание нужного вам сктрипта, необходимо сохранить файл с расширением .vbs для VBScript или .js для JScript. Запуск скриптов - тоже несложная задача. Есть несколько способов. Самый простой - командная строка DOS и аналогичная версия Windows Scripting Host, CSCRIPT.ЕXE. Эта версия позволяет контролировать исполнение скрипта с помощью параметров командной строки.

Одни и те же функциональные возможности, предусмотренные в языках VBScript и JavaScript, некоторые пользователи считают достоинством, а некоторые - недостатком в зависимости от того, на какие технологии они ориентируются. VBScript тяготеет к технологиям Microsoft, JavaScript - к Netscape. Исходя из этого для разработки программного средства для разграничения доступа пользователей и групп, работающего в ОС Microsoft Windows, выбор очевиден, это VBScript. В таблице 3.2 представлен сравнительный анализ скриптовых языков программирования VBScript и JavaScript.

Таблица 3.2 - Сравнительный анализ скриптовых языков прогаммирования

Параметры	VBScript 2.0	JavaScript 1.2
Работа с массивами
Сортировка	+	+
Преобразование массива в строковую переменную	+	+
Операторы
Сравнения (<, >, <=, >=, <>)	+	+
Логические и булевы (AND, OR, XOR)	+	+
Равенство и неравенство объектов	+	+
Слияние строк	+	+
Математические операции
Сравнение объектов	+	+
Работа со строковыми переменными
Извлечение подстрок	+	+
Извлечение части строки с определенной позиции	+	-
Разбиение строки	+	+
Сравнение с применением фильтров	+	-
Поиск и замена внутри строки	+	-
Управление форматом вывода строки	+	-
Операции ввода и вывода
Чтение и запись текстовых файлов	+	-

Visual Basic Scripting Edition (обычно просто VBScript) - скриптовый язык программирования, интерпретируемый компонентом Windows Script Host. Данный язык широко используется при создании скриптов в операционных системах семейства Microsoft Windows.

VBScript был создан компанией Microsoft как замена устаревшему пакетному языку, интерпретируемому приложением command.com.

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

? автоматизация администрирования систем Windows;

? серверный программный код в страницах ASP;

? клиентские скрипты в браузере Internet Explorer.

Такой тип сценариев обычно используется для:

? создания сложных сценариев;

? использования объектов из других приложений и библиотек;

? скрытия окон в ходе выполнения сценария;

? шифрования логики сценария.

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

Сценарии не компилируются, а интерпретируются. То есть для обработки скрипта в системе должен присутствовать интерпретатор языка VBS, и таких интерпретаторов в Windows два: оконный WScript и консольный CScript, оба интерпретатора это Windows Script Host (WSH)/26/.

3.5 Характеристика разработанной программы для назначения прав доступа

Итогом разработки стало программное средство для назначения прав доступа.

Данное программное средство предназначено для назначения прав доступа пользователям и группам, состоящим в АD, путем предварительного сопоставления списка групп и пользователей со списком каталогов и категорий прав. программное средство может применять в организациях имеющих структуру аналогичную ФГУП.

Программное средство состоит из трех взаимосвязанных модулей:

dost.bat - основная часть программного средства;

sop.vbs - модуль получения пользователей и групп состоящих в АD; их с каталогами и правами доступа.

Схема связи модулей и рабочих файлов приведена на рисунке 3.8.

dost.bat

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

1. Установка времени запуска

2. Получение списка каталогов на сервере и его сравнение с listK.txt

3. Назначение прав доступа

Первая функция реализована средствами стандартного планировщика Microsoft Windows в командной строке.

аt 13:30 с:\ dost.bat

Данная строка является первой строкой в модуле dost.bat. принцип работы её заключается в следующем: как только наступает заданное время, в нашем случае 13:30, запускается основная часть программного средства - dost.bat.

Вторая функция представляет собой простой вывод списка каталогов и входящих в них подкаталогов, реализованная функцией командной строки dir:

dir D:\ /S /А:D /B



Рисунок 3.8 - Схема связи модулей и рабочих файлов

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

D:\отдел\пользователь

При первом запуске программного средства данный список сохраняется в текстовый файл listK.txt. При повторных запусках происходит сравнение полученного списка каталогов со списком в файле listK.txt, в случае несовпадения, происходит дозапись listK.txt.

После дозаписи в файл listK.txt, происходит вызов второго модуля программного средства.

Полученные списки пользователей и групп записываются в итоговый файл listUF.txt, путем добавления записи имени пользователя к его каталогу. Таким образом, получается некий массив состоящий из двух столбцов и n строк. Значение строк первого столбца в дальнейшем будет является значением переменной i, а значение сток второго столбца значением переменной j. Данные переменный в дальнешем будут использоваться для автоматического назначения прав доступа. Но для того что бы ни произошло ошибки при отсутствии этого текстового файла, необходимо его дождаться. Для этого используется условный цикл «goto»:

if exist c:\ listUF.txt goto go

sleep 10

goto test

:go

В результате работы данной программной конструкции будет проходить проверка на появления файла listUF.txt в корне диска «С» с интервалом 10 секунд, после того как файл появится, будет выполнено действие, указанное после метки go, у нас это редактирование таблицы доступа АСL. При желание можно сократить интервал проверки, изменив значение sleep.

Третья функция, главная и финальная, реализована встроенной программной просмотра и управления прав доступа cаcls.exe.

cacls d:\ %%i /T /G %%j:C /P director:R admin:F

В данной строке происходит применение прав j пользователя на i ресурс, и жесткая установка прав чтения и полного доступа на все ресурсы директора и системного администратора, соответственно. Назначение прав производится в цикле «for», т.е. права назначаются перебором всех каталогов и пользователей, согласно разработанной модели разграничения доступа в пункте 3.1. Значение переменных i и j хранится в текстовом файле listUF.txt.

sop.vbs

Модуль sop.vbs предназначен для возврата списка пользователей и групп состоящих АD, в результате запроса. Для возврата списка в данном модуле формируется запрос к АD, но перед этим модуль производит ещё один запрос для определения имени домена и организационной единицы. Предварительный запрос происходит динамически, что придает программному средству адаптируемость в использовании. Результат со списком пользователей и групп помещается во временный файл, из которого производится дозапись в файл listUF.txt.

3.6 Интеграция разработанного программного средства в систему ПО АСОД ФГУП «Ростехинвентаризация - Федеральное БТИ»

Интеграция программного средства проходит в три этапа.

1. Предварительная настройка.

2. Запуск программного средства.

3. Проверка появления рабочих файлов.

На первом этапе производится настройка программного средства непосредственным изменением некоторых значений программного кода, а именно:

? задание времени ежедневного запуска программного средства, изменением значения времени запуска пакетного файла;

? прописывание пути расположения модулей программного средства и рабочих файлов, в случае если производится запуск не с корня системного диска «C»;

? прописывание пути расположения корневого каталога, в котором располагаются ресурсы подлежащие защите;

? прописывание пути хранения рабочих и временных файлов.

Все остальные настойки производятся динамически сами программным средством.

На втором этапе производится запуск программного средства, путем старта модуля dost.bаt. старт данного модуля производится двойным щелчком правой кнопки манипулятора по этому файлу.

На третьем этапе производится проверка создания рабочих файлов, программное средство должно автоматически создать два рабочих файла:

1) listK.txt

2) listUF.txt

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

3.7 Разработка инструкции программиста и пользователя

Разработка структуры и содержание документов «Руководство пользователя» и «Руководство программиста» описаны в ГОСТ 19.506-79 и ГОСТ 19.503-79* соответственно.

Согласно этим государственным стандартам были разработаны «Руководство пользователя» и «Руководство программиста», которые представлены ниже.

Руководство пользователя

1. Назначение программы

1.1. Функциональное назначение программы

Программное средство предназначено для перекрытия недостатка системы информационной безопасности АСОД ФГУП «Ростехинвентаризация - Федеральное БТИ».

1.2. Эксплуатационное назначение программы

С помощью данного программного продукта производится автоматизированное разграничение прав доступа пользователей и групп состоящих в домене АD.

2. Условия выполнения программы

2.1. Минимальный состав аппаратных средств

Для работы программного средства необходимы следующие аппаратные средства и их характеристики:

? Непосредственно файловый сервер, на котором располагаются ресурсы подлежащие защите от НСД;

? Видеотерминал;

? Манипулятор;

? Клавиатура;

? Наличие сетевого адаптера.

Требования к техническим характеристикам сервера:

? Минимальная частота процессора - 133МГц;

? Минимальный объем оперативной памяти - 128МБ;

? Пространство на диске для - 10МБ.

2.2. Минимальный состав программных средств

Для функционирования программного средства необходимо наличие ОС семейства Windows 9х или NT

2.3. Требования к персоналу (пользователю)

Программное средство после настройки полностью автоматизировано, и не требует дополнительного обслуживания.

3. Выполнение программы

3.1. Загрузка и запуск программы

Программное средство не компилируются, а интерпретируются. То есть для обработки скрипта в системе должен присутствовать интерпретатор языка VBS: консольный CScript. Программное средство после первой загрузки запускается автоматически по расписанию

3.2. Выполнение программы

Все функции программного средства выполнятся в фоновом режиме.

3.3. Завершение работы программы

Завершение программного средства не требуется, т.к. оно является средством защиты от НСД.

4. Сообщения оператору

Сообщения операторы программное средство не выдает на протяжение всего функционирования после настройки и первого запуска.

Руководство программиста

1. Назначение и условия применения программы

1.1. Назначение программы

Программное средство предназначено для установки прав доступа пользователей и групп, состоящих в домене АD, на уровне файловой системы NTFS.

1.2. Функции, выполняемые программой

Программное средство выполняет следующие функции:

? Проверка появления новых каталогов пользователей;

? Установка прав доступа пользователям на каталоги, в которых хранится ресурсы подлежащие защите.

1.3. Условия, необходимые для выполнения программы

1.3.1. Объем оперативной памяти

Для нормального функционирования программного средства необходимо минимум 16МБ оперативной памяти.

1.3.2. Требования к составу периферийных устройств

Наличие сетевого адаптера.

1.3.3. Требования к параметрам периферийных устройств

Сетевой адаптер должен поддерживать соединение по сети со скоростью до 10Мб/сек

1.3.4. Требования к программному обеспечению

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

? dost.bаt

? sop.vbs

1.3.5. Требования к персоналу (программисту)

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

В задачи выполняемые программистом, входят:

? задача поддержания работоспособности технических средств;