Система ИТ - специфическое воплощение изделия с конкретным назначением и условиями эксплуатации.

Продукт ИТ, согласно определению общих критериев, есть совокупность программных, программно - аппаратных и/или аппаратных средств ИТ, предоставляющая определенные функциональные возможности и предназначенная для непосредственного использования или включения в различные системы ИТ. В данном случае наш программный продукт предназначен для расчета нормативного запаса готовой продукции, реализуемый в СУБД Paradox.

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

- административная область (политика безопасности предприятия);

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

- физическая область (физическая среда и средства физической защиты);

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

Следующим шагом в оценке является описание следующих материалов:

- изложение предположений, которым удовлетворяла бы среда разрабатываемой ИТ для того, чтобы она считалась безопасной, то есть чтобы объект оценки считался защищенным;

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

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

- изложение политики безопасности, применяемой в организации.

Для системы ИТ такая политика может быть описана достаточно точно, а для продукта ИТ могут быть сделаны только рабочие предположения.

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

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

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

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

Размещено на http://www.allbest.ru/

Рис. 6.1 Последовательность формирования требований информационной безопасности

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

6.2 Профиль защиты

В состав профиля защиты (ПЗ) входят:

1. Введение ПЗ (идентификация ПЗ, аннотация ПЗ).

2. Описание объекта оценки (ОО).

3. Среда безопасности ОО (предположение безопасности, угрозы, политика безопасности организации).

4. Цели безопасности (цели безопасности для ОО, цели безопасности для среды).

5. Требования безопасности ИТ (для среды ИТ).

6. Требования безопасности для ОО (функциональные требования безопасности ОО, требования доверия к безопасности ОО).

7. Замечания по применению.

8. Обоснование (логическое обоснование целей безопасности, логическое обоснование требований безопасности).

Идентификация ПЗ

Название: Профиль защиты. Контролируемый доступ.

Обозначение: ПЗ КД.

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

Аннотация ПЗ

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

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

В общем случае ПЗ КД применим для распределенных систем, но не учитывает требования безопасности, выходящие за рамки потребностей распределения ресурсов внутри сети.

Стойкость, обусловленная средой

ПЗ КД определен для некой обобщенной среды со средним уровнем риска для активов. Требования доверия и минимально допустимая стойкость функций выбраны в соответствии с этим уровнем риска.

ОУД3 (EAL3) является оценочным уровнем доверия к безопасности ОО, а средняя стойкость функции безопасности является для данного профиля минимально допустимой стойкостью функций безопасности, реализуемых вероятностными и/или перестановочными (но не криптографическими) механизмами.

В данном профиле используются следующие термины:

- пользователь;

- уполномоченный пользователь;

- уполномоченный администратор;

- политика дискреционного управления доступом (DAC);

- посредничество;

- доступ;

- полномочие.

Пользователь - лицо, обращающееся к сервисам, предоставляемым объектом оценки.

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

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

Политика дискреционного управления доступом (DAC) является основной политикой, которую ПЗ КД-совместимые ОО осуществляют по отношению к пользователям и ресурсам.

Политика DAC состоит из правил двух типов: те, которые применимы к поведению уполномоченных пользователей (обозначаемые правилами доступа), и те, которые применимы к поведению уполномоченных администраторов (обозначаемые правилами полномочий). Если удовлетворен запрос уполномоченного пользователя на операцию с объектом, то говорят, что пользователь получил доступ к объекту. Если уполномоченным администратором предоставлен запрошенный сервис, то говорят, что пользователь имеет полномочия на запрошенный сервис или объект. Как и в случае с доступом, полномочия могут быть множественными. Типичным примером полномочий являются полномочия аудита, которые позволяют администратору просматривать записи аудита, пользоваться средствами аудита.

6.3 Описание объекта оценки

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

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

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

ПЗ КД предполагает, что ответственность за сохранность данных, защищаемых функциями безопасности объекта оценки, может быть делегирована пользователям ОО. Все данные находятся под управлением ОО.

Данные хранятся в объектах, и ФБО могут связать с каждым управляемым объектом описание прав доступа к нему.

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

6.4 Среда безопасности ОО

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

Предполагается, что для ПЗ КД - совместимого ОО приняты эффективные меры безопасности в невраждебной среде, если ОО установлен, управляется и используется корректно.

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

Предположения безопасности:

- для управления ОО и безопасностью информации назначены компетентные лица;

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

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

- любые системы, с которыми ОО взаимодействует, находятся под таким же управлением и функционируют по тем же правилам политики безопасности, что и ОО. ПЗ КД - совместимые ОО применимы только к тем сетевым или распределенным средам, в которых вся сеть работает с одинаковыми правилами политики безопасности и остается в пределах одной области управления;

- все связи с периферийными устройствами остаются в пределах возможностей контролируемого доступа. ПЗ КД - совместимые ОО предполагают условия безопасности, предусматривающие обращение к объекту оценки через санкционированные точки. Внутренние пути к точкам доступа, таким как терминалы, надежно защищены;

- пользователи осведомлены о политике безопасности предприятия

Угрозы безопасности:

1. Раскрытие конфиденциальной информации (несанкционированный доступ к БД, прослушивание каналов связи).

2. Компрометация информации (несанкционированное применение информационных ресурсов).

3. Несанкционированный обмен информацией (при закрытом доступе).

4. Ошибочное использование информационных ресурсов (чаще всего программные ошибки).

5. Отказ от информации (не признание факта получения или отправления), отказ от обслуживания (отказ системы).

6. Незаконное проникновение на территорию организации.

7. Компьютерные вирусы и другие вредоносные программы.

Политика безопасности предприятия:

- управление доступом - присвоение каждому пользователю персонального идентификатора, опознание подлинности идентификатора, проверка полномочий (уровень доступа к системе),

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

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

Вычислительные ресурсы сосредоточены в контролируемой зоне.

Аппаратное и программное обеспечение ОО защищено от несанкционированной физической модификации.

6.5 Цели безопасности

Цели безопасности для ИТ

1. ФБО должны обеспечивать, чтобы только уполномоченные пользователи могли получить доступ к ОО и его ресурсам. Предусматривается так же и физическая защита ресурсов.

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

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

