Файл: Ошибка! Закладка не определена.pdf

Скачать файл
Заказать решение

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 08.11.2023

Просмотров: 47

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Оглавление 45. Реализации политики безопасности при эксплуатации БД. Уровни защиты данных. .................. 47 49. Многоуровневая модель безопасности баз данных. Иерархия прав доступа. Метки безопасности..................................................................................... Ошибка! Закладка не определена. 1. Базы данных, системы управления базами данных. Основные понятия и опре 2. деления. База данных – это совокупность связанных данных, организованных по определенным правилам, предусматривающим общие принципы описания, хранения и манипулирования, независимая от прикладных программ. База данных (БД) – это структурированная совокупность взаимосвязанных данных в некоторой предметной области. Отличительные признаки БД: • База данных хранится и обрабатывается в вычислительной системе • Данные в базе данных логически структурированы (систематизированы) • База данных включает метаданные, описывающие логическую структуру БД Важно: • данные о некоторой области (не обо всем) • упорядоченные Система управления базой данных (СУБД) — это программное обеспечение для работы с БД. Функции: • поиск информации в БД • выполнение несложных расчетов • вывод отчетов на печать • редактирование БД 2. Аспекты рассмотрения вопросов информационной безопасности баз данных Вопросы информационной безопасности баз данных целесообразно рассматривать с двух взаимодополняющих позиций: • оценочные стандарты, направленные на классификацию информационных систем и средств их защиты по требованиям безопасности; • технические спецификации, регламентирующие различные аспекты реализации средств защиты. Оценочные стандарты выделяют важнейшие, с точки зрения ИБ, аспекты автоматизированных информационных систем, играя роль архитектурных спецификаций. Технические спецификации построения средств защиты определяют, каким образом строить информационную систему конкретной архитектуры. 3. Уровни информационной системы, на которых должна строиться комплексная система обеспечения информационной безопасности Интеграция программных средств обработки информации и средств ее доставки привела к необходимости создания комплексных программных систем обеспечения безопасности автоматизированных информационных систем. Комплексная система обеспечения информационной безопасности должна строиться с учетом средств и методов, характерных для четырех уровней информационной системы: • уровня прикладного программного обеспечения, отвечающего за взаимодействие с пользователем; • уровня СУБД, обеспечивающего хранение и обработку данных информационной системы; • уровня операционной системы, отвечающего за функционирование СУБД и иного прикладного программного обеспечения; • уровня среды доставки, отвечающего за взаимодействие информационных серверов и потребителей информации. 4. Задачи, решаемые для обеспечения безопасности автоматизированных информационных систем (обеспечение конфиденциальности, целостности, доступности), их характеристика. Проблема обеспечения безопасности автоматизированных информационных систем может быть, определена как решение трех взаимосвязанных задач по реализации требуемого уровня: • конфиденциальности — обеспечения пользователям доступа только к тем данным, для которых пользователь имеет явное или неявное разрешение на доступ (синонимы — секретность, защищенность); • целостности — обеспечения защиты от преднамеренного или непреднамеренного изменения информации или процессов ее обработки; • доступности — обеспечения возможности авторизованным в системе пользователям доступа к информации в соответствии с принятой технологией (синоним — готовность). Методы и средства решения трех отмеченных взаимосвязанных задач характерны для любых АИС. В частности, задача обеспечения конфиденциальностипредусматривает комплекс мер по предотвращению несанкционированного доступа к информации ограниченного пользования. Задача обеспечения целостностипредусматривает комплекс мер по предотвращению умышленного или случайного изменения или уничтожения информации, используемой ИС. Задача обеспечения доступности информации предусматривает систему мер по поддержке всем уполномоченным пользователям доступа к ресурсам системы в соответствии с принятой технологией (например, круглосуточно). Общая характеристика анализа безопасности СУБД Анализ информационной безопасности СУБД должен проводиться по двум направлениям: • безопасность архитектурных решений и их программных реализаций, собственно, в СУБД; • безопасность взаимодействия с внешними по отношению к СУБД программными и аппаратными компонентами. Анализ безопасности архитектурных решений и их программных реализаций в СУБД должен включать исследование следующих проблем: • идентификация и аутентификация субъектов системы, • технологии реализации дискреционной, мандатной и ролевой модели доступа к ресурсам системы, • реализация аудита действий пользователей. 5. Понятие роли, представления, триггеров. Их назначение, характеристика использования. Ролевая модель доступа наиболее широко распространена в мировой практике обеспечения защищенных технологий обработки баз данных. Понятие роли входит в последний стандарт SQL и стандарт Common Criteria для коммерческого профиля безопасности. Большое число пользователей, статус которых требует различных привилегий для доступа к ресурсам базы данных, создает значительный объем рутинной работы администратору. Роль — это поименованный набор привилегий, который может быть предоставлен пользователю или другой роли; по сути, это языковое средство для автоматизации работы администратора по разграничению доступа. Описание привилегий, характерных для той или иной роли, готовится заранее. При регистрации нового пользователя в системе администратор выполняет только предоставление пользователю привилегий конкретной роли. При необходимости изменить привилегии конкретному приложению достаточно изменить только привилегии соответствующей роли. Все пользователи, отображенные на эту роль, автоматически получат измененные привилегии. Широко используемым, простым и эффективным способом реализации разграничения доступа является использование представлений (view). Представление — это поименованная динамически поддерживаемая сервером выборка из одной или нескольких таблиц. Оператор SELECT, определяющий выборку, ограничивает видимые пользователем данные. Кроме того, представление позволяет эффективно ограничить данные, которые пользователь может модифицировать. Сервер гарантирует актуальность представления, то есть формирование представления (материализация соответствующего запроса) производится каждый раз при использовании представления. Используя представления, администратор безопасности ограничивает доступную пользователям часть базы данных только теми данными, которые реально необходимы для выполнения его работы. Триггеры — это совокупности предложений языка SQL, или другого процедурного языка, автоматически запускаемые сервером при регистрации определенных событий в системе. Триггеры выполняются системой автоматически до или после возникновения предопределенных событий, таких, как выполнения операций INSERТ, UPDATE, DELЕТЕ в какой-либо таблице. Обычно рассматривают два способа пользования триггеров для повышения защищенности системы: • дополнительный контроль допустимости действий пользователя; • введение специализированного (нестандартного) аудита действий пользователя. Триггеры позволяют автоматически выполнить необходимую проверку полномочий перед выполнением операций над таблицами. В одной БД можно определить несколько триггеров. Комбинации триггеров, выполняемых до и после операций, позволяют создавать изощренные механизмы проверки допустимости тех или иных действий в базе данных и фиксации (или откате) их результатов. Современные СУБД промышленного уровня поддерживают триггеры, запускаемые для определенных системных событий, в частности: начала и завершения сессии взаимодействия пользователя с системой, запуска и останова экземпляра сервера баз данных, создания и уничтожения объектов и т. п. 6. Этапы научного формирования проблемы обеспечения информационной безопасности баз данных Первый этап был нацелен на то, чтобы обеспечить безопасность данных механизмами, функционирующими по строго формальным алгоритмам. Для создания таких механизмов использовались технические и, в основном, программные средства. Программные средства защиты включались в состав операционных систем и систем управления базами данных. Слабым звеном разработанных механизмов защиты была технология разграничения доступа пользователей к данным. Поэтому следующим шагом к повышению эффективности защиты стала организация дифференцированного доступа к данным. Главным достижением второго этапа стала разработка концепции и реализации специального программного компонента, управляющего программными и, частично, аппаратными средствами защиты данных — ядра безопасности. В составе операционных систем ядро безопасности реализовывалось как функционально самостоятельная подсистема управления механизмами защиты данных, которая включала технические, программные, и лингвистические средства. Этот этап также характеризовался интенсивным развитием технических и криптографических средств защиты. Отличительной особенностью третьего этапа стало применение принципа системности. Принцип системности требует, чтобы обеспечение безопасности данных представляло собой регулярный процесс на всех этапах жизненного цикла АИС при комплексном использовании всех средств и механизмов защиты. При этом все средства и механизмы, используемые для защиты данных, объединяются в систему обеспечения безопасности данных, которая должна обеспечивать многоуровневую защиту данных не только от злоумышленников, но и от обслуживающего персонала АИС, а также случайных ошибок пользователей. Четвертый этап развития характеризуется разработкой и внедрением стандартов в области информационной безопасности. На этом этапе ставится и решается задача управления обеспечением информационной безопасности конкретного объекта, в частности, баз данных. Цель управления - обеспечение требуемого уровня защищенности информационных активов от объективно существующих угроз. Требуемый уровень защищенности определяется как разумный баланс между потенциальным ущербом, связанным с реализациями существующих угроз, и затратами на обеспечение процесса управления 7. Модели баз данных Различают три основные модели базы данных – это иерархическая, сетевая и реляционная. Иерархические базы данных – это самая первая модель представления данных, в которой все записи базы данных представлены в виде дерева, с соотношением предок-потомок. Сетевая модель может быть представлена как развитие и обобщение иерархической модели данных, позволяющее отображать разнообразные взаимосвязи данных в виде произвольного графа. В реляционной базе данных вся информации представляется в виде таблиц, и любые операции над данными – это операции над таблицами. Таблицы строят из строк и столбцов. Строки – это записи, а столбцы представляют собой структуру записи (каждый столбец имеет определенный тип данных и длину данных). Строки в таблице не упорядочены – не существует первой или десятой строки. Однако поскольку на строки необходимо как-то ссылаться, то вводится понятие «первичный ключ». 8. Нормализация таблиц баз данных Для поддержания БД в устойчивом состоянии используется ряд механизмов, которые получили обобщенное название средств поддержки целостности. Приведение структуры БД в соответствие этим ограничениям — это и есть нормализация. Нормализацией отношений базы данных называется процедура, производимая над базой данных с целью удаления в ней избыточности. Выделяются шесть нормальных форм, пять из которых так и называются: первая, вторая, третья, четвертая, пятая нормальная форма, а также нормальная форма Бойса-Кодда, лежащая между третьей и четвертой. База данных считается нормализованной, если ее таблицы представлены как минимум в третьей нормальной форме. 1. Чтобы база данных находилась в 1 нормальной форме, необходимо чтобы ее таблицы соблюдали следующие реляционные принципы: • В таблице не должно быть дублирующих строк • В каждой ячейке таблицы хранится атомарное значение (одно не составное значение) • В столбце хранятся данные одного типа • Отсутствуют массивы и списки в любом виде 2. Таблица (отношение) находится во 2 нормальной форме, если она находится в 1НФ, и при этом все неключевые поля (атрибуты) зависят только от первичного ключа, т.е. 2НФ требует, чтобы неключевые столбцы таблиц зависели от первичного ключа в целом, но не от его части. Если таблица находится в первой нормальной форме и первичный ключ у нее состоит из одного столбца, то она автоматически находится и во второй нормальной форме. 3. Таблица (отношение) находится в третьей нормальной форме (3НФ), если оно находится во второй нормальной форме и каждое неключевое поле (атрибут) зависит только от первичного ключа и не зависят друг от друга. 9. Проектирование связей между таблицами. Правила установления связей. Типы связей. Связи между таблицами, установленные по ключам, позволяют быстро и эффективно выводить нужную информацию из разных таблиц БД. Связь между таблицами устанавливает отношения между совпадающими значениями в ключевых полях разных таблиц, имеющих соответствующие по смыслу (или одинаковые) имена. Основные правила установления связей между таблицами: 1. Необходимо выбрать из двух связываемых таблиц главную и подчиненную. 2. В каждой таблице необходимо выбрать ключевое поле. 3. Связываемые поля таблиц должны иметь один тип данных. Типы связей между таблицами: 1. «1: 1» – любому экземпляру сущности А, соответствует только один экземпляр сущности Б, и наоборот. 2. «1: М» – любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности Б, но любому экземпляру сущности В соответствует только один экземпляр сущности А. 3. «М: М» – любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности Б, и любому экземпляру сущности Б соответствует 0, 1 или несколько экземпляров сущности А. вваыпвапа 10. Понятие первичного и внешнего ключей таблицы. Каскадирование. Ограничение. Установление. Ключом считается поле, значения которого однозначно определяют значения всех остальных полей в таблице. Различают ключи двух типов: первичные и вторичные (внешние). Первичный ключ— это одно или несколько полей (столбцов), комбинация значений которых однозначно определяет каждую запись в таблице. Первичный ключ не допускает значений Null и всегда должен иметь уникальный индекс. Первичный ключ используется для связывания таблицы с внешними ключами в других таблицах. Внешний (вторичный) ключ— это одно или несколько полей (столбцов) в таблице, содержащих ссылку на поле или поля первичного ключа в другой таблице. Внешний ключ определяет способ объединения таблиц. Каскадирование. При изменении данных первичного ключа в главной таблице происходит изменение соответствующих данных внешнего ключа в зависимой таблице. Все имеющиеся связи сохраняются. Ограничение. При попытке изменить значение первичного ключа, с которым связаны строки в зависимой таблице, изменения отвергаются. Допускается изменение лишь тех значений первичного ключа, для которых не установлена связь с зависимой таблицей. Установление. При изменении данных первичного ключа внешний ключ устанавливается в неопределенное значение (NULL). Информация о принадлежности строк зависимой таблице теряется. Если изменить несколько значений первичного ключа, то в зависимой таблице образуется несколько групп строк, которые ранее были связаны с измененными ключами. После этого невозможно определить, какая строка с каким первичным ключом была связана. 11. Проектирование БД, решение проблем информационной безопасности на различных этапах проектирования. Современная практика проектирования информационных систем различного назначения показывает, что для хранения больших и сверхбольших объемов информации обычно выбирается реляционная СУБД. На последующих стадиях проектирования и разработки обеспечение безопасности базы данных (ядра всей системы) обычно сводится к следующему: • выделению классов пользователей, • выявлению их информационных потребностей и привилегий (эти и еще несколько этапов входят в формирование политики безопасности), • проектированию системы разграничения доступа. Далее для назначения либо отмены привилегий используется язык SQL, включающий операторы GRANT, REVOKE и т. п. Большинство современных реляционных СУБД поддерживает дискреционную и мандатную модели разграничения доступа, а также дополнительные средства обеспечения безопасности. (Как-то так) 12. Инфологическое моделирование баз данных Инфологическая модель представляет собой описание структуры и динамики ПО, характера информационных потребностей пользователей системы в терминах, понятных пользователю и независимых от реализации системы. Более того, инфологическая модель ПО не должна зависеть от модели данных, которая будет использована при создании БД.   1   2   3   4   5   6

