опять я, про InterBase. Часть 3, Средства разработки и компоненты.
Welcome.
Запись предыдущего вебинара (о UDF) пока не выложена, будет скоро.
Шифрование в InterBase существует в «трех частях»
Большинство, конечно, хочет просто «шифрования базы», чтобы ее не украли или чтобы не стащили информацию. Но к сожалению, опять же у большинства, представление о шифровании достаточно примитивное, и «зашифровать базу» это как бы как «зашифровать файл или архив». В реальности это не так, и требует определенных усилий по планированию и управлению.
Слова «а зачем оно нам такое, нам бы попроще» отметаются сразу, потому что простое шифрование так же просто вскрывается. В общем, давайте лучше посмотрим, как оно устроено.
Операционные системы клиента и сервера должны поддерживать SSL v3 и TLS v1. Сертификат и CA файлы должны быть сгенерированы заранее, быть в формате PEM, и размещены на компьютерах клиента (клиентский и публичный серверный ключ) и сервера (серверный ключ).
Строка коннекта при этом получается чудовищная (пример из OpGuide.pdf)
«localhost/gds_ssl?ssl=true?clientPassPhrase=clientkey?clientCertFile=c:InterBaseclientclient.pem?serverPublicFile=c:InterBaseclientserverCAfile.pem??:c:/db/database.ib»
На сервере должен быть файл ibss.config, в котором прописываются параметры для серверной стороны, и если честно, все это настолько страшно, что я не хочу дальше это описывать, и предоставлю вам самостоятельно дочитать об этом в OpGuide.pdf — там приведен максимум информации, включая примеры настроек и конфигураций (без проверки клиента, с проверкой, и т.п.).
Главное, что шифрование коннекта есть, оно настраивается, но требует определенных усилий по его настройке. Собственно, безопасность через тяп-ляп не обеспечивается.
Вот о шифровании БД (всей или столбцов) я расскажу подробнее, но в следующем посте.