4. ФБО должны обеспечивать, чтобы любая информация, содержащаяся в защищаемом ресурсе, не раскрывалась при перераспределении ресурса.

5. ФБО должны предоставлять все необходимые функции и возможности для поддержки уполномоченных администраторов, которые являются ответственными за управление безопасностью ОО.

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

Цели безопасности, не относящиеся к ИТ

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

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

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

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

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

6.6 Требования безопасности

Требования безопасности для среды ИТ

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

Уровень доверия к реализации ФТБ для ИТ - среды должен быть не ниже уровня доверия к реализации ФТБ объектом оценки.

Функциональные требования безопасности

ОК предусматривают 11 классов функциональных требований:

1. FAU - аудит безопасности;

2. FCO - связь;

3. FCS - криптографическая поддержка;

4. FDP - защита данных пользователя;

5. FIA - идентификация и аутентификация;

6. FMT - управление безопасностью;

7. FPR - приватность;

8. FPT - защита ФБО;

9. FRU - использование ресурсов;

10. FTA - доступ к ОО;

11. FTP - доверенный маршрут/канал.

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

Класс FAU:

- генерация данных аудита безопасности, FAU_GEN;

- просмотр аудита безопасности, FAU_SAR;

- выбор событий аудита, FAU_SEL;

- хранение данных аудита, FAU_STG.

Класс FDP:

- политика управления доступом, FDP_ACC;

- функции управления доступом, FDP_ACF;

- защита остаточной информации, FDP_RIP;

- защита конфиденциальности данных при передаче между ФБО, FDP_UCT.

Класс FIA:

- аутентификация пользователя, FIA_UAU;

- идентификация пользователя, FIA_UID;

- определение атрибутов пользователя, FIA_ATD;

- спецификация секретов, FIA_SOS;

- связывание пользователь - субъект, FIA_USB.

Класс FMT:

- управление атрибутами безопасности, FMT_MSA;

- управление данными, FMT_MTD;

- отмена, FMT_REV;

- роли управления безопасностью, FMT_SMR.

Класс FPT:

- тестирование базовой абстрактной машины, FPT_AMT;

- посредничество при обращениях, FPT_RVM;

- разделение домена, FPT_SEP;

- надежные метки времени, FPT_STM.

Далее приведем таблицу зависимости требований. Знак "x" означает однозначную зависимость между компонентами, "o" - зависимость может быть выбрана, "-" - косвенная зависимость.

Таблица 6.1. Зависимости требований

F A U _ G E N.1

F A U _ S A R.1

F A U _ S T G.1

F D P _ A C C.1

F D P _ A C F.1

F D P _ I F C.1

F D P _ I F F.1

F I A _ A T D.1

F I A _ U A U.1

F I A _ U I D.1

F MT _ MS A.1

F MT _ MS A.3

F MT _ MT D.1

F MT _ S MR.1

F P T _ A MT.1

F P T _ S T M.1

FAU_GEN.1

x

FAU_GEN.2

x

x

-

FAU_SAR.1

x

-

FAU_SAR.2

-

x

-

FAU_SAR.3

-

x

-

FAU_SEL.1

x

-

x

-

-

FAU_STG.1

x

-

FAU_STG.2

x

-

FAU_STG.3

-

x

-

FAU_STG.4

x

-

FDP_ACC.1

-

x

-

-

-

-

-

-

FDP_ACC.2

-

x

-

-

-

-

-

-

FDP_ACF.1

x

-

-

-

-

-

x

-

FDP_RIP.1

FDP_RIP.2

FDP_UCT.1

o

-

o

-

-

-

-

-

FIA_ATD.1

FIA_SOS.1

FIA_SOS.2

FIA_UAU.1

x

FIA_UAU.2

x

FIAUAU.7

x

-

FIA_UID.1

FIA_UID.2

FIA_USB.1

x

FMT_MSA.1

o

-

o

-

-

-

-

x

FMT_MSA.2

o

-

o

-

-

x

-

x

FMT_MSA.3

-

-

-

-

-

x

-

x

FMT_MTD.1

-

x

FMT_MTD.2

-

x

x

FMT_MTD.3

-

x

-

FMT_REV.1

-

x

FMT_SMR.1

x

FMT_SMR.2

FMT_SMR.3

-

x

FPT_AMT.1

FPT_RVM.1

FPT_SEP.1-3

Требования доверия

Требования доверия также подразделяются на классы.

1. Класс АСМ - Управление конфигурацией (УК):

- средства контроля УК, ACM_CAP;

- охват УК объекта оценки, ACM_SCP.

2. Класс ADO - Поставка и эксплуатация:

- поставка, ADO_DEL;

- установка, генерация, запуск, ADO_IGS.

3. Класс ADV - Разработка:

- функциональная спецификация, ADV_FSP;

- детализация вопросов безопасности в проекте верхнего уровня, ADV_HLD;

- соответствие представлений, ADV_RCR.

4. Класс AGD - Руководства:

- руководство администратора, AGD_ADM;

- руководство пользователя, AGD_USR.

5. Класс ALC - Поддержка жизненного цикла:

- безопасность разработки, ALC_DVS.

6. Класс ATE - Тестирование:

- анализ покрытия, ATE_COV;

- анализ глубины, ATE_DPT;

- функциональное тестирование, ATE_FUN;

- независимое тестирование, ATE_IND.

7. Класс AVA - Оценка уязвимостей:

- неправильное применение, AVA_MSU;

- оценка стойкости функций безопасности ОО, AVA_SOF;

- анализ уязвимостей, AVA_VLA.

Далее приведем таблицу сводного описания оценочного уровня доверия ОУД3. [15]

Таблица 6.2. Сводное описание оценочного уровня доверия

Класс доверия	Компоненты доверия
Управление конфигурацией	ACM_CAP.3 Средства контроля авторизации
	ACM_SCP.1 Охват УК объекта оценки
Поставка и эксплуатация	ADO_DEL.1 Процедуры поставки
	ADO_IGS.1 Процедуры установки, генерации и запуска