Цель инфологического моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты). Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д.Связь – ассоциирование двух или более сущностей. Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей. Атрибуты используются для определения того, какая информация должна быть собрана о сущности. 13. СУБД. Языковые средства описания, манипулирования, запросов. Функции и использование. Языковые средства СУБД необходимы для описания данных, организации общения и выполнения процедур поиска и различных преобразований данных. Языковые средства используются для выполнения следующих функций: 1. для описания представления базы данных на управляемых уровнях архитектуры системы; 2. для инициирования выполнения операций манипулирования данными; 3. для управления данными. …………… Язык описания данных (DDL - Data Definition Language), предназначен для описания данных на разных уровнях абстракции: внешнем, логическом и внутреннем. Язык манипулирования данными (DML - Data Manipulation Language) используется для обработки данных, их преобразований и написания программ. DML может быть базовым или автономным. Базовый язык DML — это один из традиционных языков программирования (BASIC, C, FORTRAN и др.). Системы, которые используют базовый язык, называют открытыми. Автономный язык DML — это собственный язык СУБД, который дает возможность выполнять различные операции с данными. Системы с собственным языком называют закрытыми. В современных СУБД для упрощения процедур поиска данных в БД предусмотрен язык запросов. Наиболее распространенными языками запросов являются SQL и QBE. 14. Структурированный язык за просов SQL. Структурированный язык запросов SQL является обычным языком программирования, состоящим из операторов и правил грамматики. Запрос к таблице базы данных на языке SQL представляет | собой инструкцию SELECT, которую можно описать следующим образом: • SELECT [АLL|] (Список полей таблицы или запроса) • FROM (Список таблиц или запросов, на основе которых формируется запрос) • [WHERE (Условия отбора данных)] • [GROUP BY(Список полей, выводимых в результат выполнения запроса)] • [HAVING (Условия для группировки данных в запросе)] • [ORDER BY (Список полей, по которым упорядочивается вывод данных в запросе)] В зависимости от характера выполняемых действий операторы SQL можно разделить на следующие группы: • операторы определения данных; • операторы манипулирования данными; • операторы (язык) запросов; • операторы управления действиями (транзакциями); • операторы администрирования данными; • операторы управления (управления курсором). 15. Архитектура систем управления базами данных. (Бизнес-логика — в разработке информационных систем — совокупность правил, принципов, зависимостей поведения объектов предметной области (области человеческой деятельности, которую система поддерживает). Иначе можно сказать, что бизнес-логика — это реализация правил и ограничений автоматизируемых операций.) При решении задачи обеспечения информационной безопасности баз данных необходимо прежде всего провести анализ архитектуры системы. СУБД является комплексом взаимодействующих программных компонент. Глобально можно выделить 2 архитектуры СУБД: • архитектура «клиент-сервер»; • многозвенная архитектура. При описании архитектур обработки данных используются разнообразные термины, поэтому дадим определения основных понятий. Следующие определения относятся к архитектуре «клиент-сервер». Сервер определим как логический процесс, который обеспечивает обслуживание запросов других процессов. Сервер не посылает результатов запрашивающему процессу до тех пор, пока не придет запрос на обслуживание. После инициирования запроса управление синхронизацией обслуживания и связей становится функцией самого сервера. Здесь сервер используется в смысле логического процесса, а не узла вычислительной сети, выполняющего определенные функции. Далее будем рассматривать серверы баз данных. Сервер баз данных — это логический процесс, отвечающий за обработку запросов к базам данных. Клиент — это процесс, посылающий серверу запрос на обслуживание. В данном контексте мы абстрагируемся от технических средств, на которых реализован процесс клиента. Рассмотрим преимущества и недостатки архитектуры «клиент-сервер». Путем распределения вычислений достигается гибкость и масштабируемость системы: во-первых, каждый компьютер в системе можно выбирать так, чтобы он лучше всего подходил к требованиям каждого компонента. Во-вторых, такая система обладает хорошей адаптируемостью и гибкостью — в силу модульности легко можно заменить переставший удовлетворять требованиям компонент или даже целиком какую-либо составляющую. Например, заменить весь парк устаревших рабочих станций. В-третьих, легко масштабировать систему, добавив в нее новые рабочие станции или нарастив вычислительные мощности на сервере. Но наряду с преимуществами имеются и недостатки. • Частые обращения клиента к серверу снижают производительность работы сети, приходится решать вопросы безопасной многопользовательской работы с данными, так как приложения и данные распределены между различными клиентами. • Распределенный характер построения системы обусловливает сложность ее настройки и сопровождения. Чем сложнее структура системы, построенной по технологии «клиент-сервер», тем выше вероятность отказа любого из ее компонентов. Указанные недостатки архитектуры «клиент-сервер» стимулировали поиск новых архитектур обработки данных, одним из результатов которого стала многозвенная архитектура, свободная от некоторых недостатков своей предшественницы. Многозвенная архитектура, специально предназначенная для работы в среде Интернет/Интранет. Трехзвенная (в некоторых случаях многозвенная) архитектура (N-tier или multi-tier). представляет собой дальнейшее совершенствование технологии «клиент – сервер». Рассмотрев архитектуру «клиент – сервер», можно заключить, что она является 2-звенной: первое звено – клиентское приложение, второе звено – сервер БД + сама БД. В трехзвенной архитектуре вся бизнес-логика (деловая логика), ранее входившая в клиентские приложения, выделяется в отдельное звено, называемое сервером приложений. Сервер приложений — совокупность логических процессов, реализующих бизнес-логику на основании данных, предоставляемых сервером баз данных и передающих результаты вычислений универсальному клиенту через некоторую среду передачи данных. Универсальный клиент — это процесс, посылающий запрос на обслуживание и способный осуществить отображение его результатов на основе некоторого универсального протокола выдачи информации. При этом клиентским приложениям остается лишь пользовательский интерфейс. Так, в качестве клиентского приложения может выступать Web- браузер. Что улучшается при использовании трехзвенной архитектуры? Теперь при изменении бизнес-логики более нет необходимости изменять клиентские приложения и обновлять их у всех пользователей. Кроме того, максимально снижаются требования к аппаратуре пользователей. 16. Архитектура «клиент – сервер». Понятие клиента и сервера. Сервер определим как логический процесс, который обеспечивает обслуживание запросов других процессов. Сервер не посылает результатов запрашивающему процессу до тех пор, пока не придет запрос на обслуживание. После инициирования запроса управление синхронизацией обслуживания и связей становится функцией самого сервера. Здесь сервер используется в смысле логического процесса, а не узла вычислительной сети, выполняющего определенные функции. Далее будем рассматривать серверы баз данных. Сервер баз данных — это логический процесс, отвечающий за обработку запросов к базам данных. Клиент — это процесс, посылающий серверу запрос на обслуживание. В данном контексте мы абстрагируемся от технических средств, на которых реализован процесс клиента. Отличие клиента от сервера в том, что клиент может начать взаимодействие с сервером, а сервер, как правило, никогда не начинает подобных действий. Функцией клиента являются инициирование установления связи, запрос конкретного вида обслуживания, получение от сервера результатов, и подтверждение окончания обслуживания. Хотя клиент может запросить синхронное или асинхронное уведомление об окончании обслуживания, он сам не управляет синхронизацией обслуживания и связи. Основным назначением архитектуры «клиент-сервер» является обеспечение прикладным программам клиента доступа к данным, которыми управляет сервер. Архитектура «клиент-сервер» позволяет нескольким клиентам совместно эффективно использовать один сервер. При использовании этой архитектуры высокая производительность распределенной автоматизированной системы обеспечивается за счет эффективного управления передачей запросов к серверу баз данных и возвратом полученных в результате этих запросов данных клиенту. Клиент взаимодействует с сервером баз данных с помощью языка, ориентированного на работу с базами данных (обычно это язык SQL). После обработки запроса клиента сервер баз данных посылает клиенту обратно только данные, которые удовлетворяют запросу. Лекция 8. 17. Многозвенная архитектура. Понятие сервера баз данных и сервера приложений. Универсальный клиент. Аналогично технологии «клиент-сервер» дадим ряд определений, существенных для описания многозвенной архитектуры. В ее состав входит универсальный клиент — это процесс, посылающий запрос на обслуживание и способный осуществить отображение его результатов на основе некоторого универсального протокола выдачи информации. Отличие универсальных клиентов от обычных — способность предоставления пользователю интерфейса для решения любых задач, низкая стоимость внедрения, администрирования и поддержки. Как правило, это браузер, программа просмотра сценариев на каком-либо языке разметки. Браузер может поддерживать с помощью run-time расширений и другие форматы файлов. Приложения, используемые в качестве таких расширений, хранят все свои файлы на клиенте. Когда браузер встречает вызов такого расширения, он загружает соответствующие исполнимые файлы и запускает приложение. Сервер приложений — совокупность логических процессов, реализующих бизнес-логику на основании данных, предоставляемых сервером баз данных и передающих результаты вычислений универсальному клиенту через некоторую среду передачи данных. Администрирование и обслуживание приложений осуществляются полностью на сервере приложений, а не на стороне клиента, поэтому обновлять программные модули универсального клиента (браузера) приходится довольно редко. Основными экономическими преимуществами многозвенной архитектуры являются: • относительно низкие затраты на внедрение и эксплуатацию; • высокая способность к интеграции существующих информационных ресурсов; • прикладные программные средства доступны с любого клиентского рабочего места; • минимальный состав программно-технических средств на клиентском рабочем месте. Связь между различными элементами в конкретной вычислительной системе может быть реализована разными способами: средствами локальной вычислительной сети или организацией межзадачной связи, например, с использованием совместно используемой памяти или электронной почты. Для поддержания работоспособности и дальнейшего развития необходимо, чтобы система поддерживала прозрачную реконфигурацию так, чтобы изменение способов реализации связи не требовало изменений приложений и дополнительную настройку баз данных. 18. Структура, свойства информационной безопасности баз данных. Структура свойств информационной безопасности баз данных: • конфиденциальность, т.е. обеспечение доступа только к тем данным, к которым пользователь имеет явные и неявные разрешения на доступ; • доступность, т.е. обеспечение возможности авторизированным в системе пользователям доступа к информации (БД) в соответствии с принятой технологией; • целостность. т.е. обеспечение защиты от преднамеренного или непреднамеренного изменения БД или процессов ее обработки. 19. Сущность проблемы обеспечения информационной безопасности систем баз данных. Сущность проблемы обеспечения информационной безопасности систем баз данных состоит в разработке методов и средств, обеспечивающих выполнение трех взаимосвязанных свойств системы: * конфиденциальность: обеспечение пользователям доступа только к тем данным, для которых пользователь имеет явное или неявное разрешение на доступ; * целостность: обеспечение защиты от преднамеренного или непреднамеренного изменения информации или процессов ее обработки; * доступность: обеспечение возможности авторизованным в системе пользователям доступа к информации в соответствии с принятой технологией. Задача обеспечения целостности предусматривает комплекс мер по предотвращению непреднаме1ренного изменения или уничтожения информации, используемой информационной системой управления или системой поддержки принятия решений. Изменение или уничтожение данных может быть следствием неблагоприятного стечения обстоятельств и состояния внешней среды (стихийные бедствия, пожары и т. п.), неадекватных действий пользователей и проблем, возникающих при многопользовательской обработке данных. Задача обеспечения доступности информации предусматривает систему мер по поддержке всем легитимным пользователям доступа к ресурсам системы в соответствии с принятой технологией (например, круглосуточно). Причиной отказа в доступе может быть перегрузка системы, вызванная потоком «информационного шума» (спам, искусственно формируемый поток бессмысленных запросов), перегрузка системы, вызванная объективными причинами, действия, направленные на остановку критически важных процессов (например, компонент сервера баз данных, прослушивающего процесса). Необходимой частью любой защищенной информационной системы является функция регистрации различных событий (действий) в системе — аудит. Лекция 9 20. Угрозы информационной безопасности баз данных. Под угрозой обычно понимают потенциально возможное событие, действие (воздействие), процесс или явление, которое может привести к нанесению ущерба чьим-либо интересам. Угрозой информационной безопасности автоматизированной информационной системе (АИС) называют возможность воздействия на информацию, обрабатываемую в системе, приводящего к искажению, уничтожению, копированию, блокированию доступа к информации, а также возможность воздействия на компоненты информационной системы, приводящего к утрате, уничтожению или сбою функционирования носителя информации или средства управления программно-аппаратным комплексом системы. Угроза нарушения конфиденциальности данных включает в себя любое умышленное или случайное раскрытие информации, хранящейся в вычислительной системе или передаваемой из одной системы в другую. Угроза нарушения целостности — это любое умышленное или случайное изменение информации, обрабатываемой в ИС или вводимой из первичного источника данных. (Как-то так) 21. Источники угроз информации баз данных. Рассмотрим перечень внешних и внутренних угроз информационной безопасности баз данных. Внешними дестабилизирующими факторами, создающими угрозы безопасности функционированию систем баз данных и СУБД, являются: • умышленные, деструктивные действия лиц с целью искажения, уничтожения или хищения программ, данных и документов системы, причиной которых являются нарушения информационной безопасности защищаемого объекта; • искажения в каналах передачи информации, поступающей от внешних источников, циркулирующих в системе и передаваемой потребителям, а также недопустимые значения и изменения характеристик потоков информации из внешней среды и внутри системы; • сбои и отказы в аппаратуре вычислительных средств; • вирусы и иные деструктивные программные элементы, распространяемые с использованием систем телекоммуникаций, обеспечивающих связь с внешней средой или внутренние коммуникации распределенной системы баз данных; • изменения состава и конфигурации комплекса взаимодействующей аппаратуры системы за пределы, проверенные при тестировании или сертификации системы. Внутренними источниками угроз безопасности баз данных и СУБД являются: • системные ошибки при постановке целей и задач проектирования автоматизированных информационных систем их компонент, допущенные при формулировке требований к функциям и характеристикам средств обеспечения безопасности системы; • ошибки при определении условий и параметров функционирования внешней среды, в которой предстоит использовать информационную систему и, в частности, программно-аппаратные средства защиты данных; • ошибки проектирования при разработке и реализации алгоритмов обеспечения безопасности аппаратуры, программных средств и баз данных; • ошибки и несанкционированные действия пользователей, административного и обслуживающего персонала в процессе эксплуатации системы; • недостаточная эффективность используемых методов и средств обеспечения информационной безопасности в штатных или особых условиях эксплуатации системы. 1   2   3   4   5   6

