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

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

Средства безопасности баз данных долгое время пребывали в зачаточной стадии и сводились к принятой в SQL модели GRANT/REVOKE, которая позволяет владельцу данных передавать другим пользователям системы права на выполнение тех или иных операций чтения-записи. В реальности подобные упрощенные модели имеют весьма ограниченную ценность с точки зрения защиты данных не только от злоумышленников, целенаправленно стремящихся скомпрометировать принадлежащую компании информацию, но даже и от случайных нарушений безопасности.

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

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

1.2.1 Языки безопасных баз данных

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

Важно отметить, что, хотя в SQL предусмотрены операторы поддержки безопасности (например операторы GRANT и REVOKE), но они не обеспечивают многоуровневой защиты (и следовательно, принудительного управления доступом, MAC). Возможность предоставлять (GRANT) привилегии доступа и модификации по отношению к определенным объектам и передавать другим пользователям права на предоставление привилегий (конструкция WITH GRANT OPTION), а также отбирать (REVOKE) права (предоставленные непосредственно или в результате использования опции WITH GRANT OPTION) - все это средства поддержки добровольного управления доступом (DAC). Даже несмотря на то, что модель безопасности в SQL-92 проработана значительно тщательнее, чем в предыдущих версиях (отметим, впрочем, что многие коммерческие реляционные SQL-ориентированные СУБД имели собственные расширения для поддержки безопасности даже и до выхода SQL-92), но все эти возможности все равно недостаточны для обеспечения безопасности баз данных не только в будущем, но и в настоящем.

В ожидаемых коммерческих версиях СУБД с многоуровневой защитой, вероятно, будут присутствовать определенные языковые расширения. Пример исследовательского прототипа такого расширенного языка - MSQL (multilevel SQL), язык СУБД SeaView28). MSQL содержит операторы DDL со средствами спецификации классов безопасности:

create relation roster (

name char (30) [U:S]

primary-key,

rank char (10) [U:S],

job_code char (10)

[U:TS],

duty_location char (20) [U:TS],

...

)

MSQL допускает составные первичные ключи, как в следующем примере:

create relation roater (

group (last_name char (20),

first_name char (10),

middle_initial char (1) )

[U:TS] primary-key,

...

)

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

create relation missions (

...

task char (30) [S; TS

NUCLEAR; TS INTEL],

...

)

В этом примере столбец TASK может содержать значения класса "секретно", "совершенно секретно/ядерное оружие", "совершенно секретно/разведка".

MSQL допускает задание классификационных ограничений, концептуально подобных ограничениям целостности SQL:

create class-constraint

JOBCodeRules

on roster as

name.class = SECRET,

rank.class = SECRET,

mission.class =

(if roster.mission = "COUNTERINTELLIGENCE" then

TOP SECRET else SECRET)

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

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

Хотя SQL3 в настоящее время не содержит команд MLS (multilevel security), и эти средства, вероятно, будут предоставляться в виде специфических для конкретных продуктов расширений, мы можем тем не менее высказать некоторые предположения относительно языковых расширений MLS.

SQL, по-видимому, предоставит основу для языковых расширений обеспечения безопасности, хотя нетрадиционные операторы, подобные принятым в MSQL (CREATE RELATION вместо CREATE TABLE), скорее всего, приблизятся к синтаксису стандартных операторов SQL.

Когда реализации многозначности вместе с поддержкой многоуровневой защиты войдут в коммерческие версии СУБД, будут приняты и соответствующие языковые расширения, причем не только в виде конструкций языка определения данных (DDL), но и в виде новых функций типа HIGHEST-CLASS. Примеры - функции HIGHEST-COVER-STORY и LOWEST-COVER-STORY, возвращающие "легенды" агента, соответственно максимального и минимального классов секретности.

1.2.2 Защищенные схемы хранения информации

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

Рис. 8. Пример применения правил доступа Белл-ЛаПадула.

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

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

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

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

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

Рис. 9. Поэлементная классификация и возникающие в связи с этим проблемы.

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

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

Рис. 10. Многозначность.