Разработка	ADV_FSP.1 Неформальная функциональная спецификация
	ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня
	ADV_RCR.1 Неформальная демонстрация соответствия
Руководства	AGD_ADM.1 Руководство администратора
	AGD_USR.1 Руководство пользователя
Поддержка жизненного цикла	ALC_DVS.1 Идентификация мер безопасности
Тестирование	ATE_COV.2 Анализ покрытия
	ATE_DPT.1 Тестирование: проект верхнего уровня
	ATE_FUN.1 Функциональное тестирование
	ATE_IND.2 Выборочное независимое тестирование
Оценка уязвимостей	AVA_MSU.1 Экспертиза руководств
	AVA_SOF.1 Оценка стойкости функции безопасности ОО
	AVA_VLA.1 Анализ уязвимостей разработчиком

Перекрестные ссылки между компонентами доверия. В таблице 10 объединены как прямые, так и косвенные зависимости. Косвенные зависимости являются, в конечном счете, результатом последовательного учета всех зависимостей каждого компонента, приведенного в списке зависимостей. [15]

Таблица 7.3. Зависимости компонентов доверия

Имена компо-нентов	A U T	C A P	S C P	D E L	I G S	F S P	H L D	I M P	I N T	L L D	R C R	S P M	A D M	U S R	D V S	F L R	L C D	T A T	C O V	D P T	F U N	I N D	C C A	M S U	S O F	V L A
CAP.1-2
CAP.3-4			1												1
CAP.5			1												2
SCP.1-3		3													1
DEL.1
DEL.2-3		3	1												1
IGS.1-2						1					1		1
FSP.1-4											1
HLD.1-2						1					1
HLD.3-4						3					2
HLD.5						4					3
RCR.1-3
ADM.1						1					1
USR.1						1					1
DVS.1-2
COV.1-3						1					1										1
DPT.1						1	1				1										1
DPT.2						1	2			1	1										1
DPT.3						1	2	2		1	1							1			1
FUN.1-2
IND.1						1					1		1	1
IND.2-3						1					1		1	1							1
MSU.1-3					1	1					1		1	1
SOF.1						1	1				1
VLA.1						1	1				1		1	1
VLA.2-4						1	2	1		1	1		1	1				1

Здесь курсивом выделены косвенные зависимости, а полужирным шрифтом - прямые.

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

Таблица 7.4. Подсистемы и требования к классу 1Г

Подсистема	Требования
Управление доступом	Идентификация, проверка подлинности, контроль доступа субъекта в систему
	Идентификация, проверка подлинности, контроль доступа субъекта к терминалам ЭВМ, каналам связи, внешним устройствам
	Контроль доступа к программам
	Контроль доступа к томам, каталогам, файлам, записям, полям записей.
Регистрация и учет	Регистрация и учет входа/ выхода субъектов доступа в/из системы.
	Регистрация выдачи печатных выходных документов
	Регистрация запуска/ завершения программ, процессов
	Регистрация доступа программ субъекта, к терминалам ЭВМ, файлам.
	Учет носителей информации
	Очистка освобождаемых носителей ОЗУ
Обеспечение целостности	Обеспечение целостности программных средств и обрабатываемой информации
	Физическая охрана средств вычислительной техники и носителей информации
	Периодическое тестирование средств защиты информации
	Наличие средств восстановления для средств защиты информации

6.7 Обоснования

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

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

Управление доступом.

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

На пользователей возложена ответственность за действия в системе.

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

Логическое обоснование требований безопасности

1. Пользователи, уполномоченные на доступ к ОО, определяются процессом идентификации и аутентификации [FIA_UID.1, FIA_UAU.1]. Для обеспечения авторизованного доступа к ОО данные аутентификации защищены [FIA_ATD.1, FIA_UAU.7]. Эффективность механизма аутентификации должна быть достаточной для обеспечения того, что неуполномоченные пользователи не смогут легко получить доступ [FIA_SOS.1].

2. Дискреционное управление доступом должно иметь определенные границы управления [FDP_ACC.1]. Должны быть определены правила политики DAC [FDP_ACF.1], атрибуты безопасности объектов и субъектов, используемые для установления политики [FIA_ATD.1, FIA_USB.1]. Уполномоченные пользователи должны быть способны управлять доступом к объектам [FMT_MSA.1] и отменять доступ [FMT_REV.1]. Защита объектов должна быть непрерывной с момента их создания [FMT_MSA.3].

3. Относящиеся к безопасности действия должны быть определены, подвержены аудиту [FAU_GEN.1] и ассоциироваться с отдельными пользователями [FAU_GEN.2, FIA_USB.1].

Журнал аудита должен быть защищен таким образом, чтобы только уполномоченные пользователи имели доступ к нему [FAU_SAR.2].

ФБО должны предоставлять возможность аудита действий отдельного пользователя [FAU_SAR.3, FAU_SEL.1, FIA_USB.1]. Журнал аудита должен быть полноценным [FAU_STG.1, FAU_STG.4]. Метки времени должны быть надежными [FPT_STM.1]. Уполномоченный администратор должен иметь возможность управлять журналом аудита [FAU_STG.3, FMT_REV.1] и просматривать его [FAU_SAR.1].

4. Остаточная информация, ассоциированная с определенными объектами в ОО, должна быть очищена (убрана из объекта) до повторного использования объекта [FDP_RIP.2].

5. Уполномоченному администратору должны предоставляться ФБО для управления ОО [FMT_SMR.1]. Администратор должен быть способен управлять возможностями пользователя [FMT_SMR.1, FMT_MTF.1, FMT_REV.1]. Администратор должен быть способен управлять просмотром журнала аудита [FAU_SAR.1, FAU_SAR.3, FAU_SEL.1, FAU_STG.3, FAU_STG.4, FMT_MTD.1, FMT_REV.1].

6. ФБО должны осуществлять ПБО [FPT_RVM.1]. При этом должна быть организована защита от вмешательства, препятствующего выполнению ФБО [FPT_SEP.1]. ОО должен демонстрировать правильность функционирования абстрактной машины, положенной в основу ФБО [FPT_AMT.1], что достигается, в частности, через требования доверия, определенные в ПЗ. Эта цель предоставляет общую поддержку для других целей безопасности, защищая части ОО, осуществляющие и поддерживающие ПБО.

