DECLARE @tomorrow char (8)

SELECT @tomorrow = CONVERT (char (8), DATEADD (dd, 1, GETDATE ()), 1)

DUMP DATABASE pubs

TO DISK = '\\ntalexeysh\disk_d\sql_experiments\pubs. dmp'

WITH INIT, EXPIREDATE=@tomorrow, STATS

Для небольшой базы данных ее журнал транзакций обычно хранится на том же устройстве, что и сама база, и архивируется вместе с ней. Журналирование транзакций ведется по принципу write-ahead, что означает, что любое изменение сначала отражается в журнале транзакций и лишь потом попадает собственно в базу. В случае нахождения журнала транзакций на отдельном устройстве существует возможность отдельного резервного копирования журнала транзакций. Как правило, резервное копирование базы данных организуется с меньшей частотой, чем журнала транзакций. Например, сохранение журнала транзакций выполняется ежедневно, а страховая копия всей базы может делаться раз в неделю, так как архивирование журнала транзакций происходит значительно быстрее по времени и занимает меньше места, чем дамп целой базы. В отличие от резервирования базы данных дамп журнала транзакций очищает его неактивную часть, т.е. все завершившиеся (зафиксированные или абортированные) с момента последнего дампа транзакции, если только не использована опция NO_TRUNCATE. Команда DUMP TRANSACTION TRUNCATE_ONLY, очищающая журнал транзакций, полезна в случае его переполнения, которое можно контролировать, например, оператором DBCC SQLPERF (LOGSPACE). Если степень переполнения журнала очень высока, можно при его очистке отказаться от журналирования факта самого этого события: DUMP TRANSACTION NO_LOG. Если резервное копирование транзакций не представляет интереса, можно включить опцию очистки последних завершенных транзакций в базе по наступлению события checkpoint. Cмысл механизма checkpoint состоит в периодической записи данных из кэша на диск, чтобы не допускать грязных данных. Такого рода события постоянно генерируются MS SQL Server или возникают по инициативе пользователя. Включенная опция truncate log on checkpoint гарантирует выполнение с определенной частотой обработчиком события действий, приблизительно эквивалентных команде DUMP TRANSACTION TRUNCATE_ONLY.

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

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

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

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

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

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

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

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

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

операционная система;

SQL Server;

база данных;

объект базы данных.

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

системный администратор, имеющий неограниченный доступ;

владелец БД, имеющий полный доступ ко всем объектам БД;

владелец объектов БД;

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

Модель безопасности SQL Server включает следующие компоненты:

тип подключения к SQL Server;

пользователь базы данных;

пользователь (guest);

роли (roles).

Тип подключения к SQL Server

При подключении (и в зависимости от типа подключения) SQL Server поддерживает два режима безопасности:

режим аутентификации Windows NT;

смешанный режим аутентификации.

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

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

Пользователи базы данных

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

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

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

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

GRANT. Позволяет выполнять действия с объектом или, для команды - выполнять ее;

REVOKE. Аннулирует права доступа для объекта или, для команды - не позволяет выполнить ее;

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

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

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

CREATE DATABASE - право создения базы данных;

CREATE DEFAULT - право создшия стандартного значения для столбца таблицы;

CREATE PROCEDURE - право содания хранимой процедуры.

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

CREATE TABLE - право создания таблицы;

CREATE VIEW - право создания представления;

BACKUP DATABASE - право создшия резервной копии;

BACKUP TRANSACTION - праве создания резервной копии журнала транзакций.

Роли

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

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

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

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

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

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

Sysadmin - дает право выполнить любое действие в SQL Server;

Serveradmin - дает право изменить параметры SQL Server и завершить его работу;

Setupadmin - дает право инсталлировать систему репликации и управлять выполнением расширенных хранимых процедур;

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

Processadmin - дает право управлять ходом выполнения процессов в SQL Server;

Dbcreator - дает право создавать и модифицировать базы данных;

Diskadmin - дает право управлять файлами баз данных на диске.

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

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

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

заранее определенные роли;

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

неявные роли.

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

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

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

db_accessadmin - осуществляет контроль за доступом к базе данных путем добавления или удаления пользователей в режимах аутентификации;

db_datareader - определяет полный доступ к выборке данных (с помощью оператора SELECT) из любой таблицы базы данных. Запрещает выполнение операторов INSERT, DELETE и UPDATE для любой таблицы БД;

db_datawriter - разрешает выполнять операторы INSERT, DELETE и UPDATE для любой таблицы базы данных. Запрещает выполнение оператора SELECT для любой таблицы базы данных;

db_ddladmin - дает возможность создавать, модифицировать и удалять объекты базы данных;

db_securityadmin - управляет системой безопасности базы данных, а также назначением объектных и командных разрешений и ролей для базы данных;

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

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

db_denydatawriter - отказ в разрешении на выполнение операторов модификации данных (INSERT, DELETE и UPDATE) для любых таблиц базы данных;

public - автоматически назначаемая роль сразу после предоставления права доступа пользователя к БД.

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

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

стандартная роль;