Многозначность впервые была применена в 1988 г. в модели безопасной базы данных SeaView (Secure Data Views10)). За прошедшие с тех пор годы в этом направлении были проведены значительные исследования и написано немало работ, авторами многих из которых являются Сушил Джаджодия (Sushil Jajodia) и Рави Сандху (Ravi Sandhu) из Мейсоновского Университета.

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

Рис. 11. Многозначность и свойства Белл-ЛаПадула.

В отсутствие многозначности отношение с многоуровневой защитой, показанное на рис. 8(a), следовало бы обрабатывать следующим образом. База данных может маскировать значения, недоступные пользователю или процессу по соображениям безопасности, и такое маскирование обычно осуществляется при помощи пустых значений (null values, рис. 8(b)).

Рис. 12. Маскированные представления данных с целью обеспечения секретности.

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

Рис. 13. Попытка модификации маскированных объектов.

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

Допустим, что СУБД с многоуровневой защитой симулирует выполнение подобных модификаций, чтобы не раскрывать скрытый канал. Но что будет, если пользователь, только что изменивший некоторые данные, попытается выполнить запрос или приложение, которое обращается к этим данным, а ему ответят, что они отсутствуют? Значит, мы опять создаем косвенный канал.

А что если попытаться поддерживать в СУБД с многоуровневой защитой нечто вроде журнала таких модификаций и использовать его для последующих выборок? Знакомая идея, и неудивительно - ведь мы только что говорили о многозначности. Даже если мы предусмотрим какое-нибудь специфическое решение для реализации многозначности, например хранить два экземпляра кортежей, - это всего лишь одна из реализаций. Важно, что многозначность - это существенное свойство данных с многоуровневой защитой, а как она будет реализована - это вопрос второстепенный, не имеющий отношения к самой идее по-разному представлять информацию для пользователей разных уровней благонадежности; хотя способы реализации многозначности остаются важным направлением для исследовательской работы.

Рассматривая проблему реализации многозначности, полезно обратить внимание на концептуальное сходство между многозначными кортежами в базе данных с многоуровневой защитой и кортежами с множественными значениями в хронологических базах данных. Напомним, что в большинстве реляционных баз данных с расширениями для поддержки хронологизма должны существовать несколько экземпляров одного кортежа с одним и тем же значением первичного ключа, чтобы обеспечить отображение и текущего состояния объекта, и исторической информации о нем. В реляционной СУБД с расширениями для поддержки многоуровневой защиты по существу присутствует такой же тип представления с той разницей, что определяющим признаком экземпляров некоторого кортежа в хронологической базе данных является время, а в базе данных с многоуровневой защитой - класс доступа. Хотя с других точек зрения, помимо реализации многозначности, хронологические СУБД и СУБД с многоуровневой защитой имеют мало общего, в связи с коммерциализацией СУБД обоих типов может оказаться полезным применять в них общие алгоритмы представления и доступа к многозначным кортежам.

Итак, многозначность, примененная впервые в проекте SeaView, стала общепринятой моделью реализации баз данных с многоуровневой защитой, в особенности реляционных. Многозначность активно исследуется и в качестве механизма обеспечения безопасности в объектно-ориентированных базах данных (развитие средств защиты в СУБД этого типа пока еще значительно отстает по сравнению с реляционными СУБД, но их значение будет неуклонно расти вместе со стремлением позиционировать ООСУБД на рынке продуктов для коммерческих и правительственных организаций).

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

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

"Оранжевая книга" идентифицирует два типа косвенных каналов:

Хотя для баз данных более характерны косвенные каналы памяти, косвенные каналы времени также нельзя сбрасывать со счетов. Мы рассмотрим примеры обоих типов.

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

