Алматы 2014 almaty

142 
 
При  всем  этом  безопасность  в  новой  версии  SQL  Server  не  лежит  только  на  триггерах  и 
хранимых  процедурах,  в  версии  2012  также  используется  интерактивное  шифрование  баз  данных; 
поддержка 
PKI; 
интеграция 
с 
доменом 
ActiveDirectory; 
аудит 
системы 
безопасности; 
усовершенствования в области проверки подлинности [3]. 
Особая  роль  отводится  представлениям,  которые  в  SQL  Server  используются  в  следующих 
целях:  
-  для  направления,  упрощения  и  настройки  восприятия  информации  в  базе  данных  каждым 
пользователем; 
- в качестве механизма безопасности, позволяющего пользователям обращаться к данным через 
представления, но, не предоставляя им разрешений на непосредственный доступ к базовым таблицам; 
-  для  предоставления  интерфейса  обратной  совместимости,  моделирующего  таблицу,  схема 
которой изменилась. 
При  построении  информационной  системы  для  сетевого  маркетинга  необходимо  провести 
подробный анализ предметной области, на основе которого будет строиться логическая и физическая 
модели базы данных (БД). 
В данном случае функции, выполняемые информационной системой, во многом будут зависеть 
от ролей пользователей, использующих данные, хранящиеся в системе. Роли определяются позицией, 
занимаемой пользователем в структуре рассматриваемого сетевого маркетинга [5]. 
Пользователями  данной  системы  будут  являться  сотрудники  сетевого  маркетинга,  клиенты  и 
потенциальные  покупатели  услуг  фирмы.  В  базе  данных  должна  быть  отражена  информация  о 
клиентах, продажах, доступных товарах на складе, а также сведения о товарах и ее наличии. Поэтому 
входными данными для проектирования базы данных должны быть следующие характеристики: 
• информация о филиалах: адрес, телефон, город, начальник филиала; 
• информация об агентах: личный номер агента, ФИО, статус агента, телефон; 
• информация о покупателях: ФИО, адрес, телефон, доставка; 
• информация о товаре: наименование товара, количество, стоимость и категория товара; 
• информация о заказах: номер заказа, дата заказа и сумма; 
База данных «Сетевой маркетинг» должна выполнять следующие задачи: 
• предоставлять  возможность  для  внесения,  изменения  и  удаления  информации  о  товарах, 
имеющихся в наличии, об их количестве и дате поступления на склад; 
• предоставлять полную информацию о товарах по запросам сотрудников и потребителей услуг 
сетевого маркетинга. 
В  соответствии  с  поставленной  задачей  выделим  для  данной  предметной  области  следующие 
сущности:  
• филиалы (код_филиала, адрес, телефон, менеджер, город); 
• агенты (код_агента, ФИО, счет, адрес, телефон, электронная почта, номер_филиала);  
• группа (код_группы, номер нового агента, ФИО агента, дата); 
• товары (код_продукта, название, категория, количество, цена, скидка, фото товара); 
• заказы (код_заказа, дата_заказа, номер_агента, сумма_заказа, доставка, оплата); 
• доставка (код_доставки, код_города, адрес, доставлен); 
• город (код_города, название); 
• покупатель (номер_покупателя, ФИО покупателя, телефон, e-mail). 
В  итоге,  восемь  сущностей  находятся  в  третьей  нормальной  форме,  т.  е.  все  атрибуты 
сущностей  содержат  атомарные  значения  (значения  в  домене  не  являются  ни  списками,  ни 
множествами  простых  или  сложных  значений);  каждый  не  ключевой  атрибут  полностью  зависит  от 
первичного ключа; никакой не ключевой атрибут не зависит от другого не ключевого атрибута. 
На  основе  анализа  предметной  области  была  спроектирована  структура  базы  данных  для 
сетевого маркетинга. 
Логическое  и  физическое  проектирование  базы  данных  было  выполнено  с  помощью  CASE-
средства AllFusion Erwin Data Modeler (Erwin). Модели ERwin визуализируют структуры данных для 
облегчения  организации и управления данными, упрощения сложных взаимосвязей данных, а также 
технологий  создания  баз  данных  и  среды  развертывания.  Были  определены  сущности,  атрибуты  и 
связи между ними [5]. Физическое проектирование  ER-диаграммы представлено на рисунке 1.  