22. Классификация угроз информационной безопасности баз данных. Классификация по цели реализации угрозы: 1. Нарушение конфиденциальности информации, т. е. использование информации, хранящейся в системе, лицами или процессами, которые не были определены владельцами информации. 2. Нарушение целостности информации, т. е. модификация или уничтожение информации для ее обесценивания путем утраты соответствия с состоянием моделируемых сущностей реального мира. 3. Полное или частичное нарушение работоспособности системы за счет вывода из строя или некорректного изменения режимов работы компонентов системы, включая их модификацию или подмену. Классификация по природе возникновения угрозы: 1. Естественные угрозы — угрозы, вызванные воздействием на систему баз данных и ее компоненты объективных физических процессов или стихийно развивающихся природных явлений. 2. Искусственные угрозы — угрозы информационной безопасности систем баз данных, связанных с деятельностью человека. Классификация по локализации источника угрозы представляется следующим образом: 1. Угрозы, источником которых является человек: • — разглашение, передача или утрата атрибутов разграничения доступа (паролей, ключей шифрования, электронных замков и т. п.) легальными пользователями системы; • — подкуп или шантаж обслуживающего персонала или пользователей, имеющих необходимые полномочия, с целью получения их параметров для процедур аутентификации; • — копирование конфиденциальных данных легальным пользователем системы с целью неправомерного использования (продажа, шантаж и т. п.); • — взлом системы защиты с целью выполнения деструктивных действий лицом, не являющимся законным пользователем системы; • — внедрение агентов фирм-конкурентов или преступных организаций в обслуживающий персонал атакуемой информационной системы (в том числе в административную группу, в группу обеспечения информационной безопасности). 2. Угрозы, источником которых являются штатные программно-аппаратные средства информационной системы: • — неквалифицированное использование или ошибочный ввод параметров программ, способных привести к полной или частичной потере работоспособности системы (аварийное завершение си стемных процессов, нецелевое расходование вычислительных ресурсов и т. п.); • — неквалифицированное использование или ошибочный ввод параметров программ, способных привести к необратимым изменениям в системе (инициализация баз данных, форматирование или рест руктуризацию носителей информации, удаление данных и т. п.); • — отказы и сбои в работе операционной системы, СУБД и прикладных программ. 3. Угрозы, источником которых являются не санкционированно используемые программно-аппаратные средства: • — нелегальное внедрение и использование программ, не являющихся необходимыми для выполнения нарушителем своих служебных обязанн остей; • — нелегальное внедрение (из-за халатности легального пользователя) и использование троянских программ, предназначенных для исследования параметров АИС, сбора данных, зомбирования компьютера с последующим нецелевым расходованием ресурсов и т. п.; • — заражение компьютера вирусами с деструктивными функциями; • — работа генераторов шума и подобных источников электромагнитного излучения. 4. Угрозы, непосредственным источником которых является среда обитания: • — внезапное и длительное отключение систем электропитания; • — техногенные и природные катастрофы; • — всплески природных электромагнитных излучений. Классификация по расположению источника угроз 1. Угрозы, источник которых расположен вне контролируемой зоны места расположения автоматизированной информационной системы: • — нарушение нормальной работы или разрушение систем жизнеобеспечения зданий, в которых расположены технические средства и обслу живающий персонал системы; • — блокирование физического доступа на объект размещения автоматизированной системы обслуживающего персонала или пользователей; • — нарушение нормальной работы или разрушение внешних каналов связи (проводные линии, радиоканалы, оптоволокно). 2. Угрозы, источник которых находится в пределах контролируемой зоны расположения АИС, исключая места расположения клиентских терминалов и серверных помещений: • — нарушение нормальной работы или разрушение систем электропитания и водоснабжения помещений, в которых расположены технические средства, обеспечивающие работу АИС; • — физическое разрушение линий связи или аппаратуры, обеспечивающей работу информационной системы; • — считывание конфиденциальной информации из аппаратных средств телекоммуникационной или вычислительной техники с использованием перехвата электромагнитных излучений; • — выведения из рабочего состояния обслуживающего персонала (организация саботажа, применение отравляющих веществ, психотропных средств и т. п.). 3. Угрозы, источник которых имеет доступ к терминальным устройствам автоматизированной информационной системы: • — получение параметров входа в систему и аутентифицирующей информации с использованием видеонаблюдения, клавиатурных закладок и технологий подбора паролей; • — получение параметров входа в систему и аутентифициующей информации с использованием мошеннических приемов, насилия или угрозы насилия; • — получение возможности несанкционированного входа в систему в период, когда легальный пользователь покинул рабочее место, не завершив сеанс взаимодействия с системой; • — получение конфиденциальной информации из распечаток результатов выполнения запросов и иных выводимых системой данных. 4. Угрозы, источник которых имеет доступ к помещениям, где расположены серверы автоматизированной информационной системы: • — физическое разрушение элементов серверов и коммутационной аппаратуры; • — выключение электропитания серверов и коммутационной аппаратуры; • — остановка серверных и иных критически важных для функционирования АИС процессов; • — уничтожение или модификация критически важных для функционирования АИС файлов ОС; • — нарушение штатной работы базовой ОС, например, за счет запуска процессов, активно расходующих ресурсы системы, критически важных для функционирования ОС файлов и т. п.; • — рассылка сообщений, дезорганизующих работу пользователей и обслуживающего персонала системы. Классификация по способу воздействия на методы и средства хранения данных информационной системы 1. Угрозы нарушения информационной безопасности данных, хранимых на внешних запоминающих устройствах: • — нарушение конфиденциальности, уничтожение или модификация данных, сохраненных средствами создания резервных копий на магнитных носителях, путем н езаконного восстановления баз данных с последующей заменой реальной копии или без таковой; • — нарушение конфиденциальности, уничтожение или модификация данных, созданных штатными средствами ведения журнала изменений баз данных; • — дискредитация криптографических систем защиты информации путем создания копии носителей ключевой информации; • — создание несанкционированных копий файлов ОС, содержащих информацию БД для проведения последующего анализа с целью доступа к конфиденциальной информации. 2. Угрозы нарушения информационной безопасности данных, хранимых в оперативной памяти серверов и клиентских компьютеров: • — изменение информации в оперативной памяти, используемой СУБД для кэширования данных, организации хранения промежуточных результатов выполнения запросов , констант и переменных процессов обработки данных; • — изменение информации в оперативной памяти, используемой операционной системой для кэширования данных, организации многопользовательского режима работы, констант и переменных процессов обработки данных; • — изменение информации в оперативной памяти, используемой прикладными программами в процессе организации и выполнения сессии взаимодействия с сервером баз данных и прослушивающим процессом. 3. Угрозы нарушения информационной безопасности данных, отображаемой на терминале пользователя или принтере: • — организация имитации процесса установления взаимодействия с сервером (ложной сессии) с целью получения идентификаторов и аутентифицирующей информации пользователей; • — изменение элементов данных, выводимых на терминал пользователя за счет перехвата потока вывода; • — изменение элементов данных, выводимых на принтер за счет перехвата потока вывода. Классификация по характеру воздействия на информационную систему (целесообразно выделить два варианта): — активное воздействие, т. е. выполнение пользователем системы БД действий, выходящих за рамки его обязанностей, предусматривающих взаимодействие с системой, или действия внешнего по отношению к ИС пользователя или процесса, нацеленные на достижение одной или нескольких перечисленных выше целей; — пассивное воздействие, т. е. наблюдение пользователем значений каких-либо параметров СУБД или системы баз данных, а также различных побочных эффектов и косвенных признаков с целью получения конфиденциальной информации на основе анализа собранных данных. 23. Политика безопасности, ее цели, структура, решаемые задачи по безопасности баз данных, ответственные лица. Политика безопасности— это совокупность норм и правил, определяющих принятые в организации меры по обеспечению безопасности информации, связанной с деятельностью организации. После того как политика безопасности определена, должен решаться вопрос о технологии ее реализации в автоматизированном контуре. Наибольшее распространение в настоящее время получили две базовые модели безопасности данных: дискреционная и мандатная. В описание политики безопасности рекомендуется включать следующие разделы. Предмет политики. В разделе должны быть определены цели и причины разработки политики, область ее применения в конкретном фрагменте системы документооборота организации. Должны быть ясно сформулированы задачи, решаемые с использованием информационных систем, которые затрагивает данная политика. Описание позиции организации. В этом разделе необходимо ясно описать характер информационных ресурсов организации, перечень допущенных к информационным ресурсам лиц и процессов и порядок получения доступа к информационным ресурсам организации. Применимость. В разделе может быть уточнен порядок доступа к данным ИС, определены ограничения или технологические цепочки, применяемые при реализации политики безопасности. Роли и обязанности. В разделе определяются ответственные должностные лица и их обязанности в отношении разработки и внедрения различных элементов политики. Соблюдение политики. В разделе описываются права и обязанности пользователей ИС. Необходимо явное описание и документированное знакомство пользователей с перечнем недопустимых действий при осуществлении доступа к информационным ресурсам организации и наказания за нарушения режимных требований. Должна быть ясно определена технология фиксации фактов нарушения политики безопасности и применения административных мер воздействия к нарушителям. Для эффективной реализации политика безопасности должна быть понятной всем пользователям информационных систем организации. Возможна подготовка презентаций и проведение семинаров с разъяснением основных положений и практических технологий реализации политики безопасности. Новые сотрудники организации должны быть ознакомлены или обучены конкретным правилам и технологиям доступа к ресурсам ИС, реализованным в соответствии с принятой политикой безопасности. Целесообразно проводить контрольные проверки действий сотрудников с обсуждением результатов. 24. Цель формализации политики безопасности. Цель формализации политики безопасности для ИС - ясное изложение взглядов руководства организации на существо угроз ИБ организации и технологий обеспечения безопасности ее информационных ресурсов. Политика безопасности обычно состоит из двух частей: общих принципов и конкретных правил работы с информационными ресурсами и, в частности, с базами данных для различных категорий пользователей. (Как-то так) 25. Комплект документов, предоставляющий основные решения организации по реализации политики безопасности. Комплект документов по реализации политики безопасности, должен включать: • документацию, определяющую подходы к оцениванию и управлению рисками для организации в целом и для конкретных подразделений; • обоснование принятых решений по выбору средств защиты для рассматриваемой ИС; • формальное описание процедуры определения допустимого уровня остаточного риска; • директиву, определяющую порядок проверки режима ИБ и журналов, в которых фиксируются результаты проверки (документы необходимы для осуществления проверки эффективности реализации средств обеспечения информационной безопасности, осуществления их контроля качества и правильности использования); • документацию, регламентирующую процессы обслуживания и администрирования информационных систем; • документацию по подготовке периодических проверок по оцениванию и управлению рисками; • документ «Ведомость соответствия», включающий сведения по организации системы управления информационной безопасностью и регистрации средств управления безопасностью; • контрмеры для противодействия выявленным рискам. 26. Принципы построения защищенных систем баз данных. Анализ наиболее успешных решений в области обеспечения информационной безопасности баз данных позволил сформулировать несколько принципов, которыми можно руководствоваться при проектировании систем защиты: — экономическая оправданность механизмов защиты — рекомендует использовать простейший из всевозможных вариантов проекта, который обеспечивает достижение желаемой цели; — открытое проектирование предполагает, чтотехнология систем защиты не должна базироваться на «секретных» алгоритмах; — распределение полномочиймежду различными субъектами в соответствии с правилами организации для критически важных приложений — следует использовать многокомпонентные схемы доступа к данным. То есть для выполнения соответствующей операции необходимо провести аутентификацию нескольких ее обязательных участников; — минимально возможные привилегии для пользователей и администраторов — предписывает, чтобы каждый пользователь (процесс) системы оперировали с данными, используя минимальный набор привилегий, необходимых для выполнения конкретной функции; — управляемость системы при возникновении отказов и сбоев — проектирование ИС, реализованной на базе СУБД, должно осуществляться в предположении, что ошибки операционной системы и СУБД, а также сбои аппаратуры неизбежны. При проектировании процедур и функций должны быть обработаны все исключительные ситуации, при обработке данных, содержащих конфиденциальную информацию, должны быть минимизированы риски восстановления этих данных по дампам оперативной памяти и содержимому временных файлов и т. п.; — психологическая приемлемость работы средств защиты данных — взаимодействие людей с системой (и подсистемой защиты) не должно быть сложным. Пользователи должны шаблонно и автоматически применять имеющиеся механизмы защиты. 27. Стратегия применения средств обеспечения информационной безопасности баз данных. Стратегия определяет структуру, приоритеты и методы принятия решений при организации и обеспечении соответствующего вида деятельности. Разработка стратегии направлена на то, чтобы наиболее важные цели соответствующей деятельности достигались при наиболее рациональном расходовании имеющихся ресурсов. Можно предложить три стратегии обеспечения информационной безопасности: оборонительная, наступательная и упреждающая. Выбирая оборонительную стратегию, проектировщик должен четко понимать и грамотно объяснить руководству, что если исключить вмешательство в процесс функционирования информационной системы, то можно нейтрализовать лишь наиболее опасные угрозы. Обычно это достигается построением «защитной оболочки», включающей разработку дополнительных организационных мер, создание программных средств допуска к ресурсам информационной системы в целом, использованию технических средств контроля помещений, в которых расположено терминальное и серверное оборудование. Наступательная стратегия предусматривает активное противодействие известным угрозам, влияющим на информационную безопасность системы. Наступательная стратегия может включать установку дополнительных программно-аппаратных средств аутентификации пользователей, внедрение более совершенных технологий разгрузки и восстановления данных, повышение доступности системы с использованием горячего и холодного резервирования. Упреждающая стратегия предполагает тщательное исследование возможных угроз системы обработки информации и разработку мер по их нейтрализации еще на стадии проектирования и изготовления системы. Важной частью упреждающей стратегии является оперативный анализ информации центров изучения проблем информационной безопасности, изучение отечественного и мирового передового опыта, проведение независимого аудита уровня обеспечения безопасности информационных ресурсов организации. 28. Основные средства защиты баз данных. К основным средствам защиты информации можно отнести следующие средства: • парольной защиты; • шифрования данных и программ; • установления прав доступа к объектам БД; • защиты полей и записей таблиц БД. Жлдж 1   2   3   4   5   6

