Модернизация информационной системы безопасности предприятия ОАО "Альфапроект"

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

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

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

информационный программный защита доступ



3. Модернизация программной защиты ОАО «Альфапроект» для разграничения доступа

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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) = 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' полностью перекрываются;

? отказать в доступе в противном случае[8].

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

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

Рисунок 3.2 - Структура каталогов на сервере предприятия ОАО «Альфапроект»

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

Рассмотрев структуру каталогов и структуру должностей, можно приступить к созданию модели разграничения доступа. На рисунке 3.4 представлена модель разграничения доступа для ОАО «Альфапроект». Данная модель полностью отражает права доступа на ресурсы расположенные на файловом сервере для групп и пользователей. Согласно модели пользователи (П) группы 1 (Гр₁) имеет доступ на запись только к собственным каталогам (К_n). Пользователи входящие в группу 2 (Гр₂-начальники отделов) помимо прав на запись собственных каталогов, имеют права доступ на чтение каталогов пользователей работающих в отделе. Пользователи состоящие в группе 3 (Гр₃-директор) так же как и пользователи Гр₁ имеют права доступа на запись в собственный каталог и права доступа на чтение всех каталогов находящихся на файловом сервере.

Рисунок 3.3 - Структура должностей предприятия ОАО «Альфапроект»

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

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

Таблица 3.1

Матрица права доступа

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

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

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

Рисунок 3.4 - Модель разграничения доступа для ОАО «Альфапроект»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{; } (3.5)

Определение администратора o АС из всех пользователей l (формула 3.6).

(3.6)

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

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

{; = {; } (3.7)

Теперь необходимо определить категории прав доступа, т.е. поставить в соответствие группам пользователей соответствующие категории прав доступа n. Для этого производится назначение соответствующей группе пользователей соответствующие категории прав доступа. Уже имеется список групп k, теперь определяется для каждого соответствующие категории прав (формула 3.8).

(3.8)

Теперь необходимо определить каталоги, принадлежащие группам. Для этого производится поиск каталогов, принадлежащих i группе. Для каждого пользователя определяем каталоги, принадлежащие ему (формула 3.9). И записываются во временный файл К.

(3.9)

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

(3.10)

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

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

(3.11)

Все полученные результаты дописываются во временный файл К. В формуле 3.12 представлена организация полученных результатов.

(3.12)

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

Программное средство управления доступом должно отвечать следующим требованиям:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 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», что определяет этому пользователю полный доступ на все ресурсы сервера.

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

Группа 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 пользователь [...]]

Ниже представлены параметры программного средства.

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

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

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

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

/g пользователь: разрешение - предоставление прав доступа указанному пользователю.

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

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

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

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

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

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

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

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

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

- предоставление средств синхронизации и контроля версий составных частей проекта;

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 3.2

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

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



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

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

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

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

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

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

Итогом разработки стало программное средство для назначения прав доступа. Данное программное средство предназначено для назначения прав доступа пользователям и группам, состоящим в А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 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», т.е. права назначаются перебором всех каталогов и пользователей, согласно разработанной модели разграничения доступа. Значение переменных i и j хранится в текстовом файле listUF.txt.

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

3.5 Внедрение программы в систему программного обеспечения ОАО «Альфапроект»

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

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

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

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

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

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

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

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

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

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

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

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

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

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



4. Обоснование экономической эффективности проекта

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

4.1 Определение трудоемкости и расчет себестоимости программного продукта

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

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

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

Расчет затрат времени на разработку программного обеспечения охватывает работы, выполняемые специалистами на различных стадиях, представленных в таблице 4.1.

Таблица 4.1

Стадии разработки программного обеспечения

Обозначение	Стадии разработки
ТЗ	Техническое задание
ЭП	Эскизный проект
ТП	Технический проект
РП	Рабочий проект
В	Стадия внедрения

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

- количество разновидностей форм входной информации;

- количество разновидностей форм выходной информации;

- степень новизны комплекса задач; - сложность алгоритма;

- виды используемой информации;

- сложность контроля входной и выходной информации;

- использование типовых проектных решений.