143 
 
 
 
Рисунок 1. Физическое проектирование ER – диаграммы 
 
При проектировании инфологической модели предметной области сетевого маркетинга были 
выделены десять сущностей с определенными атрибутами и связями между ними: filials (филиалы), 
agents (агенты), zakazi (заказы), tovary (товары), tov_zak (товары в заказах), city (города),  dostavka 
(доставка), pokupatel (покупатели), Users (пользователи БД). 
Сущность Filials содержит информацию о филиалах и включает в себя следующие атрибуты: 
 id_f (номер филиала);  
 adres (адрес филиала); 
 telephone (номер телефона филиала); 
 manager (управляющий филиалом); 
 id_c (код города, где находится филиал). 
Первичным ключом сущности является id_f (номер филиала). Внешним ключом для этой 
сущности будет manager (номер агента, который управляет тем или иным филиалом) и city (код 
города). 
Сущность agents содержит информацию об агентах и включает в себя следующие атрибуты:  
 id_a (идентификационный номер); 
 FIO_a (ФИО агента);  
 account («виртуальный кошелек» агента);  
 phone (телефон для связи с агентом);  
 email (электронная почта агента); 
 id_f (номер филиала, в котором он зарегистрирован); 
 avatar (фотография агента); 
 id_c (город, где проживает агент); 
 id_g (номер группы, которую сформировал агент). 
Первичным ключом сущности является id_а (идентификационный номер), внешними ключами 
сущности являются id_f (номер филиала), city (место проживания агента) и id_g (код группы). 
Сущность Gruppa содержит информацию о новых привлеченных агентах и содержит 
информацию о: 
 id_g (идентификационный номер группы);  
 id_a (номер агента, который сформировал группу); 
 id_new (номер нового агента); 
 data_p (дата начала работы); 
Первичным ключом является id_g (номер группы), а внешним ключом будет id_a (номер 
агента, который сформировал группу). 
Сущность zakazi содержит информацию о сформированном заказе и включает в себя 
следующие атрибуты:  
 id_z (идентификационный номер заказа);  
 sum_z (общая сумма заказа);  

144 
 
 data_z (дата формирования заказа); 
 oplata (информация об оплате заказа);  
 id_a (идентификационный номер агента); 
 id_d (код доставки);  
 nom_p (номер случайного покупателя). 
Первичным ключом сущности является id_z (идентификационный номер заказа), внешними 
ключами сущности являются id_a (номер агента), dostavka (информация о доставке) и nom_p (номер 
случайного покупателя). 
Сущность tovary содержит информацию о товаре на складе и включает в себя следующие 
атрибуты:  
 id_t (идентификационный номер товара);  
 name_t (название товара);  
 price_t (предлагаемая цена для покупателей); 
 sale (цена для агентов со скидкой); 
 photo (фотография товара); 
 kol_vo (количество товара на складе); 
 category (категория товара). 
Первичными ключами сущности являются id_t (номер товара). 
Так как связь сущностей zakazi и tovary имеют отношение «многие-ко-многим», возникла 
необходимость в создании сущности tov_zak, которая включает в себя следующие атрибуты:  
 nom0 (порядковый номер); 
 id_t (идентификационный номер товара);  
 id_z (идентификационный номер заказа). 
Внешними ключами сущности являются id_t (идентификационный номер товара) и id_z 
(идентификационный номер заказа). 
Сущность city содержит информацию о городе, т.к. сетевой маркетинг может иметь филиалы в 
разных городах, то в данной сущности будет только два поля id_c (код города), который является 
первичным ключом, а также name_c (название города).  
Сущность dostavka будет содержать информацию о доставке товара, и включать в себя 
следующие атрибуты:  
 id_d (код доставки); 
 adres (адрес доставки); 
 id_c (код города); 
 dostavlen (товар доставлен или нет). 