37. Учетные записи пользователей. Общие сведения Учетная запись пользователя MySQL представляет собой запись (строку) в таблице user (Пользователь) системной базы данных mysql. Первичным ключом в этой таблице служат поля Host и User. Таким образом, в MySQL идентификация пользователя основана не только на имени пользователя, но и на комбинации имени пользователя и хоста, с которого пользователь подключается. В качестве хоста может быть любой компьютер или сервер, подключенный к локальной или глобальной сети. Это значит, что можно ограничить круг хостов, с которых разрешено подключаться данному пользователю. Например, можно создать разные учетные записи (а, следовательно, назначить разные привилегии доступа) для пользователя student, подключающегося с компьютера localhost, и для пользователя student, подключающегося с компьютера somedomain.com. При подключении пользователя к серверу MySQL происходит идентификация пользователя, то есть поиск его учетной записи. Этот поиск в таблице user начинается с тех записей, в которых в поле Host не содержится подстановочных символов. Так, например, если в таблице зарегистрированы две учетные записи с идентификаторами, соответственно, 'student'@% и 'student'@'localhost', то при подключении пользователя с именем student с локального компьютера будет выбрана вторая запись. После определения учетной записи выполняется аутентификация (проверка подлинности) пользователя. Суть аутентификации состоит в том, пароль, введенный пользователем, сравнивается с паролем учетной записи, хранящемся в поле Password таблицы user. 38. Создание учетной записи пользователя, установка пароля, просмотр учетных записей и их удаление. Учетная запись пользователя MySQL представляет собой запись (строку) в таблице user (Пользователь) системной базы данных mysql. Первичным ключом в этой таблице служат поля Host и User. Для создания учетной записи пользователя используется команда: CREATE USER <идентификатор пользователя> [IDENTIFIED BY [PASSWORD] '<Пароль>']; Если же вводится не реальный, а зашифрованный пароль, то необходимо указывать параметр PASSWORD. Это позволяет избежать передачи незашифрованного пароля при отправке на сервер команды CREATE USER. Для получения зашифрованного значения из реального пароля можно использовать функцию: PASSWORD('<Реальный пароль>') Установка пароля выполняется следующей командой: SET PASSWORD [FOR <идентификатор пользователя>] = PASSWORD('<Пароль>'); Параметрами этой команды являются идентификатор учетной записи пользователя и новый пароль для этой записи. Если не указать идентификатор пользователя, то ваш пароль будет изменен. Например, при выполнении следующей команды: SET PASSWORD FOR 'student'@'%' =PASSWORD('newstudent'); для пользователя student будет установлен пароль newstudent при подключении с любого компьютера. Для удаления учетной записи пользователя используется команда: DROP USER <идентификатор пользователя>; После удаления учетной записи пользователь больше не может подключаться к серверу MySQL. Однако, если в момент удаления пользователь был подключен к серверу, то соединение не прерывается. Вместе с учетной записью удаляются все привилегии доступа для этой записи. Чтобы получить информацию обо всех зарегистрированных пользователях необходимо выполнить запрос к таблице user (Пользователь) системной базы данных mysql следующим образом: SELECT * FROM mysql.user; Первые три поля Host, User и Password в таблице user нам уже известны. Далее следуют поля глобальных привилегий, которые будут рассмотрены в разделе «Система привилегий доступа», а также поля, в которых содержатся параметры безопасности соединения и сведения о ресурсах, предоставляемых соединению (эти поля нами рассматриваться не будут). 39. Система привилегий доступа. Общие сведения. Под привилегией будем понимать некоторый поддерживаемый системой признак, который определяет право пользователя на выполнение той или иной операции с базой данных. Для создания привилегии доступа в MySQL необходимо определить следующие параметры: • идентификатор учетной записи пользователя, которому предоставляется привилегия; • тип привилегии, то есть тип операций, которые будут разрешены пользователю; • область действия привилегии. MySQL позволяет использовать следующие основные типы привилегий: • ALL [PRIVILEGES] – предоставляет все привилегии, кроме GRANT OPTION, для указанной области действия; • ALTER – разрешает выполнение команд ALTER DATABASE и • ALTER TABLE; • CREATE – разрешает выполнение команд CREATE • DATABASE и CREATE TABLE; • CREATE USER – разрешает выполнение команд CREATE USER, DROP USER, RENAME USER; • DELETE – разрешает выполнение команды DELETE; • DROP – разрешает выполнение команд DROP DATABASE и DROP TABLE; • FILE – разрешает чтение и создание файлов на сервере с помощью команд SELECT…INTO OUTFILE и LOAD DATA INFILE; • INDEX – разрешает выполнение команд CREATE INDEX и DROP INDEX; • INSERT – разрешает выполнение команды INSERT; • SELECT – разрешает выполнение команды SELECT; • LOCK TABLES – разрешает выполнение команды LOCK TABLES при наличии привилегии SELECT для блокируемых таблиц; • SHOW DATABASES – разрешает отображение всех баз данных при выполнении команды SHOW DATABASES (если эта привилегия отсутствует, то в списке будут отображены только те базы данных, по отношению к которым у пользователя есть какая-либо привилегия); • RELOAD – разрешает выполнение команды FLUSH; • SUPER – привилегия администратора сервера; в частности, разрешает выполнение команды SET GLOBAL; • UPDATE – разрешает выполнение команды UPDATE; • GRANT OPTION – разрешает назначать и отменять привилегии другим пользователям (эта возможность распространяется только на те привилегии, которые есть у самого пользователя для указанной области действия). Область действия привилегии может распространяться на все базы данных (такие привилегии называются глобальными), отдельную базу данных, таблицу или поле таблицы. Для каждого типа привилегии имеются свои допустимые области действия. Так, привилегии FILE, SHOW DATABASES, RELOAD, SUPER и CREATE USER могут быть только глобальными. Чтобы получить разрешение на выполнение операции с каким-либо объектом базы данных, пользователю достаточно иметь привилегию соответствующего типа для какой-либо области действия, содержащей этот объект. 40. Предоставление, просмотр и отмена привилегий доступа пользователей. Для предоставления привилегий пользователям используется команда GRANT, имеющая следующий формат: GRANT <Тип привилегии> [(<Список полей>)] ON <Область действия> TO <идентификатор пользователя> [WITH GRANT OPTION]; В качестве области действия можно указать одно из следующих значений: • *.* – привилегия будет действовать глобально; • <Имя базы данных>.* – привилегия будет действовать для указанной базы данных; • * – привилегия будет действовать для базы данных, которая во время выполнения команды GRANT является текущей; • <Имя базы данных>.<Имя таблицы> или <Имя таблицы> – привилегия будет действовать для указанной таблицы (если имя базы данных не указано, подразумевается текущая база данных). Существует ряд особенностей, которые необходимо учитывать при назначении привилегий. Рассмотрим их подробнее. • Если учетная запись с указанным идентификатором не существует, то команда GRANT автоматически создает такую запись. Чтобы отключить автоматическое создание учетной записи нужно в значении переменной sql_mode указать ключевое слово NO_AUTO_CREATE_USER. • Привилегия ALTER должна предоставляться с осторожностью, поскольку пользователь может изменить настройки системы привилегий путем переименования таблиц и столбцов. • Использование параметра WITH GRANT OPTION при создании привилегии дает пользователю возможность «делиться» не только созданной привилегией, но и другими своими привилегиями в рамках данной области действия. Для удаления привилегии, которая была ранее назначена пользователю, используется команда REVOKE, имеющая следующий формат: REVOKE <Тип привилегии> [(<Список столбцов>)] ON <Область действия> FROM <идентификатор пользователя>; Параметры команды REVOKE по своему смыслу аналогичны параметрам команды GRANT. Аналогичны и правила вступления изменений в силу. Отметим, что в MySQL при удалении баз данных, таблиц и полей связанные с ними привилегии не удаляются автоматически, а для удаления таких привилегий требуется выполнить команду REVOKE. Чтобы узнать, к каким объектам имеет доступ конкретный пользователь, служит команда: SHOW GRANTS [FOR идентификатор пользователя>]; Команда SHOW GRANTS выводит сведения о привилегиях пользователя в виде набора команд GRANT, с помощью которых можно сформировать текущий набор привилегий пользователя. Если идентификатор пользователя не задан, то можно увидеть свои привилегии. Чтобы получить информацию о пользователях, обладающих привилегиями доступа к тому или иному объекту базы данных можно использовать таблицы user, db, tables_priv и columns_priv. • Глобальные привилегии хранятся в таблице user. Каждому типу привилегии соответствует отдельное поле (столбец), допускающее значения 'Y' (операция разрешена) и 'N' (операция не разрешена). • Привилегии, областью действия которых является отдельная база данных, хранятся в таблице db (база данных). Первичный ключ в этой таблице образуют поля Host (хост), Db (база данных) и User (пользователь). Таким образом, каждая строка таблицы определяет привилегии одного пользователя по отношению к одной базе данных. Как и в таблице user, каждой привилегии соответствует отдельное поле (столбец), в котором допустимыми являются значения 'Y' и 'N'. • Привилегии, относящиеся к отдельным таблицам, хранятся в таблице tables_priv. Первичным ключом в этой таблице служат поля Host (Хост), Db (База данных), User (Пользователь) и Table_name (Имя таблицы). Таким образом, каждая строка таблицы tables_priv определяет привилегии доступа конкретного пользователя к конкретной таблице. • Привилегии для отдельных полей хранятся в таблице columns_priv. Первичный ключ этой таблицы состоит из полей, идентифицирующих пользователя (Host и User), и полей, идентифицирующих поле (Db, Table_name и Column_name). Типы привилегий, которыми обладает пользователь по отношению к полю, содержатся в поле Column_priv (Привилегии доступа к полю) с типом данных SET. 41. Резервирование баз данных. Полное резервное копирование базы данных. Ведение двоичных журналов. Обычно рекомендуется использовать стратегию резервного копирования, сочетающую в себе два взаимодополняющих метода: • полное резервное копирование базы данных, выполняемое с определенной периодичностью; • ведение двоичных журналов, в которых регистрируются все изменения данных в промежутках между резервными копированиями. Двоичные журналы. В файле двоичного журнала накапливается история изменений в базе данных за определенный период времени, что обеспечивает возможность воспроизвести эти изменения при необходимости. Чтобы включить ведение двоичных журналов, следует запустить сервер MySQL с параметром –log-bin. Во время работы сервера в папке data корневой папки MySQL будут создаваться двоичные журналы. Они представляют собой файлы с именами вида <Имя xocтa>-bin.xxxxxx, где xxxxxx – порядковый номер журнала. Очередной файл журнала создается в следующих случаях: • когда предыдущий файл достиг своего предельного размера; • когда происходит запуск или перезапуск сервера; • когда происходит принудительный «сброс» журналов. «Сброс» журналов при полном резервном копировании необходим для того, чтобы изменения в базе данных, происходящие с момента резервирования, отражались в новом файле (при этом старые файлы журналов становятся ненужными). Кроме того, принудительный «сброс» осуществляется перед промежуточным резервным копированием: сервер начнет протоколировать изменения в новом файле, а предыдущие файлы нужно скопировать на резервный носитель. Полное резервное копирование баз данных выполняется с помощью утилиты mysqldump. Для запуска этой утилиты следует открыть окно командной строки Windows и выполнить команду: mysqldump –u <Имя пользователя> -p [Опциональные параметры] <Копируемые базы данных и таблицы> > <Путь и имя результирующего файла> В ответ на запрос Enter password (Введите пароль) нужно ввести пароль пользователя. После того, как файл с резервной копией базы данных будет создан, его следует перенести на резервный носитель информации, который должен быть надежно защищен от несанкционированного доступа. При создании резервной копии впервые, рекомендуется проверить ее корректность, выполнив тестовое восстановление данных. 42. Восстановление данных в СУБД MY SQL. Восстановление утраченных данных в случае сбоя согласно стратегии резервного копирования проводится в два этапа: • в первую очередь необходимо восстановить базу данных из резервной копии; • затем требуется восстановить изменения данных, которые произошли с момента создания резервной копии, из двоичных журналов. Перед началом восстановления данных должен быть запущен сервер MySQL. Если при сбое были повреждены таблицы, управляющие доступом пользователей, при запуске сервера необходимо указать параметр – skip- grant-tables. Для восстановления базы данных из файла, содержащего полную резервную копию, нужно открыть окно командной строки Windows и выполнить команду mysql –u root –p [<Имя базы данных>] < <Путь и имя файла> После появления приглашения Enter password (Введите пароль) нужно ввести пароль пользователя root. Обратим внимание на следующий факт. Поскольку файл с резервной копией содержит данные в виде SQL-команд, то с его помощью можно восстанавливать отдельные таблицы по своему выбору, просто копируя SQL- команды CREATE TABLE и INSERT в какое-либо клиентское приложение и отправляя их на сервер. Следующим шагом является восстановление изменений из двоичных журналов, которое выполняется с помощью команды: mysqlbinlog <Список журналов> | mysql –u root -p В качестве первого журнала указывается тот журнал, ведение которого началось в момент запуска полного резервного копирования. Определить этот журнал можно по дате создания. Далее перечисляют имена всех журналов вплоть до последнего, созданного перед сбоем. 43. Профилактическая проверка таблиц и их восстановление в СУБД MY SQL. После сбоев в работе сервера, а также при появлении подозрительных сообщений об ошибках необходимо проверить таблицу на наличие повреждений. CHECK TABLE <Список таблиц>; Команда CHECK TABLE отображает результат проверки таблиц. Например, чтобы получить информацию о состоянии таблиц db и user системной базы данных mysql, нжно выполнить следующую команду: CHECK TABLE mysql.db, mysql.user; Если в столбце Msg_text (Текст сообщения) присутствует значение, отличное от OK или Table is already up to date (Таблица уже проверена), то это означает, что таблица повреждена. Для восстановления таблицы необходимо выполнить следующие действия. 1) Выполнить команду: REPAIR TABLE <Имя таблицы> QUICK; После выполнения команды REPAIR TABLE будет получена таблица с теми же столбцами, что в результате выполнения команды CHECK TABLE. Таблица может включать несколько строк, причем, если в последней строке в столбце Msg_text (Текст сообщения) указано значение OK, то это значит, что таблица успешно восстановлена. В противном случае нужно выполнить следующий пункт. 2) Скопировать файл <Имя таблицы>.MYD из папки <Корневая папка MySQL>\ data\<Имя базы данных> в любую резервную папку, т.к. при попытке восстановления данные, содержащиеся в этом файле, могут быть повреждены. 3) Выполнить команду: REPAIR TABLE <Имя таблицы>; Если же и эта команда не помогла восстановить таблицу, необходимо выполнить команду: REPAIR TABLE <Имя таблицы> EXTENDED; Если опять не получилось исправить повреждения, следует выполнить команду: REPAIR TABLE <Имя таблицы> USE_FRM; Параметр USE_FRM должен использоваться только в том случае, если все предыдущие действия не дали ожидаемого результата. Если таблица все же не была восстановлена, нужно перейти к следующему пункту. 4) Открыть файл с полной резервной копией базы данных (созданный в подразделе «Полное резервирование»). Найти в нем SQL-команду CREATE TABLE для той таблицы, которую нужно восстановить. С помощью этой команды нужно создать точно такую же таблицу в другой базе данных. Затем следует переместить файлы <Имя таблицы>.MYI и <Имя таблицы>.frm из папки <Корневая папка MySQL>\data\<Имя другой базы данных> в папку <Корневая папка MySQL>\data\<Имя исходной базы данных>. Далее нужно повторить действия, описанные в п. 3. 5) Если все попытки исправления таблицы оказались неудачными, можно воссоздать таблицу из резервной копии с использованием двоичных журналов. 44. Журналы работы (журнал ошибок, двоичные журналы, общий журнал запросов, журнал медленных запросов) и их просмотр в СУБД MY SQL. По умолчанию журналы работы сервера MySQL хранятся в папке data корневой папки MySQL. Их несколько видов. Журнал ошибок – это файл с именем <Имя хоста>.err. Содержит сведения об ошибках в работе сервера, а также о запусках и остановках сервера. Просмотреть этот файл можно в любом текстовом редакторе. 1   2   3   4   5   6


