AP> 1) Шифрование БД средствами сервера в настоящее время AP> это полнейшая бессмыслица. Не надо на это тратить время.
В корне не согласен. Видимо никогда вы не сталкивались с плагиатом AP> 2) При доступе к серверному процессу всё будет ломаться AP> на ура. Самое плохое(или хорошее :) что из за популярности AP> FB появятся тулы для автоматического взома. Смотря чем защищать и как. AP> 3) Исключением из п.2 безуспешно пытается стать Яап :-) AP> Ну чтож, дорогу осилит идущий. Но, технологии "в два клика" AP> не будет! Разработчику приложения (даже если LOA всё закроет) AP> придёт приложить много трудозатрат чтобы защитить базу от AP> взлома. Чего греха таить, среди программеров пишущих морды AP> к БД специалистов в этой области мало. Ну и последний AP> аргумент - если Yap станет очень популярен, то сразу AP> возникнет опасность создания универсальный крякеров. Автор AP> будет делать новые сборки и т.д. всё выдет на замкнутый AP> круг. Одна надежда на моего теску, он хоть что-то делает для нас AP> 4) Аргументы типа "стоимость взлома на порядок превысит AP> стоимость программы", "хакер затрахается это анализировать" AP> оставьте чтобы обрабатывать девочек на вечеринке! Мы не AP> в бирюльки играем, и не защищяет прогу от соседа Васи. AP> (Кто хочет защищаться от Васи, который двух команд на AP> асме связать не сможет, см п.3 и п.5) Да! Лучше хакеру не мешать! Это видимо девиз разработчиков Firebird :) AP> 5) Справедливый вопрос и зала: "как притивостоять краже БД?" AP> Чтож, не поленимся, ответим. Первым надо защитить серверный AP> процесс от негодяев (или бойцов информационного фронта)! AP> Далее надо защитить БД. Сразу слышны выкрики - "шифровать, AP> мать её!". Не обязательно. Если мы защитили серверный AP> процесс, то ничто не мешает защитить систему целиком. AP> Но допустим наконец, что базу выкрали тайно или явно люди AP> в масках. В последнем случае есть ещё метод паяльника, который AP> раскалывает любые пароли. Так что советую термитрную шашку AP> в системник. AP> Итак, как же противостоять тайной краже? Вот тут частично AP> шифрование может помочь. Но опять же при условии защищённости AP> серверного процесса. Но если защитить сервер то вероятность AP> кражи файла БД очень мала. Да и нафиг шифрование БД сервером? AP> Помещайте БД на шифрованный диск, архивируйте backup с паролем AP> и всё. Даже в этом случае есть потенциальная дыра во взломе AP> клиентского процесса, который легко доступен. Эту дыру тоже AP> должен затыкать программер базы. Опять двадцать пять! А что делать если нужно распостранить программу и базу данных среди 1000 своих клиентов без проблем с инсталяцией и учитывая что не везде есть администраторы и уж тем более из них только процентов 5 знает, что такое шифрованный диск! AP> 6) Защита от несанкцонированного копирования ПО. Расслабтесь, AP> в общем случае защититься от этого невозожно. Поэтому можно AP> особо не напрягаться. Для защиты от Васи - см. привязка софта к AP> железу/аппаратные ключи/серийные номера и проч. Еще лишний раз убеждаюсь, что у вас жизненное кредо не мешать хакерам :) Софт можно защитить с помощью аппаратного ключа а базу Firebird не получиться, пробовал уже. С наилучшими пожеланиями, Oleg Prosvetov.