Первичным ключом в данном случае является id_d, внешним ключом сущности является id_c 
(код города). 
Сущность pokupatel содержит информацию о случайном покупателе и включает в себя 
следующие атрибуты:   
 nom_p (порядковый номер); 
 FIO_p (ФИО покупателя);  
 tel_p (номер телефона);  
 email (адрес электронной почты);  
 id_с (код города). 
Первичным ключом сущности является nom (порядковый номер), внешним ключом сущности 
является id_c (код города). 
При этом необходимо создать сущность Users, в котором будет отображена информация о 
пользователях БД. Сущность Users будет включать в себя такие атрибуты как: 
- id (идентификационный номер пользователя);  
- password (пароль пользователя). 
Для оптимизации работы БД необходимо объединить сущности, создав для этого связи между 
ними, чтобы значения в таблицах совпадали и не приводили к отказу системы [6]. 
По полученной инфологической модели будем иметь 3 типа связи между сущностями: 
- «один-к-одному» (1:1) означает, что каждый экземпляр одной сущности связан только с 
одним экземпляром другой сущности. Это самая простая связь.  

145 
 
- «один-ко-многим» (1:М) означает, что один экземпляр одной сущности связан с несколькими 
экземплярами другой сущности. Это наиболее часто используемый вид связи. В данном случае к 
такому типу связи можно отнести например, связь филиалы-агенты, т.е. в одно филиале могут быть 
несколько агентов, и наоборот один агент не может быть в нескольких филиалах. 
- «многие-ко-многим» (М:М) имеет связь, когда каждый экземпляр первой сущности может 
быть связан с несколькими экземплярами другой сущности, и наоборот, когда каждый экземпляр 
второй сущности может быть связан с несколькими экземплярами первой сущности. Например, связь 
«Товары-Заказы» - несколько товаров может быть в одном заказе, и в нескольких заказах может быть 
один и тот же товар [7]. 
База  данных  была  реализована  в  MS  SQL  Server  2012.  Спроектированы  и  реализованы 
представления  и    хранимые  процедуры  базы  данных,  обеспечивающие  комфортность  работы 
пользователей  и  защиту  физических  таблиц:  вывод  данных  в  отсортированном  виде,  получение 
справочной  информации  по  наличию  товара  на  складе,  дистрибьюторам  и  покупателям, 
действующим  на  тот  или  иной  товар  скидкам    и  специальным  предложениям,  получение 
статистических данных по продажам товаров и дистрибьюторам (в разрезе месяцев, типов товаров и 
пр.) и т.д.  
Одно из разработанных представлений предназначено для расчета вознаграждения агентам в 
случае оплаты за заказ (рисунок 2). Команда создания представления с SQL-запросом, формирующим   
вознаграждение агентам выглядит следующим образом:  
CREATE VIEW voznag_a1 AS 
SELECT  dbo.agents.fio_a AS ФИО, SUM(dbo.zakazi.summa_z) * 0.3 AS бонус, 
MONTH(dbo.zakazi.data_z) AS месяц 
FROM            dbo.agents INNER JOIN 
                      dbo.zakazi ON dbo.agents.id_a = dbo.zakazi.a_id 
WHERE        (dbo.zakazi.oplata = 'yes') 
GROUP BY dbo.agents.fio_a, MONTH(dbo.zakazi.data_z)  
 
 
 
Рисунок 2. Представление для расчета вознаграждения агентам за заказ 
 