Процедуры вызываются оператором CALL и могут использовать как входные параметры (передающие значения в процедуру), так и выходные параметры (возвращающие результаты процедуры вызывающему программному объекту). Процедуры могут вызываться из процедур, функций и других типов программных объектов. Хранимые процедуры, создаются оператором CREATE PROCEDURE. Модификация тела хранимой процедуры осуществляется оператором АLTER PROCEDURE.
Эти операторы могут использовать:
• пользователи, которым разрешено создавать объекты базы данных, т.е. тем, кто имеет класс полномочий - RESOURCE;
• администратор базы данных.
Любая хранимая процедура всегда выполняется с привилегиями ее владельца. Это позволяет пользователям, не имеющим прямого доступа к таблицам данных, возможность обращения к этим таблицам через процедуры, которые они имеют право использовать. Для каждой таблицы хранимые процедуры представляет собой унифицированный механизм взаимодействия с ней. Это лишает пользователей сделать что-нибудь лишнее с таблицами данных и способствует поддержанию целостности данных.
Триггер — это специальный вид хранимой процедуры, которую СУБД вызывает при выполнении операций модификации соответствующих таблиц.
Триггер автоматически активизируется при выполнении операции, с которой он связан. Триггеры связываются с одной или несколькими операциями модификации над одной таблицей, Например, триггер может выполняться при вставке, изменении или удалении строки в существующей таблице.
Триггер сообщает СУБД, как нужно выполнять команды SQL INSERT, UPDATE,
DELETE чтобы выполнялись бизнес правила организации.
33. Администрирование баз данных. Функции администратора.
Администрация базы данных в основном состоит в обеспечении того, чтобы точная и непротиворечивая информация была доступна пользователям в нужное время и в нужной форме.
Администратор базы данных должен хорошо знать структуру БД, состав и все характеристики системы, так как сбои и нарушения в системе могут возникнуть в самых различных местах.