Но и при соблюдении *-свойства Белл-ЛаПадула информация может быть скомпрометирована косвенными способами, опять же при посредстве Троянского коня. Пример на рис. 8 показывает ситуацию, когда в условиях отсутствия многозначности для скрытия секретной информации от недостаточно благонадежных процессов используются пустые значения. Мы говорили о том, что отказ, полученный низкоуровневым процессом при попытке модифицировать эти как бы пустые значения, открывает косвенный канал, поскольку тем самым предоставляется информация о наличии секретных данных, маскируемых пустыми значениями (хотя содержание информации при этом не раскрывается). Однако при той же модели, путем кооперирования встроенного Троянского коня с низкоуровневым процессом, можно организовать передачу реальной классифицированной информации при помощи некоторого сигнального механизма. Троянский конь может открыть транзакцию, создать фиктивную таблицу известной структуры, заполнив ее фиктивными классифицированными данными и установив маски пустых значений. Низкоуровневый процесс затем мог бы в определенное время предпринять серию модификаций по отношению к этой таблице, интерпретируя коды результатов успешного или неуспешного завершения по отношению к выбранным строкам в соответствии с установленным кодом. Код может быть просто последовательностью бит ASCII-кодировки интересующих секретных данных. Например, для каждой восьмерки строк в таблице коды результата модификации будут интерпретироваться как 8-битный код одного символа. Могут применяться и более сложные коды. Закончив передачу данных по такому косвенному каналу, высокоприоритетный процесс может затем уничтожить (DROP) таблицу.

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

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

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

Ниже приведен еще один пример косвенного канала. Поскольку высокоуровневым процессам разрешено читать данные из объектов низкой классификации, может возникнуть следующая ситуация. Предположим, что высокоуровневый процесс посылает следующий SQL-запрос удаленной низкоуровневой СУБД:

SELECT name, rank, date_of_birth

FROM roster

WHERE duty_building=445

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

1.2.3 Разработанная схема данных

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

Схема данных была разделена на три составляющие:

Описание групп доступа и входящих в них пользователей.

Матрица доступа групп к объектам системы.

Описание объектов системы, на которые раздаются права.

Под пользователем с точки зрения системы безопасности понимается внутренний пользователь СУБД.

В матрице доступа к объектам системы потенциально содержится большое количество записей ( до нескольких миллионов ), поэтому при проектировании особый упор делался на обеспечение должной производительности. Это особенно важно, т.к. обращение к этой таблице может быть достаточно интенсивным. Для проверки производительности был проведен ряд тестов.

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

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

Записи в таблице создавались следующим образом.

Было решено, что для тестового примера достаточно такого набора параметров:

То есть, по статистическим оценкам (количество записей на объект - мат. ожидание псевдослучайной величины диапазона 1..9 с раномерным распределением - 5 - умножается на количество объектов - 300 000) общее количество записей должно быть в районе 1 500 000.

Записи создавались следующим образом: для каждого кода объекта бралось псевдослучайное количество записей на объект (1..9), затем для каждой из записей выбиралось псевдослучайные тип объекта, группа пользователей и маска с правами. Вероятность ошибки при вставке (выпадение двух и более одинаковых кодов групп пользователей для одного кода объекта) составляет 0, 000004% и поэтому не учитывается и не обрабатывается. защита данные серверный компьютерный

Как показывают тесты (см. лист 7, 8), разработанная модель обладает требуемой производительностью и реализует все требования, предъявляемые ей системой безопасности.

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

Журнал событий.

Журнал ошибок.

Журнал сообщений.

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

Журналы имеют следующую структуру:

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

Информационные поля, содержащие журналируемую информацию.

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

К любой системе безопасности применимы 3 основных требования:

Надежность

Быстродействие

Прозрачность

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

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

Быстродействие схемы данных было проанализировано на основе результатов выборок по случайным образом сгенерированной таблице размером 1 500 000 записей и было признано соответствующим предъявляемым требованиям быстродействия.

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

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

PowerBuilder Enterprise. Новые средства распределенных вычислений усилили и без того достаточно мощный продукт. Однако их нельзя считать завершенными. Эти функции PowerBuilder лишены инструментов визуального управления и контролируются только кодом. Средства переноса приложений на Web пока находятся в стадии разработки. Но эти недостатки легко компенсируются кроссплатформенными возможностями PowerBuilder и сильной поддержкой со стороны дополнительных продуктов независимых поставщиков. Еще одно полезное новшество -- компилятор собственного кода, повышающий производительность приложений. Кроме среды разработки PowerBuilder, версия 5.0 включает инструмент формирования запросов и отчетов InfoMaker и сервер реляционной базы данных Sybase SQL Anywhere. Инструмент InfoMaker способен генерировать приложения: он пригоден для создания простых приложений на основе шаблонов и значительно сокращает объем работы по написанию кода.