роль уровня приложения.

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

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

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

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

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

необходимо рассматривать лишь те цели, вероятность достижения которых р>р0 за время t<t0, где/? 0 и t0 - пороги осуществимости цели.

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

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

2.3 Организация защиты Oracle

Ограничение доступа

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

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

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

Таблица PAYROLL

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

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

CREATE VIEW vjpayroll AS SELECT id

, name, dept

, payment_period FROM payroll WHERE dept = (SELECT dept

FROM mysys_users WHERE username = USER) WITH CHECK OPTION;

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

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

Примечание

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

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

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

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

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

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

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

PROCEDURE del (p_emp_id INTEGER);

PROCEDURE ins (p_emp_id INTEGER, p_name VARCHAR2

,p_dept INTEGER, p_payment_period VARCHAR2

,p_salary INTEGER);

PROCEDURE upd (p_emp__id INTEGER, p_name VARCHAR2

,p_payment_penod VARCHAR2,p_salary INTEGER);

END k_payroll;

/

CREATE OR REPLACE PACKAGE BODY k_payroll AS

mgr_flag payroll. mgr_flag%TYPE;

CURSOR c_me IS

SELECT dept,

mgr_flag

FROM mysys_users

WHERE username = USER;

FUNCTION checkdept (p_emp_id INTEGER) RETURN BOOLEAN IS

dept payroll. dept%TYPE;

CURSOR cjpayroll IS

SELECT pay. dept

FROM payroll pay

WHERE id = p_emp_id;

BEGIN

OPEN c_payroll;

FETCH cjpayroll INTO dept;

CLOSE c_payroll;

IF dept <> my_dept THEN

RETURN FALSE;

END IF;

RETURN TRUE;

END checkdept;

PROCEDURE del (p_emp_id INTEGER) IS

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

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

IF checkdept (p_emp_id) AND mgr THEN

DELETE payroll

WHERE id = p_emp_id;

ELSE

raise_application_error (-20001, 'Insufficient Privilege'); END IF;

END del;

PROCEDURE ins (p_emp_id INTEGER, p_name VARCHAR2

,p-dept INTEGER

,payment_period VARCHAR2

,p_salary INTEGER) IS

Можете вставлять записи Payroll только в свой отдел ~ Устанавливать зарплату может только начальник отдела (в противном случае устанавливается в пустое значение)

l_salary payroll. salary%TYPE;

BEGIN

IF NOT checkdept (p_emp_id) THEN

raise_application_error (-20001, 'Insufficient Privilege');

END IF;

IF NOT mgr THEN

l_salary: = NULL;

ELSE

l_salary: = p_salary;

END IF;

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

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

END ins;

PROCEDURE upd (p_emp_id INTEGER, p_name VARCHAR2

,p_payment_period VARCHAR2,p_salary INTEGER) IS

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

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

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

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

l_salary payroll. salary%TYPE;

CURSOR c_old_salary IS

SELECT pay. salary

FROM payroll pay

WHERE id = p_erap_id;

BEGIN

IF NOT checkdept (p_emp_id) THEN

raise applicatiori_error (-20001, 'Insufficient Privilege');

END IF;

IF NOT mgr THEN

OPEN c_old_salary;

FETCH c__old_s alary INTO l__salary;

CLOSE c_old_salary,

ELSE

l_salary: = p_salary;

END IF;

UPDATE payroll

SET name = p_name

,payment_period = p_payment_period

,salary = l_salary

WHERE id = p_emp_id;

END upd;

Код инициализации пакета

BEGIN

OPEN c_me;

FETCH c_me

INTO ray_dept

,mgr_flag;

CLOSE c_me;

IF mgr_flag = 'Y' THEN

mgr: = TRUE;

ELSE

mgr: = FALSE;

END IF;

END k_payroll;

/

2.4 Организация защиты MySQL

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

Используемая в MySQL система безопасности для всех подключений, запросов и иных операций, которые может пытаться выполнить пользователь, базируется на списках контроля доступа ACLs (Access Control Lists). Обеспечивается также некоторая поддержка SSL-соединений между клиентами и серверами MySQL. Многие из рассматриваемых здесь концепций не относятся исключительно к MySQL; те же общие соображения применимы практически ко всем приложениям.

При работе в MySQL следует следовать приведенным ниже инструкциям:

Не предоставлять никому (за исключением пользователя mysql под именем root) доступа к таблице user в базе данных mysql! Это чрезвычайно важно. В MySQL зашифрованный пароль является реальным паролем. Узнав пароль, занесенный в таблицу user, и имея доступ к удаленному компьютеру, занесенному в соответствующую учетную запись, войти в систему под именем зарегистрированного владельца пароля легко может кто угодно.

Стоит изучить систему прав доступа MySQL. Для управления доступом к MySQL служат команды GRANT и REVOKE. Нельзя предоставлять права всем хостам. Полезно проводить следующие контрольные проверки:

Выполните команду mysql - u root. Если удается успешно установить соединение с сервером без получения запроса пароля, значит, у вас имеются проблемы. Это означает, что кто угодно может подсоединиться к вашему серверу MySQL как клиент MySQL под именем root, получая таким образом право неограниченного доступа! Проанализируйте инструкцию по инсталляции MySQL, обращая особое внимание на ту часть, которая касается задания пароля пользователя root.

С помощью команды SHOW GRANTS проверьте, кто и к каким ресурсам имеет доступ. Воспользуйтесь командой REVOKE, отмените права доступа, которые не являются необходимыми.

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

Нельзя использовать в качестве пароля слова из словарей. Для взлома такого рода паролей имеются специальные программы. Даже слова типа ``xfish98'' - это очень плохие пароли. Куда лучше ``duag98'': здесь используется то же слово ``fish'', но при этом буквы в нем заменены ближайшими к ним слева буквами клавиатуры QWERTY. Еще один метод - составить парольное слово из первых букв слов какого либо словосочетания, например ``Mhall'' - по фразе ``Mary had a little lamb. '' Такой пароль легко запоминается и его легко вводить. А вот разгадать его тому, кто не знает ключевой фразы, будет непросто.

Стоит приобрести брандмауэр. Эта мера обеспечит защиту как минимум от половины всех видов несанкционированного использования любого ПО, с которым вы работаете. Разместите MySQL за брандмауэром или в демилитаризованной зоне (demilitarised zone - DMZ). Полезно проводить следующие контрольные проверки:

Попробуйте просканировать ваши порты из Internet с помощью утилиты типа nmap. MySQL использует по умолчанию порт 3306. Этот порт должен быть недоступен с неблагонадежных компьютеров. Еще один простой способ проверить, открыт или нет ваш MySQL-порт, - попытаться выполнить с какой либо удаленной машины следующую команду, где server_host - имя хоста, на котором установлен ваш сервер MySQL:

shell> telnet server_host 3306

Если соединение будет установлено, и вы получите какие-либо бессмысленные символы, это будет означать, что порт открыт, и его нужно закрыть на брандмауэре или маршрутизаторе (если, конечно, нет действительно веских причин держать его открытым). Если же telnetпросто зависнет или в подсоединении будет отказано, тогда все в порядке: порт заблокирован.

Не доверяйте никаким данным, которые вводят пользователи. Возможны попытки перехитрить вашу программу путем ввода последовательностей специальных или экранированных символов в веб-формы, URL-ы или любое приложение, созданное вами. Убедитесь, что защита вашего приложения не будет нарушена, если пользователь введет что-нибудь типа "'; DROP DATABASE mysql; ''. Это крайний случай, но действия хакеров, использующих подобную технологию, могут привести к потере информации и появлению брешей в системе безопасности, если вы не готовы к ним. Не следует также забывать о необходимости проверки цифровых данных (распространенной ошибкой является защита только строк). Некоторые полагают, что если в базе данных хранятся только открытые данные, то в ее защите нет необходимости. Это неверно. Такие базы могут стать объектом успешных атак типа отказа от обслуживания. Простейший способ защиты от взломов такого типа - заключать числовые константы в кавычки: SELECT * FROM table WHERE ID='234', а не SELECT * FROM table WHERE ID=234. MySQL автоматически преобразует эту строку в число и выбросит из нее все нецифровые символы. Полезно проводить следующие контрольные проверки:

Для всех веб-приложений:

Попробуйте ввести во все ваши веб-формы одинарные и двойные кавычки - `'' и `"'. Если MySQL выдаст любое сообщение об ошибке, немедленно разберитесь, в чем дело.

Попробуйте видоизменять динамические URL, добавляя в них %22 (`"'), %23 (`#'), и %27 (`'').

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

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

Проверяйте размер данных перед тем, как они будут переданы в MySQL.

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

Пользователям PHP:

Проверьте функцию addslashes (). Что касается PHP 4.0.3, то в нем имеется функция mysql_escape_string (), базирующаяся на функции с тем же именем из MySQL C API.

Пользователям MySQL C API:

Проверьте API-вызов mysql_real_escape_string ().

Пользователям MySQL++:

Проверьте такие модификаторы, как escape и quote, - для потоков запросов.

Пользователям Perl DBI:

Проверьте метод quote () или используйте для проверки заполнители.

Пользователям Java JDBC:

Используйте для проверки объект PreparedStatement и символы-заполнители.

Не передавайте по Internet открытые (незашифрованные) данные. Они могут оказаться у кого угодно, имеющего достаточно времени и возможностей для того, чтобы перехватить их и использовать в своих целях. Используйте вместо этого протоколы с шифрованием данных, такие как SSL и SSH. MySQL, начиная с версии 4.0.0, поддерживает собственные SSL-соединения. Пересылка по SSH (SSH Port Forwarding) может быть использована для создания туннеля передачи данных с шифрованием и сжатием.

Научитесь пользоваться утилитами tcpdump и strings. В большинстве случаев проверить, являются ли потоки данных MySQL зашифрованными, можно с помощью команды, подобной той, которая приведена ниже:

shell> tcpdump - l - i eth0 - w - src or dst port 3306 | strings

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

Размещено на Allbest.ru