Предусматривается четыре степени новизны разрабатываемых задач, которые представлены в таблице 4.2.

Таблица 4.2

Степени новизны разрабатываемых задач

Обозначение	Степень новизны
А	Разработка комплекса задач, предусматривающая применение новых методов разработки, проведение научно-исследовательских работ
Б	Разработка решений задач и систем, не имеющих аналогов
В	Разработка решений задач и систем, имеющих аналогичное решение
Г	Привязка типовых проектных решений

Сложность алгоритма представлена тремя группами, отображенными в таблице 4.3.

Таблица 4.3

Группы сложности алгоритмов

Обозначение	Виды алгоритмов
С1	Алгоритмы оптимизации и моделирования систем и объектов
С2	Алгоритмы учета и отчетности, статистики, поиска
С3	Алгоритмы, реализующие стандартные методы решения, а также не предусматривающие применение сложных численных и логических методов

Трудоемкость разработки проекта зависит также от вида используемой информации. Виды информации представлены в таблице 4.4.

Таблица 4.4

Виды используемой информации

Обозначение	Виды информации
ПИ	Переменная информация
НСИ	Нормативно-справочная информация
БД	Базы данных
РВ	Режим работы в реальном времени
ТОУ	Телекоммуникационная обработка данных, управление удаленными объектами

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

Таблица 4.5

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

Обозначение	Группа сложности
11	Входные данные и документы разнообразных форматов и структур (контроль осуществляется перекрестно)
12	Входные данные и документы однообразной формы и содержания (осуществляется формальный контроль)
21	Печать документов сложной многоуровневой структуры, разнообразной формы и содержания
22	Печать документов однообразной формы и содержания, вывод массивов данных на машинные носители

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

Далее в справочных таблицах 4.6 и 4.7 представлены затраты времени при выполнении различных видов работ на разных стадиях процесса разработки программного продукта.



Таблица 4.6

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

Комплекс задач, подсистем	Степень новизны (дни)
	А	Б	В	Г
1. Перспективное планирование, размещение и развитие отрасли; управление проектируемым капитальным строительством; технико-экономическое планирование; ценообразование	79	57	37	34
2. Управление материально-техническим снабжением, сбытом продукции; управление комплектацией и поставками	105	76	42	30
3. Управление бухгалтерским учетом, финансовой деятельностью предприятия	103	72	30	35
4. Управление организацией труда, зарплата, кадры, нормы и нормативы, охрана труда	63	46	30	19
5. Управление качеством продукции, технологическими процессами в производстве, стандартизации, технической подготовкой производства	64	47	31	22
6. Управление транспортными перевозками, техобслуживанием, вспомогательными службами и энергоснабжение	91	66	43	26
7. Управление научно-технической информацией. Совершенствование.	50	36	24	15
8. Учет пенсий, пособий и страховых операций	79	55	36	26
9. Статистические задачи	129	111	61	38
10. Задачи расчетного характера	92	69	47	29

Таблица 4.7

Затраты времени при выполнении работ на стадии эскизного проектирования

Комплекс задач, подсистем	Степень новизны (дни)
	А	Б	В	Г
1. Перспективное планирование, размещение и развитие отрасли; управление проектируемым капитальным строительством; технико-экономическое планирование; ценообразование	175	117	77	53
2. Управление материально-техническим снабжением, сбытом продукции; управление комплектацией, экспортными и импортными поставками	115	79	53	35
3. Управление бухгалтерским учетом, финансовой деятельностью предприятия	166	112	67	57
4. Управление организацией труда, зарплата, кадры, нормы и нормативы, охрана труда	151	101	67	44
5. Управление качеством продукции, технологическими процессами в производстве, стандартизации, технической подготовкой производства	157	99	67	44
6. Управление транспортными перевозками, техобслуживанием, вспомогательными службами и энергоснабжение	170	100	70	45
7. Управление научно-технической информацией. Совершенствование документооборота и контроль исполнения документа. Управление охраной природы и окружающей среды	151	101	67	46
8. Учет пенсий, пособий и страховых операций	103	70	45	36
9. Статистические задачи	103	70	45	49
10. Задачи расчетного характера	103	70	45	41

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

