Несмотря на широкий диапазон компьютерных средств контроля, общий уровень защищенности СУБД определяется возможностями используемой операционной системы, поскольку работа этих двух компонентов тесно связана между собой. Обычно применяются перечисленные ниже типы средств контроля.
1) Авторизация пользователей.
2) Представления.
3) Резервное копирование и восстановление.
4) Поддержка целостности.
5) Шифрование.
6) Вспомогательные процедуры.
Авторизация– это предоставление прав (или привилегий), позволяющих их владельцу иметь законный доступ к системе или к ее объектам.
Средства авторизации пользователей могут быть встроены непосредственно в программное обеспечение и управлять не только предоставленными пользователям правами доступа к системе или объектам, но и набором операций, которые пользователи могут выполнять с каждым доступным ему объектом. Термин “владелец” в определении может представлять пользователя-человека или программу. Термин “объект” может представлять таблицу данных, представление, приложение, процедуру или любой другой объект, который может быть создан в рамках системы. В некоторых системах все предоставляемые субъекту права должны быть явно указаны для каждого из объектов, к которым этот субъект должен обращаться. Процесс авторизации включает аутентификацию субъектов, требующих получения доступа к объектам.
Аутентификация – механизм определения того, является ли пользователь тем, за кого себя выдает.
За предоставление пользователям доступа к компьютерной системе обычно отвечает системный администратор, в обязанности которого входит создание учетных записей пользователей. Каждому пользователю присваивается уникальный идентификатор, который используется операционной системой для определения того, кто есть кто. С каждым идентификатором связывается определенный пароль, выбираемый пользователем и известный операционной системе. При регистрации пользователь должен предоставлять системе свой пароль для аутентификации.
Подобная процедура позволяет организовать контролируемый доступ к компьютерной системе, но не обязательно предоставляет право доступа к СУБД или иной прикладной программе. Для получения пользователем права доступа к СУБД может использоваться отдельная подобная процедура. Ответственность за предоставлен прав доступа к СУБД обычно несет администратор базы данных (АБД), в обязанности которого входит создание индивидуальных идентификаторов пользователей, на этот раз уже в среде самой СУБД. Каждый из идентификаторов пользователей СУБД также связывается с паролем, который должен быть известен только данному пользователю. Этот пароль будет использоваться подпрограммами СУБД для идентификации данного пользователя.
Некоторые СУБД поддерживает списки разрешенных идентификаторов пользователей и связанных с ними паролей, отличающиеся от аналогичного списка, поддерживаемого ОС. Другие типы СУБД поддерживают списки, элементы которых приведены в соответствие существующим спискам пользователей операционной системы и выполняют регистрацию исходя из текущего идентификатора пользователя, указанного им при регистрации в системе. Это предотвращает попытки пользователей зарегистрироваться в среде СУБД под идентификатором, отличным от того, который они использовали при регистрации в системе.
Использование паролей является наиболее распространенным методом аутентификации пользователей. Однако этот подход не дает абсолютной гарантии, что данный пользователь является именно тем, за кого себя выдает.
Как только пользователь получит право доступа к СУБД, ему могут автоматически предоставляться различные другие привилегии, связанные с его идентификатором. В частности, эти привилегии могут включать разрешение на доступ к определенным базам данных, таблицам, представлениям и индексам или же право запуска различных утилит СУБД. Некоторые типы СУБД функционируют как закрытые системы, поэтому пользователям помимо разрешения на доступ к самой СУБД потребуется иметь отдельные разрешения и на доступ к конкретным ее объектам. Эти разрешения выдаются либо АБД, либо владельцами определенных объектов системы. В противоположность этому, открытые системы по умолчанию предоставляют авторизированным пользователям полный доступ ко всем объектам базы данных. В этом случае привилегии устанавливаются посредством явной отмены тех или иных прав конкретных пользователей. Типы привилегий, которые могут быть предоставлены авторизированным субъектам, включают, например, право доступа к указанным базам данных, право выборки данных, право создания таблиц и других объектов.
Некоторыми объектами в среде СУБД владеет сама СУБД. Обычно это владение организуется посредством использования специального идентификатора особого суперпользователя – например, с именем Database Administrator. Как правило, владение некоторым объектом предоставляет его владельцу весь возможный набор привилегий в отношении этого объекта. Это правило применяется ко всем авторизированным пользователям, получающим права владения определенными объектами. Любой вновь созданный объект автоматически передается во владение его создателю, который и получает весь возможный набор привилегий для данного объекта. Тем не менее, хотя пользователь может быть владельцем некоторого представления, единственной привилегией, которая будет предоставлена ему в отношении этого объекта, может оказаться право выборки данных из этого представления. Принадлежащие владельцу привилегии могут быть переданы им другим авторизированным пользователям. В некоторых типах СУБД, всякий раз, когда пользователю предоставляется определенная привилегия, дополнительно может указываться, передается ли ему право предоставлять эту привилегию другим пользователям (уже от имени этого пользователя). Естественно, что в этом случае СУБД должна контролировать всю цепочку предоставления привилегий пользователям, с указанием того, кто именно ее предоставил, что позволит поддерживать корректность всего набора установленных в системе привилегий. В частности, эта информация будет необходима в случае отмены предоставленных ранее привилегий для организации каскадного распространения вносимых изменений среди цепочки пользователей.
Если СУБД поддерживает несколько различных типов идентификаторов авторизации, с каждым из существующих типов могут быть связаны различные приоритеты. В частности, если СУБД поддерживает использование идентификаторов как отдельных пользователей, так и их групп, то, как правило, идентификатор пользователя будет иметь более высокий приоритет, чем идентификатор группы.
Очень важно освоить все механизмы авторизации и другие средства защиты, предоставляемые целевой СУБД. Особенно это важно для тех систем, в которых существуют различные типы идентификаторов и допускается передача права присвоения привилегий. Это позволит корректно выбирать типы привилегий, предоставляемых отдельным пользователям, исходя из исполняемых ими обязанностей и набора используемых прикладных программ.
Представление – это динамический результат одной или нескольких реляционных операций с базовыми отношениями с целью создания некоторого иного отношения. Представление является виртуальным отношением, которого реально в базе данных не существует, но которое создается по требованию отдельного пользователя в момент поступления этого требования.
Механизм представления является мощным и гибким инструментом организации защиты данных, позволяющим скрыть от определенных пользователей некоторые части базы данных. В результате пользователи не будут иметь никаких сведений о существовании любых атрибутов или строк данных, которые недоступны через представления, находящиеся в их распоряжении. Представление может быть определено на базе нескольких таблиц, после чего пользователю будут предоставлены необходимые привилегии доступа к этому представлению, но не к базовым таблицам. В данном случае использование представления являет собой более жесткий механизм контроля доступа, чем обычное предоставление пользователю тех или иных прав доступа к базовым таблицам.
Резервное копирование–периодически выполняемая процедура получения копии базы данных и ее файла журнала (а также, возможно, программ) на носителе, сохраняемом отдельно от системы.
Средства резервного копирования позволяют восстанавливать базу данных в случае ее разрушения. Рекомендуется создавать резервные копии базы данных и ее файла журнала с некоторой установленной периодичностью и организовывать хранение созданных копий в местах, обеспеченных необходимой защитой. В случае отказа, в результате которого база данных становится непригодной для дальнейшей эксплуатации, резервная копия и зафиксированная в файле журнала оперативная информация используются для восстановления базы данных до последнего согласованного состояния.
Ведение журнала – это процедура создания и обслуживания файла журнала, содержащего сведения обо всех изменениях, внесенных в базу данных с момента создания последней резервной копии, и предназначенного для обеспечения эффективного восстановления системы в случае ее отказа.
Если в отказавшей системе функция ведения системного журнала не использовалась, базу данных можно будет восстановить только до того состояния, которое было зафиксировано в последней созданной резервной копии. Все изменения, которые были внесены в базу данных после создания последней резервной копии, окажутся потерянными.
Контрольная точка это момент синхронизации между состоянием базы данных и состоянием журнала выполнения транзакций. В этот момент все 6yфера принудительно выгружаются на устройства вторичной памяти.
Механизм создания контрольных точек используется совместно с ведением системного журнала, что повышает эффективность процесса восстановления. В момент создания контрольной точки СУБД выполняет действия обеспечивающие запись на диск всех данных, хранившихся в основной памяти машины, а также помещение в файл журнала специальной записи контрольной точки.
Средства поддержки целостности данных также вносят определенный вклад в общую защищенность базы данных, поскольку их назначением является предотвращение перехода данных в несогласованное состояние, а значит, и предотвращение угрозы получения ошибочных или некорректных результатов расчетов.
Шифрование – кодирование данных с использованием специального алгоритма, в результате чего данные становятся недоступными для чтения любой программой, не имеющей ключа дешифрования.
Если в системе с базой данных содержится весьма важная конфиденциальная информация, то имеет смысл закодировать ее с целью предупреждения возможной угрозы несанкционированного доступа с внешней стороны (по отношению к СУБД). Некоторые СУБД включают средства шифрования, предназначенные для использования в подобных целях. Подпрограммы таких СУБД обеспечивают санкционированный доступ к данным (после их декодирования), хотя этосвязано с некоторым снижением производительности, вызванным необходимостью перекодировки. Шифрование также может использоваться для защиты данных при их передаче по линиям связи. Существует множество различных технологий кодирования данных с целью сокрытия передаваемой информации, одни из них называют необратимыми, а другие обратимыми. Необратимые методы, как и следует из их названия, не позволяют установить исходные данные; хотя последние могут использоваться для сбора достоверной статистической информации. Обратимые технологии используются чаще. Для организации защищенной передачи данных по незащищенным сетям должны использоваться системы шифрования, включающие следующие компоненты:
1) ключ шифрования, предназначенный для шифрования исходных данных (обычного текста);
2) алгоритм шифрования, который описывает, как с помощью ключа шифрования преобразовать обычный текст в шифротекст;
3) ключ дешифрования, предназначенный для дешифрования шифротекста;
4) алгоритм дешифрования, который описывает, как с помощью ключа дешифрования преобразовать шифротекст в исходный обычный текст.
Некоторые системы шифрования, называемые симметричными, используют один и тот же ключ как для шифрования, так и для дешифрования, при этом предполагается наличие защищенных линий связи, предназначенных для обмена ключами. Однако большинство пользователей не имеют доступа к защищенным линиям связи, поэтому для получения надежной защиты длина ключа должна быть не меньше длины самого сообщения. Тем не менее большинство эксплуатируемых систем построено на использовании ключей, которые короче самих сообщений. Одна из распространенных систем шифрования называется DES (Data Encryption Standard) – в ней используется стандартный алгоритм шифрования, разработанный фирмой IBM. В этой схеме для шифрования и дешифрования используется один и тот же ключ, который должен храниться в секрете, хотя сам алгоритм шифрования не является секретным. Этот алгоритм предусматривает преобразование каждого 64-битового блока обычного текста с использованием 56-битового ключа шифрования. В системе шифрования POP (Pretty Good Privacy) используется 128-битовый симметричный алгоритм, применяемый для шифрования блоков отсылаемых данных.
Другой тип систем шифрования предусматривает использование для шифровки и дешифровки сообщений различных ключей – подобные системы принято называть несимметричными. Примером такой системы является система с открытым ключом, предусматривающая использование двух ключей, один из которых является открытым, а другой хранится в секрете. Алгоритм шифрования также может быть открытым, поэтому любой пользователь, желающий направить владельцу ключей зашифрованное сообщение, может использовать его открытый ключ и соответствующий алгоритм шифрования. Однако дешифровать данное сообщение сможет только тот, кто знает парный закрытый ключ шифрования. Системы шифрования с открытым ключом могут также использоваться для отправки вместе с сообщением “цифровой подписи”, подтверждающей, что данное сообщение было действительно отправлено владельцем открытого ключа. Наиболее популярной несимметричной системой шифрования является RSA (это инициалы трех разработчиков данного алгоритма). Как правило, симметричные алгоритмы являются более быстродействующими, чем несимметричные, однако на практике обе схемы часто применяются совместно, когда алгоритм с открытым ключом используется для шифрования случайным образом сгенерированного ключа шифрования, а уже этот случайный ключ – для шифровки самого сообщения с применением некоторого симметричного алгоритма.
Вспомогательные процедуры. Хотя выше уже были описаны различные механизмы, которые могут использоваться для защиты данных в среде СУБД, сами по себе они не гарантируют необходимого уровня защищенности и могут оказаться неэффективными в случае не правильного применения или управления. По этой причине различные вспомогательные процедуры, должны использоваться совместно с описанными выше механизмами защиты.
Одно из назначений процедуры аудита состоит в проверке того, все ли предусмотренные средства управления задействованы и соответствует ли уровень защищенности установленным требованиям. В ходе выполнения инспекции, аудиторы могут ознакомиться с используемыми ручными процедурами, обследовать компьютерные системы и проверить состояние всей имеющейся документации на данную систему.
Для определения активности использования базы данных анализируются ее файлы журнала. Эти же источники могут использоваться для выявления любых необычных действий в системе. Регулярное проведение аудиторских проверок, дополненное постоянным контролем содержимого файлов журнала с целью выявления ненормальной активности в системе, очень часто позволяет своевременно обнаружить и пресечь любые попытки нарушения защиты.
Установка нового прикладного программного обеспечения. Новые приложения обязательно следует тщательно протестировать, прежде чем принимать решение об их развертывании и передаче в эксплуатацию. Если уровень тестирования будет недостаточным, существенно возрастает риск разрушения базы данных. Следует считать хорошей практикой выполнение резервного копирования базы данных непосредственно перед сдачей нового программного обеспечения в эксплуатацию. Кроме того, в первый период эксплуатации нового приложения обязательно следует организовать тщательное наблюдение за функционированием системы. Отдельным вопросом, который должен быть согласован со сторонними разработчиками программ, является право собственности на разработанное ими программное обеспечение. Данная проблема должна быть решена еще до начала разработки, причем это особенно важно в тех случаях, когда существует вероятность, что впоследствии организации обязательно потребуется вносить изменения в создаваемые приложения. Риск, связанный с подобной ситуацией состоит в том, что организация не будет иметь юридического права использовать данное программное обеспечение или модернизировать его. Потенциально подобная ситуация угрожает организации серьезными потерями.
Установка или модернизация системного программного обеспечения. В обязанности АБД входит выполнение модернизации программного обеспечения СУБД при поступлении от разработчика очередных пакетов изменений. В некоторых случаях вносимые изменения оказываются совсем незначительными и касаются небольшой части модулей системы. Однако возможны ситуации, когда требуется полная ревизия всей установленной системы. Никакие изменения и модернизации ни в коем случае не должны вноситься в систему без предварительной оценки их возможного влияния на имеющиеся данные и программное обеспечение.
Результатом ознакомления с сопроводительной документацией пакета должен быть план действий по его установке. Главная задача АБД — обеспечить полный и безболезненный переход от старой версии системы к новой.
