Подход Helios Information Technologies к защите баз данных

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

• Защита непосредственно информации в базе данных.

• Защита СУБД от неблагоприятных воздействий на информацию.

Реальная и «бумажная» защита данных

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

Преимущества подхода:

1. Реальная прозрачная защита данных:

   • прозрачное шифрование всей базы данных или конкретных «чувствительных» колонок;

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

   • дискретное или мандатное разграничение доступа, в том числе, для защиты от администратора базы данных;

   • расширенный аудит событий безопасности.

2. «Бумажная» защита данных:

   • использование сертифицированных средств криптографической защиты информации в рамках СУБД Oracle;

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

   • соблюдение методических рекомендаций контролирующих органов.

Защита субд

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

Helios Information Technologies предлагает консультационные и интеграционные услуги для внедрения регламентных и технических мер защиты СУБД, основанных на лучших мировых практиках и программно-аппаратных комплексах ведущих производителей.

Внедрение систем защиты субд позволит:

• осуществлять мониторинг СУБД разных типов: Oracle, MSSQL, DB2 и др;

• осуществлять контроль и управление состоянием СУБД и БД;

• выявлять атаки на СУБД на раннем этапе;

• проводить анализ событий и разбор инцидентов;

• осуществлять мониторинг активности пользователей и приложений при работе с СУБД;

• составлять отчеты разного уровня детализации;

• собирать и обрабатывать подробные данные аудита состояний СУБД.

Результат применения

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

2. Расширенные возможности аудита использования корпоративной информации в базах данных.

3. Мониторинг состояний СУБД и баз данных (доступность, режимы работы, защищенность и пр.) в режиме 24/7.

4. Выполнение требований контролирующих органов при работе с «чувствительной» информацией (например ПДн).

48. Ядро субд и параллельная обработка

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

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

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

СУБД ЛИНТЕР имеет настраиваемый параметр "квант обработки", в течение которого непрерывно ведется работа над одним запросом. Обратите внимание, что это не "квант времени", как в некоторых других системах. СУБД ЛИНТЕР прерывается на обработку другого запроса, просмотрев определенное число записей или проработав с определенным числом индексов. Пара этих чисел задается при настройке системы перед запуском и определяет "квант обработки".

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

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

СУБД ЛИНТЕР ведет следующие очереди:

• очередь описателей таблиц;

• очередь описателей столбцов;

• очередь дескрипторов файлов;

• очередь страниц (пул системы);

• очередь ответов.

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

Таблица 1 Средние показатели динамичности очередей СУБД ЛИНТЕР

Место по динамичности	Очередь и длина элемента, байт	Уровень динамичности  от динамичности очереди столбцов, %
1	Столбцов (80)	100
2	Страниц (4096)	50
3	Файлов (28)	20
4	Таблиц (204)	10
5	Пользователей  (54)	5

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

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

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

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

• пространство файла сортировки используется монопольно;

• пространство файла битвекторов выделяется по требованию системы для обработки запроса и закрепляется за каналом до нового запроса по каналу или ошибки в обработке запроса.

На многозапросную среду этот ресурс влияния не оказывает.