Гайдамакин Н. А. 19 страница

В модели Белл —ЛаПадула устанавливаются и поддержи­ваются два основных ограничения политики безопасности:

• запрет чтения вверх (no read up — NRU);

• запрет записи вниз (no write down — NWD).

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

Ограничение NWD предотвращает перенос (утечку) кон­фиденциальной информации путем ее копирования из объек­тов с высоким уровнем конфиденциальности в неконфиденциальные объекты или в объекты с меньшим уровнем конфиден­циальности.

Ограничения NRU и NWD приводят к тому, что по разным типам доступа («чтение», «создание», удаление», «запись») в модели Белл—ЛаПадула устанавливается разный порядок до­ступа конкретного субъекта к объектам. В частности, в схеме, приведенной на рис. 7.4, может показаться странным, что по типу доступа «создание» субъект (процесс) с допуском степе­ни 3 (низшей) имеет возможность создавать объекты (записи) в объектах более высокого уровня конфиденциальности.* Такой подход, тем не менее, отражает реальные жизненные ситуации, когда работники, к примеру, кадрового подразделения могут заполнять формализованные карточки на новых сотрудников, направляя их в специальную картотеку личных данных сотруд­ников организации и порождая первые документы личных дел новых сотрудников, но не имеют при этом собственно самого доступа к этой картотеке по другим типам операций (чтение, удаление, изменение).

* В литературе подобные возможности доступа в многоуровневых моделях обозначаются *-свойством

 

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

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

При реализации политик и моделей безопасности данных в фактографических АИС на основе реляционных СУБД воз­никают специфические проблемы разграничения доступа на уровне отдельных полей таблиц. Эти проблемы связаны с от­сутствием в реляционной модели типов полей с множествен­ным (многозначным) характером данных.*

* Требование первой нормальной формы

 

Поясним суть подобных проблем следующим образом. Предположим, в базе данных имеется таблица с записями по сотрудникам с полями «Лич_№», «Фамилия», «Подразделение», «Должность». Предположим также, что в структуре организа­ции имеется засекреченное подразделение «Отдел_0», извест­ное для всех непосвященных под названием «Группа консуль­тантов». Соответственно поля «Подразделение», «Должность» для записей сотрудников этого подразделения будут иметь двой­ные значения — одно истинное (секретное), другое для при­крытия (легенда). Записи таблицы «Сотрудники» в этом случае могут иметь вид:

Таблица 7.1

 

В таблице знаком [С] обозначены секретные значения, зна­ком [НС] несекретные значения соответствующих полей. Как видно из приведенной таблицы, требования первой нормаль­ной формы в таких случаях нарушаются.

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

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

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

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

7.2.2. Технологические аспекты защиты информации

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

• технологии идентификации и аутентификации;

• языки безопасности баз данных;

• технологии обеспечения безопасности повторного исполь­зования объектов;

• технологии надежного проектирования и администриро­вания.

7.2.2.1. Идентификация и аутентификация

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

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

Под аутентификацией понимается проверка и подтверж­дение подлинности образа идентифицированного субъекта, объекта, процесса.

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

В системотехническом плане структуру систем идентифи­кации/аутентификации можно проиллюстрировать схемой, при­веденной на рис. 7.5.

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

Рис. 7.5. Системотехнический аспект идентификации/аутенти­фикации

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

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

Формирование образов осуществляется на разной методо­логической и физической основе в зависимости от объекта иден­тификации/аутентификации (пользователь-субъект; процесс; объект-ресурс в виде таблицы, формы, запроса, файла, устрой­ства, каталога и т. д.). В общем плане для идентификации/аутен­тификации пользователей-субъектов в компьютерных системах могут использоваться их биометрические параметры (отпечат­ки пальцев, рисунок радужной оболочки глаз, голос, почерк и т. д.), либо специальные замково-ключевые устройства (смарт-карты, магнитные карты и т. п.). Однако при доступе непосред­ственно в АИС (в базы данных), чаще всего используются па­рольные системы идентификации/аутентифшкации.

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

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

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

Поэтому в некоторых случаях парольные аутентифи

ры могут усиливаться диалогово-вопросными сис

системами «коллективного вхождения». В диалогово

ных системах для каждого зарегистрирован

создается некоторая база вопросов я ответов

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

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

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

* Так называемый принцип надежного пути и гарантированности архитектуры.

 

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

Для аутентификации процессов широкое распространение нашли технологии меток (дескрипторов) доступа.

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

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

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

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

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

7.2.2.2. Языки безопасности баз данных

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

В реляционных СУБД такой язык должен являться соот­ветственно составной частью языка SQL. Исторически впер­вые подобные вопросы были поставлены и реализованы в упо­минавшихся языках SEQUEL (созданного в рамках проекта System R фирмы IBM) и языка QUEL (созданного в рамках про­екта INGRES) и послуживших в дальнейшем основой для язы­ка SQL.