Функции администратора базы данных главным образом лежат в области работы с пользователями базы данных, планировании, проектировании и реализации информационных систем. Эффективная работа включает в себя разработку общих стандартов и процедур, целью которых является эффективный контроль целостности и защиты данных.
Администратор БД отвечает за следующие аспекты:
• проектирование структуры БД, методы упорядочивания файлов
БД, методы доступа к файлам БД;
• задание ограничений целостности при описании структуры БД и обработки БД;
• первоначальную загрузку и ведение БД;
• защиту данных;
• обеспечение восстановления БД;
• сбор статистики по характеру запросов;
• анализ эффективности работы БД;
• работу с конечными пользователями;
• подготовку и поддержку ПО;
• организационно-методическую работу по проектированию БД.
Администратор базы данных назначается в момент инсталляции системы и наделяется рядом особых привилегий: располагает всеми полномочиями по всем объектам базы данных и для всех команд.
При решении вопросов защиты данных в обязанности администратора базы данных входит следующее:
• классификация данных в соответствии с их использованием;
• определение прав доступа отдельных пользователей к определенным группам данных в базе и ограничений на характер операций, выполняемых пользователем с этими данными;
• организация системы контроля доступа к данным;
• тестирование всех вновь создаваемых средств защиты данных;
• периодическое проведение проверок правильности функционирования системы защиты данных;
• исследование возникающих случаев нарушения защиты данных и проведение политики их предотвращения;
• исследование современных достижений в области технологии защиты данных и их использование для совершенствования соответствующих средств функционирующей БД и т. п.

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

3) Изолированности - транзакции, конкурирующие за доступ к БД, выполняются изолированно друг от друга, но для пользователя это может выглядеть так, что они выполняются одновременно.
4) Долговечности. Если транзакция успешно завершена, то изменения данных, которые были произведены, не могут быть потеряны ни при каких обстоятельствах.
Транзакции необходимы для устранения конфликтов пользователей, пытающихся одновременно обращаться к одним и тем же данным.
35. Использование транзакций для восстановления после сбоев
или отказов системы. Причины отказов.
Потеря изменений происходит в ситуации, когда две или несколько программ читают одни и те же данные, вносят в них какие-либо изменения и затем пытаются одновременно записать результат на прежнее место.
Разумеется, в базе данных могут быть сохранены изменения, выполненные только одной программой - другие изменения будут потеряны.
Транзакции используются для восстановления данных после сбоя или отказа системы. Источниками отказов могут быть:
1) Системные ошибки. Системные ошибки возникают тогда, когда система вошла в нежелательной состояние, например, такое, как взаимоблокировка, не позволяющая нормально продолжить выполнение программы. Такой отказ может приводить, а может и не приводить к повреждению файлов данных. Принцип блокировки заключается в том, что когда пользователь выбирает данные из БД, СУБД автоматически запрещает к ним доступ, чтобы какой-либо пользователь не мог провести над ними операции обновления. Существует много видов блокировок. В основном операции блокирования и разблокирования производятся автоматически, но в некоторых системах пользователи могут управлять определенными аспектами блокировок, например с помощью команд SQL они могут выбрать уровень применения блокировки (уровень строки или уровень таблицы).
2) Отказы оборудования. Два наиболее часто встречающихся отказа: ошибка диска (авария головки), потеря способности передачи данных через сеть.
3) Логические ошибки. Плохие данные или их отсутствие часто является причиной, не позволяющей нормально продолжить выполнение программы.