Выводы

1. Программный продукт является автоматизированной системой.

2. Сформулированы функциональные требования и требования к среде.

3. Разработан профиль защиты автоматизированной системы на основе государственного стандарта ГОСТ 15408/2002.

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

Заключение

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

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

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

Список литературы

1. Конопка Р. Создание оригинальных компонент в среде Delphi / Пер. с англ. К.: ДиаСофт Лтд. 1996, 512 с.;

2. Ковязин А., Востриков С. Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/Firebird/Yaffil / П.: КУДИЦ-Образ, 2005, 496 с.;

3. Бирш Т. Firebird. Быстрый старт / Пер. с англ., 2003,19 с.

4. URL: http://megalib.com/books/1057/firebird_qsg. pdf

5. KDV Использование InterBase eXpress в приложениях / 2007, 32 с.

6. URL: http://www.ibase.ru/devinfo/ibx. htm

7. KDV Версионность метаданных/ 2004, 2 с.

8. URL: http://www.ibase.ru/devinfo/metaver. htm

9. Кузьменко Д. Генераторы и их использование / 2005, 18 с.

10. URL: http://www.ibase.ru/devinfo/generator. htm

11. Штунц К. Жизненный цикл транзакций / Пер. с англ., 2004, 12 с.

12. URL: http://www.ibase.ru/devinfo/utl. htm

13. KDV Кооперативная сборка мусора/ 2005, 6 с.

14. URL: http://www.ibase.ru/devinfo/garbage. htm

15. Харрисон А. Как работает версионность данных / Пер. с англ., 2001, 14 с.

16. URL: http://www.ibase.ru/devinfo/versions. htm

17. Кузьменко Д. Транзакции в InterBase / 2005, 38 с.

18. URL: http://www.ibase.ru/devinfo/ibtrans. htm

19. Служба поддержки iBase.ru Выбор компонент доступа / 2006, 9 с.

20. URL: http://www.ibase.ru/devinfo/choosecomp. htm

Приложение А

Текст программы:

unit uMain;

interface

uses

IniFiles, Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, Menus, ImgList, ActnList, ComCtrls, XPMan, StdCtrls, IBDatabase;

type

TfrMain = class (TForm)

stMain: TStatusBar;

imlMain: TImageList;

mnMain: TMainMenu;

btnFile: TMenuItem;

btnHelp: TMenuItem;

btnAbout: TMenuItem;

N1: TMenuItem;

btnExit: TMenuItem;

N2: TMenuItem;

btnSettings: TMenuItem;

btnChangeModul: TMenuItem;

btnLogOff: TMenuItem;

XPManifest1: TXPManifest;

lblMain: TLabel;

actMain: TActionList;

actSettingsDB: TAction;

actAbout: TAction;

actExit: TAction;

actLogout: TAction;

actChangeModule: TAction;

btnTest: TButton;

procedure FormClose (Sender: TObject; var Action: TCloseAction);

procedure FormShow (Sender: TObject);

procedure actSettingsDBExecute (Sender: TObject);

procedure actAboutExecute (Sender: TObject);

procedure actLogoutExecute (Sender: TObject);

procedure actExitExecute (Sender: TObject);

procedure actChangeModuleExecute (Sender: TObject);

private

{ Private declarations }

procedure FreeFrames;

public

{ Public declarations }

function Initialize: boolean;

function InitUser (db: TIBDatabase; login, pass: string): boolean;

function InitFrame: boolean;

function SelectFrame: boolean;

end;

var

frMain: TfrMain;

implementation

uses uFrmUsers, uSettings, uDM, uLogin, uConnect, uFrmPattern,

uSelectFrame, uAbout, uConstants, uDBState, uFrmPark, uFrmRequest,

uFrmStore;

{$R *. dfm}

procedure TfrMain. FormShow (Sender: TObject);

begin

if Initialize and InitFrame

then SelectFrame

else Close;

end;

procedure TfrMain. FormClose (Sender: TObject; var Action: TCloseAction);

begin

FreeFrames;

end;

function TfrMain. Initialize;

var

Passed: boolean;

begin

Caption: = ProductName;

result: = false;

passed: = false;

with TfrLogin. Create (nil) do try

while not Passed do

// отображение окна авторизации

if ShowModal = mrCancel then begin

Passed: = true;

result: = false;

end

else if dm. DBMain. TestConnected

or IsPositiveResult (ConnectTo (dm. DBMain, 'Главная БД')) then

if InitUser (dm. DBMain, edtLogin. Text, edtPass. Text) then begin

Passed: = true;

result: = true;

end;

finally

Free;

end;

end;

procedure TfrMain. FreeFrames;

begin

if Assigned (frmPattern) then begin

frmPattern. Finalize;

frmPattern. Free;

frmPattern: = nil;

end;

if Assigned (frmUsers) then begin

frmUsers. Finalize;

frmUsers. Free;

frmUsers: = nil;

end;

if Assigned (frmPark) then begin

frmPark. Finalize;

frmPark. Free;

frmPark: = nil;

end;

if Assigned (frmRequest) then begin

frmRequest. Finalize;

frmRequest. Free;

frmRequest: = nil;

end;

if Assigned (frmStore) then begin

frmStore. Finalize;

frmStore. Free;

frmStore: = nil;

end;

end;

function TfrMain. InitUser (db: TIBDatabase; login, pass: string): boolean;

begin

result: = false;

if db. TestConnected then try

with DM. qRead do begin

if Active then Close;

SQL. Text: = 'select * from USERS where UPPER (LOGIN) =: LOGIN';

ParamByName ('LOGIN'). AsString: = AnsiUpperCase (Login);

Open;

if EOF

