Elettracompany.com

Компьютерный справочник
4 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Технология защиты баз данных

Технология защиты баз данных

Технологии баз данных
и знаний

АДМИНИСТРИРОВАНИЕ БАЗ ДАННЫХ

Разработчик: ст. преподаватель Черепица Л.С.

2. Защита баз данных

2. ЗАЩИТА БАЗ ДАННЫХ

2.1. Актуальность защиты базы данных

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

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

Чтобы обеспечить защиту данных в компьютерных системах необходимо определить перечень мер, обеспечивающих защиту.

2.2. Методы защиты баз данных: защита паролем, шифрование, разграничение прав доступа

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

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

§ шифрование данных и программ;

§ разграничение прав доступа к объектам базы данных;

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

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

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

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

Процесс дешифрования восстанавливает данные в исходное состояние.

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

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

По отношению к таблицам могут предусматриваться следующие права доступа:

§ просмотр (чтение) данных;

§ изменение (редактирование) данных;

§ добавление новых записей;

§ добавление и удаление данных;

§ изменение структуры таблицы.

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

Защита данных в полях таблиц предусматривает следующие уровни прав доступа:

§ полный запрет доступа;

§ разрешение всех операций (просмотр, ввод новых значений, удаление и изменение).

По отношению к формам могут предусматриваться две основные операции:

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

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

Отчеты во многом похожи на экранные формы. На отчеты, так же как и на формы, может накладываться запрет на вызов средств их разработки.

К дополнительным средствам защиты БД можно отнести такие, которые нельзя прямо отнести к средствам защиты, но которые непосредственно влияют на безопасность данных. Их составляют следующие средства:

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

§ повышения достоверности вводимых данных;

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

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

2.3. Правовая охрана баз данных

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

Республика Беларусь стремится к созданию цивилизованного информационного рынка. Об этом свидетельствуют принятые указы, постановления, законы:

— О научно-технической информации;

— О национальном архивном фонде и архивах в Республике Беларусь

— О печати и других средствах массовой информации

— О правовой охране программ для ЭВМ и баз данных

— О введении в действие Единой системы классификации и кодирования технико-экономической и социальной информации Республики Беларусь и др.

Наличие з акона «Об информатизации» важно тем, что в нем даются «узаконенные» определения основных понятий.

Закон о научно-технической информации , принятый 5 мая 1999г устанавливает правовые основы регулирования правоотношений, связанных с созданием, накоплением, поиском, получением, хранением, обработкой, распространением и использованием научно-технической информации в Республике Беларусь.

Закон «О правовой охране программ для ЭВМ и баз данных» и закон «Об авторском праве и смежных правах» следует рассматривать взаимосвязано, т.к. их положения затрагивают правовую охрану программ для персональных компьютеров и баз данных.

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

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

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

  • В случае избирательного управления некоторый пользователь обладает различными правами (привилегиями или полномочиями) при работе с данными объектами. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту. Избирательные права характеризуются значительной гибкостью.
  • В случае неизбирательного управления, наоборот, каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. При таком подходе доступом к определенному объекту данных обладают только пользователи с соответствующим уровнем допуска.
  • Для реализации избирательного принципа предусмотрены следующие методы. В базу данных вводится новый тип объектов БД — это пользователи. Каждому пользователю в БД присваивается уникальный идентификатор. Для дополнительной защиты каждый пользователь кроме уникального идентификатора снабжается уникальным паролем, причем если идентификаторы пользователей в системе доступны системному администратору, то пароли пользователей хранятся чаще всего в специальном кодированном виде и известны только самим пользователям.
  • Пользователи могут быть объединены в специальные группы пользователей. Один пользователь может входить в несколько групп. В стандарте вводится понятие группы 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 требует хорошего знания как семантики принципов поддержки прав доступа, так и физической реализации этих возможностей.

Читать еще:  Методы защиты от воздействия вредных веществ

Методы защиты и безопасность базы данных

физико-математические науки

  • Дудкина Анастасия Сергеевна , бакалавр, студент
  • Баш­кирс­кий го­су­дарст­вен­ный аг­рар­ный уни­вер­си­тет
  • Похожие материалы

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

    К основным средствам защиты информации относят следующие:

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

    Защита БД производится на двух уровнях:

    • на уровне пароля;
    • на уровне пользователя (защита учетных записей пользователей и идентифицированных объектов).

    Безопасная система авторизации и регистрации является одним из важнейших элементов при создании проекта. Один из возможных способов — это создание системы регистрации с помощью PHP и MySQL.

    РhpMyAdmin — это программа написанная на PHP и предназначенная для управления сервером MySQL через всемирную сеть. phpMyAdmin поддерживает широкий набор операций над MySQL. Наиболее часто используемые операции поддерживаются с помощью пользовательского интерфейса (управление базами данных, таблицами, полями, связями, индексами, пользователями, правами, и т. д.), одновременно вы можете напрямую выполнить любой SQL запрос.

    Обеспечение информационной безопасности разрабатываемого проекта осуществляется на нескольких уровнях. На первом уровне защиту информации обеспечивает сама система «phpMyAdmin» начиная со входа в панель управления где панель требуется ввести логин и пароль.

    Рисунок 1. Авторизация в системе «phpMyAdmin»

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

    Рисунок 2. Обзор учетных записей

    Кроме того, также можно ограничить доступ не только к самой системе управления базами данных, но и отдельно к базам данных, к таблицам базы данных, к записям конкретных таблиц и даже к значениям полей таблиц или записей. Стоит отметить, что встроенные функции шифрования присутствуют далеко не во всех СУБД. Следовательно, универсальным данный метод назвать нельзя. Данная СУБД предлагает два однотипных набора функций шифрования, в одном из которых реализован алгоритм DES, а в другом — AES. Кроме того, в MySQL реализовано несколько алгоритмов хэширования. Набор криптографических функций данной СУБД выглядит так:

    Таблица 1. Криптографические функции СУБД

    Зашифрование данных алгоритмом AES.

    Расшифрование данных алгоритмом AES.

    Зашифрование данных алгоритмом DES.

    Расшифрование данных алгоритмом DES.

    Зашифрование данных функцией crypt().

    Хэширование данных алгоритмом MD5.

    Хэширование данных алгоритмом SHA-1.

    Функции шифрования данных алгоритмом AES используют 128-битный ключ шифрования, т. е. шифрование ключами размером 192 и 256 бит, предусмотренными стандартом AES , в MySQL не реализовано. Ключ шифрования задается явным образом как один из параметров функции. В отличие от них, функции DES_ENCRYPT() и DES_DECRYPT(), которые шифруют алгоритмом TripleDES, помимо явного задания ключа шифрования, допускают простейший вариант управления ключами в виде ключевого файла, содержащего пронумерованные значения ключей. Однако, данные функции по умолчанию выключены, для их использования необходимо включить поддержку протокола SSL в конфигурации СУБД.

    Функция ENCRYPT() может быть использована только в операционных системах семейства Unix, поскольку она шифрует данные с помощью системного вызова crypt(). Что касается используемых функций хэширования, то в документации на MySQL содержится предупреждение о том, что лежащие в их основе алгоритмы взломаны (подробно об этом написано, в частности, в, поэтому использовать их следует с осторожностью. Однако, MySQL пока не предлагает более стойких функций хэширования взамен существующих. Перечисленные выше криптографические функции также весьма просты в использовании. Например, следующий запрос помещает в таблицу table значение “text”, зашифрованное на ключе “password” : INSERT INTO table VALUES ( 1, AES_ENCRYPT( ‘text’, ‘password’ ) ); Отметим, что формат поля, в которое записывается зашифрованное значение, должен соответствовать ограничениям, накладываемым используемым криптоалгоритмом — в данном случае, оно должно быть двоичным (например, типа VARBINARY) и предполагать выравнивание в соответствии со 128-битным размером блока алгоритма AES.

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

    Список литературы

    1. Мельников,В.П.Информационная безопасность и защита информации. / В.П.Мельников,
    2. С.А.Клейменов, А.М.Петраков // 3-е изд., стер. — М.: Академия, 2008. — 336 с.
    3. Панасенко С.П. Комплексная защита информации. // Информационные технологии. -2001 — № 3 — с. 14-16
    4. Рабочая программа дисциплины «Информационная безопасность» : направление подготовки 080500 Бизнес-информатика [Электронный ресурс] : профиль подготовки Информационные системы в бизнесе : квалификация (степень) выпускника Бакалавр / Башкирский ГАУ, [Каф. информатики и информационных технологий ; сост. А. Р. Басыров]. — Уфа : [б. и.], 2013. — 16 с. — Б. ц.
    5. Сайт PHP веб-приложения «phpMyAdmin» [Электронный ресурс]. – Режим доступа: http://www.phpmyadmin.net/home_page/ , свободный

    Электронное периодическое издание зарегистрировано в Федеральной службе по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор), свидетельство о регистрации СМИ — ЭЛ № ФС77-41429 от 23.07.2010 г.

    Соучредители СМИ: Долганов А.А., Майоров Е.В.

    Способы защиты баз данных

    Базовые средства защиты баз данных

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

    Например, сотруднику отдела “А” временно понадобился доступ к клиенту отдела “Б”. С большой вероятностью внесение изменений в матрицу доступа к данным не будет иметь обратного характера, что в конечном итоге приводит к наличию учетных записей с сильно расширенными привилегиями, за использованием которых стоит следить.

    Штатный аудит баз данных

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

    Ключевые недостатки штатного аудита как защиты баз данных:

    • Дополнительная нагрузка на серверы баз данных (10-40% в зависимости от полноты аудита).
    • Вовлечение администраторов баз данных в настройку аудита (невозможность контроля администраторов – основных привилегированных пользователей).
    • Отсутствие удобного интерфейса продукта и возможности централизованной настройки правил аудита (особенно актуально для крупных распределенных компаний, в задачи защиты которых входит целый перечень СУБД).
    • Невозможность контроля действий пользователей в приложениях с трехзвенной архитектурой (наличие WEB и SQL-сегмента, что сейчас используется повсеместно из соображений безопасности).

    Автоматизированные системы защиты баз данных

    Более эффективный подход – использование специализированных систем информационной безопасности в области защиты бд – решений классов DAM и DBF.

    DAM (Database Activity Monitoring) – это решение независимого мониторинга действий пользователей в СУБД. Под независимостью здесь понимается отсутствие необходимости переконфигурации и донастройки самих СУБД. Системы такого класса могут ставиться пассивно, работая с копией трафика и не оказывая никакого влияния на бизнес-процессы, частью которых являются базы данных.

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

    • Классификации – определение местонахождения критичной для компании информации. Опция позволяет, просканировав СУБД, увидеть названия таблиц и полей, в которых могут содержаться персональные данные клиентов. Это крайне важно для упрощения последующей настройки политик безопасности.
    • Проверки на уязвимости – соответствие конфигурации и настройки СУБД лучшим практикам.
    • Получение матрицы доступа к данным – задача решается для выявления расширенных привилегий доступа, неиспользуемым правам, и наличие так называемых «мертвых» учетных записей, которые могли остаться после увольнения сотрудника из компании.

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

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

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

    На российском рынке представлено решение класса DAM «Гарда БД» от компании «Гарда Технологии». Это программно-аппаратный комплекс, который проводит непрерывный мониторинг всех запросов к базам данных и веб-приложениям в реальном времени и хранит их в течение длительного срока. Система проводит сканирование и выявление уязвимостей СУБД, такие как незаблокированные учётные записи, простые пароли, неустановленные патчи. Реагирование на инциденты происходит мгновенно в виде оповещений на e-mail и в SIEM-систему.

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

    В следующей статье мы более подробно рассмотрим задачи, которые часто стоят перед DAM-системами, расскажем, почему для DAM так важно умение работы с http/http’s трафиком и как обеспечить защиту от SQL инъекций.

    Защита баз данных

    Уязвимость баз данных

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

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

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

    Попробуй обратиться за помощью к преподавателям

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

    Рисунок 1. Причины утечек данных. Автор24 — интернет-биржа студенческих работ

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

    Методы защиты БД

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

    • вход по паролю: для начала работы с БД необходимо ввести определенную комбинацию символов;
    • разграничение прав доступа к объектам БД;
    • защита полей и строк таблиц БД;
    • шифрование данных.

    Задай вопрос специалистам и получи
    ответ уже через 15 минут!

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

    • чтение данных;
    • редактирование данных;
    • добавление записей;
    • добавление, изменение и удаление данных;
    • изменение структуры таблицы.

    Рисунок 2. Назначение полномочий пользователям на действия с таблицами.Автор24 — интернет-биржа студенческих работ

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

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

    • повышение достоверности вводимых данных: с помощью ограничений, закладываемых при проектировании таблиц, а также масок ввода в формах предотвращается появление в БД некорректных записей, например, когда превышается количество дней в месяце (31 ноября), вводятся слишком большие или слишком малые значения, появляются незаполненные поля где это недопустимо и т.п.;
    • обеспечение целостности связей между таблицами: таблицы, как правило, включают в себя т.н. ключевые поля, благодаря чему становится невозможным в связанных таблицах появления ссылок на несуществующие записи; например, если в таблице «Покупатели» нет пользователя с идентификатором 123, то невозможным становится и внесение этого значения в соответствующее поле таблицы «Покупки»;
    • резервное копирование: при наступлении обстоятельств непреодолимой силы (отключение электроэнергии, природные катастрофы) данные могут быть утрачены, поэтому следует регулярно копировать БД на внешние носители и удалённые хранилища; резервные копии рекомендуется хранить в зашифрованном виде; большинство современных СУБД предоставляет готовые механизмы резервного копирования;
    • правовые аспекты: БД могут являться объектами интеллектуальной собственности и авторских прав, поэтому следует своевременно регистрировать их в соответствующих государственных органах; хранение персональных данных в БД также регулируется законодательством;
    • компьютеры и операционные системы, на которых развернуты БД, также должны соответствовать правилам безопасности: сетевые данные должны передаваться по защищенным соединениям, пользователи — работать с ограниченными полномочиями, на ОС должны присутствовать антивирус и/или фаервол и т.п.

    Примеры защиты БД

    PHP, MySQL и РhpMyAdmin

    При использовании популярной среди веб-программистов «связки» PHP и MySQL защиту баз данных можно организовать с помощью программы phpMyAdmin. Она предназначена для управления сервером MySQL через Интернет. phpMyAdmin с помощью удобного пользовательского интерфейса обеспечивает управление базами данных, таблицами, индексами, правами пользователей, и т.д., а также позволяет выполнять SQL запросы.

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

    Microsoft Access

    К данным, хранящимся в таблицах Microsoft Access, могут применяться следующие уровни доступа:

    • полный запрет доступа;
    • только чтение;
    • просмотр, ввод новых значений, удаление и изменение.

    С этой точки зрения Microsoft Access соответствует стандартной концепции реляционных БД.

    К формам и отчетам в Access применяют два метода защиты:

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

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

    Рисунок 3. Настройки безопасности Microsoft Access. Автор24 — интернет-биржа студенческих работ

    Так и не нашли ответ
    на свой вопрос?

    Просто напиши с чем тебе
    нужна помощь

Ссылка на основную публикацию
Adblock
detector