В стандарте ANSI/ISO SQL включены операторы фиксации транзакции и отката транзакции СОММIТ, ROLLBACK.
• СОММIТ означает успешное завершение транзакции, все изменения принимаются.
• ROLLBACK - прерывание транзакции, отмена выполненных действий сделанных в БД в рамках этой транзакции
Если какую-то транзакцию необходимо отменить до того, как она будет выполнена - либо по причине какого-то сбоя, либо просто потому, что пользователю что-то не понравилось, - результаты выполнения всех ее операторов, которые успели завершиться, должны быть отменены.
Транзакцию можно отменить (или вернуть в исходное положение) с помощью команды транзакции ROLLBACK в любой момент до выполнения команды транзакции СОММIТ.
Для сохранения промежуточных состояний, подтверждения или отката транзакции, используется специальный механизм, называемый журналом
транзакций. Журнал транзакций создается на этапе создания базы данных и обеспечивает надежное хранение данных, возможность восстановления согласованного состояния БД после любого рода сбоев.
В журнале транзакций фиксируются все изменения БД. После сбоя восстанавливается всегда последнее согласованное состояние базы.
Восстановление базы происходит в следующих случаях:
1. Индивидуальный откат транзакций (применение ROLLBACK, аварийное завершение работы программы, взаимоблокировка, при параллельном выполнении транзакций).
2. Восстановление после потери содержимого оперативной памяти (мягкий сбой) (аварийное выключение питания, неустранимый сбой процессора).
3. Поломка ВЗУ (жесткий сбой).
В журнале транзакций, каждая транзакция имеет свой номер. Все изменения помечаются номером транзакции и значениями изменяемых атрибутов, там же сохраняются команды начала и конца транзакции.
36. Идентификация и аутентификация пользователей баз
данных (установление подлинности)

На самом элементарном уровне концепции обеспечения безопасности баз данных и управления информацией исключительно просты. Необходимо поддерживать два фундаментальных принципа: проверку полномочий
(санкционирование) и проверку подлинности (аутентификация).
Идентификация - присвоение объекту уникального имени или числа.
Проверка полномочий (авторизация пользователя) основана на том, что для каждого пользователя или процесса информационной системы устанавливается набор санкционированных действий, которые он может выполнять по отношению к определенным объектам.
Аутентификация или проверка подлинности означает достоверное подтверждение того, что пользователь или процесс, пытающийся выполнить санкционированные действия, действительно является тем, за кого он себя выдает. Указанные проверки используются совместно для принятия решения о доступе.
При подключении пользователя к серверу MySQL происходит
идентификация пользователя, то есть поиск его учетной записи. Этот поиск в таблице user начинается с тех записей, в которых в поле Host не содержится подстановочных символов. Так, например, если в таблице зарегистрированы две учетные записи с идентификаторами, соответственно, 'student'@% и 'student'@'localhost', то при подключении пользователя с именем student с локального компьютера будет выбрана вторая запись.
После определения учетной записи выполняется аутентификация
(проверка подлинности) пользователя. Суть аутентификации состоит в том, пароль, введенный пользователем, сравнивается с паролем учетной записи, хранящемся в поле Password таблицы user.
Подлинность обычно устанавливается один раз, но в установках, обеспечивающих высокую степень безопасности, может потребоваться периодическая перепроверка или перепроверка в определенных условиях.
Повторное установление подлинности желательно, например, после системных сбоев. Процедуры идентификации, аутентификации и авторизации являются обязательными для любой защищенной ИС.
Можно выделить три типа принципов, лежащих в основе конкретных процедур аутентификации:
— аутентификация, основанная на знании (пользователь обладает некоторым конфиденциальным знанием);

— аутентификация, основанная на наличии (пользователь обладает некоторым конфиденциальным предметом);
— аутентификация, основанная на проверке характеристик
(пользователь предъявляет некоторые уникальные характеристики).
1   2   3   4   5   6

37. Учетные записи пользователей. Общие сведения
Учетная запись пользователя MySQL представляет собой запись
(строку) в таблице user (Пользователь) системной базы данных mysql.
Первичным ключом в этой таблице служат поля Host и User. Таким образом, в MySQL идентификация пользователя основана не только на имени пользователя, но и на комбинации имени пользователя и хоста, с которого пользователь подключается.
В качестве хоста может быть любой компьютер или сервер, подключенный к локальной или глобальной сети. Это значит, что можно ограничить круг хостов, с которых разрешено подключаться данному пользователю. Например, можно создать разные учетные записи (а, следовательно, назначить разные привилегии доступа) для пользователя student, подключающегося с компьютера localhost, и для пользователя student, подключающегося с компьютера somedomain.com.
При подключении пользователя к серверу MySQL происходит идентификация пользователя, то есть поиск его учетной записи. Этот поиск в таблице user начинается с тех записей, в которых в поле Host не содержится подстановочных символов. Так, например, если в таблице зарегистрированы две учетные записи с идентификаторами, соответственно, 'student'@% и 'student'@'localhost', то при подключении пользователя с именем student с локального компьютера будет выбрана вторая запись.
После определения учетной записи выполняется аутентификация
(проверка подлинности) пользователя. Суть аутентификации состоит в том, пароль, введенный пользователем, сравнивается с паролем учетной записи, хранящемся в поле Password таблицы user.
38. Создание учетной записи пользователя, установка пароля,
просмотр учетных записей и их удаление.

Учетная запись пользователя MySQL представляет собой запись
(строку) в таблице user (Пользователь) системной базы данных mysql.
Первичным ключом в этой таблице служат поля Host и User.
Для создания учетной записи пользователя используется команда:
CREATE USER <идентификатор пользователя>
[IDENTIFIED BY [PASSWORD] '<Пароль>'];
Если же вводится не реальный, а зашифрованный пароль, то необходимо указывать параметр PASSWORD. Это позволяет избежать передачи незашифрованного пароля при отправке на сервер команды
CREATE USER. Для получения зашифрованного значения из реального пароля можно использовать функцию: PASSWORD('<Реальный пароль>')
Установка пароля выполняется следующей командой:
SET PASSWORD [FOR <идентификатор пользователя>] =
PASSWORD('<Пароль>');
Параметрами этой команды являются идентификатор учетной записи пользователя и новый пароль для этой записи. Если не указать идентификатор пользователя, то ваш пароль будет изменен.
Например, при выполнении следующей команды: SET PASSWORD FOR
'student'@'%' =PASSWORD('newstudent'); для пользователя student будет установлен пароль newstudent при подключении с любого компьютера.
Для удаления учетной записи пользователя используется команда:
DROP USER <идентификатор пользователя>;
После удаления учетной записи пользователь больше не может подключаться к серверу MySQL. Однако, если в момент удаления пользователь был подключен к серверу, то соединение не прерывается.
Вместе с учетной записью удаляются все привилегии доступа для этой записи.
Чтобы получить информацию обо всех зарегистрированных пользователях необходимо выполнить запрос к таблице user (Пользователь) системной базы данных mysql следующим образом:
SELECT * FROM mysql.user;
Первые три поля Host, User и Password в таблице user нам уже известны.

Далее следуют поля глобальных привилегий, которые будут рассмотрены в разделе «Система привилегий доступа», а также поля, в которых содержатся параметры безопасности соединения и сведения о ресурсах, предоставляемых соединению (эти поля нами рассматриваться не будут).
39. Система привилегий доступа. Общие сведения.
Под привилегией будем понимать некоторый поддерживаемый системой признак, который определяет право пользователя на выполнение той или иной операции с базой данных.
Для создания привилегии доступа в MySQL необходимо определить следующие параметры:
• идентификатор учетной записи пользователя, которому предоставляется привилегия;
• тип привилегии, то есть тип операций, которые будут разрешены пользователю;
• область действия привилегии.
MySQL позволяет использовать следующие основные типы привилегий:
•
ALL [PRIVILEGES] – предоставляет все привилегии, кроме GRANT OPTION, для указанной области действия;
•
ALTER – разрешает выполнение команд ALTER DATABASE и
•
ALTER TABLE;
•
CREATE – разрешает выполнение команд CREATE
•
DATABASE и CREATE TABLE;
•
CREATE USER – разрешает выполнение команд CREATE
USER, DROP USER, RENAME USER;
•
DELETE – разрешает выполнение команды DELETE;
•
DROP – разрешает выполнение команд DROP DATABASE и DROP TABLE;
•
FILE – разрешает чтение и создание файлов на сервере с помощью команд SELECT…INTO OUTFILE и LOAD DATA INFILE;
•
INDEX – разрешает выполнение команд CREATE INDEX и DROP INDEX;
•
INSERT – разрешает выполнение команды INSERT;
•
SELECT – разрешает выполнение команды SELECT;

•
LOCK TABLES – разрешает выполнение команды LOCK TABLES при наличии привилегии SELECT для блокируемых таблиц;
•
SHOW DATABASES – разрешает отображение всех баз данных при выполнении команды SHOW DATABASES (если эта привилегия отсутствует, то в списке будут отображены только те базы данных, по отношению к которым у пользователя есть какая-либо привилегия);
•
RELOAD – разрешает выполнение команды FLUSH;
•
SUPER – привилегия администратора сервера; в частности, разрешает выполнение команды SET GLOBAL;
•
UPDATE – разрешает выполнение команды UPDATE;
•
GRANT OPTION – разрешает назначать и отменять привилегии другим пользователям (эта возможность распространяется только на те привилегии, которые есть у самого пользователя для указанной области действия).
Область действия привилегии может распространяться на все базы данных (такие привилегии называются глобальными), отдельную базу данных, таблицу или поле таблицы.
Для каждого типа привилегии имеются свои допустимые области действия. Так, привилегии FILE, SHOW DATABASES, RELOAD, SUPER и CREATE
USER могут быть только глобальными.
Чтобы получить разрешение на выполнение операции с каким-либо объектом базы данных, пользователю достаточно иметь привилегию соответствующего типа для какой-либо области действия, содержащей этот объект.
40. Предоставление, просмотр и отмена привилегий доступа
пользователей.
Для предоставления привилегий пользователям используется команда GRANT, имеющая следующий формат:
GRANT <Тип привилегии>
[(<Список полей>)] ON <Область действия>
TO <идентификатор пользователя>
[WITH GRANT OPTION];

