Главная страница
Навигация по странице:

  • Кафедра информационных технологий и социально-гуманитарных дисциплин Курсовая Работа по дисциплине « Хранилища данных » Тема

  • Пользователей СУБД можно разделить на три категории

  • Идентификация и проверка подлинности пользователей

  • MAINAIN_LOCATION

  • GRANT привилегии ON объект TO пользователи; Оператор REVOKE имеет следующий формат: REVOKE привилегии

  • SELECT

  • Получение информации о привилегиях

  • Шифрование Шифрование

  • MEDIUM

  • Копирование и Восстановление

  • Резервное копирование на примере MS SQL SERVER В MS SQL SERVER для ускорения и "облегчения жизни" существует три метода создания резервных копий:1. SIMPLE

  • Пример защиты таблицы с помощью триггера

  • Курсовая работа Хранилища данных. Курсовая работа, Хранилища данных, ЗКМ-701 Василюк А.А. Курсовая Работа по дисциплине Хранилища данных Тема Безопасность баз данных


    Скачать 130.5 Kb.
    НазваниеКурсовая Работа по дисциплине Хранилища данных Тема Безопасность баз данных
    АнкорКурсовая работа Хранилища данных
    Дата02.03.2021
    Размер130.5 Kb.
    Формат файлаdoc
    Имя файлаКурсовая работа, Хранилища данных, ЗКМ-701 Василюк А.А.doc
    ТипКурсовая
    #181189

    Подборка по базе: практическая работа по трудовому праву.docx, Контрольная работа 10 вариант Климов мат. моделирование.docx, курсовая работа.docx, Практическая работа физкультура верхняя прямая передача.docx, Курсовая работа.docx, Курсовая работа.docx, Курсовая работа по СКСС.docx, Курсовая работа.Журналистика..docx, курсавая работа БЕктуров 3 вариант.docx, Курсовая работа1.pdf

    МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ

    РОССИЙСКОЙ ФЕДЕРАЦИИ

    Минский филиал

    федерального государственного бюджетного образовательного учреждения высшего образования

    «Российский экономический университет имени Г.В. Плеханова» еспублика Беларусь)







    Кафедра информационных технологий и
    социально-гуманитарных дисциплин

    Курсовая Работа
    по дисциплине « Хранилища данных»
    Тема: Безопасность баз данных

    Студент Василюк А.А. ЗКМ-701 ___________ ________

    (Ф.И.О., № группы, номер зачетной книжки) (подпись) (дата)
    Руководитель Луневич А.В. ___________ ________

    (Ф.И.О.) (подпись) (дата)
    Зарегистрировано

    на кафедре ______________ ___________ ________

    (Ф.И.О.) (подпись) (дата)

    Минск 2021

    Оглавление


    Введение 2

    1. Типы опасностей 3

    2. Основные критерии пользователей 4

    3. Типы защиты данных 4

    Идентификация и проверка подлинности пользователей 4

    Виды привилегий 5

    Привилегии безопасности 5

    Привилегии доступа 6

    Получение информации о привилегиях 8

    Представления 9

    Иерархия прав доступа 9

    Шифрование 10

    Ограничения 12

    Правила 12

    Копирование и Восстановление 13

    Резервное копирование на примере MS SQL SERVER 14

    Триггеры 15

    Заключение: 16

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


    Введение



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

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

    1. Типы опасностей



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

    2. Основные критерии пользователей



    Пользователей СУБД можно разделить на три категории:
    1. Администратор сервера баз данных. Он отвечает за установку, настройку сервера, регистрацию пользователей, групп, ролей и т. Д. Администратор сервера имеет имя INGRES. Прямо или косвенно он обладает всеми привилегиями, которые есть или могут быть у других пользователей.
    2. Администраторы баз данных. К этой категории относится любой пользователь, создавший базу данных и, следовательно, являющийся ее владельцем. Он может предоставить другим пользователям доступ к базе данных и содержащимся в ней объектам. Администратор базы данных отвечает за сохранение и восстановление базы данных. В принципе, в организации может быть много администраторов баз данных. Чтобы пользователь мог создать базу данных и стать ее администратором, он должен получить (вероятно, от администратора сервера) привилегию CREATDB.
    3. Другие (конечные) пользователи. Они работают с данными, хранящимися в базах данных, в пределах предоставленных им привилегий.
    Стоит отметить, что администратор сервера баз данных, как самый привилегированный пользователь, нуждается в особой защите. Компрометация пароля, по сути, это компрометация сервера и всех баз данных, которые на нем хранятся.

    3. Типы защиты данных


    Идентификация и проверка подлинности пользователей
    Предоставление пользователям доступа к компьютерной системе обычно является обязанностью системного администратора, который отвечает за создание учетных записей пользователей. Каждому пользователю присваивается уникальный идентификатор, связанный с определенным паролем, выбранным пользователем и известным операционной системе. При регистрации пользователь должен предоставить системе пароль для аутентификации. Аутентификация-это механизм определения того, является ли пользователь тем, за кого он себя выдает.
    Как правило, СУБД использует либо соответствующие механизмы операционной системы, либо инструкцию CONNECT SQL для идентификации и аутентификации пользователей.
    Администратор базы данных обычно отвечает за предоставление прав доступа к СУБД. Его задачей было создание идентификаторов пользователей в среде СУБД. Соответственно, каждый идентификатор должен быть связан с индивидуальным паролем, который должен быть известен только этому пользователю.
    Например, в СУБД ORACLE оператор CONNECT выглядит следующим образом:
    CONNECT к пользователю [/Пароль] [@база_данных];
    Использование паролей является наиболее распространенным методом аутентификации пользователей. Однако этот метод не дает абсолютной гарантии.
    Виды привилегий
    Привилегии в системе баз данных можно разделить на две категории: привилегии безопасности и привилегии доступа. Привилегии безопасности позволяют выполнять административные действия. Привилегии доступа, согласно названию, определяют права доступа субъектов к определенным объектам.
    Привилегии безопасности
    Привилегии безопасности всегда назначаются конкретному пользователю (а не группе, роли или всем) во время его создания (оператором CREATE USER) или изменения характеристик (оператором ALTER USER). Таких привилегий пять: SECURITY – право управлять безопасностью СУБД и контролировать действия пользователя. Пользователь с этой привилегией может подключаться к любой базе данных, создавать, удалять и изменять характеристики пользователей, групп и ролей, передавать права доступа к базе данных другим пользователям, управлять записью регистрационной информации, отслеживать запросы от других пользователей и, наконец, выполнять команды INGRES от имени других пользователей. Эта привилегия требуется администратору сервера баз данных, а также лицу, лично ответственному за информационную безопасность. Передача этой привилегии другим пользователям (например, администраторам баз данных) увеличивает число потенциальных уязвимостей безопасности на сервере баз данных.

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

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

    MAINAIN_LOCATION – право управления местоположением базы данных администратора сервера баз данных и операционной системы.

    TRACE – право изменять состояние флагов трассировки отладки. Эта привилегия полезна администратору сервера баз данных и другим знающим пользователям при анализе сложных, непонятных ситуаций.
    Привилегии доступа
    Права доступа назначаются пользователям, группам, ролям или всем пользователям с помощью инструкции GRANT и отменяются с помощью инструкции REVOKE. В самом общем виде заявка на GRANT имеет следующий формат:
    GRANT привилегии ON объект TO пользователи;

    Оператор REVOKE имеет следующий формат:

    REVOKE привилегии ON объект FROM пользователи;
    Эти привилегии обычно назначаются владельцем соответствующих объектов (также известным как администратор базы данных). Группы и роли создаются с помощью операторов CREATE GROUP и CREATE ROLE. Чтобы изменить состав группы, используйте оператор ALTER GROUP. Оператор DROP GROUP позволяет удалять группы, но только после того, как список членов группы будет опустошен. Альтер роли заявление используется для смены ролей пароли, и падение роли заявление используется для удаления ролей.
    Права доступа могут быть разделены в зависимости от типов объектов, к которым они относятся. В СУБД INGRES существует пять таких типов:


    • таблицы и виды

    • процедуры

    • базы данных

    • сервер баз данных

    • события


    Назначьте права доступа с помощью инструкции GRANT. Что касается таблиц и представлений, то вы можете управлять следующими правами доступа:
    SELECT - право выбора данных
    INSERT-право добавления данных
    DELETE-право на удаление данных
    UPDATE-право на обновление данных (можно указать определенные столбцы, которые разрешено обновлять)
    REFERENCES-право использовать внешние ключи, которые ссылаются на эту таблицу (можно указать конкретные столбцы)
    По умолчанию пользователь не имеет никаких прав доступа к таблицам и представлениям – они должны передаваться с помощью операторов GRANT.
    В отношении процедуры вы можете предоставить право на ее выполнение. При этом вам не нужно беспокоиться о выделении прав доступа к объектам, обрабатываемым процедурой, – они не требуются. Права доступа к базе данных в целом могут быть предоставлены ее администратором или пользователем с привилегиями SECURITY. Эти "права" фактически устанавливают ряд ограничений на использование базы данных, то есть, по сути, являются запретительными. Это означает ограничение на количество операций ввода-вывода или количество строк, возвращаемых одним запросом, а также ограничение на право создания таблиц и процедур. По умолчанию пользователь не ограничен количественными ограничениями и получает право создавать объекты в базе данных.
    Стоит отметить, что при создании базы данных указывается ее статус – общий или личный. Это влияет на подразумеваемое право доступа к базе данных. По умолчанию каждый имеет право подключиться к общей базе данных. Право на подключение к персональной базе данных должно быть явно передано. Право подключения необходимо для выполнения всех других операций с базой данных и содержащимися в ней объектами.
    Привилегии (которые в данном случае точнее было бы назвать ограничениями) QUERY_IO_LIMIT и QUERY_ROW_LIMIT проверяются на основе оценок, выданных оптимизатором запросов. Если оптимизатор предсказывает, что запрос превысит выделенный лимит на количество возвращаемых операций ввода-вывода или строк, запрос отклоняется. Введение таких количественных ограничений предотвращает монополизацию сервера одним клиентом и может быть использовано в качестве одного из инструментов поддержания высокой доступности.
    Получение информации о привилегиях
    Важно не только давать и отнимать привилегии, но и иметь информацию о том, какими правами доступа обладает каждый из субъектов. Такие данные можно получить с помощью функции dbmsinfo, а также путем анализа содержимого таблиц в базе данных iidbdb.
    Функция dbmsinfo возвращает права доступа к базе данных, связанные с текущим подключением. Вы можете узнать имена активных групп и ролей, значение количественных ограничений и наличие прав на создание таблиц и процедур.
    Таблицы iiusergroup, second role и iidbprivileges базы данных iidbdb содержат соответственно список групп и их состав, список ролей вместе с зашифрованными паролями и информацию о привилегиях доступа к базе данных. Итак, таблица iiusergroup состоит из трех столбцов:


    • groupid - название группы,

    • groupmem - имя члена группы,

    • reserve -резервная колонка.


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


    • операционные ограничения (связанные с выбором SELECT, INSERT, UPDATE, DELETE, применимых ко всем или только к некоторым столбцам таблицы);

    • ограничения на значения (из-за механизма представления);

    • ограниченные ресурсы (из-за привилегий доступа к базе данных).


    При обработке запроса СУБД сначала проверяет права доступа к объектам. В случае нарушения эксплуатационных ограничений запрос отклоняется и выдается соответствующий диагноз. После учета двух предыдущих ограничений запрос отправляется оптимизатору для обработки. Если он обнаружит, что лимиты ресурсов превышены, запрос будет отклонен и будет выдана соответствующая диагностика.
    Вы можете взглянуть на иерархию привилегий с другой точки зрения. Каждый пользователь, помимо своих собственных, имеет ПУБЛИЧНЫЕ привилегии. Кроме того, он может быть членом различных групп и запускать приложения с определенными ролями. Иерархия авторизации для СУБД INGRES выглядит следующим образом:


    • роль (высший приоритет)

    • пользователь

    • группа

    • PUBLIC (самый низкий приоритет)


    Для каждого объекта, к которому осуществляется доступ, INGRES пытается найти привилегию в иерархии, относящуюся к запрашиваемому типу доступа. Например, при попытке доступа к таблице с целью обновления INGRES проверяет привилегии роли, пользователя, группы и всех пользователей. Если хотя бы один уровень иерархии имеет привилегию UPDATE, запрос передается для дальнейшей обработки. В противном случае используется подразумеваемое право доступа, которое предписывает вам отклонить запрос.
    Шифрование
    Шифрование – это кодирование данных с помощью специального алгоритма, в результате которого данные становятся недоступными для чтения любой программой, не имеющей ключа дешифрования.
    Для организации безопасной передачи данных по незащищенным сетям необходимо использовать схемы шифрования, включающие следующие компоненты:
    1. ключ шифрования, используемый для шифрования исходных данных (обычный текст);
    2. алгоритм шифрования, который описывает, как использовать ключ шифрования для преобразования обычного текста в зашифрованный.;
    3. ключ расшифровки, используемый для расшифровки зашифрованного текста;
    4. алгоритм расшифровки, который описывает, как использовать ключ шифрования для преобразования зашифрованного текста в исходный обычный текст.
    Существуют симметричные и несимметричные системы шифрования. Симметричные системы-это системы, которые используют один и тот же ключ как для шифрования, так и для дешифрования, и предполагается, что существуют защищенные линии связи, предназначенные для обмена ключами. Асимметричный тип систем предполагает использование различных ключей для шифрования и дешифрования сообщений.
    С помощью параметра SET SECURITY TO можно задать четыре режима шифрования данных в базе данных, которые определяют степень защиты информации. Это следующие режимы:
    NONE – в базе данных нет шифрования, режим шифрования отключен.

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

    MEDIUM – обеспечивает более высокую безопасность (64-битный ключ) и мало влияет на производительность СУБД.

    HIGH – самый высокий уровень защиты и обеспечивает не очень сильное влияние на производительность СУБД (128-битный ключ.)
    Во время работы базы данных возможно переключение с одного уровня шифрования на другой, вплоть до полного отключения этого режима (НЕТ). Эти операции выполняются в административном режиме. Если безопасность включена, журналы и транзакции шифруются с помощью метода носителя.
    Ограничения
    Ограничения могут быть применены к таблицам или отдельным столбцам. Ограничения на столбцы устанавливаются при создании таблицы в операторах CREATE TABLE.
    Ограничения таблицы относятся к группе столбцов и могут быть заданы либо при создании таблицы, либо позже с помощью инструкции ALTER TABLE.
    Все виды ограничений накладываются владельцем таблицы и влияют на результат последующих операций с данными. Существующие ограничения проверяются перед завершением выполнения инструкции SQL. При обнаружении нарушений СУБД сигнализирует об аварийном завершении работы и отменяет внесенные оператором изменения. Чтобы наложить ссылочное ограничение, необходимо иметь привилегию REFERENCES для ссылочной таблицы.
    Ограничения могут быть не только введены, но и отменены. В то же время между ограничениями могут существовать зависимости, и удаление одного из них может потребовать удаления других ограничений, которые зависят от исходного.
    СУБД INGRES пытается согласовать контроль ограничений и оперативную эффективность. При массовом копировании данных контроль ограничений отключается. Это означает, что вам необходимо дополнить копию, выполнив процедуру глобальной проверки целостности.
    Правила
    Правила позволяют запускать выполнение определенных действий при возникновении определенных изменений в базе данных. Обычно действие-это вызов процедуры. Правила связаны с таблицами и запускаются при изменении этих таблиц.
    В отличие от ограничений, которые являются лишь средством управления относительно простыми условиями, правила позволяют проверять и поддерживать сколь угодно сложные отношения между элементами данных в базе данных.
    Проверка правил отключена для операций массового копирования. Администратор базы данных также может отменить проверку правил с помощью оператора


    • SET NORULES;

    Оператор

    • SET RULES;

    Позволяет затем восстановить работу механизма правил. Этот механизм включен по умолчанию.

    Чтобы удалить правила, используйте оператор

    • DROP RULE правило;


    СУБД обеспечивает автоматическое удаление правил при удалении соответствующей таблицы. Это поддерживает целостность таблицы и системы правил.
    В контексте информационной безопасности важно отметить, что владелец этой таблицы, который имеет право выполнить соответствующую процедуру, может создать правило, связанное с таблицей. Пользователь, действия которого запускают правило, должен иметь только необходимые права доступа к таблице. Таким образом, правила неявно расширяют права пользователей. Такое расширение требует строгого административного контроля, поскольку даже незначительное изменение правил или связанных с ними процедур может резко повлиять на безопасность данных. Ошибка в сложной системе правил обычно чревата непредсказуемыми последствиями.
    Копирование и Восстановление
    Процедуры копирования и восстановления должны быть тщательно продуманы и проработаны. Процедуры, регулирующие создание резервных копий, определяются типом и размером эксплуатируемой базы данных, а также набором соответствующих инструментов, предоставляемых используемой СУБД. В зависимости от частоты внесения изменений в систему в течение одного дня может быть сделано несколько копий. Процедуры копирования также могут указывать, какие другие части системы, кроме самих данных, должны быть скопированы. Место хранения последних копий должно быть хорошо защищено.
    Что касается восстановительных процедур, то какие восстановительные процедуры будут выполняться, должно определяться типом отказа. Важно также, чтобы процедуры восстановления учитывали особенности методов восстановления, принятых в используемой СУБД. Вы должны регулярно проверять процессы восстановления, чтобы иметь полную уверенность в том, что они работают правильно.
    Резервное копирование на примере MS SQL SERVER
    В MS SQL SERVER для ускорения и "облегчения жизни" существует три метода создания резервных копий:
    1. SIMPLE – самая простая модель. При его использовании после каждой резервной копии освобождается дисковое пространство, которое будет занимать журнал транзакций. Это означает, что размер файла журнала не будет расти бесконечно. При использовании этой модели наилучшая производительность будет при массовой загрузке данных в базу данных. С другой стороны, нет никакого способа восстановить изменения, сделанные с момента последней резервной копии. В случае неудачи мы просто восстанавливаем последнюю копию, и изменения, внесенные после этого, безвозвратно теряются.
    2. FULL – Полное резервное копирование. Самая мощная модель, в которой можно создавать промежуточные копии, например, резервные копии журналов транзакций.

    Сила модели заключается в том, что база данных может быть восстановлена в любой момент. Например, если данные были уничтожены в какой-то момент времени, то мы восстанавливаем данные только до момента за 5 минут до трагического события, и все данные возвращаются.
    Самым важным недостатком является то, что каждая операция подкрепляется в деталях. При массовой загрузке каждая операция записи регистрируется, а скорость сервера оставляет желать лучшего.
    3. BULK-LOGGED-это упрощенная версия полной резервной копии. В этой модели при выполнении массовых операций в журнале хранится минимально необходимая информация, а точнее, только сам факт выполнения этой операции. Поэтому в этой модели массовые изменения происходят быстрее. Однако если такая операция будет выполнена, то восстановить данные в течение определенного времени уже будет невозможно.
    Частота резервного копирования зависит от объема данных, частоты их обновления и важности. Если данные меняются часто, но не так сильно, то даже полная копия возможна каждый час, потому что небольшой объем данных копируется быстро.
    Триггеры
    Не менее интересным способом обеспечения безопасности являются триггеры – коды, аналогичные процедурам, хранящимся на сервере. Такой код нельзя вызвать напрямую: он выполняется в ответ на определенные события (вставка, изменение и удаление строк). Внутри триггера можно проверить правильность выполняемых действий. Если хакер пытается повредить данные, вы можете увидеть эти действия в триггере.
    Пример защиты таблицы с помощью триггера:
    Для защищенной таблицы мы создаем поле SECURITY. В этом поле должен храниться код, который вычисляется способом, известным только определенному пользователю. Например, путем вычисления контрольной суммы всех полей. Если пользователь изменил значения строки с помощью программы, она автоматически пересчитывает контрольную сумму. Если строка будет изменена на прямую линию, поле SECURITY будет иметь неправильное значение, которое легко обнаружить в триггере и предотвратить вредоносные изменения. Точно так же можно защитить таблицы не только от изменений, но и от вставок и удалений.

    Заключение:


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

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



    1. Bobrowski S. – «Руководство по концепциям сервера. Oracle 7.2», Перевод: Compek Systems, Москва, 1994.
    2. Delaney K. - “Inside Microsoft SQL Server 2000”, Microsoft Press., 2000.
    3. DuBois P. - “MySQL. Second Edition”, Sams, 2003.
    4. Manola F.A. - “A Personal View on DBMS Security”, Elsevier science Publishers B.V. (North Holland), p. 23-34., 1988.
    5. Suehring S. – “MySQL Bible”, Wiley Publishing, Inc., 2002.
    6. Waymire R., Thomas B. – “Безопасность Microsoft SQL Server 2000”,
    7. Аткинсон Л. - «Библиотека профессионала MySQL», М.: Вильямс, 2002.
    8. Вьюкова Н.И., Галатенко В.А. – «Информационная безопасность систем управления базами данных», Системы Управления Базами Данных №1 стр. 29-54, 1996.
    9. Гарсиа-Молина Гектор, Джеффри Д.Ульман, Дженнифер Уидом - «Системы баз данных. Полный Курс», М.: Вильямс, 2003.
    10. Горев А.., Макашарипов С., Владимиров Ю. – «Microsoft SQL Server 6.5», С.-Пб.: Питер, 1998.
    11. Елманова Н., Федоров А. – «Oracle и Microsoft SQL Server: прошлое, настоящее и будущее», журнал «КомпьютерПресс», 2001.
    12. Кайт Т. – «Детальный контроль доступа и контексты приложения», (http://www.interface.ru/oracle/kontrol_1.htm) – материал взят с сайта Студворк https://studwork.org/shop/11197-informacionnaya-bezopasnost-baz-dannyh



    написать администратору сайта