Защита баз данных

метки: Пользователь, Защита, Данные, Работа, Право, Курсовой, Доступ, Grant

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

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

Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньшей степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ. Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также базы данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер».

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

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

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

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

«Создание базы данных в Microsoft Access» Ташкент 2016 г

... данных, а также санкционирования доступа. Цель курсовой работы: ознакомление с основными средствами Microsoft Access для создания баз данных; создание собственную базу данных. Перед тем как приступить к изучению СУБД ACCESS рассмотрим несколько основных понятий. Данные ...

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

Защита информации. Понятие защиты информации

Защита информации – это комплекс мероприятий, направленных на обеспечение основных аспектов информационной безопасности, таких как целостность, доступность и, при необходимости, конфиденциальность информации и ресурсов, используемых для ввода, хранения, обработки и передачи данных [1].

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

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

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

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

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

Раскрытие темы

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

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

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

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

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

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

Защита информации в информационных системах

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

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

Защита ПК от несанкционированного доступа

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

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

2) многие ПК служат коллективным средством обработки информации, что обезличивает ответственность, в том числе и за защиту информации;

3) современные ПК оснащены несъемными накопителями на ЖМД очень большой емкости, причем информация на них сохраняется даже в обесточенном состоянии;

4) накопители на ГМД производятся в таком массовом количестве, что уже используются для распространения информации также, как и бумажные носители;

5) первоначально ПК создавались именно как персональное средство автоматизации обработки информации, а потому и не оснащались специально средствами защиты от НСД.

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

Основные механизмы защиты ПК от НСД могут быть представлены следующим перечнем:

1) физическая защита ПК и носителей информации;

2) опознавание (аутентификация) пользователей и используемых компонентов обработки информации;

3) разграничение доступа к элементам защищаемой информации;

4) криптографическое закрытие защищаемой информации, хранимой на носителях (архивация данных);

5) криптографическое закрытие защищаемой информации в процессе непосредственной ее обработки;

6) регистрация всех обращений к защищаемой информации.

Ниже излагаются общее содержание и способы использования перечисленных механизмов.

Защита информации в базах данных

Обеспечение безопасности данных в современных СУБД

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

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

Создание с помощью SQL Server базы данных для магазина продуктов

... информация о различных элементах базы данных: индексах, таблицах, пользователях и т.д. Файлы БД сохраняются с расширением MDF, а системные файлы с расширением LDF. Основные операции, связанные с управлением работой SQL ... модель. Создадим базу данных «Магазин продуктов»: create ... информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по ...

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

Для реализации избирательного подхода в СУБД предусмотрены следующие методы. Вводится новый тип объектов БД — пользователи. Каждому пользователю присваивается уникальный идентификатор, а также уникальный пароль для дополнительной защиты. Пароли пользователей обычно хранятся в кодированном виде и доступны только самим пользователям. Пользователи могут быть объединены в группы пользователей, где один пользователь может быть членом нескольких групп. В стандарте СУБД вводится понятие группы PUBLIC, для которой определен минимальный набор прав. По умолчанию каждый новый пользователь относится к группе PUBLIC.

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

В последних версиях ряда коммерческих СУБД появилось понятие «роли». Роль — это поименованный набор полномочий. Существует ряд стандартных ролей, которые определены в момент установки сервера баз данных. И имеется возможность создавать новые роли, группируя в них произвольные полномочия. Введение ролей позволяет упростить управление привилегиями пользователей, структурировать этот процесс. Кроме того, введение ролей не связано с конкретными пользователями, поэтому роли могут быть определены и сконфигурированы до того, как определены пользователи системы.

Пользователю может быть назначена одна или несколько ролей.

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

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

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

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

СУБД в своих системных каталогах хранит как описание самих пользователей, так и описание их привилегий по отношению ко всем объектам.

Защита баз данных

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

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

В ряде СУБД вводится следующий уровень иерархии пользователей — это администратор БД. В этих СУБД один сервер может управлять множеством СУБД (например, MS SQL Server, Sybase).

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

В стандарте SQL определены два оператора: GRANT и REVOKE соответственно предоставления и отмены привилегий.

Оператор предоставления привилегий имеет следующий формат:

• GRANT {<списокдействий | ALL PRIVILEGES }

ON <имя_объекта> ТО (<имя_пользователя> ] PUBLIC } [WITH GRANT OPTION ]

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

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

<имя_обьекта> — задает имя конкретного объекта: таблицы, представления, хранимой процедуры, триггера.

<имя_пользователя> или PUBLIC определяет, кому предоставляются данные привилегии.

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

Рассмотрим пример, пусть у нас существуют три пользователя с абсолютно уникальными именами userl, user2 и user3. Все они являются пользователями одной БД.

User1 создал объект Таb1, он является владельцем этого объекта и может передать права на работу с этим объектом другим пользователям. Допустим, что пользователь user2 является оператором, который должен вводить данные в Таb1 (например, таблицу новых заказов), а пользователь user3 является большим начальником (например, менеджером отдела), который должен регулярно просматривать введенные данные.

Назначение прав доступа к таблице — это один из важных аспектов безопасности данных в базе данных. Полный набор операций, которые могут быть выполнены для таблицы, включает в себя SELECT, INSERT, DELETE и UPDATE. При этом операция UPDATE может быть ограничена несколькими столбцами.

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

• GRANT {[SELECT][.INSERT][,DELETED[.UPDATE <список столбцов>

• ]} ON <имя таблицы>

• TO {<имя_пользователя>
• PUBLIC }

[WITH GRANT OPTION ]

Например, оператор GRANT INSERT ON Tab1 TO user2 назначит право вставки новых строк в таблицу Tab1 пользователю user2. Оператор GRANT SELECT ON Tab1 TO user3 назначит право просматривать все строки в таблице Tab1 пользователю user3.

При назначении прав на операции модификации (UPDATE, DELETE) можно ограничить список изменяемых пользователем столбцов. Например, оператор GRANT SELECT. UPDATE (COST) ON Tab1 TO user3 назначит право обновлять только столбец COST таблицы Tab1 пользователю user3.

Если нужно передать все полномочия по работе с таблицей другому пользователю, можно использовать оператор GRANT ALL PRIVILEGES. Например, GRANT ALL PRIVILEGES ON Tab1 TO user4 WITH GRANT OPTION назначит пользователю user4 все возможные права на работу с таблицей Tab1 и право делегировать эти права другим пользователям при необходимости.

При передаче прав другому пользователю, этот пользователь может передать только те права, которые были назначены ему. Например, если пользователю user4 назначены права SELECT, UPDATE и DELETE, то он может передать те же права или их часть другому пользователю. При этом он не может передать право INSERT (если оно не было назначено ему в исходном наборе прав).

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

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

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

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

Представления могут соответствовать итоговым запросам, и для них недопустимы операции изменения. Поэтому, для таких представлений набор допустимых действий ограничивается операцией SELECT. Но если представление соответствует выборке из базовой таблицы, то для него допустимы все 4 операции: SELECT, INSERT, UPDATE и DELETE.

Для отмены ранее назначенных привилегий в стандарте SQL используется оператор REVOKE. Он имеет следующий синтаксис:

REVOKE <список операций | ALL PRIVILEGES> ON <имя_объекта> FROM <список пользователей | PUBLIC> {CASCADE | RESTRICT}

Параметры CASCADE или RESTRICT определяют, каким образом должна производиться отмена привилегий. Параметр CASCADE отменяет привилегии не только пользователя, который непосредственно упоминался в операторе GRANT при предоставлении ему привилегий, но и всем пользователям, которым этот пользователь передал привилегии, используя параметр WITH GRANT OPTION.

Например, при использовании операции:

REVOKE ALL PRIVILEGES ON Tab1 TO user4 CASCADE

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

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

Например, операция:

REVOKE ALL PRIVILEGES ON Tab1 TO user4 RESTRICT

не будет выполнена, потому что пользователь user4 передал часть своих полномочий пользователю user5.

Оператор REVOKE позволяет отобрать привилегии по работе с конкретным объектом. Этот оператор может быть использован для отзыва привилегий у одного или нескольких пользователей или у группы PUBLIC.

Например, следующая команда REVOKE отзывает привилегию INSERT у пользователей user2 и user4 для таблицы Tab:

REVOKE INSERT ON Tab FROM user2, user4 CASCADE

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

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

REVOKE EXECUTE ON COUNT_EX FROM PUBLIC CASCADE

После выполнения этой команды, пользователи из группы PUBLIC больше не смогут запускать хранимую процедуру COUNT_EX. Затем можно предоставить новые права пользователю user4:

GRANT EXECUTE ON COUNT_EX TO user4

Системный администратор может предоставить пользователю user1 права на создание, изменение и удаление таблиц в БД OB_LIB:

GRANT CREATE TABLE, ALTER TABLE, DROP TABLE ON OB_LIB TO user1

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

В некоторых СУБД, пользователь может получить права на создание БД. Например, в MS SQL Server, системный администратор может предоставить пользователю main_user право на создание своей БД:

GRANT CREATE DATABASE ON SERVERJ TO main_user

Теперь пользователь main_user может предоставлять права на создание и изменение объектов в своей БД другим пользователям.

В СУБД Oracle, где используется однобазовая архитектура, такие разрешения недопустимы. Вместо этого, вводятся системные привилегии, которых существует 80 различных. Пользователи могут работать на уровне подсхемы, что позволяет им управлять доступом к частям таблиц БД и связанным объектам.

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

Реализация защиты в некоторых СУБД, Архитектура защиты Access

Если у вас имеется опыт работы с защитой, используемой на сервере или большой ЭВМ, структура защиты в Access покажется вам знакомой. Вы можете указать пользователей, которым предоставляется или, наоборот, не разрешается доступ к объектам базы данных. Кроме того, вы можете определить группы пользователей и назначить разрешения на уровне группы, чтобы облегчить построение защиты для большого числа пользователей. Пользователю достаточно быть членом группы, чтобы получить права доступа, установленные для неё.

Access хранит информацию о защите в двух местах. Во время установки программа Setup создаст в папке \Program Files\Microsoft Ofice\0ffice стандартный файл рабочей группы (System.mdw), который впоследствии используется по умолчанию при запуске Access. Этот файл содержит информацию обо всех пользователях и группах. При создании базы данных Access сохраняет сведения о правах, предоставляемых конкретным пользователям и группам, в файле базы данных.

Общая структура защиты Access отображена на рисунке 1. Учётные записи пользователей и групп хранятся в файле рабочей группы. Разрешение на доступ к конкретным объектам сохраняются в файле базы данных.

Рис. 1

Расположение текущего файла рабочей группы — важная информация, которая хранится в реестре Windows. Для изменения этого файла или определения нового можно использовать служебную программу Wrkadm.exe (администратор рабочих групп).

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

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

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

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

Одним из преимуществ параллельного резервного копирования является возможность использования нескольких резервных устройств, каждому из которых отводится свой поток. Симметричная архитектура поддерживает до 32 одновременных резервных устройств (backup devices), что позволяет быстро создавать страховочные копии баз данных даже большого объема.

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

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

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

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

DUMP DATABASE pubs
TO DISK = '\\ntalexeysh\disk_d\sql_experiments\pubs.dmp'
WITH INIT, EXPIREDATE=@tomorrow, STATS

В данном примере выполняется резервное копирование базы данных «pubs» на устройство с указанным путем «\\ntalexeysh\disk_d\sql_experiments\pubs.dmp». Параметр «INIT» указывает, что при каждом выполнении операции резервного копирования должен быть создан новый файл, заменяющий предыдущий. Параметр «EXPIREDATE» указывает дату утраты актуальности резервной копии, после которой она не может быть использована для размещения других резервных копий. Параметр «STATS» позволяет отображать статистику выполнения операции резервного копирования.

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

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

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

В отличие от резервного копирования базы данных, при создании дампа журнала транзакций автоматически очищается его неактивная часть. Это означает, что все завершенные транзакции с момента последнего дампа удаляются из журнала, если не используется опция NO_TRUNCATE. Команда DUMP TRANSACTION TRUNCATE_ONLY полезна в случаях, когда журнал транзакций заполняется полностью, и для его очистки используются различные методы контроля заполненности, например, DBCC SQLPERF (LOGSPACE).

Если степень заполненности журнала высока, можно отказаться от журналирования факта самого процесса очистки с использованием команды DUMP TRANSACTION NO_LOG.

Если резервное копирование транзакций не так важно, можно включить опцию очистки завершенных транзакций в базе данных при выполнении события checkpoint. Событие checkpoint заключается в периодической записи данных из кэша на диск, чтобы избежать сохранения «грязных» данных. Это событие может происходить автоматически в MS SQL Server или быть запущено пользователем. Включенная опция truncate log on checkpoint обеспечивает автоматическое выполнение операций, эквивалентных команде DUMP TRANSACTION TRUNCATE_ONLY.

Восстановление данных из журнала транзакций является важной операцией при работе с базой данных. MS SQL Server 6.5 предоставляет возможность восстановления данных на произвольный момент времени с использованием команды LOAD TRANSACTION STOPAT <t> или опции until time при выполнении операции резервного копирования и восстановления базы данных. Это позволяет поднять состояние базы данных на определенный момент и последовательно применить все транзакции из журнала, предшествующие этому моменту.

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

MS SQL Server 6.5 также предоставляет возможность зеркалирования устройств, переключения на зеркальные устройства в качестве основных, выключения зеркалирования и уничтожения зеркального устройства без остановки работы сервера. Это позволяет обеспечить отказоустойчивость и дуплексирование данных. Зеркалирование и дуплексирование устройств для работы с MS SQL Server можно выполнить с использованием средств Windows NT или на аппаратном уровне, например, с помощью RAID-систем.

Первый этап кластерной технологии WolfPack должен поддерживать MS SQL Server 6.5 в отказоустойчивых кластерах из двух узлов. Ожидается, что следующая версия MS SQL Server позволит работать серверам в кластере как единому виртуальному серверу.

Transfer Manager используется для экспорта/импорта объектов и данных БД на MS SQL Server между разными аппаратными платформами, например между процессорами Intel и Alpha, а также между разными версиями MS SQL Server, в частности из более ранних в более поздние или между равноценными (имеются в виду 4.х и 6.х).

Очень часто проектирование объектов базы ведется с помощью различных графических средств, но проектная документация может требовать структуру объектов с точностью до операторов DDL. Для получения скриптов, описывающих создание отдельного объекта базы данных, можно использовать команду transfer из контекстного меню объекта или выбрать соответствующий класс и имя объекта в Transfer Manager. Кроме этого, содержимое данных может быть выгружено/загружено при помощи утилиты bcp (см. табл. 1).

Вопросы безопасности доступа

Говоря о преимуществах интеграции с операционной системой, MS SQL Server использует в своей работе сервисы безопасности Windows NT. Напомним, что Windows NT на сегодня сертифицирована по классам безопасности С2/Е3. MS SQL Server может быть настроен на работу в одном из трех режимах безопасности. Интегрированный режим предусматривает использование механизмов аутентификации Windows NT для обеспечения безопасности всех пользовательских соединений. В этом случае к серверу разрешаются только трастовые, или аутентифицирующие, соединения (named pipes и multiprotocol).

Администратор имеет возможность отобразить группы пользователей Windows NT на соответствующие значения login id MS SQL Server при помощи утилиты SQL Security Manager. В этом случае при входе на MS SQL Server login name и пароль, переданные через DB-Library или ODBC, игнорируются. Стандартный режим безопасности предполагает, что на MS SQL Server будут заводиться самостоятельные login id и соответствующие им пароли. Смешанный режим использует интегрированную модель при установлении соединений по поименованным каналам или мультипротоколу и стандартную модель во всех остальных случаях.

MS SQL Server обеспечивает многоуровневую проверку привилегий при загрузке на сервер. Сначала идентифицируются права пользователя на установление соединения с выбранным сервером (login name и пароль) и выполнение административных функций: создание устройств и баз данных, назначение прав другим пользователям, изменение параметров настройки сервера и т.д. Максимальными правами обладает системный администратор. На уровне базы данных каждый пользователь, загрузившийся на сервер, может иметь имя пользователя (username) базы и права на доступ к объектам внутри нее. Имеется возможность отобразить нескольких login id на одного пользователя базы данных, а также объединять пользователей в группы для удобства администрирования и назначения сходных привилегий. По отношению к объектам базы данных пользователю могут быть назначены права на выполнение различных операций над ними: чтение, добавление, удаление, изменение, декларативная ссылочная целостность (DRI), выполнение хранимых процедур, а также права на доступ к отдельным полям. Если этого недостаточно, можно прибегнуть к представлениям (views), для которых сказанное остается справедливым. Наконец, можно вообще запретить пользователю непосредственный доступ к данным, оставив за ним лишь права на выполнение хранимых процедур, в которых будет прописан весь сценарий его доступа к базе. Хранимые процедуры могут создаваться с опцией WITH ENCRYPTION, которая шифрует непосредственный текст процедуры, хранящийся обычно в syscomments. Права на выполнение некоторых команд (создание баз, таблиц, умолчаний, правил, представлений, процедур, резервное копирование баз и журналов транзакций) не являются объектно-специфичными, поэтому они назначаются системным администратором сервера или владельцем (создателем) базы данных при редактировании базы данных. Администрирование пользовательских привилегий обычно ведется в SQL Enterprise Manager, тем не менее в Transact-SQL имеются хранимые процедуры (sp_addlogin, sp_password, sp_revokelogin, sp_addalias, sp_adduser) и операторы (GRANT, REVOKE), которые позволяют осуществлять действия по созданию пользователей, назначению и отмене прав при выполнении скриптов. Дополнительную возможность администрирования привилегий предоставляют рассмотренные нами выше SQL-DMO.

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

Система безопасности SQL Server имеет несколько уровней безопасности:

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

Механизм безопасности SQL Server предполагает существование четырех типов пользователей. Системный администратор является пользователем с неограниченным доступом. Он имеет возможность управлять всеми аспектами системы и имеет полный доступ ко всем объектам базы данных.

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

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

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

Модель безопасности SQL Server включает несколько компонентов. Тип подключения к SQL Server определяет режим безопасности, используемый при подключении. Существуют два режима безопасности: режим аутентификации Windows NT и смешанный режим аутентификации.

В режиме аутентификации Windows NT используется система безопасности Windows NT и ее механизм учетных записей. Пользователи могут подключаться к SQL Server, используя свои учетные записи Windows, без необходимости указывать имя пользователя и пароль. Информация об имени пользователя и пароле получается из атрибутов системы сетевой безопасности пользователей Windows.

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

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

Единственным исключением из этого правила является пользователь guest (гость).

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

Права доступа

Для управления правами доступа в SQL Server используются следующие команды:

• GRANT. Позволяет выполнять действия с объектом или, для команды — выполнять ее;
• REVOKE. Аннулирует права доступа для объекта или, для команды — не позволяет выполнить ее;
• DENY. He разрешает выполнять действия с объектом (в то время, как команда REVOKE просто удаляет эти права доступа).

Объектные права доступа позволяют контролировать доступ к объектам в SQL Server, предоставляя и аннулируя права доступа для таблиц, столбцов, представлений и хранимых процедур. Чтобы выполнить по отношению к некоторому объекту некоторое действие, пользователь должен иметь соответствующее право доступа. Например, если пользователь хочет выполнить оператор SELECT * FROM table, то он должен и меть права выполнения оператора SELECT для таблицы table.

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

• CREATE DATABASE — право создения базы данных;
• CREATE DEFAULT — право создшия стандартного значения для столбца таблицы;
• CREATE PROCEDURE — право содания хранимой процедуры.

CREATE ROLE — право создания гоавила для столбца таблицы;

• CREATE TABLE — право создания таблицы;
• CREATE VIEW — право создания представления;
• BACKUP DATABASE — право создшия резервной копии;
• BACKUP TRANSACTION — праве создания резервной копии журнала транзакций.

Роли

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

• роли уровня сервера;
• роли уровня базы данных.

Роли уровня сервера

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

В SQL Server существуют следующие типы ролей уровня сервера:

• Sysadmin — дает право выполнить любое действие в SQL Server;
• Serveradmin — дает право изменить параметры SQL Server и завершить его работу;
• Setupadmin — дает право инсталлировать систему репликации и управлять выполнением расширенных хранимых процедур;
• Securityadmin — дает право контролировать параметры учетных записей для подключения к серверу и предоставлять права доступа к базам данных;
• Processadmin — дает право управлять ходом выполнения процессов в SQL Server;
• Dbcreator — дает право создавать и модифицировать базы данных;
• Diskadmin — дает право управлять файлами баз данных на диске.

Роли уровня базы данных

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

В SQL Server существует три типа ролей:

• заранее определенные роли;
• определяемые пользователем роли;
• неявные роли.

Заранее определенными являются стандартные роли уровня БД. Эти роли имеет каждая база данных SQL Server. Они позволяют легко и просто передавать обязанности.

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

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

• db_accessadmin — осуществляет контроль за доступом к базе данных путем добавления или удаления пользователей в режимах аутентификации;
• db_datareader — определяет полный доступ к выборке данных (с помощью оператора SELECT) из любой таблицы базы данных. Запрещает выполнение операторов INSERT, DELETE и UPDATE для любой таблицы БД;
• db_datawriter — разрешает выполнять операторы INSERT, DELETE и UPDATE для любой таблицы базы данных. Запрещает выполнение оператора SELECT для любой таблицы базы данных;
• db_ddladmin — дает возможность создавать, модифицировать и удалять объекты базы данных;
• db_securityadmin — управляет системой безопасности базы данных, а также назначением объектных и командных разрешений и ролей для базы данных;
• db_backupoperator — позволяет создавать резервные копии базы данных;
• db_denydatareader — отказ в разрешении на выполнение оператора SELECT для всех таблиц базы данных. Позволяет пользователям изменять существующие структуры таблиц, но не позволяет создавать или удалять существующие таблицы;
• db_denydatawriter — отказ в разрешении на выполнение операторов модификации данных (INSERT, DELETE и UPDATE) для любых таблиц базы данных;
• public — автоматически назначаемая роль сразу после предоставления права доступа пользователя к БД.

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

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

• стандартная роль;
• роль уровня приложения.

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

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

Системный анализ — это применение системного подхода при обработке конкретной информации и принятию решений. Рассмотренные принципы системного подхода являются и принципами системного анализа.

Их дополняют следующие специфические принципы:

• анализ любого процесса принятия решения должен начинаться с выявления и четкой формулировки целей (желаемых результатов деятельности), которые часто определяются на основе рассмотрения системы более высокого уровня;
• необходимо рассматривать лишь те цели, вероятность достижения которых р>р0 за время t<t0, где/?0 и t0 — пороги осуществимости цели.

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

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

Безопасность данных в Oracle 7, Ограничение доступа

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

Огромным шагом вперед в обеспечении безопасности данных стало введение ролей в Oracle7. До Oracle7 каждому пользователю приходилось явно предоставлять права доступа к каждому объекту базы данных, который ему разрешено было использовать. Этот процесс упрощается за счет того, что доступ к совокупности объектов предоставляется роли, а затем право на использование этой роли предоставляется соответствующим лицам. С помощью команды GRANT мы можем предоставить пользователям право выполнять над объектами БД (например, над таблицами) операции SELECT, INSERT, UPDATE и DELETE. Однако само по себе это не обеспечивает значительной гибкости. Мы можем ограничить доступ пользователей частями таблицы, разделив ее по горизонтали (ограничив пользователя определенными строками), по вертикали (ограничив его определенными столбцами) или и по горизонтали, и по вертикали. Как это сделать?

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

Таблица PAYROLL

ID	NAME	DEFT	PAYMENT_PERIOD	SALARY
1	JONES	10	WEEKLY	120
2	K1RKUP	10	MONTHLY	900
3	DAVIES	10	WEEKLY	150
4	ARMSTRONG	20	MONTHLY	1030
5	KEMP	20	MONTHLY	1005
6	FISHER	30	WEEKLY	150

Мы можем определить представление и предоставить пользователям доступ к этому представлению, а не к базовой таблице (PAYROLL).

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

CREATE VIEW vjpayroll AS SELECT id

, name , dept

, payment_period FROM payroll WHERE dept = (SELECT dept

FROM mysys_users WHERE username = USER) WITH CHECK OPTION;

• Столбец SALARY в этом примере не включен в представление, поэтому зарплату в нем увидеть нельзя, а фраза WHERE гарантирует, что пользователи смогут запрашивать данные из таблицы PAYROLL только по своему отделу.

По поводу этого решения надо сказать следующее. Во-первых, мы должны сделать так, чтобы пользователи не могли изменить свой отдел, обновив значение MYSYSJUSERS, и затем запросить записи из другого отдела. Во-вторых, с помощью этого представления пользователи могли бы обновлять, вставлять и удалять даже не относящиеся к их отделу строки таблицы PAYROLL, если бы мы не отключили эту функцию с помощью фразы WITH CHECK OPTION.

Примечание

Вряд ли представление V_PAYROLL будет обновляемым, потому что к столбцу SALARY почти наверняка применено ограничение NOT NULL. Тем не менее, мы рекомендуем использовать опцию WITH CHECK OPTION во всех ограничивающих представлениях, так как в версии 7.3 значительно увеличилось число обновляемых представлений.

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

Использование пакетов

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

Наша первая попытка создать такой пакет представлена в примере 10.2. Пакет k_payroll гарантирует, что записи могут удаляться только начальником отдела и что устанавливать значение столбца SALARY может только начальник отдела.

Пример построения пакета для обеспечения безопасности доступа к данным

CREATE OR REPLACE PACKAGE k_payroll AS my_dept payroll.dept%TYPE; mgr BOOLEAN;

• PROCEDURE del (p_emp_id INTEGER);

PROCEDURE ins (p_emp_id INTEGER, p_name VARCHAR2

,p_dept INTEGER, p_payment_period VARCHAR2

,p_salary INTEGER);

PROCEDURE upd (p_emp__id INTEGER, p_name VARCHAR2

,p_payment_penod VARCHAR2 ,p_salary INTEGER);

• END k_payroll;

/

CREATE OR REPLACE PACKAGE BODY k_payroll AS

mgr_flag payroll.mgr_flag%TYPE;

CURSOR c_me IS

SELECT dept,

mgr_flag

FROM mysys_users

WHERE username = USER;

FUNCTION checkdept (p_emp_id INTEGER) RETURN BOOLEAN IS

dept payroll.dept%TYPE;

CURSOR cjpayroll IS

SELECT pay.dept

FROM payroll pay

WHERE id = p_emp_id;

BEGIN

OPEN c_payroll ;

• FETCH cjpayroll INTO dept;
• CLOSE c_payroll;
• IF dept <>
• my_dept THEN

RETURN FALSE;

• END IF;
• RETURN TRUE;
• END checkdept;

PROCEDURE del (p_emp_id INTEGER) IS

Удалять сотрудников могут только начальники их отделов

Записитаблицы Payroll

BEGIN

IF checkdept(p_emp_id) AND mgr THEN

DELETE payroll

WHERE id = p_emp_id;

ELSE

raise_application_error (-20001, ‘Insufficient Privilege’); END IF;

• END del;

PROCEDURE ins (p_emp_id INTEGER, p_name VARCHAR2

,p—dept INTEGER

,payment_period VARCHAR2

,p_salary INTEGER) IS

• Можете вставлять записи Payroll только в свой отдел

~ Устанавливать зарплату может только начальник отдела

(в противном случае устанавливается в пустое значение)

l_salary payroll.salary%TYPE;

BEGIN

IF NOT checkdept(p_emp_id) THEN

raise_application_error (-20001, ‘Insufficient Privilege’);

• END IF;

IF NOT mgr THEN

l_salary := NULL;

ELSE

l_salary := p_salary;

• END IF;

INSERT INTO payroll (id,name,dept,payment_period, salary)

VALUES (p_erap_id,p_name,p_dept,p_payraent_period,l_salary);

• END ins;

PROCEDURE upd (p_emp_id INTEGER, p_name VARCHAR2

,p_payment_period VARCHAR2 ,p_salary INTEGER) IS

• Можете обновлять записи Payroll только в своем отделе
• Обновлять зарплату может только начальник отдела

(в противном случае остается без изменений)

• Отделизменятьнельзя

l_salary payroll.salary%TYPE;

CURSOR c_old_salary IS

SELECT pay.salary

FROM payroll pay

WHERE id = p_erap_id;

BEGIN

IF NOT checkdept (p_emp_id) THEN

raise applicatiori_error (-20001, ‘Insufficient Privilege’);

• END IF;

IF NOT mgr THEN

OPEN c_old_salary;

• FETCH c__old_s alary INTO l__salary;

CLOSE c_old_salary,

ELSE

l_salary := p_salary;

• END IF;

UPDATE payroll

SET name = p_name

,payment_period = p_payment_period

,salary = l_salary

WHERE id = p_emp_id;

• END upd;
• Код инициализации пакета

BEGIN

OPEN c_me;

FETCH c_me

INTO ray_dept

,mgr_flag;

• CLOSE c_me;

IF mgr_flag = ‘Y’ THEN

mgr := TRUE;

ELSE

mgr := FALSE;

• END IF;
• END k_payroll;

/

Юридическая защита авторских прав на базы данных

Вопросы правовой защиты программ для ЭВМ и базы данных от незаконного использования являются очень актуальными в настоящий момент. Для иллюстрации этого приведем несколько фактов. По данным Ассоциации производителей компьютерного обеспечения, уровень компьютерного пиратства в России составляет 94%. Уровень пиратства в странах Запада существенно ниже: в Германии — 50%, в США — 35%. По данным МВД РФ, потери российского бюджета от неуплаты налогов продавцами компьютерных программ составляют 85 млн. долл. Деньги, полученные от продажи, часто уходят в распоряжение криминальных структур. Кроме того, 105 млн. долл. теряют российские предприятия. В области разработки компьютерных программ и баз данных в стране работает около шести тысяч фирм, обеспечивающих занятость более 200 тыс. человек. Данной сфере производства грозит стагнация — программисты попросту теряют стимулы к созданию новых передовых программных продуктов.

Признание права – первый из перечисленных в п. 1 ст. 18 Закона РФ «О правовой охране программ для ЭВМ и баз данных» способов защиты авторских прав. Этот способ защиты играет в основном превентивную роль и служит установлению определенности во взаимоотношениях субъектов гражданского права. Признание права как способ защиты применяется, когда оспаривается или отрицается принадлежность определенному лицу исключительных авторских прав на программу для ЭВМ или базу данных. Признание права как средство его защиты может быть реализовано лишь в судебном порядке путем подтверждения наличия или отсутствия у лица отдельных авторских правомочий или их совокупности.

П. 1 ст. 17 Закона РФ «О правовой охране программ для ЭВМ и баз данных» определяет нарушителя авторского права как физическое или юридическое лицо, которое не выполняет требований настоящего закона в отношении исключительных прав правообладателей, в том числе ввозит в Российскую Федерацию экземпляры программы для ЭВМ или базы данных, изготовленные без разрешения их правообладателя. Это может выражаться в присвоении авторства, осуществлении перечисленных в ст. 10 Закона РФ «О правовой охране программ для ЭВМ и баз данных» действий без разрешения правообладателя и т. д. Отдельное выделение импорта экземпляров программы для ЭВМ или базы данных, изготовленных без разрешения их правообладателей объясняется тем, что в государстве, где данные экземпляры были изготовлены, это действие может считаться законным и не влекущим ответственности.

Заключение

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

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

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

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

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

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

[Электронный ресурс]//URL: https://liarte.ru/kursovaya/zaschita-kursovoy-rabotyi-po-bazam-dannyih/

Голицына О.Л., Максимов Н.В. и др., «Базы данных» (учебное пособие)

Могилёв А.В., Пак Н.И. и др., «Информатика»

Изюмин В.П. «Пиратство в сфере программного обеспечения» // Финансовые известия от 23 мая 2003 г.

Статья Юрия Шермана // www.tour-soft.com

Статья Сергея Гаврилова // [email protected]

Партыка Т.Л., Попов И.И. «Информационная безопасность», М.: Форум: инфра – м, 2004 г.

Герасименко В.А., Малюк А.А., «Основы защиты информации» М.: МИФИ, 2001 г.