Следующее представление показывает данные о недоставленных заказах по адресу (рисунок 3).  
CREATE VIEW inf_zak AS 
SELECT        dbo.zakazi.id_z, dbo.zakazi.summa_z AS сумма, dbo.city.city AS город, 
dbo.dostavka.adres AS адрес, dbo.dostavka.dostavlen 
FROM            dbo.zakazi INNER JOIN 
                         dbo.dostavka ON dbo.zakazi.dostavka = dbo.dostavka.id_d INNER JOIN 
                         dbo.city ON dbo.dostavka.id_c = dbo.city.id_c 
WHERE        (dbo.dostavka.dostavlen = 'no') 

146 
 
 
 
 
Рисунок 3. Представление о недоставленных по адресу заказах 
 
Необходимо также представление для предоставления отчета о заказе (рисунок 4), т.е. ФИО 
агента, номер заказа, товар, который входит в этот заказ и его цена. 
CREATE VIEW tov_z AS 
SELECT dbo.agents.fio_a AS Агент, dbo.zakazi.id_z AS н_заказа, dbo.tovary.name_t AS товар, 
dbo.tovary.cena_t AS цена 
FROM       dbo.tov_zak INNER JOIN 
                  dbo.tovary ON dbo.tov_zak.id_t = dbo.tovary.id_t INNER JOIN 
                  dbo.zakazi ON dbo.tov_zak.id_z = dbo.zakazi.id_z INNER JOIN 
                  dbo.agents ON dbo.zakazi.a_id = dbo.agents.id_a 
 
 
 
Рисунок 4. Информация о заказе 

147 
 
Для безопасного функционирования базы данных необходимо создание хранимых процедур, с 
помощью  которых  осуществляются  вставки  новых  строк  и  выборка  данных  по  условию,  что 
позволяет свести к минимуму риск от SQL инъекций. 
Процедура вставки новой строки в таблицу gruppa: 
create procedure new_g  @vid_new int, @vid_a int, @vfio nchar(20), @vrgup int, @vacnt money as 
insert into s_marketing..gruppa values (@vid_new, @vid_a, @vfio, @vrgup, @vacnt) 
Хранимая процедура может быть вызвана с использованием оператора: 
execute new_a 202014, 101111, 'Куанышева К.К.', '20', '500' 
При  этом  все  входные  и  выходные  параметры  должны  быть  заданы  обязательно  и  в  том 
порядке,  в  котором  они  определены  в  процедуре.  Результат  выполнения  хранимой  процедуры 
показан на рисунке 5. 
 
 
 
Рисунок 5. Результат хранимой процедуры new_g 
 
В базе данных «Сетевой маркетинг» создана процедура для уменьшения цены товара заданной 
категории в соответствии с указанным %. 
CREATE PROCEDURE skidka @k nchar(10) = 'мыло', @p float = 0.1 as 
UPDATE tovary set cena_t = cena_t*(1-@p) 
WHERE category = @k  
Для обращения к процедуре можно использовать команды:  
EXEC skidka 'подарок', 0.05 
EXEC skidka @k='подарок', @p=0.05 или 
EXEC skidka @p=0.05 
EXEC skidka 
Первый и второй случаи идентичны и их результат приведен на рисунке 6. А в третьем случае, 
уменьшается цена мыла (значение типа не указано при вызове процедуры и берется по  умолчанию). 
В четвертом примере, оба параметра (и категория, и процент) не указаны при вызове процедуры, их 
значения берутся по умолчанию. 
 
 
 
Рисунок 6. Результат процедуры skidka:  
 
Триггер  представляет  собой  специальный  тип  хранимых  процедур,  запускаемых  сервером 
автоматически  при  попытке  изменения  данных  в  таблицах,  с  которыми  триггеры  связаны.  Каждый 
триггер  привязывается  к  конкретной  таблице.  Все  производимые  им  модификации  данных 
рассматриваются  как  одна  транзакция.  В  случае  обнаружения  ошибки  или  нарушения  целостности 
данных  происходит  откат  этой  транзакции.  Тем  самым  внесение  изменений  запрещается. 
Отменяются также все изменения, уже сделанные триггером. 

148 
 