Как уже отмечалось в п. 4.1, в перечне базовых инструк­ций языка SQL представлены инструкции GRANT и REVOKE, предоставляющие или отменяющие привилегии пользователям. Структура инструкции GRANT выглядит следующим образом:

GRANT список_привилегий_через_запятую ON ИмяОбъекта

TO ИменаПользователей_через_запятую

[ WITHGRANTOPTION ];

где:

— список привилегий составляют разрешенные инструк­ции (операции) над объектом (таблицей) — SELECT, INSERT, UPDATE, DELETE;

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

— директива WITH GRANT OPTION наделяет перечисленных пользователей дополнительными особыми полномочиями по предоставлению (перепредоставлению) указанных в списке привилегий-полномочий другим пользователям.

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

Хотя в явном виде такой подход не предусматривает созда­ние матрицы доступа,* тем не менее, реализуется классичес­кий принцип дискреционного разграничения доступа с соче­танием как добровольного, так и принудительного управления доступом.

* На самом деле в большинстве СУБД привилегии и установки доступа, как и структура базы данных, «прописываются» в системных таблицах БД, т.е. в системном каталоге БД. который можно рассматривать, в том числе и в качестве матрицы досту­па.

 

Как уже отмечалось, дискреционный принцип обладает большой гибкостью по настройке системы разграничения дос­тупа на особенности предметной области базы данных и по­требности пользователей, но не обеспечивает эффективной уп­равляемости и затрудняет проведение какой-либо целенаправ­ленной политики безопасности в системе. Преодоление этого недостатка достигается двумя путями — использованием тех­ники «представлений» и специальными расширениями языка SQL.

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

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

1. Для всех зарегистрированных пользователей в системе с помощью конструкций CREAТЕ VIEW создаются свои представ­ления объектов базы данных.

2. С помощью инструкций «GRANT SELECT ON ИмяПредставления ТО ИмяПользователя» созданные представления ав­торизуются со своими пользователями.

Вместе с тем такой подход является более грубым по срав­нению с применением инструкции GRANT непосредственно к объектам базы данных, т. к. не обеспечивает расщепления ус­тановок доступа к объектам на уровне отдельных операций (SELECT, INSERT, UPDATE, DELETE).

Поэтому другим подходом являются специальные расши­рения языка SQL, основанные на событийно-процедурной иде­ологии с введением специальных правил (RULE) безопаснос­ти:

CREATESECURITYRULE ИмяПравила

GRANT список_привилегий_через_запятую ON ИмяОбъекта

WHERE условия

TO ИменаПользователей_через_запятую

Реакция_на_нарушение_правила;

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

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

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

7.2.2.3. Безопасность повторного использования объектов

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

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

• изоляция процессов;

• очистка памяти после завершения процессов;

• перекрытие косвенных каналов утечки информации.

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

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

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

* Ударение на последнем слоге.

 

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

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

Специфический косвенный канал утечки информации, от­носящийся именно к СУБД, в том числе и при использовании техники «представлений», связан с агрегатными (статистичес­кими) функциями обработки данных, который можно пояснить на следующем примере. Предположим, пользователь в своем «представлении» базы данных видит не всю таблицу «Сотруд­ники», а только записи, непосредственно относящиеся к его подразделению. Тем не менее, формируя и выполняя запрос на выборку данных с вычисляемым полем «МахОклад» при ис­пользовании соответствующей агрегатной статистической фун­кции «Мах()>>, пользователь может получить хоть и в обезли­ченном виде, но не предназначенные для него данные, в том случае, если процессор и оптимизатор запросов не «сливает» сам запрос с соответствующим «представлением» базы данных.

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

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

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

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

Ядро СУБД после идентификации и аутентификации пользователя при его входе в систему предъявляет ему разре­шенный набор процедур. Непосредственного доступа к самим данным пользователь не имеет и работает только с результата­ми их обработки по соответствующим процедурам.

Данные АИС размещаются в файлах данных, структура которых может быть известна нарушителю. Поэтому еще одной угрозой безопасности данных АИС является возможность несанкционированного доступа к файлам данных вне программ­ного обеспечения АИС (СУБД) средствами операционной сис­темы или дисковых редакторов. Для нейтрализации этой уг­розы применяются методы и средства криптозащиты. В большинстве случаев криптографические средства защиты встраиваются непосредственно в программное обеспечение СУБД. Файл (файлы) базы данных* при размещении на устройствах дисковой памяти шифруется. Соответственно, криптографическая подсистема при открытии файла данных его дешиф­рует. Специфической особенностью СУБД является особый порядок работы с файлами базы данных через организацию специальной буферизации страниц в оперативной памяти. По­этому криптографическая подсистема встраивается в ядро СУБД, перехватывая все операции считывания страниц в опе­ративную память и, соответственно их дешифрируя, и все опе­рации обратного «выталкивания» страниц из оперативной па­мяти на диски и, соответственно, шифруя данные.

* В том числе с авторизованными хранимыми процедурами и запросами пред­ставлений.

 

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