then MessageDlg ('База данных: ' + db. DatabaseName + #13 + 'Пользователь не найден: ' + Login, mtError, [mbOK], 0)

else

if trim (FieldByName ('PASS'). AsString) = trim (Pass) then begin

with dm. User do begin

ID: = FieldByName ('UID'). AsInteger;

LOGIN: = FieldByName ('LOGIN'). AsString;

NAME: = FieldByName ('NAME'). AsString;

Rules: = FieldByName ('RULES'). AsString;

end;

Close;

result: = true;

end

else MessageDlg ('База данных: ' + db. DatabaseName + #13 + 'Неверный пароль: ' + Pass, mtError, [mbOK], 0);

end;

except

result: = false;

end;

end;

function TfrMain. InitFrame: boolean;

begin

result: = true;

try

FreeFrames;

// Инициализация фреймов для данного пользователя

frSelectFrame. listFrames. Clear;

with DM. User do begin

if ( (pos ('c', Rules) > 0) or (pos ('a', Rules) > 0)) then begin

frmPark: = TfrmPark. Create (nil);

frmPark. Parent: = self;

frSelectFrame. listFrames. AddItem (frmPark. ModuleName, frmPark);

end;

if ( (pos ('e', Rules) > 0) or (pos ('a', Rules) > 0)) then begin

frmRequest: = TfrmRequest. Create (nil);

frmRequest. Parent: = self;

frSelectFrame. listFrames. AddItem (frmRequest. ModuleName, frmRequest);

end;

if ( (pos ('s', Rules) > 0) or (pos ('a', Rules) > 0)) then begin

frmStore: = TfrmStore. Create (nil);

frmStore. Parent: = self;

frSelectFrame. listFrames. AddItem (frmStore. ModuleName, frmStore);

end;

if pos ('a', Rules) > 0 then begin

frmUsers: = TfrmUsers. Create (nil);

frmUsers. Parent: = self;

frSelectFrame. listFrames. AddItem (frmUsers. ModuleName, frmUsers);

end;

{else begin

result: = false;

MessageDlg ('Ваша учетная запись не имеет прав в системе ' + ProductName + #13 + 'Обратитесь к администратору. ', mtError, [mbOK], 0)

end; }

end;

except

on e: exception do begin

result: = false;

MessageDlg (e. Message, mtError, [mbOK], 0);

end;

end;

end;

function TfrMain. SelectFrame: boolean;

begin

result: = true;

// Скрытие всех фреймов

if Assigned (frmUsers) then frmUsers. Visible: = false;

if Assigned (frmPark) then frmPark. Visible: = false;

if Assigned (frmRequest) then frmRequest. Visible: = false;

if Assigned (frmStore) then frmStore. Visible: = false;

with frSelectFrame do begin

// если инициализирован хотя бы 1 фрейм,

// установка курсора в списке фреймов

if listFrames. Items. Count > 0 then begin

listFrames. ItemIndex: = 0;

btnChangeModul. Visible: = false;

if listFrames. Items. Count > 1 then begin

// если фреймов несколько, показ окна выбора фрейма

btnChangeModul. Visible: = true;

if isPositiveResult (ShowModal)

then lblMain. Caption: = ''

// если отменили, выход

else begin

lblMain. Caption: = 'Выберите модуль';

result: = false;

end;

end;

end;

// отображение выбранного (или единственного) фрейма

with DM do begin

if (result) {and (DBMain. TestConnected) } then

with (listFrames. Items. Objects [listFrames. ItemIndex] as TfrmPattern) do begin

DBMain. CloseDataSets;

DBPark. CloseDataSets;

DBStore. CloseDataSets;

if trnWriteMain. Active then trnWriteMain. Rollback;

if trnWritePark. Active then trnWritePark. Rollback;

if trnWriteStore. Active then trnWriteStore. Rollback;

// Вызывается переопределенный Initialize:

// Если соединение с необходимой БД неактивно, то модуль не отображается.

// Отображение происходит при последующем соединении с БД (повторно вызывается SelectFrame)

if Initialize then begin

frMain. Caption: = ProductName + ' - ' + ModuleName + ' - ' + ' [' + User. Name + '] ';

Visible: = true;

end else MessageDlg ('Отсутствует соединение с БД, необходимой '#13'для работы модуля', mtError, [mbOK], 0);

end;

end;

end;

end;

procedure TfrMain. actSettingsDBExecute (Sender: TObject);

begin

with (TfrDBState. Create (nil)) do try

// Если произошло изменение подлючений БД, присходит закрытие

// модулей и отображение окна выбора модуля

if not IsPositiveResult (ShowModal)

then SelectFrame;

Finally Free;

end;

end;

procedure TfrMain. actChangeModuleExecute (Sender: TObject);

begin

SelectFrame;

end;

procedure TfrMain. actLogoutExecute (Sender: TObject);

begin

Hide;

Show;

end;

procedure TfrMain. actAboutExecute (Sender: TObject);

begin

with TfrAbout. Create (nil) do

try Showmodal

Finally Free;

end;

end;

procedure TfrMain. actExitExecute (Sender: TObject);

begin

Close;

end;

end.

unit uFrmRequest;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, uFrmPattern, PropFilerEh, PropStorageEh, ImgList, ActnList,

ComCtrls, Grids, DBGridEh, ToolWin, ExtCtrls;

type

TfrmRequest = class (TfrmPattern)

actNewRequest: TAction;

actEditRequest: TAction;

actDelRequest: TAction;

pnlGoods: TPanel;

Splitter1: TSplitter;

gridGoods: TDBGridEh;

pnlCapGoods: TPanel;

ToolBar2: TToolBar;

ToolButton4: TToolButton;

actNewGoods: TAction;

actEditGoods: TAction;

actDelGoods: TAction;

ToolButton5: TToolButton;

ToolButton6: TToolButton;

actFilterRequest: TAction;

pnlRequest: TPanel;

pnlCapReq: TPanel;

ToolBar1: TToolBar;

ToolButton1: TToolButton;

ToolButton2: TToolButton;

ToolButton3: TToolButton;

ToolButton7: TToolButton;

gridCar: TDBGridEh;

pnlRoute: TPanel;

Splitter2: TSplitter;

Panel1: TPanel;

ToolBar3: TToolBar;

ToolButton8: TToolButton;

ToolButton9: TToolButton;

ToolButton10: TToolButton;

gridRoute: TDBGridEh;

actNewCP: TAction;

actEditCP: TAction;

actDelCP: TAction;

procedure actNewRequestExecute (Sender: TObject);

procedure actEditRequestExecute (Sender: TObject);

procedure actDelRequestExecute (Sender: TObject);

procedure actNewGoodsExecute (Sender: TObject);

procedure actEditGoodsExecute (Sender: TObject);

procedure actDelGoodsExecute (Sender: TObject);

procedure actFilterRequestExecute (Sender: TObject);

procedure actNewCPExecute (Sender: TObject);

procedure actEditCPExecute (Sender: TObject);

procedure actDelCPExecute (Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

constructor Create (AOwner: TComponent); override;

function Initialize: boolean; override;

function Finalize: boolean; override;

end;

var

frmRequest: TfrmRequest;

implementation

uses uDM, uConnect, uEditRequest, uEditReqGoods, DB, uFilterRequest, uEditRoute;

{$R *. dfm}

constructor TfrmRequest. Create (AOwner: TComponent);

begin

inherited;

ModuleName: = 'Офис';

end;

function TfrmRequest. Initialize: boolean;

begin

if dm. DBMain. TestConnected

then result: = true

else result: = IsPositiveResult (ConnectTo (dm. dbMain, 'Главная БД'));

if result then begin

sControls. LoadProperties;

with DM do begin

qRequest. Open;

qRequest. FetchAll;

qReqGoods. Open;

qReqGoods. FetchAll;

qRoute. Open;

qRoute. FetchAll;

end;

end;

end;

function TfrmRequest. Finalize: boolean;

begin

sControls. SaveProperties;

with DM do begin

if trnWriteMain. InTransaction then

trnWriteMain. Rollback;

if qRequest. Active then qCar. Close;

if qReqGoods. Active then qReqGoods. Close;

if qRoute. Active then qRoute. Close;

end;

end;

procedure TfrmRequest. actNewRequestExecute (Sender: TObject);

begin

with TfrEditRequest. Create (self) do try

Caption: = 'Добавить заявку';

with DM do begin

updRequest. UpdateTransaction. StartTransaction;

with qRequest do begin

Insert;

qRead. SQL. Text: = 'select tID,NAME from request_type';

qRead. Open;

qRead. FetchAll;

qRead. First;

cbRequestType. KeyValue: = qRead. FieldByName ('tID'). AsInteger;

FieldByName ('COMPLETED'). AsInteger: = 0;

if isPositiveResult (Showmodal) then begin

if clientID <> - 1 then FieldByName ('CLIENT'). AsInteger: = clientID;

FieldByName ('USER_ADD'). AsInteger: = User. ID;

if FieldByName ('COMPLETED'). AsInteger = 1 then

FieldByName ('USER_CLOSE'). AsInteger: = User. ID;

FieldByName ('request_type'). AsInteger: = cbRequestType. KeyValue;

Post;

updRequest. UpdateTransaction.commit;

end else begin

CancelUpdates;

updRequest. UpdateTransaction. Rollback;

end;

qRead. Close;

Refresh;

end;

end;

finally Free

end;

end;

procedure TfrmRequest. actEditRequestExecute (Sender: TObject);

var complet: integer;

begin

if not DM. qRequest. IsEmpty then

with TfrEditRequest. Create (self) do try

Caption: = 'Изменить заявку';

with DM do begin

updRequest. UpdateTransaction. StartTransaction;

with qRequest do begin

Edit;

qRead. SQL. Text: = 'select tID,NAME from request_type';

qRead. Open;

qRead. FetchAll;

edtName. Text: = FieldByName ('CLIENT_NAME'). AsString;

if not FieldByName ('CLIENT'). IsNull then

clientID: = FieldByName ('CLIENT'). AsInteger;

complet: = FieldByName ('COMPLETED'). AsInteger;

if isPositiveResult (Showmodal) then begin

if clientID <> - 1 then FieldByName ('CLIENT'). AsInteger: = clientID;

if FieldByName ('COMPLETED'). AsInteger <> complet then

FieldByName ('USER_CLOSE'). AsInteger: = User. ID;

Post;

updRequest. UpdateTransaction.commit;

end else begin

CancelUpdates;

updRequest. UpdateTransaction. Rollback;

end;

qRead. Close;

Refresh;

end;

end;

finally Free

end;

end;

procedure TfrmRequest. actDelRequestExecute (Sender: TObject);

begin

with DM do if not qRequest. IsEmpty then begin

updRequest. UpdateTransaction. StartTransaction;

qRequest. Delete;

updRequest. UpdateTransaction.commit;

end;

end;

procedure TfrmRequest. actNewGoodsExecute (Sender: TObject);

begin

with DM do begin

if not qRequest. IsEmpty then

with TfrEditReqGoods. Create (self) do try

Caption: = 'Добавить детализацию';

updReqGoods. UpdateTransaction. StartTransaction;

with qReqGoods do begin

Insert;

FieldByName ('CNT'). AsInteger: = 1;

FieldByName ('WEIGHT'). AsInteger: = 0;

if isPositiveResult (Showmodal) then begin

FieldByName ('REQUEST'). AsInteger: = qRequest. FieldByName ('rID'). AsInteger;

Post;

updReqGoods. UpdateTransaction.commit;

end else begin

CancelUpdates;

updReqGoods. UpdateTransaction. Rollback;

end;

end;

finally Free

end;

end;

end;

procedure TfrmRequest. actEditGoodsExecute (Sender: TObject);

begin

with DM do begin

if not qReqGoods. IsEmpty then

with TfrEditReqGoods. Create (self) do try

Caption: = 'Изменить детализацию';

updReqGoods. UpdateTransaction. StartTransaction;

with qReqGoods do begin

Edit;

if isPositiveResult (Showmodal) then begin

Post;

updReqGoods. UpdateTransaction.commit;

end else begin

CancelUpdates;

updReqGoods. UpdateTransaction. Rollback;

end;

end;

finally Free

end;

end;

end;

procedure TfrmRequest. actDelGoodsExecute (Sender: TObject);

begin

with DM do if not qReqGoods. IsEmpty then begin

updReqGoods. UpdateTransaction. StartTransaction;

qReqGoods. Delete;

updReqGoods. UpdateTransaction.commit;

end;

end;

procedure TfrmRequest. actNewCPExecute (Sender: TObject);

begin

with DM do begin

if not qRequest. IsEmpty then

with TfrEditRoute. Create (self) do try

Caption: = 'Добавить пункт маршрута';

updRoute. UpdateTransaction. StartTransaction;

with qRoute do begin

Insert;

cbPassed. Checked: = false;

if isPositiveResult (Showmodal) then begin

if cbPassed. Checked then begin

FieldByName ('PASSED'). AsInteger: = 1;

if VarType (edtDate_pass. Value) <> varNull then

FieldByName ('DATE_PASS'). AsDateTime: = edtDate_pass. Value;

end

else FieldByName ('PASSED'). AsInteger: = 0;

FieldByName ('REQUEST'). AsInteger: = qRequest. FieldByName ('rID'). AsInteger;

Post;

updRoute. UpdateTransaction.commit;

end else begin

CancelUpdates;

updRoute. UpdateTransaction. Rollback;

end;

Refresh;

end;

finally Free

end;

end;

end;

procedure TfrmRequest. actEditCPExecute (Sender: TObject);

begin

with DM do begin

if not qRoute. IsEmpty then

with TfrEditRoute. Create (self) do try

Caption: = 'Изменить пункт маршрута';

updRoute. UpdateTransaction. StartTransaction;

with qRoute do begin

Edit;

if FieldByName ('PASSED'). AsInteger = 1

then cbPassed. Checked: = true

else cbPassed. Checked: = false;

if not FieldByName ('DATE_PASS'). IsNull then

edtDate_pass. Value: = FieldByName ('DATE_PASS'). AsVariant;

if isPositiveResult (Showmodal) then begin

if cbPassed. Checked then begin

FieldByName ('PASSED'). AsInteger: = 1;

if VarType (edtDate_pass. Value) <> varNull then

FieldByName ('DATE_PASS'). AsDateTime: = edtDate_pass. Value;

end

else FieldByName ('PASSED'). AsInteger: = 0;

Post;

updRoute. UpdateTransaction.commit;

end else begin

CancelUpdates;

updRoute. UpdateTransaction. Rollback;

end;

Refresh;

end;

finally Free

end;

end;

end;

procedure TfrmRequest. actDelCPExecute (Sender: TObject);

begin

with DM do if not qRoute. IsEmpty then begin

updRoute. UpdateTransaction. StartTransaction;

qRoute. Delete;

updRoute. UpdateTransaction.commit;

end;

end;

procedure TfrmRequest. actFilterRequestExecute (Sender: TObject);

begin

with DM do

// with TfrFilterRequest. Create (self) do try

with frFilterRequest do begin

if isPositiveResult (Showmodal) then begin

qRequest. Close;

qRequest. SQL. LoadFromFile (ExtractFilePath (Application. ExeName) + '\Res\Request. Select. sql');

qRequest. SQL. Add (FilterSQL);

qRequest. SQL. Add (' order by rID ');

qRequest. Open;

qRequest. FetchAll;

qReqGoods. Open;

qReqGoods. FetchAll;

end else begin

end;

end;

end;

end.

unit uDM;

interface

uses

Forms, SysUtils, Classes, DB, IBCustomDataSet, IBQuery, IBDatabase, IBUpdateSQL,

IBUpdateSQLW, PropStorageEh, PropFilerEh, IniFiles, Dialogs;

type

TUser = record

ID: integer;

Name: string;

Rules: string;

Login: string;

end;

TDM = class (TDataModule)

DBMain: TIBDatabase;

trnReadMain: TIBTransaction;

trnWriteMain: TIBTransaction;

qWrite: TIBQuery;

qRead: TIBQuery;

dsRead: TDataSource;

updUsers: TIBUpdateSQLW;

qUsers: TIBQuery;

qUsersUID: TIntegerField;

qUsersLOGIN: TIBStringField;

qUsersPASS: TIBStringField;

qUsersNAME: TIBStringField;

qUsersRULES: TIBStringField;

dsUsers: TDataSource;

smgControls: TIniPropStorageManEh;

DBStore: TIBDatabase;

trnReadStore: TIBTransaction;

trnWriteStore: TIBTransaction;

trnReadPark: TIBTransaction;

trnWritePark: TIBTransaction;

DBPark: TIBDatabase;

dsCar: TDataSource;

qCar: TIBQuery;

qCarCID: TIntegerField;

qCarNAME: TIBStringField;

qCarCARGO: TFloatField;

qCarTRAILER_CNT: TIntegerField;

qCarPLACE: TIntegerField;

updCar: TIBUpdateSQLW;

qDriver: TIBQuery;

updDriver: TIBUpdateSQLW;

dsDriver: TDataSource;

qCarDriver: TIBQuery;

dsCarDriver: TDataSource;

qCarDriverDID: TIntegerField;

qCarDriverNAME: TIBStringField;

qCarDriverPASSPORT: TIBStringField;

qCarDriverCAR: TIntegerField;

qWritepark: TIBQuery;

qDriverDID: TIntegerField;

qDriverDRIVERNAME: TIBStringField;

qDriverPASSPORT: TIBStringField;

qDriverCAR: TIntegerField;

qDriverCID: TIntegerField;

qDriverCARNAME: TIBStringField;

qRequest: TIBQuery;

dsRequest: TDataSource;

updRequest: TIBUpdateSQLW;

qReqGoods: TIBQuery;

dsReqGoods: TDataSource;

updReqGoods: TIBUpdateSQLW;

qRequestRID: TIntegerField;

qRequestNAME: TIBStringField;

qRequestREQUEST_TYPE: TIntegerField;

qRequestUSER_ADD: TIntegerField;

qRequestUSER_CLOSE: TIntegerField;

qRequestREQUEST_TYPE_NAME: TIBStringField;

qRequestTID: TIntegerField;

qRequestCOMPLETED: TIntegerField;

qStoreGoods: TIBQuery;

dsStoreGoods: TDataSource;

updStoreGoods: TIBUpdateSQLW;

qStoreGoodsGID: TIntegerField;

qStoreGoodsGOODS_NAME: TIBStringField;

qStoreGoodsCLIENT: TIntegerField;

qStoreGoodsREQUEST: TIntegerField;

qStoreGoodsINV_NUM: TIBStringField;

qStoreGoodsDIMENSION: TIBStringField;

qStoreGoodsWEIGHT: TFloatField;

qStoreGoodsCNT: TIntegerField;

qStoreGoodsCLIENT_NAME: TIBStringField;

qRequestCLIENT_NAME: TIBStringField;

qRequestCLIENT: TIntegerField;

qStoreGoodsIS_OLD: TIntegerField;

qStoreGoodsSTAND: TIntegerField;

qStoreGoodsSHELF: TIntegerField;

qCarREQUEST: TIntegerField;

updRoute: TIBUpdateSQLW;

dsRoute: TDataSource;

qReqGoodsGID: TIntegerField;

qReqGoodsREQUEST: TIntegerField;

qReqGoodsINV_NUM: TIBStringField;

qReqGoodsNAME: TIBStringField;

qReqGoodsCNT: TIntegerField;

qReqGoodsDIMENSION: TIBStringField;

qReqGoodsWEIGHT: TFloatField;

qRoute: TIBQuery;

qRouteOID: TIntegerField;

qRouteNAME: TIBStringField;

qRouteDATE_PASS: TDateTimeField;

qRouteREQUEST: TIntegerField;

qRoutePASSED: TIntegerField;

procedure DBMainAfterConnect (Sender: TObject);

procedure DBMainBeforeDisconnect (Sender: TObject);

procedure DataModuleCreate (Sender: TObject);

procedure DataModuleDestroy (Sender: TObject);

procedure DBParkAfterConnect (Sender: TObject);

procedure dbParkBeforeDisconnect (Sender: TObject);

procedure qCarDriverAfterOpen (DataSet: TDataSet);

procedure DBStoreAfterConnect (Sender: TObject);

procedure DBStoreBeforeDisconnect (Sender: TObject);

private

{ Private declarations }

fGID: integer;

procedure LoadINIDB (filename: string);

procedure SaveINIDB (filename: string);

procedure LoadINISQL;

procedure SaveINISQL (filename: string);

public

{ Public declarations }

User: TUser;

ConnectionString: string;

end;

var

DM: TDM;

implementation

{$R *. dfm}

uses uConstants;

procedure TDM. SaveINIDB (filename: string);

begin

with TIniFile. Create (filename) do try

WriteString (iniDBMainSection, 'DBName', DBMain. DatabaseName);

WriteString (iniDBMainSection, 'Param0', DBMain. Params. Strings [0]);

WriteString (iniDBMainSection, 'Param1', DBMain. Params. Strings [1]);

WriteString (iniDBParkSection, 'DBName', DBPark. DatabaseName);

WriteString (iniDBParkSection, 'Param0', DBPark. Params. Strings [0]);

WriteString (iniDBParkSection, 'Param1', DBPark. Params. Strings [1]);

WriteString (iniDBStoreSection, 'DBName', DBStore. DatabaseName);

WriteString (iniDBStoreSection, 'Param0', DBStore. Params. Strings [0]);

WriteString (iniDBStoreSection, 'Param1', DBStore. Params. Strings [1]);

UpdateFile;

Free;

except

on e: Exception do MessageDlg ('Ошибка ini-файла: ' + e. Message, mtError, [mbOK], 0)

end;

end;

procedure TDM. LoadINIDB (filename: string);

begin

with TIniFile. Create (filename) do try

DBMain. DatabaseName: = ReadString (iniDBMainSection, 'DBName', '');

DBMain. Params. Strings [0]: = ReadString (iniDBMainSection, 'Param0', '');

DBMain. Params. Strings [1]: = ReadString (iniDBMainSection, 'Param1', '');

DBPark. DatabaseName: = ReadString (iniDBParkSection, 'DBName', '');

DBPark. Params. Strings [0]: = ReadString (iniDBParkSection, 'Param0', '');

DBPark. Params. Strings [1]: = ReadString (iniDBParkSection, 'Param1', '');

DBStore. DatabaseName: = ReadString (iniDBStoreSection, 'DBName', '');

DBStore. Params. Strings [0]: = ReadString (iniDBStoreSection, 'Param0', '');

DBStore. Params. Strings [1]: = ReadString (iniDBStoreSection, 'Param1', '');

Free;

except

on e: Exception do MessageDlg ('Ошибка ini-файла: ' + e. Message, mtError, [mbOK], 0)

end;

end;

procedure TDM. SaveINISQL (filename: string);

begin

with TIniFile. Create (filename) do try

Free;

except

on e: Exception do MessageDlg ('Ошибка ini-файла: ' + e. Message, mtError, [mbOK], 0)

end;

end;

procedure TDM. LoadINISQL;

var AppFolder: string;

begin

AppFolder: = ExtractFilePath (Application. ExeName);

qRequest. SQL. LoadFromFile (AppFolder + '\Res\Request. Select. sql');

qRequest. SQL. Add ('order by rID');

updRequest. RefreshSQL. LoadFromFile (AppFolder + '\Res\Request. Refresh. sql');

qReqGoods. SQL. LoadFromFile (AppFolder + '\Res\ReqGoods. Select. sql');

updReqGoods. RefreshSQL. LoadFromFile (AppFolder + '\Res\ReqGoods. Refresh. sql');

qCar. SQL. LoadFromFile (AppFolder + '\Res\Car. Select. sql');

updCar. RefreshSQL. LoadFromFile (AppFolder + '\Res\Car. Refresh. sql');

qCarDriver. SQL. LoadFromFile (AppFolder + '\Res\CarDriver. Select. sql');

qDriver. SQL. LoadFromFile (AppFolder + '\Res\Driver. Select. sql');

updDriver. RefreshSQL. LoadFromFile (AppFolder + '\Res\Driver. Refresh. sql');

qStoreGoods. SQL. LoadFromFile (AppFolder + '\Res\StoreGoods. Select. sql');