Ниже  описываются  три  различных  триггера  из  созданных  в  базе  данных.    Первый  триггер 
должен отреагировать так, что при добавлении нового товара в заказ необходимо будет проверить его 
наличие на складе, которое указывается в таблице tovary, в поле kol_vo. 
CREATE TRIGGER trig_ins1 
ON tov_zak FOR INSERT 
AS 
IF @@ROWCOUNT=1 
BEGIN 
  IF NOT EXISTS (SELECT * FROM inserted  
      WHERE inserted.kol <= (SELECT  
    tovary.kol_vo FROM inserted, tovary  
  WHERE tovary.id_t = inserted.id_t ))  
    BEGIN 
      ROLLBACK TRANSACTION 
    RAISERROR ('Отмена заказа: необходимого количества товара на складе нет', 16, 10) 
    END 
END 
Следующий триггер необходим для того, чтобы пользователь базы данных guest не мог 
изменять или вставлять данные в таблицу tovary. 
CREATE trigger modif on tovary FOR INSERT, UPDATE 
AS 
IF USER = 'guest' 
BEGIN 
RAISERROR ('У вас нет прав на изменение таблицы ', 16, 10) 
ROLLBACK TRANSACTION 
END 
А также создан триггер для обработки операции удаления записи из таблицы Zakazi:  
CREATE TRIGGER zak_del2 ON tov_zak FOR DELETE  
AS 
DECLARE @result int 
SET @result = 1 
IF EXISTS (SELECT * FROM zakazi, deleted WHERE oplata = 'no' and zakazi.id_z = deleted.id_z) 
     
 BEGIN 
raiserror ('Попытка удаления неоплаченного товара! ', 16, 10) 
SET @result = 0 
     
 END 
IF @result = 0 
     
 BEGIN 
RAISERROR ('Удаление запрещено', 16, 10) 
ROLLBACK TRANSACTION 
     
 END 
Разработанные  триггеры  создают  определенные  ограничения  в  базе  данных,  что  позволяет 
избежать  несоответствия  в  данных,  обеспечивают  поддержку  целостности  данных  и  запрет 
несанкционированных действий. 
Исходя  из  анализа  предметной  области,  были  определены  пользователи  и  их  полномочия, 
заведены учетные записи, реализованы роли, назначены привилегии  ролям. 
 
ЛИТЕРАТУРА 
1. Карпова Т.С. Базы данных. Модели, разработка, реализация. – СПб.: Питер, 2001. – 304 с.  
2. Айтхожаева Е.Ж. Системы баз данных. – Алматы: КазНТУ, 2002. – 224 с. 
3.  Петкович  Д.  Microsoft  SQL  Server  2012.  Руководство  для  начинающих  –  СПб:  БХВ-Петербург,  2013.                   
– 816 с. 
4. Дейт К.Дж. Введение в системы баз данных, 7-е издание.: Пер. с англ. – М.: Вильямс, 2003. – 1328 с. 
5. Маклаков С.В. B Pwin и Erwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ–
МИФИ, 1999. – 304 с. 
6. Гудсон Дж., Таранушенко С. Практическое руководство по доступу к данным. – СПб: БХВ-Петербург, 
2013. – 304 с. 
7. Дунаев В.В. Базы данных. Язык SQL для студентов. – СПб.: БХВ – Петербург, 2006. – 288 с. 

149 
 
Абулхасимова М.Б., Айтхожаева Е.Ж. 
Желілік маркетингке серверлік дерекқорды жасау және оның қауіпсіздігін ұйымдастыруы 
Түйіндеме.  Мақалада  желілік  маркетингке  серверлік  дерекқорды  жасау  және  оның  қауіпсіздігін 
ұйымдастыруы  қарастырылған.  Болашақта  тиімді  дерекқорды  жасауға  ыңғай  ететңн  логикалық  және 
физикалық модельдер өңделді. Заттар саласының талдауы жүргізілді. Дерекқор қандай кестелерден тұратынын 
толық  мазмұндаған.  Әрбір  түйіннің  мүмкін  байланыстарын  суреттеген.  MS  SQL  Server-дің  кіріктірме  қорғау 
механизмдерімен қолдану арқылы дерекқорды қорғау түрлерін ұйымдастырған. 
Түйін сөздер: дерекқор, ақпаратты қауіпсіздендіру, желілік маркетинг, ER-диаграмма, инфологикалық 
модельдеу, түйін, байланыс 
 
