Progress-servis55.ru

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

Методы защита бд

Какие методы используются для защиты БД?

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

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

· Защита с использованием пароля БД

Данный способ защиты позволяет установить пароль на открытие БД, для всех пользователей. Для его создания необходимо открыть файл БД в «монопольном» режиме и выбрать пункт меню Сервис / Защита / Задать пароль базы данных. Для работы с такой базой данных в MS Access потребуется вводить пароль. Вот пример работы с файлом БД, используя DAO или ADO.

Public Sub TestDAO()
Dim mWS As DAO.Workspace
Dim mDB As DAO.Database
Set mWS = DBEngine.Workspaces(0)
Set mDB = mWS.OpenDatabase _
(«C:a97.mdb», True, True, «;pwd=123»)
End Sub

Public Sub TestADO()
Dim CnDB As New ADODB.Connection
CnDB.Open «Prov > «;Data Source=C:a97.mdb» & _
«;Jet OLEDB:Database Password=123»
End Sub

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

· Защита с использованием пароля пользователя

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

Нестандартные способы защиты

· Изменение расширения файла

Достаточно простой способ ввести в заблуждение — изменение расширения файла БД. Увидев незнакомое расширение, не каждый попытается выяснить природу этого файла. Кроме этого появляется возможность связать это расширение с вашей программой, так чтобы при клике по файлу запускалось ваше приложение, а не Access. Желательно открывать такой файл с монопольным доступом, так как в этом случае не будет создаваться ldb файл.

· Защита с использованием пароля БД, содержащего непечатные символы

Способ основан на том, что пароль БД формата Access 2000 и 2002-2003 — текстовая строка в формате Unicode. При этом, нет ни каких ограничений на её содержимое. Стандартный способ установки и использования пароля БД подразумевает его ввод с клавиатуры в диалоговом окне. Если стока пароля содержит непечатные символы, то они не будут корректно отображены программой открывающей пароли БД. С другой стороны этот пароль нельзя ввести в диалоговом окне при открытии БД в MS Access.
Но и про Access 97 я не забыл. Дело в том, что в спецификации баз данных и в справке по DAO 3.60 указано, что максимальное число символов в пароле — 14. Но на самом деле их может быть 20. При этом и сам Access 97 не допускает ввода строк пароля более 14 символов. В спецификации Access 2003 также сказано про 14 символов, но программа допускает ввод всех 20. Также возможно использование непечатных символов, что приводит большинство программ взламывающих пароли в ступор.

Для установки такого пароля потребуется использовать программу, использующую метод CompactDatabase библиотек ADOX или DAO.

· Защита с модификацией файла

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

· Защита изменением версии БД

Этот способ — дальнейшее развитие идеи модификации заголовка файла с целью противодействия программам, читающим пароли. Метод основан на том, что для работы с БД Access 97 и 2k программы используют разные алгоритмы чтения пароля и при этом пытаются самостоятельно определить версию mdb файла.

Для определения версии можно использовать последовательность из 40 байт, начиная с 122 от начала файла. Если в БД Access 97 вписать эту последовательность от Access 2k, то получим интересный результат. Программа ms Access, ADO и DAO нормально работают с этим файлом, а большинство взламывающих пароли программ попадаются на эту уловку. Аналогичный результат может быть получен при пересадке байтовой последовательности из Access 97 в Access 2k

· Защита с использованием электронного ключа

Это ещё одно подтверждение, того, что стандартные способы защиты, даже от сторонних производителей уязвимы. Речь идёт о ключах HASP. С помощью утилиты HASP Envelope можно зашифровать файл (в данном случае БД) и разрешить к нему доступ только из защищённого приложения. Используется механизм «прозрачного» шифрования. Со стартом операционной системы запускается некий процесс, который отслеживает все обращения к защищённому файлу БД. Если это обращение исходит от обычного приложения, например от ms Access — файл читается и выводится сообщение о «нераспознаваемом формате базы данных». Но если с файлом работает указанное при шифровании приложение, то данные передаются ему в дешифрованном виде. В результате, сама программа, не подозревает о наличии защиты. Да, сложность взлома такой базы возрастает в разы. Но при этом надо помнить, что с приложением должен поставляться электронный ключ, ценой N у.е. и что скорость доступа к данным падает в два — три раза.

· Шифрование значений таблиц

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

Читать еще:  Самоучитель по matlab

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Сдача сессии и защита диплома — страшная бессонница, которая потом кажется страшным сном. 9231 — | 7433 — или читать все.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать еще:  Matlab модуль числа

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

будут отменены привилегии и пользователя 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 требует хорошего знания как семантики принципов поддержки прав доступа, так и физической реализации этих возможностей.

Обзор методов защиты БД от несанкционированного копирования

Опубликовано:
27 ноября 2009 в 07:50

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

  1. Через SQL -сервер.
  2. Через хранилище БД (файлы БД на SQL-сервере).
  3. Через архивное хранилище БД (бэкапы).

Несанкционированный доступ к SQL -серверу

В большинстве случаев группа администраторов Windows-сервера, накотором установлен также SQL-сервер, являются членами SQL -группы «Sysadmin». Соответственногруппа администраторов Windows-сервера автоматически становится и администраторамиSQL-сервера, то есть получает полный доступ к нему.

Это не совсем правильно, т.к. администратор Windows -сервера считаетсянесанкционированным пользователем SQL -сервера.

  • Чтобы исключить данную ситуацию, необходимо контролировать SQL -группу «Sysadmin»,а именно:
  • убрать локальную группу администраторов Windows — сервера из SQL -группы « Sysadmin » и добавить только учетнуюзапись администратора SQL -сервера;
  • если учетная запись «SA» активна — рекомендуетсяустановить ей очень сложный пароль;
  • обеспечить уникальность и регулярное изменение паролейдля всех учетных записей администраторов;
  • включить полный аудит ( Successful and Failed Logins ), чтобы контролироватьвсе действия учетных записей администраторов.

Файлы хранилища БД – это обычные Windows файлы (*. mdf , *. ndf и *. ldf ).

Примечание. Они доступны для копирования только тогда, когда SQL -служба остановлена.

Доступ несанкционированного пользователяк хранилищу БД дает возможность перенести и развернуть эти файлы на другом SQL -сервере.

Чтобы защитить хранилище БД, рекомендуется:

  • хранить файлы БД на диске с Файловой системой NTFS ;
  • запустить SQL -службы от Windows / Domain учетной записи;
  • выдать полные правадоступа к хранилищу БД только учетной записи, под которой запускается SQL -служба;
  • запустить аудит файлов, чтобы контролировать вседействия, зависящие от хранилища БД;
  • регулярно просматривать журнал безопасности Windows , с цельюсвоевременного обнаружения несанкционированного доступа.

Несанкционированный доступ к архивному хранилищу БД

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

Для защиты архивного хранилища следует выполнять следующие действия:

  • Архивировать БД с помощью следующего запроса :

BACKUP DATABASE < database_name | @database_name_var>

With Password = ‘ p@ssw0rd ’

В этом случае невозможно восстановитьархив без пароля.

Для восстановления используетсяследующий запрос:

Restore DATABASE < database_name | @database_name_var>

With Password = ‘ p@ssw0rd ’

Примечание. Невозможно узнать используемый пароль через SQL — Trace .

  • Хранить архивы на диске с Файловой системой NTFS .
  • Включить функцию «Шифровать содержимое для защиты данных» для архивногохранилища БД.
  • Примечание. Для шифрованияиспользуется учетная запись, от которой запущены SQL -службы.
  • Выдать полные правадоступа к архивному хранилищу БД только учетной записи, под которой запускается SQL -служба.
  • Запустить аудит файлов, чтобы контролировать вседействия, зависящие от архивного хранилища БД.
  • Регулярно просматривать журнал безопасности Windows , с цельюсвоевременного обнаружения несанкционированного доступа.

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

Для DIRECTUM рекомендуется использоватьпакет управления системой DIRECTUM для SCOM 2007 R 2 ( System center operations manager 2007).

Обратите внимание на то, что любаясистема защиты/безопасности объекта зависит на 50% от системы аудита/мониторингаэтого объекта.

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