Тем, кто только начинает работать с PowerBuilder, предлагается такая полезная опора, как мультимедиа-практикум. Другая программа мультимедиа демонстрирует новые функции PowerBuilder -- распределенную среду многоуровневой разработки PowerBuilder; согласованный броузер объектов; библиотеку готовых базовых объектов Foundation Class Library; дополнения к элементам управления DataWindow, включая Rich Text Editor; Windows 95-подобные элементы управления, такие как многостраничные формы с закладками, списки и деревья. Элементы управления ActiveX и OLE теперь доступны из меню Controls или с инструментальной панели. Пользователи могут создавать объекты OLE из приложений-серверов OLE или выбирать готовые элементы из реестров своих систем.

Как и в предыдущих версиях PowerBuilder, разработчики собирают приложения, пользуясь набором художников (painters). Работа начинается с Application Painter, где создается иерархическая структура окон и объектов, входящих в приложение. Application Painter генерирует шаблон приложения, включающий базовый код запуска приложения, примерно соответствующий функции быстрого запуска PowerBuilder. Некоторый недостаток интуитивной наглядности PowerBuilder с лихвой компенсируется мощностью его инструментов для работы с базами данных.

Может показаться, что в Window Painter недостает быстродействующих инструментов разработки, таких как автоматические мастера форм, но в Database Painter и DataWindow Painter присутствует большинство функций, характерных для мастеров из других продуктов. Форматы контроля достоверности и редактирования данных (маски ввода, выпадающие списки, флажки и переключатели) можно связывать с колонками, редактируя их свойства в Database Painter. Все обычные форматы представления данных: страницы отчетов, формы ввода данных и таблицы представлены в виде шаблонов в DataWindow Painter. Еще один инструмент для разработки баз данных Data Pipeline Painter позволяет копировать данные из таблицы в новую или существующую БД. Это особенно полезно при загрузке данных с сервера в разрабатываемую базу данных или при установке базы данных на сервер. Эту же функцию можно использовать для организации информационного хранилища или вспомогательной БД, так как каждая конфигурация Data Pipeline Painter сохраняется в файле SQL. PowerBuilder Enterprise способен взаимодействовать с множеством СУБД. Он поставляется с собственными драйверами для большинства серверов баз данных и с драйверами ODBC для других источников данных. Драйверы ODBC прилагаются также к версии для рабочих групп PowerBuilder Professional.

В основе всего этого лежит управляемый событиями язык программирования PowerScript, близко напоминающий Basic и Cobol и кое-что взявший от С. Язык PowerScript поддерживает широкий набор типов данных, включая тип Апу, который может содержать данные, объекты или структуры любого рода, а также такие крупные двоичные объекты, как графические файлы. PowerBuilder поддерживает встроенные операторы SQL. Код PowerScript функционирует без каких-либо модификаций на всех платформах PowerBuilder Unix, Windows 95 и NT, Windows 3.1 и Macintosh, хотя некоторые специфические для той или иной платформы операторы могут не работать на других платформах.

Редактор программ PowerBuilder помогает в написании кода для объектов. Ряд падающих меню позволяет вставлять в него аргументы, ссылки на другие объекты и переменные. Object Browser также помогает ссылаться на связанные с объектами события и методы, даже на события и методы объектов OLE.

Тем, кто работал с предшественника ми PowerBuilder 5.0, все это хорошо знакомо. Что касается крупных изменений в продукте, то они относятся к средствам коллективной разработки, компилятору и технологиям распределенных вычислений. PowerBuilder Enterprise, кроме привязки к Intersolv PVCS, содержит теперь программу управления исходным кодом Powersoft ObjectCycle. Продукт PowerBuilder 5.0 компилирует приложения, генерируя собственный двоичный код. Такие приложения могут быть многоуровневыми и использовать объекты, расположенные на сервере приложений.

Средства поддержки распределенных вычислений PowerBuilder основаны на собственной технологии брокера объектных запросов. Транспортный объект PowerBuilder работает на сервере приложений, распределяя поступающие от приложений-клиентов запросы между объектами любых приложений-серверов. PowerBuilder способен установить связи с удаленными объектами, применяя WinSock, именованные каналы или протокол Sybase Open Client/Open Server, а также с объектами других исполняемых локально приложений.