Abulkhassimova M.B., Aithozhaeva E.Zh. 
Development and organization of protection server database for multi-level marketing 
Summary. The article deals with the development and organization of protection server database for network 
marketing. Was developed logical and physical models for further effective database. Also, an analysis was conducted 
of the subject area. Detail from which tables will include a database for multi-level marketing. Describes what types of 
communication are possible between different entities. Organized protection of the database, using built-in mechanisms 
for the protection of MS SQL Server 2012. 
Key words: database, data protection, multi-level marketing, ER diagrams, infological model, entity, relations 
 
 
УДК   004. 382. 004. 056 
 
Адильбекова А.А. магиcтрант, Джурунтаев Ж.З.,  
Казахский национальный технический университет имени К.И. Сатпаева, 
г. Алматы, Республика Казахстан, juruntaev@mail.ru 
 
МНОГОУРОВНЕВАЯ БЕЗОПАСНОСТЬ ИНФОРМАЦИОННЫХ СИСТЕМ 
 
Аннотация. В статье рассматриваются различные подходы обеспечения информационной безопасности 
объектов.  На  основе  проведенного  анализа  рассмотрены  задачи  многоуровневой  защиты  централизованных 
объектов.  Приведены  соответствующие  модели  и  методы.  Разработанные  методы  позволят  обеспечить 
эффективную защиту информационных объектов.  
Ключевые слова: информационная безопасность, модели, методы, объект, задача.  
 
Вопросы  информационной  безопасности  объектов  и  информационных  ресурсов  являются 
важными  при  создании  любой  информационной  системы  и  имеют  бессрочную  актуальность.                     
В  настоящее  время  существует  большое  число  систем  и  средств  обеспечения  безопасности, 
основанные на программных и технических, а в ряде случаев комбинированных систем защиты. Как 
правило,  система  информационной  безопасности  (СИБ)  у  каждого  разработчика  оригинальны  и  не 
подлежат тиражированию. Поэтому у пользователей нет доступа к таким системам. Вместе с тем для 
обеспечения  эффективной  защиты  используются  формализованные  методы,  например  в 
криптографии.  В  системе  надежной  информационной  безопасности  широко  используется 
многоуровневая защита.  
  Многоуровневая  защита  предназначена  для  обеспечения  комплексной  безопасности  объекта. 
В  качестве  такого  объекта  могут  быть  хранилище  данных,  серверные  центры,  автоматизированные 
информационные системы. Модель многоуровневой защиты можно представить следующим образом 
(рис. 1).  
 
 
 
 
 
 
 
 
 
 
 
Рис. 1. Модель многоуровневой защиты информационной системы 
1-уровень 
2-уровень 
3-уровень 
Информационная 
система 

150 
 
Постановка  задач.  Реализация  указанные  уровней  безопасности  должна  обеспечиваться 
множеством  соответствующих  средств  защиты  от  потенциальных  нарушителей.  Сформулируем 
следующую  задачу.  Предположим,  что  информационная  система  защищена  средствами 
информационной безопасности (СИБ) на каждом из уровней (рис. 2).  
 
 
 
 
 
 
 
 
 
 
 
 
 
Рис. 2. Модель защиты информационной системы 
 
При этом каждая система информационной безопасности имеет такие характеристики как С
i
 – 
стоимость системы защиты i-го уровня и Р
i
 – вероятность взлома системы защиты i-го уровня. Тогда 