(4.1)

где: m - количество наборов данных ПИ;

n - количество наборов данных НСИ;

p - количество наборов данных БД.

Поправочные коэффициенты для определения трудоемкости работ, учитывающие сложность контроля входной и выходной информации, приведены в таблицах 4.8, 4.9, 4.10 и 4.11.

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

, (4.2)

где: - затраты труда на стадии технического задания (в днях);

- затраты труда на стадии эскизного проекта (в днях);

- затраты труда на стадии технического проекта (в днях);

- затраты труда на стадии рабочего проекта (в днях);

- затраты труда на стадии внедрения (в днях).



Таблица 4.8

Поправочные коэффициенты на стадии технического проекта

Вид используемой информации	Степень новизны
	А	Б	В	Г
ПИ, K1	1,7	1,2	1	0,5
НСИ, K2	1,45	1,08	0,72	0,43
БД, K3	4,37	3,12	2,08	1,25

Таблица 4.9

Поправочные коэффициенты на стадии рабочего проекта

Вид используемой информации	Группа сложности алгоритма	Степень новизны
		А	Б	В	Г
ПИ, K1	С1	2,27	1,62	1,2	0,65
	С2	2,02	1,44	1,1	0,58
	С3	1,68	1,2	1	0,48
НСИ, K2	С1	1,36	0,97	0,65	0,4
	С2	1,21	0,86	0,58	0,34
	С3	1,01	0,72	0,48	0,29
БД, K3	С1	1,14	0,81	0,54	0,32
	С2	1,05	0,72	0,48	0,29
	С3	0,85	0,6	0,4	0,24

Таблица 4.10

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

Сложность контроля выходной информации	Сложность контроля выходной информации
	21	22
11	1,16	1,07
12	1,08	1

Таблица 4.11

Поправочные коэффициенты для определения трудоемкости работ на стадиях технического и рабочего проектов, внедрения

Вид используемой информации	Группа сложности алгоритма	Степень новизны
		А	Б	В	Г
ТП	РВ	1,67	1,45	1,26	1,1
	ТОУ	1,75	1,52	1,36	1,15
РП	РВ	1,75	1,52	1,36	1,15
	ТОУ	1,92	1,67	1,44	1,25
В	РВ	1,6	1,39	1,21	1,05
	ТОУ	1,67	1,45	1,26	1,1

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

По таблице 4.6 определяются затраты труда на стадии технического задания - 22 день. Используя таблицу 4.7, определим затраты труда на стадии эскизного проекта - 44 дней. Оцениваемые трудозатраты на стадии технического проекта составляют 5 дней, на стадии рабочего проекта - 24 дня, на стадии внедрения - 2 дня.

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

(день)

Общая трудоемкость разработки программного продукта с учетом поправочных коэффициентов рассчитывается по формуле 4.3:

, (4.3)

где: - затраты труда на стадии технического проекта с учетом поправки;

' - затраты труда на стадии рабочего проекта с учетом поправки;

- затраты труда на стадии внедрения с учетом поправки.

Для расчета затрат труда на стадии технического проекта с учетом поправки по формуле 4.1 и на основе таблицы 4.8 рассчитывается поправочный коэффициент на использование разных видов информации. Количество наборов данных БД равно 3, нормативно-справочной информации - 4, переменной информации - 20. Значение коэффициента равно:

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

(дней).

Аналогичным образом рассчитывается поправочный коэффициент для стадии рабочего проекта:

.

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

(день).

Для расчета затрат труда на стадии внедрения используются поправочные коэффициенты из справочных таблиц 4.10 и 4.11:

(дня).

Таким образом, общие затраты труда на разработку программного продукта с учетом поправочных коэффициентов составят:

(дней).

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

(4.4)

.

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

Для определения себестоимости программного продукта используется формула 4.5:

, (4.5)

где: - затраты на вспомогательные материалы, руб.;

Э - затраты на электроэнергию в технологических целях, руб.;

- основная заработная плата разработчика, руб.;

- дополнительная заработная плата разработчика, руб.;

- взносы на социальное страхование и обеспечение, руб.;

