| Документация Firebird → Документация по Firebird → Безопасность файлов и метаданных → Решение |
|
|
|
Существует единственный способ решить указанные ранее вопросы: размещайте базы данных и СУБД на Ваших собственных серверах, и предоставляйте к ним доступ клиентам, например, через интернет и т.п. Возможности терминальных серверов (terminal servers) (Windows или Linux/Unix) так же можно использовать для реализации таких требований.
Таким образом, у Вас есть контроль над базой данных, и Вы можете ограничивать доступ к различным функциям и структурам баз данных, используя имеющиеся в СУБД Firebird методы обеспечения безопасности (роли, привилегии и т.д.).
Стоит отметить, что и при таком подходе существуют некоторые трудности, если Ваша цель - защита структуры базы данных.
Различные библиотеки доступа к базе данных запрашивают метаданные, такие как первичные ключи, домены (domain) и т.п., чтобы облегчить процесс разработки клиентских приложений. Поэтому Вы можете открыть для себя факт, что Вы не можете предотвратить доступ пользователей к метаданным без прекращения предоставления приложению той информации, которая ему необходима.
Это означает, что Вам необходимо выбирать между разрешением открывать пользователям детали метаданных и пользоваться возможностями развитого интерфейса доступа к данным, и проведением значительного времени за разработкой приложений, которые используют менее совершенные библиотеки доступа к данным.
Существует вопрос клиентских приложений, которые, по сути, организуют «утечку» информации о структуре базы данных, с которой эти приложения работают. Очень редко можно встретить в приложениях, где главную роль играет база данных, интерфейс, не сильно отражающий детали структур, на основе которых он построен.
Некоторые детали можно скрыть использованием представлений (views) и хранимых процедур-выборок (selectable stored procedures), но создание такого функционала, чтобы скрыть структурную информацию, является упражнением в разочарованиях. Вероятнее всего, это бесполезное занятие, так как часть деталей строения базы данных все равно станет доступной публике, как бы Вы ни старались.
Перед тем, как продолжить обсуждение вопросов шифрования данных в СУБД Firebird, хочется обратить Ваше внимание на то, что пользователи могут защищать свои данные при помощи шифрования. Это не поможет разработчикам защитить свою информацию от легальных пользователей базы данных, но поможет удовлетворить требование заказчиков, желающих увеличить безопасность баз данных.
В некоторых (офисных) случаях бывает непрактичным размещать сервер с СУБД Firebird в реально безопасном окружении: в течение рабочего дня очень маловероятно, что кто-то сможет проникнуть в офис и получить доступ к компьютеру с целью копирования файлов базы данных (или украсть компьютер или жесткий диск, чтобы получить доступ к файлам позже). Однако в остальное время (ночью и/или в выходные) безопасность сервера может быть под вопросом, и это должно рассматриваться в конкретных случаях.
В то время, как СУБД Firebird не предоставляет встроенных средств шифрования данных, существует несколько замечательных продуктов, чтобы это делать. Вы можете установить программное обеспечение, которое создает защищенные тома (volumes) на Вашем компьютере, и Вы размещаете базы данных (и другие конфиденциальные данные) на этих томах. Когда компьютер выключен, все данные таких томов существуют в зашифрованном виде, и Вы не сможете получить к ним доступ без ключа. При загрузке компьютера Вам необходимо смонтировать (mount) защищенные тома и указать ключ для дешифрования, чтобы получить доступ к данным. Этот дополнителный, и, обязательно, собственноручный, шаг при запуске компьютера может быть неудобным, но он может обеспечить превосходную безопасность для «не сильно обслуживаемых» компьютерных систем.
Программным обеспечением с указанными функциями являются TrueCrypt (www.truecrypt.org), Bestcrypt от Jetico (www.jetico.com) и PGPDisk (www.pgpi.org/products/pgpdisk/ (заметьте, что эта ссылка ведет на старую бесплатную версию программы, а сайт содержит ссылки и на более новые платные версии продукта). Существуют и другие программные продукты... Последними двумя пользуюсь я сам.
Из-за вышеприведенных причин обычным среди пользователей является пожелание для будущих версий СУБД Firebird добавить возможность шифрования метаданных, результатов запросов пользователей к базе данных и даже базы данных целиком. Не будучи основным разработчиком СУБД, я не могу сказать категорично, что этого не случится. Однако суть вопроса заключается не в том, является шифрование практичным и/или полезным, а в том, обеспечат ли решение указанных проблем методы управления ключами шифрования.
Шифрование является хорошим настолько, насколько хорош закрытый ключ (secret key), используемый для дешифрования. Оно может быть хуже, но не лучше. Существует несколько замечательных алгоритмов шифрования, которые можно использовать. Когда используется хорошие алгоритмы шифрования, скорее всего, атаки будут предприниматься на поиски методов доступа к ключу, а не на само шифрование.
Давайте представим, как бы обстояли дела, если бы СУБД Firebird шифровала метаданные базы данных...
Перед тем, как СУБД сможет подключиться к базе данных, ей необходимо предоставить ключ для дешифрования данных. Предоставление ключа дешифрования пользователю было бы бессмысленным, так как это действие вернуло бы нас обратно к исходной проблеме. Тогда, скорее всего, при любом перезапуске сервера пользователям нужно звонить разработчику, чтобы он некоторым образом указал серверу ключ. Даже если бы это было практически реализуемо, такой подход вовсе не обязательно решил бы проблему. Например, заказчики могут устанавливать на свои серверы программы слежения, которые могут зафиксировать все нажатия клавиш.
Существуют решения предоставления ключа процессу дешифрования на основе некоторого оборудования. Но, опять же, это оборудование будет находиться у Ваших заказчиков/клиентов, и Вы не сможете предотвратить использование этого оборудования клиентом, чтобы получить доступ к базе даных с другого сервера баз данных, где известен пароль пользователя SYSDBA.
СУБД Firebird является проектом с открытым исходным кодом. Если бы возможности шифрования были встроены, или использовались бы дополнительные библиотеки шифрования с открытым исходным кодом (plug-ins), то для пользователя было бы вполне возможно создать свою версию СУБД или библиотеки, которая не только выполняла бы необходимые шифрование и дешифрование для доступа к базе данных, но и, например, сохраняла бы ключ в файл, или напрямую сохраняла незащищенные данные. Разработчик, не обладая контролем над сервером, не в состоянии ни определить, ни предотвратить такие действия.
Вы можете рассматривать вариант создания собственной версии СУБД Firebird, в которой ключ дешифрования будет скрыт в исполняемом файле. Однако существуют декомпиляторы. Не составит большого труда обнаружить ключ, просто сравнив декомпилированные версии Вашего исполнимого файла СУБД и обычной версии.
Существуют продукты для работы с базами данных, чья цель - обеспечение сильного шифрования. Возможно, шифрование и является сильным, но, если отсутствует хорошая система управления ключами (key management), то шифрование не достигнет желаемого эффекта. Это может лелеять в Вас веру в то, что Вы защищены, но Вам необходимо поближе познакомиться с системой управления ключами, чтобы выяснить, так ли это на самом деле.
Горькой правдой является то, что даже при однократной потере контроля над оборудованием, где производится шифрование и дешифрование, положение становится неясным. Если ключ дешифрования не может быть в полной безопасности, то даже хорошее шифрование становится немного больше, чем «безопасностью по неясности» (security by obscurity).
Некоторые просят шифровать данные базы данных, и, таким образом, хотят попытаться ограничить распространение данных. Их устраивает, если авторизованный пользователь имеет доступ к данным для их просмотра, но они бы хотели ограничить возможности таких пользователей передавать данные другим.
Представьте, что все ранее описанные проблемы с управлением ключами решены, так что пользователю нет смысла делать обычную копию базы данных. В этом случае пользователь может создать простую программу, которая будет извлекать интересующие его данные (используя легально установленный сервер) и записывать их в свой собственный файл или базу данных.
Думаю, что в будущем СУБД Firebird сможет обеспечивать некоторую систему опознавания (аутентификации) приложений, что позволит ограничить указанную форму извлечения данных, однако бОльшая часть проблем остается. Если Вы не имеете контроля над сервером, то не сможете предотвратить установку версии сервера, не требующую аутентификации.
Периодически люди предлагают исключить возможность доступа пользователя SYSDBA к объектам базы данных. Идея заключается в том, что при переносе базы данных на другой сервер, где пароль пользователя SYSDBA известен, знание пароля не поможет получить доступ к данным, потому что у пользователя SYSDBA к базе данных доступ будет запрещен. Некоторые сообщают об небольших успехах: создается роль SQL с именем SYSDBA, и эта роль не имеет прав для доступа к объектам базы данных.
Однако на самом деле это не решает проблему. Файл базы данных может быть исследован при помощи утилит просмотра двоичных файлов (hex viewer) или подобных утилит, что даст список доступных имен пользователей. Особенно полезной окажется информация о владельцах объектов базы данных. Как только станет известна эта информация, пользователи с найденными именами могут быть добавлены в базу данных пользователей нового сервера и использоваться напрямую.
Можно поступить еще проще, если использовать встроенную версию (embedded version) СУБД Firebird (см. далее), или скомпилировать Вашу собственную версию сервера Firebird, которая будет игнорировать органичения системы безопасности SQL.
Были предложения позволить изменять имя администратора SYSDBA на другое. Это может немного помочь противостоять прямым сетевым атакам для выяснения пароля администратора, так как при таких атаках придется подбирать не только пароль, но еще и имя, но это не поможет защитить систему от злоумышленника, имеющего прямой доступ к файлу базы данных.
При создании хранимой процедуры или триггера СУБД Firebird сохраняет практически полную копию исходного кода хранимой процедуры или триггера вместе с «откомпилированной» копией, называемой также BLR (Binary Language Representation). Откомпилированная копия выполняется сервером, исходный код им не используется.
Некоторые разработчики пытаются защитить по крайней мере некоторые из метаданных, удаляя исходный код из базы данных перед тем, как передавать базу данных заказчикам (простое прямое обновление соответствующих полей системных таблиц). Я не рекомендую удалять исходные коды по двум причинам...
BLR является довольно несложным преобразованием исходного кода. Не составит особого труда декодировать BLR обратно в понятное представление. Такое декодирование не будет содержать комментариев и форматирования, но обычно используемые операторы SQL не являются слишком сложными, так что это, скорее всего, не будет проблемой. Соответственно, защита, предоставляемая удалением исходного кода, не является значимой.
Исходный код может пригодиться для других целей. Можно сразу вносить поправки в базу данных: нет необходимости брать исходный код где-то еще, а потом не забыть снова удалить его. Исходный код также используется различными утилитами, такими как моя собственная программа DBak - альтернатива стандартной программе резервирования "gbak". Я пока не пытался создавать декодер для BLR, поэтому DBak рассчитывает на доступность исходных кодов, чтобы строить скрипты DDL (data definition language, язык определения данных), которые реконструируют базу данных.
|
| Документация Firebird → Документация по Firebird → Безопасность файлов и метаданных → Решение |