(Возврат на основную страницу)
Бак Вуди
Мониторинг системы. Часть 2
Снижение риска возможной компрометации MS SQL Server 2000
Артур Фюллер
Использование хеш-ключей вместо строковых индексов в MS SQL Server
Лаурентиу Кристофор
Криптография в SQL Server 2005. Кому это нужно?
Мониторинг системы. Часть 2*
*См. Бак Вуди. Мониторинг системы. Часть 1 // SQL Server для администраторов. 2007. №12.
Снижение риска возможной компрометации MS SQL Server 2000
По материалам www.securitylab.ru
Внимание, данные уязвимости присутствуют в последнем сервис-паке для MS SQL Server 2000, так как их устранение может нарушить работы сторонних программ, рассчитанных на стандартную настройку СУБД.
Использование хеш-ключей вместо строковых индексов в MS SQL Server
Артур Фюллер (Arthur Fuller)
Вашему приложению может потребоваться индекс на основе длинной строки символов или, что еще хуже, конкатенации двух строк или строки и одного-двух целых чисел. Для небольшой таблицы вы можете не заметить какого-либо отрицательного влияния такого индекса. Но если предположить, что рассматриваемая таблица содержит 50 миллионов записей? Теперь вы не сможете не заметить воздействия, которое скажется как на требованиях к хранению, так и к производительности поиска. Однако вам не обязательно так поступать. Есть очень простая альтернатива, использующая то, что еще известно под названием хеш-блоков или хеш-ключей.
Что такое хеширование?
Говоря коротко, хеширование — это целочисленный результат алгоритма (известного как хешфункция), применяемого к заданной строке. Вы передаете в алгоритм строку, а на выходе получаете целое число. Если вы используете эффективную хешфункцию, то вероятность того, что две различных строки дадут одно и то же значение хешфункции, будет невелика. Такой случай известен под названием коллизии хеширования. Предположим, что вы применили к этой статье алгоритм хеширования, затем изменили один символ в статье и повторили алгоритм: он возвратил бы другое целое число.
Хеш-ключи в проекте базы данных
Как бы теперь грамотно применить хешключи в наших проектах баз данных? Предположим, что интересующая нас таблица (табл. 1) имеет следующие столбцы: «Имя столбца» и «Тип данных».
Составной индекс на обоих столбцах потреблял бы 50+50 символов на строку. Учитывая, что у нас 50 миллионов строк, это — проблема. Хешключ, построенный на тех же двух столбцах будет значительно меньше (4 байта на строку). Еще лучше, что мы не должны хранить сами хешключи — или более точно, мы должны сохранить их только однажды. Мы создаем вычисляемый столбец, формула которого дает нам хешключ этих двух столбцов. Теперь мы индексируем строку по хешключу и обходимся без индекса на двух упомянутых выше столбцах.
Основной процесс состоит в следующем:
• Пользователь (либо человек, либо приложение) запрашивает некоторые значения.
• Эти значения теперь преобразовываются в хешключ.
• Механизм базы данных выполняет поиск в индексе, построенном на хешстолбце, возвращая требуемую строку, или небольшой набор соответствующих строк.
В таблице с 50 миллионами строк, несомненно, будут возникать коллизии хеширования, но это не является проблемой. Возвращаемый набор строк будет значительно меньше, чем набор строк, которые пришлось бы запросить, чтобы найти точное совпадение с оригинальными поисковыми значениями. Вы локализуете небольшой набор строк, используя хешключ, и затем выполняете сравнение на точное совпадение с каждой строкой из этого набора. Поиск, основанный на целочисленном столбце, может оказаться существенно быстрее, чем поиск на базе строкового ключа большой длины, и еще быстрее, чем для составного ключа.
Криптография в SQL Server 2005. Кому это нужно?
Лаурентиу Кристофор (Laurentiu Cristofor)
Для тех, кто читал мои предыдущие статьи, вопрос в заголовке может показаться удивительным. Я хочу вас сразу успокоить: эта статья не про то, что криптография это бесполезная технология. Она про то, что криптография может помочь в решении не всех задач и уж точно не является каким-то общим универсальным решением любых проблем. Информация, которая содержится в статье, не привязана к какому-то конкретному продукту. Я хочу обсудить не то, как криптография реализована, например в SQL Server, а вопросы применения криптографии в целом. Ограничения, о которых я хочу рассказать — это ограничения стандартных криптографических методов, а не ограничения их реализации в каком-то конкретном продукте.
В последнее время я видел много попыток применения криптографии для решения проблем, где реально криптография не решает ничего. Поэтому в этой статье я решил рассказать, почему криптографию не надо считать какимто волшебным средством, которое достаточно применить к данным, чтобы сделать их защищенными. Для того чтобы понять, почему это так, мы должны понять несколько базовых фактов касающихся криптографии. Таких фактов не так много, но они действительно важные.
Для понимания статьи не требуется какихто глубоких знаний в области криптографии. Единственное, что вы должны знать о шифровании, это то, что оно преобразует данные в форму, в которой они теряют всю свою ценность, если не известен соответствующий дешифрующий ключ (decryption key). Алгоритмы шифрования, где ключ шифрования (encryption key) совпадает с дешифрующим ключом — называют симметричными алгоритмами шифрования. Если для шифрования и дешифрования используются разные ключи — то такие алгоритмы называют ассиметричными алгоритмами.
(Возврат на основную страницу)