Н - накладные расходы, руб.

Затраты на вспомогательные материалы, использованные в проектировании, приведены в таблице 4.12.

Таблица 4.12

Затраты на вспомогательные материалы

Наименование затрат	Количество	Сумма, руб.
Литература: Ален Лиссуар «WMI: программирование на JavaScript и VBScript»	1	450
Доступ в Интернет	1 месяц	350
Бумага офисная А4	500 листов	150
Всего	950

Затраты на электроэнергию рассчитываются по формуле 4.6:

, (4.6)

где: P - мощность потребляемой электроэнергии, кВт;

- стоимость одного киловатт-часа электроэнергии, руб.;

- коэффициент загрузки компьютера;

- общие затраты труда на разработку программного продукта, час.

Подставив в формулу 4.6 числовые значения, рассчитываются затраты на электроэнергию:

Основная заработная плата разработчика рассчитывается по формуле 4.7:

(4.7)

где - часовая тарифная ставка разработчика, руб.;

- общие затраты труда на разработку программного продукта, час.

Используя формулу 4.7, рассчитывается основная заработная плата разработчика:

руб.

Дополнительная заработная плата разработчика принята как 10% от основной зарплаты. Таким образом, = 5564 руб.

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

(4.8)

где: - коэффициент взносов на социальное страхование и обеспечение, = 0,35

Накладные расходы составляют 10% от суммы основной и дополнительной заработной платы разработчика и вычисляются по формуле 4.9:

(4.9)



Подставив в формулу 4.9 числовые значения, получим:

H = (55640 + 5564) * 0,1 = 6120,4 руб.

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

С = 950 + + 55640 + 5564+ 21421,4 + 6120,4 = 90553,52 руб.

Результаты расчетов себестоимости программного продукта сведены в таблицу 4.13.

Таблица 4.13

Калькуляция себестоимости программного продукта

Наименование статьи расходов	Затраты, руб.
Вспомогательные материалы	950
Основная зарплата	55640
Дополнительная зарплата	5564
Взносы на социальное страхование и обеспечение	21421,4
Затраты на электроэнергию	857,72
Накладные расходы	6120,4
Полная себестоимость	90553,52

4.2 Расчет экономического эффекта от внедрения программного продукта

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

, (4.10)

где: N - количество проверок корректности назначения прав доступа в год;

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

- часовая тарифная ставка пользователя, С_чтс = 65 руб.;

- коэффициент отчислений на дополнительную зарплату, =0,1;

- коэффициент отчислений на социальные нужды, = 0,35;

- коэффициент окупаемости капитальных вложений, ;

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

Используя ранее рассчитанные значения и подставив их в формулу 4.10, получаем значение экономического эффекта:

Э_ф = 24 * (49 - 23) * 65 * 1,1 * 1,35 - 0,39 * 90553,52= 24915,73 руб.

Срок окупаемости проекта рассчитывается по формуле 4.11:

(4.11)

где: - себестоимость программного продукта, руб.;

- затраты при использовании ручного труда, руб.;

- затраты при использовании программы, руб.

Для расчета стоимостных затрат используется измененная формула (4.10):

С₁ = 24 * 49 * 65 * 1,1 *1,35 - 0,39 * 90553,52= 78197,53 руб.

С₂ = 24 * 23 * 65 * 1,1 * 1,35 - 0,39 * 90553,52= 17965,93 руб.

Подставив полученные значения в формулу 4.11, получаем:

.

Полученные экономические показатели проекта сведены в таблице 4.14.



Таблица 4.14

Экономические показатели проекта

Наименование показателя	Значение	Ед. изм.
Вспомогательные материалы	950	руб.
Основная зарплата	55640	руб.
Дополнительная зарплата	5564	руб.
Взносы на социальное страхование и обеспечение	21421,4	руб.
Затраты на электроэнергию	857,72	руб.
Накладные расходы	6120,4	руб.
Полная себестоимость	90553,52	руб.
Затраты при использовании ручного труда	78197,53	руб.
Затраты при использовании программы	17965,93	руб.
Экономический эффект	24915,73	руб.
Срок окупаемости	1,5	года

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

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