Защита информации в базах данных

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

Эти два подхода отличаются следующими свойствами:

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

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

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

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

СУБД в своих системных каталогах хранит как описание самих пользователей, так и описание их привилегий по отношению ко всем объектам.

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

В ряде СУБД вводится следующий уровень иерархии пользователей — это администратор БД . В этих СУБД один сервер может управлять множеством СУБД (например, MS SQL Server , Sybase).

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

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

В стандарте SQL определены два оператора: GRANT и REVOKE соответственно предоставления и отмены привилегий .

Оператор предоставления привилегий имеет следующий формат:

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

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

— задает имя конкретного объекта: таблицы, представления, хранимой процедуры, триггера.

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

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

Рассмотрим пример, пусть у нас существуют три пользователя с абсолютно уникальными именами user1, user2 и user3 . Все они являются пользователями одной БД .

User1 создал объект Tab1 , он является владельцем этого объекта и может передать права на работу с эти объектом другим пользователям. Допустим, что пользователь user2 является оператором, который должен вводить данные в Tab1 (например, таблицу новых заказов), а пользователь user 3 является большим начальником (например, менеджером отдела), который должен регулярно просматривать введенные данные.

Для объекта типа таблица полным допустимым перечнем действий является набор из четырех операций: SELECT, INSERT, DELETE, UPDATE . При этом операция обновление может быть ограничена несколькими столбцами.

Общий формат оператора назначения привилегий для объекта типа таблица будет иметь следующий синтаксис :

Тогда резонно будет выполнить следующие назначения:

Эти назначения означают, что пользователь user2 имеет право только вводить новые строки в отношение Tab1 , а пользователь user3 имеет право просматривать все строки в таблице Tab1 .

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

Если наш пользователь user1 предполагает, что пользователь user4 может его замещать в случае его отсутствия, то он может предоставить этому пользователю все права по работе с созданной таблицей Tab1 .

В этом случае пользователь user4 может сам назначать привилегии по работе с таблицей Tab1 в отсутствие владельца объекта пользователя user1 . Поэтому в случае появления нового оператора пользователя user5 он может назначить ему права на ввод новых строк в таблицу командой

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

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

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

Читать еще: Цели и задачи технической защиты информации

Так как представления могут соответствовать итоговым запросам, то для этих представлений недопустимы операции изменения, и, следовательно, для таких представлений набор допустимых действий ограничивается операцией SELECT . Если же представления соответствуют выборке из базовой таблицы, то для такого представления допустимыми будут все 4 операции : SELECT , INSERT , UPDATE и DELETE .

Для отмены ранее назначенных привилегий в стандарте SQL определен оператор REVOKE . Оператор отмены привилегий имеет следующий синтаксис :

Параметры CASCADE или RESTRICT определяют, каким образом должна производиться отмена привилегий . Параметр CASCADE отменяет привилегии не только пользователя, который непосредственно упоминался в операторе GRANT при предоставлении ему привилегий, но и всем пользователям, которым этот пользователь присвоил привилегии, воспользовавшись параметром WITH GRANT OPTION .

Например, при использовании операции :

будут отменены привилегии и пользователя user5 , которому пользователь user4 успел присвоить привилегии.

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

не будет выполнена, потому что пользователь user4 передал часть cвоих полномочий пользователю user5 .

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

Поэтому корректным будет следующее использование оператора REVOKE :

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

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

Если вы хотите изменить это условие, то после создания хранимой процедуры необходимо записать оператор REVOKE .

И теперь мы можем назначить новые права пользователю user4 .

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

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

В некоторых СУБД пользователь может получить права создавать БД . Например, в MS SQL Server системный администратор может предоставить пользователю main_user право на создание своей БД на данном сервере. Это может быть сделано следующей командой:

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

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

Для того чтобы разрешить пользователю создавать объекты внутри этой БД , используется понятие системной привилегии, которая может быть назначена одному или нескольким пользователям. Они выдаются только на действия и конкретный тип объекта . Поэтому если вы, как системный администратор , предоставили пользователю право создания таблиц ( CREATE TABLE ), то для того чтобы он мог создать триггер для таблицы, ему необходимо предоставить еще одну системную привилегию CREATE TRIGGER . Система защиты в Oracle считается одной из самых мощных, но это имеет и обратную сторону — она весьма сложная. Поэтому задача администрирования в Oracle требует хорошего знания как семантики принципов поддержки прав доступа, так и физической реализации этих возможностей.

Защита информации в базах данных

Защита баз данных – обеспечение защищённости базы данных против любых предумышленных или непредумышленных угроз с помощью различных компьютерных и некомпьютерных средств.

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

База данных представляет собой важнейший корпоративный ресурс, который должен быть надлежащим образом защищён с помощью соответствующих средств контроля. Мы обсудим проблемы защиты баз данных с точки зрения таких потенциальных опасностей, как:

– Похищение и фальсификация данных;

– Нарушение неприкосновенности личных данных;

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

Контрмеры – компьютерные средства контроля

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

– Резервное копирование и восстановление.

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

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

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

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

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

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

– ключ шифрования, предназначен для шифрования исходных данных;

– алгоритм шифрования, который описывает, как с помощью ключа шифрования преобразовать обычный текст в шифротекст;

– ключ дешифрования, предназначен для дешифрования шифротекста;

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

Существует две системы шифрования: симметричная и несимметричная. В симметричной системе используется один и тот же ключ как для шифрования так и для дешифрования. А в несимметричной системе используются разные ключи, причём один из ключей должен храниться в секрете.

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

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

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

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

г) Установка или модернизация системного программного обеспечения.

Дата добавления: 2015-05-09 ; Просмотров: 684 ; Нарушение авторских прав?

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Защита информации в базах данных

Шайтова Н.Ж., Туленгалиева М.Г.

Актюбинский политехнический колледж, г. Актобе

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

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

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

Методы защиты баз данных в различных СУБД условно делятся на две группы (анализ современных фирм Borland и Microsoft): основные и дополнительные.

К основным средствам защиты относится:

— разделение прав доступа к объектам БД;

— защита полей и записей таблиц БД.

Защита паролем – это самый простой способ защиты БД от несанкционированного доступа.

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

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

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

Шифрование обеспечивает три состояния безопасности информации:

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

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

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

К дополнительным средствам защиты БД можно отнести следующие средства:

— встроенные средства контроля значений данных в соответствии с типами:

— повышение достоверности вводимых данных:

— обеспечения целостности связей таблиц:

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

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

Список использованной литературы

1. Дейт, К., Дж. Введение в системы баз данных. 6-е изд. – К.; М., СПб.: «Вильямс», 2000. – 848с.

2. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений/Под ред. проф. А.Д. Хомоненко. – СПб.: КОРОНА принт, 2002. – 672с.

3. В.В. Корнеев, А.Ф. Гареев, С.В. Васютин, В.В. Райх Базы данных. Интеллектуальная обработка информации. – М.: Нолидж, 2001.- 496с.

Записки ИТ-многостоночника

Архитектурный и технический консалтинг во внедрении и разработке ПО. Системный бизнес анализ и дизайн

Информационная безопасность баз данных

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

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

Читать еще: Как полностью почистить компьютер от вирусов

Даже последние нормативные документы от российских законотворцев в области ИБ показывают, что коллеги в Министерствах и Федеральных агентствах и службах постепенно отошли от ГБ-шной модели «все зашифровать, поставить гриф, трехметровый забор и расстреливать каждого, кто не назовет пароль» и стали под объектами защиты больше понимать не средства обработки информации, но саму информацию (в виде данных) и технологии ее обработки. Например, в требованиях к защите информации в Государственных информационных системах (утвержденных приказом ФСТЭК России №17) появился такой раздел, как защита потоков информации.

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

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

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

Частично эти свойства обеспечивается такими традиционно не ИБ-шными средствами «защиты» как например резервной копирование и восстановление после сбоев (о чем я писал, например, здесь, а здесь описывал требования, предъявляемые к этим процессам для автоматизированных банковских систем Банком России). Здесь подробно останавливаться на этом не буду, отмечу только, что традиционно требования к этому, а также соответствующие решения являются «вотчинной» специалистов по инфраструктуре.

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

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

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

Независимо от метода аутентификация и разграничение доступа — это базовые средства защиты данных, обрабатываемых в базе данных, от несанкционированных действий.

Основными угрозами/уязвимостями для данных, обрабатываемых в БД, являются:

Завышенные или неиспользуемые привилегии. Как правило, являются следствием лени или нежелания сформировать ролевую матрицу для пользователей в соответствии с широко известным принципом минимального знания. Может привести к тому, что в системе появляются учетные записи, доступ к данным которых неоправданно широкий, при этом защите этих учетных записей не уделяется достаточное внимание. В случае применение второго метода аутентификации и контроля доступа эта угроза будет относится не только к данным, обрабатываемым в базе, но на этом уровне она наиболее опасна.
Злоупотребление полномочиями. Является следствием предыдущей угрозы/уязвимости, а также следствием особенности большинства промышленных ИТ-систем — наличия суперпользователя. Данный неконтролируемый пользователь должен быть максимально ограничен, а полномочия его и ему подобных пользователей должны анализироваться и отслеживаться. Например, в большинстве рекомендаций по политикам безопасности для Microsoft говорится, что следует внимательнее относиться к пользователям группы «Продвинутые пользователи», так как это не пользователи с расширенными правами, а скорее администраторы с урезанными.
SQL-инъекции. Самая «популярная» угроза для RDBMS. Описывать ее не имеет смысла, гугл в помощь.
Вредоносное ПО, которое поможет злоумышленнику получить доступа непосредственно к СУБД. Основная «фишка» данной угрозы заключается в том, что системы, особенно построенные по n-Tier-принципам, как правило, не предусматривают прямого доступа кого-либо извне к СУБД как к СУБД, т.е. не через уровни (Tier), реализующие соответствующие архитектурные слои, лежащие над слоем данных. Даже при построения простейших систем на базе одной только СУБД (например, Oracle DB) рекомендуется использовать простейший слой сервисов и хотя бы презентационной логики (например, Oracle APEX). Однако, соответствующее вредоносное ПО может обеспечить доступ к СУБД как к ПО в составе ПО и КТС системы и, соответственно, неконтролируемый прикладной логикой доступ к данным. Это особенно опасно при реализации аутентификации и разграничения доступа первым методом.
Выводимые из эксплуатации носители данных. Есть старая ГБ-шная шутка, что самым лучшим источником информации для шпиона является мусорная корзина. По аналогии, выводимые из эксплуатации носители данных, которые раньше использовались БД, могут содержать защищаемую информацию с незначительными преобразованиями и потерей актуальности.
DoS и DDoS-атаки. Про этот тип угроз также можно найти любую информацию в открытом доступа.
Недостаток информации аудита («слабые» политики аудита). Регистрация событий безопасности (а в базе данных большинство событий можно отнести к таковым) является головной болью администраторов, так как логи занимают много места, как правило, негативно сказываются на производительности, и вообще «кто там будет что-то копать?». При проектировании системы следует избегать таких мыслей. При этом стоит стараться учитывать наличие привилегированных пользователей, которые могут отключать аудит определенных событий. В идеале система должна быть настроена таким образом, чтобы не позволять неконтролируемо совершать каких-либо действий любому пользователю.

Это основные угрозы, а также решения по обеспечению безопасности данных, обрабатываемых в базах данных, которые следует принимать во внимание во время проектирования системы. Конечно, полноценная защита на всех уровнях (как бы я ни недолюбливал это расплывчатое понятие, но именно в ИБ оно применяется довольно успешно) обеспечивается через сквозную функциональность и эшелонированную защиту (Defense in Depth), однако, как правило при разработке и внедрении программно-технических решений в ведении исполнителя остается только очень ограниченная часть возможностей, которые следует использовать по полной.

Позднее я опишу такой спорный метод защиты информации в базе данных как шифрование и расскажу о своем опыте проектирования и экспертизе решения с шифрованием в СУБД.

голоса

Рейтинг статьи