задача формулируется следующим образом.  
Задача  1.  Необходимо  определить  средства  информационной  безопасности  тех  уровней, 
которые  при  заданных  характеристиках  (C
i
,  P
i
)  обеспечивают  минимальную  стоимость  защиты 
информационной  системы  при  заданной  надежности  либо  максимальную  надежность  при  заданной 
стоимости.  
Для формализованной постановки введем переменную х
i
=1, если выбирается средства защиты 
i-го  уровня  безопасности  информационной  системы  и  х
i
=0,  в  противном  случае.  Далее,  если  Р
i
  – 
вероятность  взлома  средства  защиты  i-го  уровня,  то  (1-  Р
i
)  –  вероятность  надежности  средства 
защиты i-го уровня. В этом случае функция безопасности информационной системы определится как  
(1 −
) 
Задача формулируется следующим образом 
∑
 → 
 
 
 
(1) 
При ограничении на уровень безопасности 
∏
(1 −
) ≥
 
 
 
(2) 
  Задача обеспечения максимальной безопасности формулируется следующим образом  
∏
(1 −
) →
   
 
(3) 
При ограничении на стоимость средств информационной безопасности  
∑
≤
, = 1,    
 
(4) 
Рассмотрим постановку задачи обеспечения многоуровневой безопасности [1, 2].  
Задача 2. Известно, что информация со временем теряет свою ценность и начинает устаревать, 
а в отдельных случаях ее цена может упасть до нуля. В этом случае за условие достаточности защиты 
ИС  можно  принять  превышение  затрат  времени  на  преодоление  системы  информационной 
безопасности нарушителем над временем жизни информационной системы.  
Рассмотрим следующие условия.  
Пусть, Р – вероятность надежности СИБ, t – время жизни ИС,  - ожидаемое время взлома СИБ 
нарушителем, q – вероятность обхода СИБ нарушителем.  
Тогда  для  случая  старения  (износа)  информационной  системы  условие  достаточности  ее 
защиты получим в следующем виде.  
Р=1, если t< и q=0 
 
 
(5) 
В  случае,  если  q=0,  то  это  отражает  необходимость  замыкания  преграды  вокруг  предмета 
защиты. Если t>, а q=0, то  
Р=(1-),   
 
 
             (6) 
Где  - вероятность преодоления защиты нарушителем за время, меньшее t.  
ИС 
C
1
P
1
 
C
2
P
2
 
C
3
P
3
 

151 
 
Для  реального  случая,  когда  t>,  а  q>0,  стойкость  защиты  можно  представить  следующим 
образом  
Р=(1-)(1- q) 
 
 
                (7) 
где q=0, если t<, q>0, если t≥ 
Формула  справедлива  для  случая,  когда  нарушителей  двое,  т.е.  когда  один  преодолевает 
защиту, а второй обходит ее. 
В  случае,  если  нарушитель  один  и  ему  известны  прочность  защиты  и  сложность  ее  обхода. 
Поскольку  одновременно  по  двум  путям  он  идти  не  сможет,  он  выбирает  один  из  них  –  наиболее 
простой.  Тогда  формальное  выражение  стойкости  защиты  в  целом  для  данного  случая  определится 
следующим образом 
Р=(1-)V(1- q)   
 
              (8) 
Следовательно,  стойкость  защиты  ИС  будет  равна  наименьшему  значению  одной  из 
составляющих (8), т.е. 
Р=min [(1-)V(1- q)] 
 
 
(9) 
Вышеуказанные  модели  и  методы  позволяют  обеспечить  эффективную  многоуровневую 
защиту информационных систем. 
 
ЛИТЕРАТУРА 
1. Анин Б.Ю. Защита компьютерной информации. – СПб.: БхВ – Санкт-Петербург 2000.  
2.  Герасименко  В.А.  Защита  информации  в  автоматизированных  системах  обработки  данных.  М.: 
Энергоатомиздат, 1994 
 
 
Адильбекова А.А., Джурунтаев Ж.З. 

жүктеу/скачать

Достарыңызбен бөлісу: