Файл: Блок 7. Организация защиты информации в современных условиях.doc

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 09.06.2021

Просмотров: 590

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

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

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

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


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

Какие существуют средства обес­печения безопасной работы базы данных?

Лидером здесь является компа­ния Oracle, выпустившая целый спектр передовых решений для своей основной системы управления база­ми данных - Oracle Enterprise Man­ager. Именно решения Oracle позво­ляют претворить в жизнь лозунг «Сделайте так, чтобы администратор баз данных не узнавал о финансовых результатах раньше генерального ди­ректора!», чего так давно ждали руко­водители ИТ.

Основным принципом является перенос идеологии распределения прав администраторов и доступа из приложений (IAMS) на уровень ба­зы данных. Этот продукт получил название Oracle Database Vault, и он стал доступен с последними верси­ями Oracle DB.

С точки зрения базы данных, по­является концепция защищенных областей (realms), в администриро­вании возникает несколько новых ролей: администратор Oracle DB Vault (настройка), администратор пользователей DB Vault, владельцы и пользователи защищенных обла­стей. Защищенные области работа­ют по аналогии с межсетевыми эк­ранами. Сами защищенные области работают с динамическими набора­ми правил, используют различные факторы, имеют собственный аудит и могут применяться к различным командам управления базой данных. Все это позволяет очень гибко и на­дежно настроить политики безопас­ности. Даже администратор базы и владелец объектов, включенных в защищенную область, может быть лишен доступа к «своим» объектам.

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

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


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

Наиболее же естественный и дол­гожданный пример - отсутствие возможности для администратора базы данных (или приложениям) видеть содержимое конфиденциаль­ных данных (рис. 1).


Стоит отметить, что помимо не­давно появившейся опции Database Vault, в базах данных Oracle имеется ряд давно существующих средств безопасности, существенно улучша­ющих возможности усиления защи­ты баз данных. Здесь и прозрачное шифрование на уровне столбцов (что позволяет шифровать и скры­вать чувствительные данные на уров­не хранения и доступа), и возможно­сти шифрования SQL-трафика, воз­можности управления метками до­ступа на уровне отдельных строк -Label Security (пользователи получают доступ к строкам на основе гиб­ких политик безопасности - рис. 2), и технология виртуальных таблиц (позволяющая «уточнять» запросы приложений, на уровне базы данных меняя SQL-запросы, и обеспечивая доступ только к «своим» данным).



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

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

50