Удаленные объекты не являются визуальными объектами PowerBuilder. Как и в большинстве трехуровневых приложений клиент/сервер, они играют роль посредников при выполнении запросов или реализуют логику задач на сервере. Эти объекты могут возвращать приложению-клиенту данные стандартных типов, структуры, массивы и специализированные не визуальные объекты.

Распределенные вычисления в PowerBuilder осуществляются довольно наглядно, но без применения графического интерфейса пользователя. Чтобы инициировать подключение к удаленному объекту с указанием протокола доступа, приложения, где помещается этот удаленный объект, и сервера, на котором выполняется данное приложение, достаточно всего восьми строк кода в клиентской программе. Затем разработчик вводит в нее замещающий объект, передающий аргументы на обработку удаленному объекту.

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

Средства работы с Internet и интрасетями в PowerBuilder ограничены элементами управления ActiveX, такими как встроенные Web-броузеры и другие принадлежности Internet из библиотек Visual Components (теперь эта компания входит в состав Powersoft), Microsoft, NetManage и др. Эти объекты позволяют разработчикам вводить в приложения источники данных Internet. Например, они могут связать удаленные Web-страницы с записями БД и отображать их при вызове этих записей.

Но планы Powersoft идут дальше, чем простое использование ресурсов Internet и Web. Через элементы управления ActiveX (и интегрируемые модули Netscape) в Web будут привнесены средства доступа к базам данных PowerBuilder, которые позволят обращаться к PowerBuilder DataWindow по Internet или интрасетям (они находятся в стадии бета тестирования).

За этим последует модуль PowerBuilder DataWindow, обеспечивающий выполнение на Web-броузере кода PowerScript и отображение данных с применением элементов управления PowerBuilder и Windows. Таким образом, разработчики смогут разворачивать в Web приложения на основе баз данных аналогично тому, как они это делают при помощи языка Java или ActiveX. В следующую версию PowerBuilder Powersoft намерена ввести возможность создания элементов управления ActiveX.

Компилятор собственного кода PowerBuilder, построенный на основе компилятора Watcom C/C++, генерирует оптимизированный код на языке С, который затем компилируется в исполняемый код.

Centura Team Developer. Компания Centura Software сделала заметный рывок от SQLWindows к 32-раз рядной визуальной среде разработки, но тот, кто знаком с SQLWindows, почувствует себя в Team Developer, как дома: сопряжение этого продукта с базами данных и готовые объекты Quick Objects перенесены из 1б-разрядного продукта.

В комбинации с дополнительными объектами Centura и ПО для связи с централизованными системами Team Developer составляет достойную конкуренцию дорогим продуктам клиент/сервер. Он совместим с такими мониторами транзакций, как CICS и Tuxedo, и устанавливает связь с приложениями для централизованных систем через ПО промежуточного слоя Centura SQLHost. Версия для языка Java, которая должна появиться к концу текущего года, превратит продукт в кроссплатформенный инструмент разработки для любой платформы, поддерживающей этот язык программирования фирмы Sun Microsystems.

Team Developer включает Centura Builder 32 -- разрядную версию интерфейса SQLWindows, комплект инструментов для развертывания БД Centura Ranger (32разрядная версия процессора базы данных SQLBase, инструменты для работы с базами данных и агент тиражирования), а также менеджер хранилища объектов и исходных кодов Team Object Manager.

Centura Team Object Manager может быть построен на основе целого ряда реляционных СУБД. Он способен хранить такие компоненты проекта, как прикладные объекты, элементы OCX и модели данных, созданные посредством инструментов моделирования или извлеченные из существующих баз данных. Кроме того, он координирует повседневную работу бригады программистов, позволяя менеджеру проекта распределять задания и уровни доступа к объектам.

По духу и форме главный интерфейс разработки Centura Builder соответствует инструменту Explorer из Windows 95 так же, как Visual C++ Developer's Studio фирмы Microsoft. Левая панель его главного окна отображает Explorer-подобное дерево компонентов приложений, в то время как правая панель через многостраничную форму с закладками предоставляет доступ к интерфейсам разработки компонентов (таким, как экран оформления компонентов и редакторы кода).