В качестве области действия можно указать одно из следующих значений:
• *.* – привилегия будет действовать глобально;
• <Имя базы данных>.* – привилегия будет действовать для указанной базы данных;
• * – привилегия будет действовать для базы данных, которая во время выполнения команды GRANT является текущей;
• <Имя базы данных>.<Имя таблицы> или <Имя таблицы> – привилегия будет действовать для указанной таблицы (если имя базы данных не указано, подразумевается текущая база данных).
Существует ряд особенностей, которые необходимо учитывать при назначении привилегий. Рассмотрим их подробнее.
• Если учетная запись с указанным идентификатором не существует, то команда GRANT автоматически создает такую запись. Чтобы отключить автоматическое создание учетной записи нужно в значении переменной sql_mode указать ключевое слово NO_AUTO_CREATE_USER.
• Привилегия ALTER должна предоставляться с осторожностью, поскольку пользователь может изменить настройки системы привилегий путем переименования таблиц и столбцов.
• Использование параметра WITH GRANT OPTION при создании привилегии дает пользователю возможность «делиться» не только созданной привилегией, но и другими своими привилегиями в рамках данной области действия.
Для удаления привилегии, которая была ранее назначена пользователю, используется команда REVOKE, имеющая следующий формат:
REVOKE <Тип привилегии>
[(<Список столбцов>)] ON <Область действия>
FROM <идентификатор пользователя>;
Параметры команды REVOKE по своему смыслу аналогичны параметрам команды GRANT. Аналогичны и правила вступления изменений в силу.
Отметим, что в MySQL при удалении баз данных, таблиц и полей связанные с ними привилегии не удаляются автоматически, а для удаления таких привилегий требуется выполнить команду REVOKE.

Чтобы узнать, к каким объектам имеет доступ конкретный
пользователь, служит команда:
SHOW GRANTS [FOR идентификатор пользователя>];
Команда SHOW GRANTS выводит сведения о привилегиях пользователя в виде набора команд GRANT, с помощью которых можно сформировать текущий набор привилегий пользователя. Если идентификатор пользователя не задан, то можно увидеть свои привилегии.

Чтобы получить информацию о пользователях, обладающих привилегиями доступа к тому или иному объекту базы данных можно использовать таблицы user, db, tables_priv и columns_priv.
• Глобальные привилегии хранятся в таблице user. Каждому типу привилегии соответствует отдельное поле (столбец), допускающее значения 'Y' (операция разрешена) и 'N' (операция не разрешена).
• Привилегии, областью действия которых является отдельная база
данных, хранятся в таблице db (база данных). Первичный ключ в этой таблице образуют поля Host (хост), Db (база данных) и User
(пользователь). Таким образом, каждая строка таблицы определяет привилегии одного пользователя по отношению к одной базе данных.
Как и в таблице user, каждой привилегии соответствует отдельное поле
(столбец), в котором допустимыми являются значения 'Y' и 'N'.
• Привилегии, относящиеся к отдельным таблицам, хранятся в таблице tables_priv. Первичным ключом в этой таблице служат поля Host (Хост),
Db (База данных), User (Пользователь) и Table_name (Имя таблицы).
Таким образом, каждая строка таблицы tables_priv определяет привилегии доступа конкретного пользователя к конкретной таблице.
• Привилегии для отдельных полей хранятся в таблице columns_priv.
Первичный ключ этой таблицы состоит из полей, идентифицирующих пользователя (Host и User), и полей, идентифицирующих поле (Db,
Table_name и Column_name). Типы привилегий, которыми обладает пользователь по отношению к полю, содержатся в поле Column_priv
(Привилегии доступа к полю) с типом данных SET.
41. Резервирование баз данных. Полное резервное копирование
базы данных. Ведение двоичных журналов.

Обычно рекомендуется использовать стратегию резервного копирования, сочетающую в себе два взаимодополняющих метода:
• полное резервное копирование базы данных, выполняемое с определенной периодичностью;
• ведение двоичных журналов, в которых регистрируются все изменения данных в промежутках между резервными копированиями.
Двоичные журналы. В файле двоичного журнала накапливается история изменений в базе данных за определенный период времени, что обеспечивает возможность воспроизвести эти изменения при необходимости.
Чтобы включить ведение двоичных журналов, следует запустить сервер MySQL с параметром –log-bin.
Во время работы сервера в папке data корневой папки MySQL будут создаваться двоичные журналы. Они представляют собой файлы с именами вида <Имя xocтa>-bin.xxxxxx, где xxxxxx – порядковый номер журнала.
Очередной файл журнала создается в следующих случаях:
• когда предыдущий файл достиг своего предельного размера;
• когда происходит запуск или перезапуск сервера;
• когда происходит принудительный «сброс» журналов.
«Сброс» журналов при полном резервном копировании необходим для того, чтобы изменения в базе данных, происходящие с момента резервирования, отражались в новом файле (при этом старые файлы журналов становятся ненужными). Кроме того, принудительный «сброс» осуществляется перед промежуточным резервным копированием: сервер начнет протоколировать изменения в новом файле, а предыдущие файлы нужно скопировать на резервный носитель.
Полное резервное копирование баз данных выполняется с помощью утилиты mysqldump. Для запуска этой утилиты следует открыть окно командной строки Windows и выполнить команду: mysqldump –u <Имя пользователя> -p [Опциональные параметры]
<Копируемые базы данных и таблицы> > <Путь и имя результирующего файла>
В ответ на запрос Enter password (Введите пароль) нужно ввести пароль пользователя.

После того, как файл с резервной копией базы данных будет создан, его следует перенести на резервный носитель информации, который должен быть надежно защищен от несанкционированного доступа. При создании резервной копии впервые, рекомендуется проверить ее корректность, выполнив тестовое восстановление данных.
42. Восстановление данных в СУБД MY SQL.
Восстановление утраченных данных в случае сбоя согласно стратегии резервного копирования проводится в два этапа:
• в первую очередь необходимо восстановить базу данных из резервной копии;
• затем требуется восстановить изменения данных, которые произошли с момента создания резервной копии, из двоичных журналов.
Перед началом восстановления данных должен быть запущен сервер
MySQL. Если при сбое были повреждены таблицы, управляющие доступом пользователей, при запуске сервера необходимо указать параметр – skip- grant-tables.
Для восстановления базы данных из файла, содержащего полную резервную копию, нужно открыть окно командной строки Windows и выполнить команду mysql –u root –p [<Имя базы данных>] < <Путь и имя файла>
После появления приглашения Enter password (Введите пароль) нужно ввести пароль пользователя root.
Обратим внимание на следующий факт. Поскольку файл с резервной копией содержит данные в виде SQL-команд, то с его помощью можно восстанавливать отдельные таблицы по своему выбору, просто копируя SQL- команды CREATE TABLE и INSERT в какое-либо клиентское приложение и отправляя их на сервер.
Следующим шагом является восстановление изменений из двоичных журналов, которое выполняется с помощью команды: mysqlbinlog <Список журналов> | mysql –u root -p
В качестве первого журнала указывается тот журнал, ведение которого началось в момент запуска полного резервного копирования. Определить
этот журнал можно по дате создания. Далее перечисляют имена всех журналов вплоть до последнего, созданного перед сбоем.
43. Профилактическая проверка таблиц и их восстановление в
СУБД MY SQL.
После сбоев в работе сервера, а также при появлении подозрительных сообщений об ошибках необходимо проверить таблицу на наличие повреждений.
CHECK TABLE <Список таблиц>;
Команда CHECK TABLE отображает результат проверки таблиц.
Например, чтобы получить информацию о состоянии таблиц db и user системной базы данных mysql, нжно выполнить следующую команду: CHECK
TABLE mysql.db, mysql.user;
Если в столбце Msg_text (Текст сообщения) присутствует значение, отличное от OK или Table is already up to date (Таблица уже проверена), то это означает, что таблица повреждена.
Для восстановления таблицы необходимо выполнить следующие действия.
1) Выполнить команду:
REPAIR TABLE <Имя таблицы> QUICK;
После выполнения команды REPAIR TABLE будет получена таблица с теми же столбцами, что в результате выполнения команды CHECK TABLE.
Таблица может включать несколько строк, причем, если в последней строке в столбце Msg_text (Текст сообщения) указано значение OK, то это значит, что таблица успешно восстановлена. В противном случае нужно выполнить следующий пункт.
2) Скопировать файл <Имя таблицы>.MYD из папки <Корневая папка
MySQL>\ data\<Имя базы данных> в любую резервную папку, т.к. при попытке восстановления данные, содержащиеся в этом файле, могут быть повреждены.
3) Выполнить команду:
REPAIR TABLE <Имя таблицы>;

Если же и эта команда не помогла восстановить таблицу, необходимо выполнить команду:
REPAIR TABLE <Имя таблицы> EXTENDED;
Если опять не получилось исправить повреждения, следует выполнить команду:
REPAIR TABLE <Имя таблицы> USE_FRM;
Параметр USE_FRM должен использоваться только в том случае, если все предыдущие действия не дали ожидаемого результата.
Если таблица все же не была восстановлена, нужно перейти к следующему пункту.
4) Открыть файл с полной резервной копией базы данных (созданный в подразделе «Полное резервирование»). Найти в нем SQL-команду CREATE
TABLE для той таблицы, которую нужно восстановить.
С помощью этой команды нужно создать точно такую же таблицу в другой базе данных. Затем следует переместить файлы <Имя таблицы>.MYI и
<Имя таблицы>.frm из папки <Корневая папка MySQL>\data\<Имя другой базы данных> в папку <Корневая папка MySQL>\data\<Имя исходной базы данных>. Далее нужно повторить действия, описанные в п. 3.
5) Если все попытки исправления таблицы оказались неудачными, можно воссоздать таблицу из резервной копии с использованием двоичных журналов.
44. Журналы работы (журнал ошибок, двоичные журналы,
общий журнал запросов, журнал медленных запросов) и их
просмотр в СУБД MY SQL.
По умолчанию журналы работы сервера MySQL хранятся в папке data корневой папки MySQL. Их несколько видов.
Журнал ошибок – это файл с именем <Имя хоста>.err. Содержит сведения об ошибках в работе сервера, а также о запусках и остановках сервера. Просмотреть этот файл можно в любом текстовом редакторе.
1   2   3   4   5   6

Смотрите также файлы