Мастера (wizards) Centura ускоряют разработку приложений. Проще всего начать с мастера QuickForm, который строит полные формы базы данных или окно MultiDocument Interface, соединенное с выбранными вами таблицами. Мастер управляет либо изолированными таблицами, либо парами связанных между собой таблиц.

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

Мастер Centura Three Tier Wizard нацелен на создание распределенных приложений клиент/сервер. Он строит их на основе монитора обработки транзакций Tuxedo, монитора обработки транзакций IBM CICS (посредством ПО Centura SQLHost, соединяющего клиентов с приложениями для мэйнфрейма) или в среде DCE с дополнительным программным обеспечением QuickRPC корпорации Open Environment. Собственный сервер распределенных приложений Centura Application Server компания планирует выпустить к концу года.

Возможности сопряжения с Internet и интрасетями Centura заложила в набор объектов QuickObjects и дополнительные программы, большая часть которых еще не была готова на момент выпуска продукта. Планируемый на сентябрь выпуск модуля Centura Web Data Publisher позволит помещать на Web данные из разных источников. Для построения приложений баз данных на основе протокола НТТР будет применяться класс форм Web. Объекты Internet QuickObjects распространяются как бесплатные приложения к продукту. В числе таких объектов Web-броузер, FTP-клиент и объект доступа к документам HTTP без применения браузера, извлекающий данные из Web-страниц без их обработки их грамматический разбор можно поручать другим приложениям.

Centura Data Explorer чрезвычайно упрощает просмотр имеющихся в наличии источников данных. Имитируя Windows Explorer, он использует для отображения серверов и локальных источников данных развертывающееся дерево, и предоставляет доступ к структуре таблиц и данных, а также к индексам и представлениям. Разработчики могут создавать новые таблицы и индексы, и даже целые базы данных SQLBase.

Язык программирования приложений в Centura несколько отличается от тех, какие применяются в других инструментах разработки. Код компонентов и события описываются не обычными командными строками, а схематически, к тому же приложения Centura являются полностью объектно-ориентированными: все в них представлено объектами. Инструмент Coding Assistant обеспечивает возможность контекстно-зависимого выбора допустимых событий для каждого объекта и наносит выбранные события на схему. Этот метод существенно ускоряет разработку и позволяет Centura сохранять в Team Object Manager почти все объекты, включая модели данных из элементы в динамически связанные библиотеки. Это не то же самое, что полностью компилированные приложения, но объекты представлены исполняемым двоичным кодом.

По способности работать на разных платформах Centura Team Developer уступает PowerBuilder Уступает и в отношении цены Team Developer стоит на 2000 дол. дороже, чем PowerBuilder Enterprise. Тем не менее связи Team Developer с промежуточным ПО Centura, дополнительные приложения вроде нового продукта SApplication Builder для сопряжения с SAP R/3 и поддержка таких стандартов, как Tuxedo и CICS, делают этот продукт адекватным для разработки приложений высокого класса.

1.3.2 Выбор средств разработки

Средства разработки клиентской части.

1.3.3 Проектирование схемы данных

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

1.3.4 Создание серверной части

В базовой версии системы было решено использовать СУБД Oracle Server 7.3, как одну из самых мощных и производительных на рынке. Oracle Server обладает мощными встроенными средствами создания серверных приложений. Но в данном случаем было решено использовать только стандартные технологии для улучшения переносимости системы на другие платформы. Средства поддержки триггеров и хранимых процедур есть во всех распространенных СУБД, как правило, все отличия только во внутреннем языке программирования. Oracle Server для реализации триггеров и хранимых процедур использует язык PL/SQL.

1.3.5 Разработка клиентской части

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

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

Для разработки структуры данных CASE система PDesigner фирмы Sybase.

Для разработки клиентской часть - систему программирования Centura Team Developer фирмы Centura.

Серверную часть - на триггерах и хранимых процедурах

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

2. Технологическая часть

2.1 Технология организации надежной безопасности КИС