Шифрование на SQL Server (ru-RU)

 

Шифрование на SQL Server

SQL Server Технические статьи

** **

Писатель:                       Джон Хикс, корпорация Майкрософт.

** **

Технические рецензенты:        Рауль Гарсия, корпорация Майкрософт.

                                      Сун Hsueh, корпорация Майкрософт.

                                      Ил Сунг ли, корпорация Майкрософт.

Редактор:                       Диана Штейнмец

** **

Опубликовано: Июль 2008

Относится К: SQL Server 2005 и SQL Server 2008

Предложенная статья является машинным переводом оригинала.

** **

Резюме: Хотя шифрование обеспечивает SQL Server с мощными инструментами для шифрование и проверки, они часто не слишком хорошо изучены. Это может привести к плохой или неполными реализациями. Этот документ представляет собой краткий обзор криптографических функций и рассматривается, каким образом это относится к аутентификации, подписанные процедур, разрешения и шифрование. Потому что целевой аудитории специалистов по базам данных и не обязательно экспертов по вопросам безопасности, основное внимание уделяется практических путей использования криптографии в SQL Server.

Авторское право

Информация, содержащаяся в настоящем документе представляет текущее представление корпорации Майкрософт по обсуждаемым на дату публикации.  Поскольку корпорация Майкрософт должна реагировать на меняющиеся условия рынка, он не должен толковаться как обязательство корпорации Майкрософт, и корпорация Майкрософт не может гарантировать точность пр��дставленных сведений после даты публикации.

** **

Этот документ является только в информационных целях.  КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ДАЕТ НИКАКИХ ГАРАНТИЙ, ЭКСПРЕСС, ПОДРАЗУМЕВАЕМЫХ ИЛИ УСТАНОВЛЕННЫХ ЗАКОНОМ, В ОТНОШЕНИИ ИНФОРМАЦИИ В НАСТОЯЩЕМ ДОКУМЕНТЕ.

** **

Ответственность за соблюдение всех авторских прав и прав на интеллектуальную собственность целиком и полностью несет пользователь.  Без ограничения авторских прав ни одна из частей этого документа не может быть воспроизведена, сохранена или использована в системах поиска либо передана в любой форме, любыми способами (электронными, механическими, в виде фотокопии, в виде записи или любыми другими) и для любых целей без письменного разрешения корпорации Майкрософт.

** **

Корпорация Майкрософт может иметь патенты, патентные заявки, охраняемые товарные знаки, авторские или другие права на интеллектуальную собственность применительно к содержимому этого документа.  За исключением, явно указанных в письменном лицензионном соглашении корпорации Майкрософт, предоставление данного документа не дает вам какой-либо лицензии на эти патенты, товарные знаки, авторские права или других видов интеллектуальной свойство.

** **

Ó2008 Корпорация Майкрософт.  Все права защищены.

** **

Microsoft, SQL Server, Visual Studio, Vista, Windows и Windows Server являются товарными знаками или зарегистрированными товарными знаками корпорации Майкрософт в США и других странах.

** **

Названия реальных компаний и продуктов, упомянутые здесь могут быть торговыми марками их соответствующих владельцев.

 
. 17Введение 

Часто кажется, что шифрование используется для решения проблем, для которых это не действительно решение. Даже в условиях целесообразно криптографические решения, это не всегда вариант , что она должна быть развернута в рамках компонента database engine. Настоящий документ содержит руководящие указания по использованию криптографические возможности вообще, и затем, как она будет осуществляться в Microsoft® SQL Server®.

Если вы сообщите пользователям, что защищен криптографически свои данные, вы неявно заверяет их, их информация защищена от нескольких видов угроз. Шифрование-это мир параноик (см., например, Брюс Шнайер плодотворном книга Прикладная криптография). Если данные действительно должна быть защищена, построить ваши системы при планировании на аудит безопасности наиболее параноидальный лицом, вы можете себе представить. Это довольно легко для создания неполной криптографические решения. Если вы планируете обезопасить ваши данные "немного", то лучше не представляют для ваших пользователей, их информация защищена на всех.

Просто потому, что вам нужно криптографически защитить ваши данные не обязательно означает компонент database engine — лучшее место, чтобы сделать это, особенно когда масштабируемость является предметом озабоченности. Поскольку шифрование является очень CPU интенсивные, может оказаться более разумным ограничить базу данных для хранения данных и оставить криптографической обработке компонентами восходящего потока данных — как средний уровень — как они легче поддаются масштаба.

SQL Server позволяет надежно защитить ваши данные — безусловно, а также ее конкурентов — и этот документ показывает вам как.

Общие сведения о криптографии

За все криптографические обработки являются по существу три функции:

• Обработка симметричный ключ
• Обработка асимметричный ключ
• Одностороннее хэширование

Симметричный ключ обработка

Наиболее известных примеров симметричные ключи являются производные от пароля. Когда документ шифруется с использованием пароля, необходимо указать точно же пароль для расшифровки документа. Вот почему функциональность называется симметричный. Естественно можно также использовать пароли для проверки личности. До 70-х годов симметричные ключи были единственный средство в набор средств криптографии.

Недостатком симметричных ключей является именно их симметрии. Если я хочу другого пользователя, чтобы иметь возможность расшифровать документ, который я зашифрованный, должен каким-то образом сообщить этот ключ ему или ей. Это представляет собой проблему: Если у меня есть безопасный способ отправить ключ, который будет также безопасный способ отправить документ; Если безопасный канал (который является, почему я зашифрованный документ) не я, я также не имеют безопасный способ сообщить ключ. (Естественно, есть обходные пути, например, общение ключ на другой канал с принципом презумпции, что любой пользователь, имеющий доступ к одному каналу не имеют доступа ко второму).

Аналогичным образом симметричные ключи являются проблематичными для проверки личности из-за их симметрии. Это точки «фишинг» сообщения электронной почты. Ввод пароля для проверки пользователя позволяет проверяющему знать пароль, который недобросовестных хост может использовать олицетворение этого пользователя в других местах.

Самая распространенная проблема с ключами от паролей и фразы пароля является, что они являются предсказуемыми, или даже угадываемых последовательности символов. Они не являются действительно случайные. Ключи, полученные от паролей являются только же сильна, как пароль, используемый для генерации. Эти ключи являются гораздо более уязвимы для атак «словарь», в которых систематически оценивать известных слов, письмо последовательности и комбинации.

Гораздо более безопасным ключ , который генерируется случайным образом. До сих пор они теоретически уязвимы к перебором, который запускается под систематически угадать значения ключ . Чем больше размер ключ , больше усилий требуется для установки такого нападения, как есть больше значений угадать. Общие размеры ключ сегодня являются достаточно крупными, что крайне маловероятно, что доступные вычислительные мощности сейчас или в обозримом будущем сможет успеш��о получить значение ключ в течение всего срока полезной службы данных (учитывая вечности, конечно же, это удастся в определенный момент). Обратите внимание, что ключ быть столь сильным, как указывает длину ключ , он должен быть действительно случайные.

В SQL Server 2005 и 2008 SymmetricKey объект является производным от пароль, если представлено "Контрольная фраза" аргумент; в противном случае ключ является случайным.

Симметричные ключи имеют два важных преимущества:

• Они могут быть получены от паролей, которые могут помнить людей или йey может быть большим, случайных значений, предлагая максимальной безопасности.
• Алгоритмы, как правило, очень быстро по сравнению с асимметричных алгоритмов.

Это не незначительные преимущества.

Асимметричные ключи

Асимметричные ключи всегда существуют как пары ключ — ключи могут быть связаны как два основных факторов еще очень большое число, через дискретного возведения или эллиптических кривых в конечное поле— и информации, кинулись на один ключ могут только восстанавливали другой ключ. Вы не можете откат криптографической операции с тем же ключ , который был использован для делать операции; необходимо использовать другой ключ. Один из ключей элементов определяется как открытый ключ и другой — закрытый ключ.

Асимметричные ключи обойти проблему того, чтобы общаться ключ к получателю. Например, если вы хотите иметь возможность получать зашифрованное сообщение от Боба, не важно если Джейн, Ширли и Фред могут также шифровать сообщения и отправлять их вам, это только вопрос, что только вы можно расшифровать сообщения. В этой схеме открытый ключ может быть выдано для любого и каждого; закрытый ключ не должен быть общим с кем-либо.

Эта операция, скремблирования сообщения с помощью открытого ключназывается шифрование. Любой пользователь с доступом к открытый ключ может создать шифрованное сообщение, но только владельцем закрытого ключ может расшифровать и прочитать.

Обратная операция, скремблирования ДИД с моей закрытый ключ, позволяет любому пользователю доступ к моей публичный ключ для проверки, что информация была обработана, мой закрытый ключ. Это называется подпись. Только лицо, имеющее доступ к закрытый ключ может кодировать сообщение, таким образом, что открытый ключ может расшифровать его. Подпись доказывает, что владелец закрытый ключ имеют доступ к соответствующее сообщение, и — самое главное — что сообщение не изменилась с тех пор.

Когда большинство людей думают о криптографии, они склонны думать о шифрование сначала. Тем не менее, возможно более значительную функциональность, включаемые подписей потому, что она может справиться с проблемами с проверки личности и обеспечить, таким образом, чтобы публично проверке, что подписанного содержимого не изменяется после к подписанию.

Существуют три трудности с асимметричного ключ криптографии. Первые два параметра являются обратное преимущества симметричных ключей:

• Ключи имеют очень большой размер и не может помнить людей (что также справедливо в отношении случайных симметричных ключей), хотя они могут быть внедренными на ключ карты и такие.
• Ключи требуют значительных вычислительных ресурсов надо использовать.
• Эти криптографические операции уязвимы для достижения в математических алгоритмов или прорыв вычислительных авансов.

Асимметричные ключи строятся на тот факт, что некоторые математические операции являются относительно легко выполнить, но трудно повернуть вспять. К примеру это гораздо проще для умножения простых чисел чем фактор результат. Асимметричные ключи являются достаточно крупными, что вычислительной мощности, необходимые для расчета соотношения между числом (учитывая все глобальные вычислительные мощности, предполагается быть доступны в пределах срока защиты) значительно превышает срок полезной службы данных. Аванс в математической логике или вычислительной мощности (например, квантовых вычислений?) может производить расчета отношения ключ , достаточно эффективной для того, чтобы разорвать эту защиту.

SQL Server реализует асимметричных ключей либо с AsymmetricKey объектов или сертификат объектов. Как использовать тот же асимметричный алгоритм RSA и оба могут быть созданы в SQL Server или импортированы из файла ключ , но только сертификаты могут быть экспортированы в SQL Server. Сертификаты могут или не могут содержать закрытых ключей (сертификаты, не содержащие закрытый ключ не может использоваться для создания подписи или расшифровки данных). На практике сертификат объекты всегда предпочтительнее AsymmetricKey объектов. (Единственным исключением является для прозрачное шифрование с оборудованием расширенного управления ключами. Это требует асимметричный ключ).

Реализация SQL Server обсуждается более подробно далее в этом документе.

Криптографический хеш

A хэш — это число, создается путем считывания содержимого документа или сообщения. Различные сообщения должен создавать различные хэш-значения, но то же самое сообщение вызывает алгоритма для создания же хэш-значение.

Хороший алгоритм хеширования имеет эти свойства:

• Особенно чувствителен к небольшие изменения в документе. Незначительные изменения в документ будет генерировать весьма иной результат хеширования.
• Невозможно отменить. Будет абсолютно никакого способа определить, что изменилось в документе или узнать что-либо о содержании документа путем изучения значения хэш-функции. По этой причине хеширования часто называют одностороннее хэширование.
• Это очень эффективно. Алгоритм хеширования может потребоваться пройти очень большими файлами, поэтому эффективнее этот алгоритм, тем лучше.

Естественно один по-прежнему можно определить содержание документа от хэш-значение, правильно угадать исходное содержание и хеширования с тот же самый алгоритм; хэш-значение совпадения указывает весьма высокая вероятность того, что исходное содержание правильно догадались. Это возможно для двух различных сообщений для создания же хэш-код, но это крайне малове��оятным, что два случайно выбранных сообщений сделают это.

Гибридные подходы

Потому что работа с асимметричных ключей требуют значительных объемов вычислений так дорого (по примерно на порядок величины над симметричных ключей), real-life реализации обычно используют несколько методов для улучшения производительности операции.

В вариант подписи вы можете создать хэш-значение для подписания документа. Закрытый ключ используется для шифрования только хэш-значение, которая включена в документ подписи. Чтобы проверить подпись, получатель должны только экспортирована документ таким же образом и расшифровывать включены хэш-значение с помощью открытого ключ. Если два хэш-значения совпадают, подпись действительна. Сам документ не кинулись и легко доступны для тех, кто читать.

Кроме того документ может быть зашифрован с помощью открытого ключ, но это требует интенсивных вычислительных ресурсов. Общее решение является для создания крупных, случайные симметричный ключ и зашифровать документ, с использованием которой. Это использует гораздо большей эффективности алгоритмов симметричного ключ . Затем этот ключ шифруется с помощью открытого ключ , таким образом, чтобы только предполагаемый получатель может получить доступ к ключ. Для расшифровки документа, владелец закрытый ключ сначала дешифруется частью документа, содержащего случайная шифрование ключи затем использует этот ключ для расшифровки сам документ.

Этот подход сочетает в себе преимущества асимметричных ключей при сведении к минимуму накладные расходы обработки — один из главных недостатков криптографии открытого ключ . SQL Server 2005 и 2008 поддержать эти обычные реализации несколько прямолинейно, путем автоматической генерации большого, случайные симметричный ключ и позволяет шифровать с сертификат.

Это также не редкость для реализации подпись и шифрование, но она может быть менее распространены, чем можно предположить, люди новой криптографии. Путем создания подписанного документа, являющегося как и зашифрован, отправитель может быть уверены что только получатель сможет прочитать его, в то время как получателя могут быть уверены, что он действительно пришли от отправителя.

Сертификаты и инфраструктура открытых ключей

Технически действительная подпись только заверяет меня что владельца закрытого ключ один раз имеют доступ к документу, который подписывается. Важно отметить является, что владелец закрытый ключ может быть кто-нибудь. Технически я мог бы подписать цифровой подписью документ совершения вашей компании, чтобы купить продукт от моей компании. По этой причине подпись является бесполезным, если мы можем проверить личность владельца закрытого ключ.

Та же проблема идентификации также создает уязвимость шифрование , под названием man-in--middle нападения. Предположим, что вы тайно осуществляют наблюдение за террористические ячейка , шифрует сообщения с использованием асимметричных ключей. Вы обнаружите, что новая террористической ячейка хочет отправить зашифрованную информацию к этой контролируемой ячейка. Чтобы сделать это, новых террористов просить открытый ключ. С быстро DNS hack вы перехватить открытый ключ ответ и вместо этого предоставить свой открытый ключ . Когда прибывает сообщение от новых террористических, вы перехватить его и легко расшифровать его, используя ваш закрытый ключ. Чтобы избежать обнаружения, вы повторно зашифровать документ, используя открытый ключ из целевой ячейкаи перенаправляют сообщение террористической ячейка. До тех пор, как вы в состоянии надежно перехватывать сообщения, ваша деятельность не поддающихся обнаружению. В этом случае ты «человек посередине». Обратите внимание, что человек в середине нападения должны быть на месте в начале разговора с тем чтобы заменить открытый ключ. Если отправитель уже правильный открытый ключ, man-in--middle нападение является импотент.

Центры сертификации

Благодаря проверке связь между ваш публичный ключ и вашу личность, вы защищены от man-in--middle атак и поддельных подписей. Нецифровые мира эта личность (очень плохо) решается с помощью нотариуса для подписей. Нотариус обеспечивает уверенность, что физический, письменной подписи был создан определенным пользователем, и проверить личность этого человека. Цифровой эквивалент к нотариусу цепи доверия из одной или нескольких сертификат власти.

Цепи доверия, скорее как сертификации человеческого «друг другу». Если кто-то имя Джо называет себя для меня и я не знаю Джо, Джо можно сообщить, что его друг Бетти однозначно будет поручиться за его и его личность. Тем не менее я не знаю Бетти либо. Бетти, однако, имеет возможность заручиться Тед поручиться за ее достоверность. Я знаю, Тед, и я верю ему. Если Тед подтверждает, что Бетти является надежным, я могу использовать Бетти сертификации для проверки Джо.

сертификат называется корневых. Это Организации, которые предоставляют общественности сертификации самобытности и открытый ключ. Базовый орган делает это путем подписания вашей организации общественной ключ и идентичность информации с их собственный закрытый ключ. Этот сертификат действителен в течение определенного периода времени. Эти власти также управлять список публичных отзыва в событие , что-то ошибочно был засертифицирован или частный ключ был скомпрометирован. Любой, кто доверяет открытый ключ корневого центра будет автоматически принимать их подписанных сертификатов как правильной проверки личности за открытый ключ.

 

Рисунок 3: Цепочки доверия

Что мешает вам от создания собственного корневого центра сертификации и сертификации собственных поддельных подписей? Ну ничего. Кроме того по умолчанию, ни компьютер будет доверять ваши сертификаты. Чтобы увидеть, что корень власти трестов ваш компьютер, запустите certmgr.msc (введите в командной строке или воспользоваться диалоговым окном Run). Чтобы узнать больше, посетите Создание, просмотр и управление сертификатами на Microsoft Developer Network (MSDN).

Если ваша организация позволяет отдельным лицам подписать документы или отправлять зашифрованные сообщения, требуется большое количество сертификатов. Каждый, кто имеет право подписать или получающие шифрованные сообщения должны иметь его или ее собственной пары различных ключ (на самом деле, пару разных ключ для каждого набор функциональности). Как это не реально Имейте каждого человека, заверенные является корневым центром, организация реализует свой собственный сертификат сертификации. Как правило этот орган локальный сертификат заверен является корневым центром; в других случаях орган локальный сертификат является доверенным корневым центром через групповую политику. На крупном предприятии сертификат может даже проверить подлинность сертификат . Сертификаты, выданные центром сертификат включают в себя подписи всех родителей до корне��ого центра. Эта цепочка доверия действительно до тех пор, пока все подписи являются действительными, происхождение является полным и первый-уровень сертификации органом является корневым центром.

Действительный сертификат файл, содержащий цепочку доверия, которое в конечном итоге преобразуется доверенным центром будет неявно доверенным. Так как файл сертификат содержит все открытые ключи в цепи доверия, не стоит обращаться все из центров сертификат . Файлы сертификатов также имеют цель обозначения (например, электронной почты шифрование, аутентификацию и доверие), даты истечения срока действия и другие свойства.

Интересно, что нельзя настроить Windows Certificate Authority Архивировать закрытый ключ подписи сертификат. Если произойдет сбой жесткого диска пользователя, он или она может быть в состоянии продолжать читать зашифрованные сообщения путем подключения к сертификат и получении ранее выданных сертификатов. Очень важно уполномоченным администратором может быть также удалось получить эти архивные закрытых ключей, если это станет необходимым для проверки пользователя корреспонденции. Однако тот факт, что Центр сертификат не содержит закрытого ключ обеспечивает "неотказа" для подписей. Это просто не же администратор может получить подписи сертификат из сертификат полномочий и знак сообщений, как будто бы они исходили от другого пользователя. Это можно сделать только владельцем закрытого ключ . Если оригинал подписи сертификат теряется, она не может быть заменен сертификат Однако Центр сертификат может выдавать новый подпись сертификат, даже в то время, как старый подписей, остаются в силе. Короче говоря один пользователь может быть связан с несколько подписей.

Аннулирование

Если компрометации закрытого ключ сертификат, выдающий можно добавить его в свой список отзыва сертификатов (CRL). В идеале подписи должны проверяться CRL выдающий прежде чем предполагается быть действительными. Обратите внимание, что сертификаты и списки отзыва сертификатов являются оба времени чувствительны, поэтому он может иметь решающее значение для сравнения время сообщения с сроки действия в сертификат или CRL.

Обратите внимание, SQL Server не проверить даты, проверка CRL или участвовать в инфраструктуре открытого ключа (PKI). SQL Server зависит от администратора обеспечить, загруженные в базу данных все сертификаты являются надежными. Помните, что по большей части, PKI предназначен для решения проблемы (такие как проверка недавно вручил сертификаты), которые являются дополнительной по отношению к роли хранилища данных SQL Server.

Краткий обзор криптографии Windows

Хотя это не всеобъемлющее представление на криптографии, краткий обзор криптографические возможности в Microsoft Windows® могут предоставить полезные ориентации. Криптографические функции SQL Server в конечном итоге оказываемых криптографических алгоритмов в Windows.

Криптографические алгоритмы в Windows обеспечиваются криптографические API-интерфейсы — также называется CryptoAPI, или просто CAPI. В конечном итоге большая часть эта функциональность была подвержена объектно ориентированного мира в случае тонкой оболочки COM, под названием CapiCom. CapiCom не рекомендуется для серверных приложений, и откровенно я считаю, это как правило так же просто для вызова API-интерфейсы непосредственно и избежать зависимости от внешнего типа библиотеки. С.NET Framework 1.х релизы были сравнительно низкий уровень поддержки для CryptoAPI, и некоторые из реализаций содержит ошибки. Если вы хотите создать приложение, которое использует криптографические возможности Windows, использовать.NET Framework 2.0 или более поздней версии. Это гораздо более полной и надежной. Microsoft Visual Studio® 2008 содержит управляемые оболочки для новые функциональные возможности, предлагаемые Windows Vista® и Windows Server® 2008. Новые алгоритмы являются более эффективным и более безопасным, но они не доступны в родной криптографические функции SQL Server .

Одна из крупнейших проблем документации криптографии Windows является Windows криптографической архитектуры призван быть расширяемым. Это великая вещь, но она также можно добавить значительный путаницы. К примеру сертификаты могут храниться в одном из нескольких магазинов определенных сертификат , но они также могут храниться в альтернативных магазинах, такие как ключ карты и аппаратных устройств. (Расширенного управления Ключами, новое в SQL Server 2008, также предлагает эту функцию.) Криптографические алгоритмы, возможностей и функций CryptoAPI также зависеть какой криптографии поставщик уже используется. Это означает, что основное криптографических поведение очень трудно документ потому, что она зависит от поставщик. Вы даже можете использовать сторонние поставщики.

Вот почему документация может показаться остановить фактически инструкциями для реализации функциональности, что вам нужно. Со временем улучшилась документации.

Кроме того различные версии Windows доступ к различным поставщикам и использовать поставщиков по умолчанию. Самые последние релизы, как правило, имеют более безопасных поставщиков, однако их использование может означать, что сертификаты, подписи или шифрование , формируемый новых версий Windows, не могут быть расшифрованы в старых версий Windows. Вот почему криптографических алгоритмов, доступных в SQL Server зависит от несколько Windows версия он работает на.

Шифрова��ие при проверке подлинности SQL Server

Поскольку суть этого обсуждения как использовать шифрование для защиты данных, хранящиеся в SQL Server, этот раздел может быть своего рода крюк. Вы можете найти эту информацию полезной, однако, и если вам действительно нужно криптографически защиты ваших данных, необходимо также надежной проверки подлинности.

Безопасность в SQL Server состоит из двух частей: аутентификации и авторизация (разрешения). Проверки подлинности состоит из проверки личности пользователя, или участника безопасности. шифрование и подписей могут играть определенную роль в этом. Разрешения или разрешения являются правами предоставлены или запрещены для пользователя. Подписи может также играть роль в разрешения, как вы можете назначить разрешения для подписания в SQL Server.

Проверка подлинности Windows

В идеале, SQL Server экземпляр следует проверять удостоверения пользователей с проверкой подлинности Windows исключительно. Проверка подлинности Windows работает с Active Directory (Kerberos) или без него (NTLM). В доменах с Active Directory встроенная проверка подлинности является:

• Легче управлять — нет необходимости создавать отдельные имена входа или управлять паролями. Имена входа может основываться на членство в группе Windows.
• Более гибкие — пользователей может быть проверен пароли, смарт-карты, биометрические устройства и так далее.
• Более безопасным — протокол Kerberos обеспечивает иммунитет для определенных атак, которые требуют дополнительную работу, чтобы избежать с помощью проверки подлинности SQL Server.

Однако, когда пользователь подключается к SQL Server с помощью проверки подлинности Windows в домен с Active Directory, экземпляр SQL Server должен подключиться к контроллеру домен для получения соответствующего клиент маркер безопасности. Маркер безопасности содержит удостоверение пользователя, членство в группах и привилегии Windows. Это позволяет SQL Server разрешения предоставляются для групп Windows. Личность токен извлекаются из контроллера домен сравнивается с сведения о соединении, представленный пользователя; Если они совпадают, личность является действительным. Путем проверки учетных данных пользователя с контроллером домен , проверка подлинности Windows не уязвим для атак, таких как man-in--middle.

Потому что SQL Server необходим доступ к контроллеру домен для получения эти маркеры из Active Directory (при условии, что это не является NTLM домен), временного или высоко -задержка подключение к контроллеру домен может привести к соединения потерпеть неудачу. Для обеспечения быстрого пользователей подключения, Убедитесь, что подключение SQL Server на контроллер домен , так же быстро, как можно скорее. (Конечно, вы должны также обеспечить что учетной записи служба SQL Server имеет разрешения на запрос домен).

Встроенная проверка подлинности Kerberos по умолчанию, но не обратно к NTLM рукопожатие при необходимости. Когда пользователь Windows подключается к SQL Server, проверка подлинности сначала выполняется самой операционной системы Windows, до получения экземплярSQL Server. Это означает, что если Windows Server отказывается от подключения пользователя, пользователь не может установить подключение к SQL Server независимо от того, какие разрешения, он или она имеет.

SQL Server Проверка подлинности

SQL Server Проверка подлинности — это хороший выбор в нескольких сценариях, например, когда Администраторы SQL Server имеют не способность управлять группы Windows, пользователи устанавливают соединения с не Windows платформы, или когда пользователю необходимо подключиться из ненадежных домен. Например, это не редкость для производства сервера домен не доверять рабочего стола пользователя домен где работают администраторов баз данных (DBA) — но это не обязательно наилучшей практики. Еще одно преимущество использования проверки подлинности SQL Server является, что при подключении к связанным серверам, он избегает делегация требование двойной прыжков.

В SQL Server 2000 рукопожатие входа не был зашифрован администратор явным образом если SSL- сертификат; в противном случае пароль и Логин имя были приняты как обычный текст. В вариант SQL Server 2005 и 2008 однако, если сертификат не указан, SQL Server создает и использует самозаверяющий сертификат. Самозаверяющие сертификаты являются уязвимыми к атакам man-in--middle, но это все еще намного лучше, чем обычный текст имен входа. В идеале, SQL Server 2000, 2005 или 2008 должен иметь действительный сертификат , подписанный центром сертификат для SSL- шифрование. Процесс установки это одинаково для обеих версий и описан в как SQL Server использует сертификат когда включен параметр Принудительное шифрование протокола.

Во время начального подключения SQL Server не знает ли будет использоваться проверка подлинности Windows или проверка подлинности SQL Server, поэтому SQL Server 2005 и 2008 всегда использовать SSL зашифрованной проверки подлинности. Это не обязательно с проверкой подлинности Windows, но так или иначе используется SSL-канал. Не все клиенты поддерживают проверку подлинности с использованием SSL- шифрование и в этих случаях имя пользователя и пароль будут отправлены как обычный текст! SQL Server может быть настроен, чтобы разрешить только клиенты, которые поддерживают шифрование входа через ForceEncryption свойство при конфигурации сети в Configuration Manager.

Политике сложности паролей является таким же, как сложность пароля на сервере (при условии на хост-сервере запущена Windows 2003 или более поздней версии). В самом деле сложность подтверждается на самом деле Windows API, который вызывается SQL Server. Настоятельно рекомендуется, что вы оставить это на, но можно отключить его с помощью параметра CHECK_POLICY инструкцию CREATE LOGIN.

Реальные проблемы

В средах, где сервер находится в другом (ненадежных) домен из мира пользователей настольных компьютеров и, следовательно, чтобы разрешить доступ пользователей используется проверка подлинности SQL Server необходимо по-прежнему иногда для пользователей на всем предприятии для доступа к данным.

Общий подход заключается в том, чтобы предоставить всем пользователям то же имя входа SQL Server; Это по сути становится общественной входа. Для тех из вас, не обращая внимания: это плохая идея. Логину общественности могут быть ограничены, соответствующие разрешения, но как имеющий опыт знает, нек��торые пользователи работает неправильно, и мы должны управлять, кто что делает одновременно затрагивая всех пользователей.

Правильный вариант заключается в том, чтобы создать имя входа SQL Server для каждого пользователя, которому нужен доступ. Это позволяет аудита, возможность отзыва доступа, возможность предоставлять дополнительные разрешения и возможность определить, кто использует ваши данные. Недостатком этого подхода является, что DBA в этой ситуации может часто считают, что он или она тратит слишком много времени, создание новых имен входа.

Одно из решений заключается в том, чтобы иметь веб-страницы, где пользователи перейдут к запроса доступа. В идеале Эта страница размещается на рабочем столе домен , и вы можете использовать ASP.NET для определения пользователей  домен имена, которые становятся их входа SQL Server. В данном вариантпользователь нужно только предоставить пароль для базовых -уровень доступа. Затем приложение может подключиться к серверу базы данных и создать учетную запись.

Основная проблема безопасности этого подхода является, что разрешения, необходимые для создания новой учетной записи значительно превышают разрешения, которые когда-либо должен быть предоставлен логин базы данных, принадлежащих к веб-приложению.

Обходной путь, который я реализовал в SQL Server 2000, необходимо создать таблица , содержащую входа запросы, веб-приложение обладает разрешение только для выполнение хранимой процедуры, которая записывает в этой таблица (то есть минимальные разрешения). Независимый агент SQL Server, задание является также набор до периодически опрашивать в таблица и создает имена входа и разрешения базы данных для любые запросы, которые он находит. Естественно задание агента SQL Server требуются разрешения повышенного уровня для создания имен входа и предоставления разрешений, но нет никакой опасности эти разрешения, подвергаясь входа приложения Web. Так��м образом, веб-приложение не требует любые дополнительные базы данных разрешения, но создание общего входа (или смена пароля) процесс может быть полностью self -служба.

Лучшее решение для проблемы предоставления повышенных разрешений для выполнения конкретной задачи (например, создание имени входа) с минимальным набором разрешений учетной записи пользователя является использование подписали хранимые процедуры и дать подпись повышенными разрешениями. Этот вопрос обсуждается в следующем разделе.

Использование подписей по процедурам разрешения Grant

Новый — и, по моему опыту, малоизвестная — функция в SQL Server 2005 является использование * сертификатподписи* подписать хранимые процедуры, сборки, представления и функции. Администраторы могут назначать разрешения для подписи сертификат сам и затем можете быть уверены, что разрешения не может быть случайно изменен, изменив хранимую процедуру, Ассамблея и так далее. Подписанного исполняемого кода нельзя изменить без нарушения подпись, которая соответственно аннулирует любые разрешения, предоставленные подпись — то есть, если только измененные процедуры, Ассамблея, представление или функция не re-signed с этой подписью.

Синтаксис для добавления подписи проста и включает в себя возможности для добавления существующей подписи (предположительно создана на другом сервере) с помощью сертификат , содержащий только открытый ключ и указать пароль, если сертификат защищен паролем:

Добавление подписи К <module_name> СЕРТИФИКАТ <key_name>

[{С ПАРОЛЕМ = «пароль» | С ПОДПИСЬЮ = binary_signature}]

Необходимость подписания кода может показаться довольно экзотические. В большинстве производственных средах администраторы не нужно беспокоиться о кто-то за исключением администраторов, изменения процедур. Однако существуют важные сценарии, где это может быть весьма полезным:

• Подпись позволяет низким уровнем привилегий учетной записи для выполнения определенных, заранее задачи, которые в противном случае учетная запись не будет иметь разрешения на выполнение. 
• Независимые поставщики программного обеспечения могут счесть полезными для обеспечения того, что хранимые процедуры, сборки и так далее, которые выходят с их продуктом не являются сертификаты подписи изменены.
• Подписи решения сложной проблемы с базами данных проверку подлинности.

Возможность развертывания подписали хранимые процедуры, сборки, функций и представлений можно разрешить ISV для эффективного предотвращения кода фальсификации администратором базы данных клиента. Это может помочь предотвратить локальных изменений, которые иначе стали бы вопросы поддержки. Подписанные процедуры являются легко включить в любом сценарии развертывания: подписи может быть резервного копирования и восстановления, придает или сценариями как blob с инструкции ADD SIGNATURE Transact-SQL. Технически системный администратор может иметь возможность временно обойти эту проблему путем внедрения свой собственный сертификат с тем же именем и подписания все те же процедуры, но это не будет тривиальным. Он бы также поддаются обнаружению с помощью независимых поставщиков.

Реальная сила подписей в случаях, когда данные для конкретного запрос распределяются среди нескольких баз данных на экземпляр сервера и среди баз данных есть модели безопасности (или владельцы базы данных).

Один из способов решения этой проблемы является обеспечение что имена входа сервера сопоставляются как пользователи в обеих базах данных и что пользователи имеют допустимые разрешения в обеих базах данных. Каждому пользователю предоставлено разрешение на выполнение запрос в первой базе данных также должны быть предоставлены соответствующие разрешения в вторую базу данных. Нет нужды говорить о том, что это может быстро стать непосильным, особенно когда базы данных принадлежат различным группам.

Другое решение заключается в том, чтобы межбазовые цепочки владения на сервере. Хотя это может быть удобное решение, это огромный риск для безопасности, и по этой причине давно отключено по умолчанию. Связанной с альтернативой является использование EXECUTE как олицетворение заявление, которое позволяет хранимой процедуры в первой базе данных для олицетворения определенного допустимым пользователем в вторую базу данных. Для того чтобы олицетворении пользователя успешно запрос целевой базы данных однако, TRUSTWORTHY свойство необходимо набор для базы данных- источник . TRUSTWORTHTY свойство позволяет олицетворенного запрос целевой базы данных, но она также открывает дыру в безопасности аналогичных до цепочки владения между базами данных. Оба параметра являются ненастной идеи, если у вас есть очень четкое понимание того, как будет работать разрешения базы данных между базами данных.

Чтобы проиллюстрировать это, предположим, я хочу взять под свой контроль базы данных злоумышленником, но у меня нет разрешений в базе данных. У меня есть моя собственная база данных, расположенных на тот же экземплярсервера. Первое, что я делаю это для добавления одного или нескольких учетных записей входа к моей базе данных для пользователей с повышенными разрешениями в ваши базы данных. Я не могу войти качестве одного из этих пользователей высоким уровнем привилегий, потому что я не знаю пароль, но как владелец моей собственной базы данных, я может предоставить себя разрешение на олицетворение этого пользователя с помощью EXECUTE AS заявление. Далее я состряпать сценарий, с которым я могу убедить администратором сервера, чтобы пометить базу данных как надежные. Теперь моя контекст олицетворения входа распространяется на вашей базы данных, давая мне всю мощь этого высоким уровнем привилегий пользователя в базе данных. Таким образом, отметки базы данных Trustworthy действительно означает, что владельцы базы данных должны быть доверенными — который является по существу только в вариант , если вы являетесь владельцем обеих баз данных.

Для получения дополнительных сведений о бит доверия, см. этом блоге запись безопасности SQL Server.

Сертификаты подписи решить эту проблему, даже тогда, когда база данных зарубежных не заслуживает доверия. Например, если пользователь хочет запрос базы данных как часть их хранимую процедуру я просто:

1. Убедитесь, что хранимая процедура является приемлемым.
2. Создайте подпись для него с помощью подписи сертификат.
3. Предоставьте соответствующие разрешения для подписи сертификат.
4. Если владелец базы данных не уже его, я представить копию сертификат (содержащий открытый ключ только).

сертификат и подпись добавляются в базу данных, я не доверяю; потому что я доверяю подпись, процедура может выполнять моей базе данных. Если владелец другой базы данных пытается изменить процедуру сделать нечто иное, чем то, что я подписал, подпись становится недействительной.

Чтобы предоставить разрешения для сертификат, необходимо создать пользователя (база данных областью действия) или именем входа (сервер уровня) к нему:

ИСПОЛЬЗОВАНИЕ базы данных myDB

СОЗДАТЬ сертификат <certname> ИЗ файла = «cert_name.cer»

Создание пользователя <username> ДЛЯ сертификата <certname>

или

ИСПОЛЬЗОВАТЬ мастер

СОЗДАТЬ сертификат <certname> ИЗ файла = «cert_name.cer»

CREATE LOGIN <loginname> ДЛЯ сертификата <certname>

Как правило будет избежать путаницы, если имя пользователя или имя входа является таким же, как имя сертификат . К примеру:

Создание SupervisorCert сертификат из файла = «SupervisorCert.cer»

Создайте пользователя SupervisorCert для SupervisorCert сертификат

ВЫДЕЛИТЬ Грант, вставка на dbo.Сотрудники SupervisorCert

Технические детали

Существует два способа, в которых подпись может позволить процедуры, Ассамблея, функцияили представления для выполнения в базе данных:

• Как Вторичный идентификатор.** Ранее в этой дискуссии, мы говорили о маркеры безопасности, которые представляют пользователя или Первичный идентификатор имени входа и вторичные идентификаторы, которые извлекаются через членство в ролях SQL Server и группы Windows. Пользователи обычно предоставляются разрешения, основанные на их вторичные идентификаторы (потому что это обычно легче управлять группами); Например я, возможно, разрешение на запуск хранимой процедуры из моего членства в группе руководителей. Когда код защищен подписи, сопоставленных подпись пользователя или учетной записи входа становится еще другой Вторичный идентификатор в ходе выполнения подписанных процедуры. Разрешения могут затем предоставляться учетной записи пользователя подписи сертификат , так же, как они будут к роли или группы Windows. Первичный идентификатор и все вторичные идентификаторы, включая подписи сертификатоценить любой проверки разрешений. Если разрешение предоставляется любому из тождества (учетной записи пользователя, роли SQL Server, группы Windows или учетные записи пользователей сертификат ), проверка завершается успешно. Звонок с подписью процедуры процедуру без знака вызывает Вторичный идентификатор удаляемого во время выполнения неподписанный код. (Одно предостережение, что создание новых объектов в межбазовых сценариев может привести к нежелательным неявного пользователя создание целевой базы данных. Если необходимо создать новые объекты базы данных, используйте следующий параметр.)
• Как личность validator.** Кроме того подписей может использоваться для проверки попытка олицетворения. Когда EXECUTE как олицетворение заявление используется в рамках подписанного процедуры, Ассамблея, функцияили представления, олицетворение является доверенным для всех баз данных, в которых подписи сертификат учетная запись имеет разрешения AUTHENTICATE. Если учетная запись входа подписи сертификат ( областьсервера) имеет разрешения AUTHENTICATE SERVER, подписали олицетворения, который заявления являются доверенными для каждой базы данных в пределах экземпляр.

Сертификаты подписи, затем, позволяет очень контролируемых эскалации разрешений между базами данных. Это можно использовать сертификат так как Вторичный идентификатор и для проверки подлинности олицетворения EXECUTE AS. Явно предоставлять разрешения на соответствующий сертификат пользователя позволяет любому пользователю наследовать это разрешение при выполнении подписанного кода. Предоставление разрешения AUTHENTICATE или AUTHENTICATE SERVER на соответствующей учетной записью пользователя сертификат позволяет сертификат для олицетворения пользователя, указанного в инструкции EXECUTE AS знаком.

В любом вариантАдминистратор заверил, что действие процедуры, Ассамблея и так далее, нельзя изменить вредоносных воспользоваться дополнительными разрешениями. Если предположить, что сертификат содержит закрытый ключ, только пользователи, имеющие разрешение control на сертификат подписи можно создать подпись.

Один из важных загвоздка состоит, что подписи могут быть скопированы как другие объекты базы данных. Подписанный процедуры, Ассамблея, функцияили представления, чей сертификат предоставляется повышенными разрешениями могут быть скопированы к моей базе данных и, если я могу также загрузитьсертификатоткрытого ключ, я должен иметь возможность выполнить подписанные код с теми же разрешениями, что исходная база данных. 

Кроме того должно быть очевидно, что никогда не рекомендуется подписать процедуру, содержащую динамического SQL. Однако если требуется динамический SQL, можно поместить в свой собственный, неподписанные процедура динамического SQL, то называют его из подписанных процедуры. Когда эта новая процедура вызывается подписанных процедуры, идентификатор расширенной безопасности, предоставляемые сертификат удаляется во время выполнения неподписанного процедуры и возобновил когда выполнение возвращается к процедуре знаком. Если вы не доверяете код, не подписать его.

SQL Server и иерархии ключ

SQL Server 2005 года представил несколько новых объектов безопасности. Большинство из них хранятся в конкретных баз данных (в которых они должны использоваться базы данных), в иерархии сортировать о безопасности. Когда используется иерархия безопасности, доступ к родительский ключ может использоваться для расшифровки дочерний ключ. В то время как иерархии обеспечивает удобный доступ к ключам, каждый ключ защищен как его родительского элемента. Иерархии можно обойти на любом уровень , и его не нужно было использовать вообще.

Сертификаты (и асимметричные ключи) и симметричных ключей защищаемые объекты, что означает, что разрешения архитектура SQL Server позволяет администратору предоставлять или отменять разрешения на них, как и для таблица или хранимой процедуры. Следовательно, доступ к этим объектам защищена двумя способами: через стандартные разрешения архитектуры и необходимость доступа к ключ , который зашифрован их.

Поскольку иерархииключ SQL Serverявляется гибким, он может быть довольно сложно понять как это работает.  Первое важное решение является, хотите ли вы продолжать использовать ключ иерархии. Он предлагает удобства на счет некоторых

 
безопасности.

** **

 

Рисунок 3 : иерархии ключ

Главный ключ службы

Верхний уровень иерархии ключ является службы главный ключ. Это серверное ключ , который используется для защиты главные ключи базы данных (и других чувствительных сервер данных, таких как имена входа связанного сервера). Он автоматически создается и не может быть удален; Он может однако, быть ALTERed.

Поскольку главный ключ службы не хранится в одном из пользовательских баз данных, важно, что этот ключ резервного копирования и хранятся в надежное и безопасное место. Существует отдельного набор резервного копирования команд для этого.

Главный ключ службы является охраняются DPAPI и сохранены на компьютера и пользователя (учетная записьслужба ) уровень. Следовательно существует возможность изменить учетные записи служба на одном компьютере без потери главного ключа службы, и это также можно изменить серверы (до тех пор, пока на новом сервере используется ту же учетную запись домен ) без потери главного ключа службы. Если компьютер иизменения учетной записислужба в то же время, главный ключ службы будут потеряны и должна быть восстановлена из резервной копии главного ключа службы. 

Главный ключ базы данных

База данныхглавные ключи существуют на уровень базы данных, хранятся в базе данных и архивируются с базой данных.  Они должны быть явно создан, и они будут удаляться, если они не нужны. Эти ключи используются для защиты базы данных -уровень объектов, таких как закрытых ключей и симметричных ключей.

По умолчанию создаются два экземпляра главный ключ базы данных; один шифрования главного ключа службы и другой шифруется пароль, указанный при создании ключ . Следовательно главный ключ базы данных доступна через доступ к главного ключа службы или через пароль. (Обратите внимание, что это не следует путать с одного экземпляр главного ключа базы данных, которая охраняется как главного ключа службы, так и пароль, который будет необходим доступ к обоим для расшифровки ключ. Скорее главный ключ базы данных зашифрован дважды, один раз пароль и независимо друг от друга by Service Master Key.) Это означает, чем кто-либо с доступом к либо главного ключа службы, такие как sysadmins, или пароль также имеет доступ к главного ключа базы данных. 

Можно создать дополнительные экземпляры главного ключа базы данных, каждый защищены другой пароль. Это позволяет ключ депозитный сценариях, где каждый администратор имеет доступ главный ключ базы данных с помощью их собственных отдельных пароля. Когда DBA покидает команды, их экземпляр главный ключ базы данных может быть снята без оказывающих влияние на других.

Чтобы попытаться защитить базы данных ключей от sysadmins, можно удалить экземпляр шифрование главного ключа службы (с помощью инструкции ALTER MASTER KEY). В данном вариантчтобы открыть и использовать ключбудет всегда требуется оператор открыть главный ключ и соответствующий пароль. Однако, это дает лишь весьма ограниченной, защищены от решительных sysadmin. Если это является проблемой, следует разместить ваши данные в других местах.

Сертификаты и асимметричные ключи

Можно создать объект сертификат (или асимметричный ключ) путем загрузки файла сертификат , который создается извне — например, посредством сертификат — или SQL Server можно создать сертификат. Естественно когда SQL Server создает сертификат является самозаверяющим. Существует небольшое различие между SQL Server сертификат и SQL Server асимметричный ключ; Основное различие заключается, что асимметричный ключ не может быть экспортирован. По этой причине они рассматриваются как то же самое в этой дискуссии. Создание Сертификат объектов, если у вас есть повод предпочитают асимметричный ключ.

Файлы сертификатов с закрытых ключей обычно требуется пароль, чтобы открыть их. Этот пароль должен предоставляться отдельно (как пароль для РАСШИФРОВКИ, аргумент) и отличается от пароля, который может быть использован для шифрования закрытого ключ на сервере.

Когда вы создаете сертификат объект (или асимметричный ключ) необходимо решить, следует ли для защиты закрытого ключ с помощью пароля или с главного ключа базы данных. Этот выбор определяет, как ключ должен быть открыт для использования. В использованием одновременно может быть только один шифрование — главный ключ базы данных или пароль. Этот параметр можно изменить, используя инструкцию ALTER CERTIFICATE.

Так как пары открытый/закрытый ключ сертификат предназначена для решения проблемы обмена ключ, вы ожидаете, что может расшифровать данные, зашифрованные с помощью SQL Server сертификат с помощью той же пареключ сертификатна внешней коробке (или наоборот).  Хотя технически возможно, это не поддерживается.

Симметричные ключи

SymmetricKey объект в SQL Server могут быть получены от пароль или пароль фразу, или из случайного набор байтов. Если пароль задан как KEY_SOURCE аргумент при создании симметричный ключ, полученный симметричных ключей основаны на что пароль семена; в противном случае результирующий симметричный ключ основан на случайный набор значений.

Это вообще лучше не указать аргумент KEY_SOURCE, которые почти наверняка гораздо менее безопасным, чем случайно созданные симметричных ключей, производимым от пароля. Основная причина для использования KEY_SOURCE является, когда ключ должен быть созданы или воссозданы в нескольких местах.

Смешения симметричный ключ , также могут быть защищены с помощью пароля. Этот пароль не то же самое как пароль семян (KEY_SOURCE аргумент). Когда обеспечено с помощью пароля, ключ сам является случайным, но доступ к ней требуется пароль. ключ до сих пор только так безопасна, как этот пароль, но это защита пароля можно изменить без изменения ключ— и без последующего необходимо повторное шифрование данных.

В отличие от сертификатов SQL Server неявно хранит и поддерживает несколько версий же симметричный ключ, каждый из которых имеет свои собственные шифрование. Это означает, что тот же самый симметричный ключ может быть защищены более чем один пароль, других симметричных ключей, несколько сертификатов и/или главного ключа базы данных.

Поскольку симметричные ключи обычно используются при шифрование, тот факт, что мы можем хранить тот же ключ несколько раз означает, что несколько пользователей могут обращаться к тем же ключ без также обмен их сертификат или пароль. К примеру я могу шифровать данные с "ключ X" и предоставить копию "ключ X" для пользователей Джо, Сью и Боб, каждый из которых имеет свои собственные отдельные пароль (или сертификат). Если Боб покидает компанию, я можно удалить его копию ключ , не влияющих на Джо и Сью. Симметричные ключи должны быть открыты перед использованием заявлению открытого СИММЕТРИЧНОГО ключа. Процесс расшифровки автоматически определяет правильный ключ из набор открытых ключей.

Таким образом, по умолчанию архитектура — иерархии ключ — в SQL Server позволяет довольно удобный доступ к любой клавиши, на которые у пользователя есть разрешения. Как правило это хорошее решение, как разрешения в SQL Server являются надежными и должны обеспечить надлежащую безопасность. Основная причина отказаться от этого подхода — когда тех, кто имеет неявные разрешения на клавиши (например, сисадмины, или те, кто сами могут предоставлять разрешения на клавиши, такие как администраторов безопасности) не следует использовать ключи.

Разумных аргументов могут быть сделаны, что удаление иерархии ключ также позволит улучшить безопасность путем удаления наследуемых разрешений и вместо него требующие пароль или другим ключ. Однако на практике пароль должны быть представлены в некотором роде, и обеспечение того, что умелый администратор не может захватить его будет весьма сложно. Если это нежелательно, то лучше для шифрования и расшифровки данных извне.

Защита данных SQL Server с помощью шифрования

Первый задавать вопрос «Почему вы хотите зашифровать данные на сервере?» Во многих случаях Управление доступом к таблица с помощью архитектуры SQL Server надежного разрешения является защита достаточно. Как правило если полностью обеспечены средства хранения (SAN, диски, ленты и т.д.), это технически не необходимые для шифрования данных. Шифрование предлагает немного помочь в управлении доступом к данным через компонент database engine; Если злоумышленник сможет победить разрешения архитектуры, он или она вероятно могут также получить доступ к ключи шифрование с только немного больше неприятностей.

Однако систем не идеальны и если злоумышленнику получить доступ к файловой системе, шифрование предлагают "глубокая защита."

В вариант шифрование сильна в следующих сценариях:

• Когда носитель уязвим, как когда переносной компьютер могут быть потеряны или лента для резервного копирования может быть нарушена.
• Когда данные должны быть защищены от сисадмины. Практически в этом случае было бы лучше не использовать SQL Server внутренней шифрование и гораздо лучше полагаться исключительно на среднем уровне для выполнения шифрование и расшифровки. Было бы очень трудно защитить данные от решительных sysadmin, если ваши ключи хранятся в SQL Server.
• Когда есть необходимость в защите набора записей (строк) в течение того же таблица , где пользователи имеют права на запрос таблица непосредственно. В данном вариантпользователи с доступом к конкретным криптографические ключи могут увидеть соответствующие записи, но не имеют доступа к другим записям в той же таблица. Без шифрованиеэто может быть гораздо труднее применять. (Когда вам просто нужно ограничить столбцы, которые доступны для пользователя, это лучше делается с разрешения на представления.)
• Когда правила требуют, чтобы данные храниться в зашифрованных формы.

Когда один или несколько из этих условий не применяются, шифрование вероятно не является необходимым.

Когда доступ к дискового пространства хранения является безопасным, но вне ленты хранения может быть менее безопасным, может потребоваться рассмотреть сторонних решений резервного копирования, которые способны шифрования файлов резервных копий.

Уровень базы данных или уровень громкости шифрования

С SQL Server 2005 Корпорация Майкрософт представила шифрование через компонент database engine. Это до сих пор наиболее гибких, гранулированных и надежный вариант шифрование . Самый большой недостаток является, что база данных должна строиться по существу с этой архитектуры шифрование в виду. Это означает, что типы данных столбец вероятно должны быть изменены (в varbinary) и процедуры доступа к данным необходимо явно расшифровать данные с действительный ключ. Могут также существовать значительное производительность при поиске зашифрованных столбцов.

Windows Server 2008, некоторые версии Windows Vista и SQL Server 2008 Enterprise Edition и Developer Edition предоставляют некоторые новые возможности. Windows Server 2008 и Windows Vista добавить BitLocker (и шифрованной файловой системы, который не рекомендуется для SQL Server). SQL Server 2008 Enterprise Edition имеет прозрачный шифрования данных (TDE).

BitLocker и TDE являются на удивление схожими. Оба работают как слои между буферный пул SQL Server и лежащие в основе хранения, расшифровка и шифрование данных равно чтения и записываются на диск. Основное преимущество для любой из этих подходов является шифрование можно добавить на носитель диска без каких-либо изменений в базу данных. В обоих случаях шифрование является прозрачным.

Как правило он, вероятно, делает больший смысл для использования BitLocker на портативных компьютерах (даже те, без SQL Server), как она защищает весь объем. Если ноутбук данных скомпрометирован, предположительно это происходит из-за физического доступа к средствам массовой информации и BitLocker защищает против этого. На сервере, тем не менее, он вероятно делает больший смысл для использования SQL Server TDE, как это шифрует файл базы данных, файл журнала, базы данных tempdbи файлы резервной копии. Если тома хранилища сервера скомпрометирован, это, как правило, через доступ к сети и BitLocker не защищает против этого. С помощью BitLocker если они хранятся на зашифрованном томе резервного копирования файлы не шифруются. С TDE также шифруются файлы резервных копий, но новый параметр С СЖАТИЯ резервной копии не обеспечивают полезные сжатие — как всегда это вариант при попытке сжатия зашифрованной информации. (Новая функция сжатия страниц SQL Server 2008 по-прежнему будет эффективным).

Обратите внимание, что ни BitLocker, ни TDE шифрования данных в памяти. Это может обеспечить существенные преимуществ над шифрование в SQL Server 2005, включая использование индексированного поиска (описаны ниже). Но это также означает, что системному администратору доступ к этой памяти может прочитать незашифрованных данных. Все пользователи с разрешения базы данных для доступа к данным будут видеть незашифрованных данных. Потому что TDE только конкретные файлы базы данных, незашифрованных данных возможность утечки на диск, ес��и двигатель вынужден страницы данных из памяти. Кроме того объекты FILESTREAM не шифруются TDE, поскольку они могут быть с помощью BitLocker.

Это позволяет объединить некоторые или все из этих методов для достижения глубокой защиты. Для получения дополнительных сведений об этих шифрование компромиссы, см. Шифрования базы данных в SQL Server 2008 Enterprise Edition , Hsueh, сон.

Шифрование на уровне ячейки

В некоторой экстентBitLocker и TDE предлагают шифрование данных с минимальной производительности и административные накладные расходы. Это может быть достаточно. Как говорилось ранее, однако, любой пользователь, имеющий доступ на чтение к таблицам увидите данные обычный текст (без шифрования). Это также возможно для этих типов шифрование "утечка" незашифрованной информации при определенных сценариях, например дампов памяти или подкачки в вариант TDE, и тома удаленного доступа и незашифрованную копий в вариант BitLocker. Стратегия безопасности действительно надежные данные предлагает глубокой защиты.

Ячейкауровень шифрование остается зашифрованным в памяти и пользователям доступ на чтение к таблицам см зашифрованные данные, если они имеют доступ к ключ и явно расшифровать эти данные. В отличие от TDE эта функциональность доступна также в SQL Server 2005 во всех выпусках продукта.

Для обзора, то, что мы обсуждали ранее: по причинам производительности, обычно не следует использовать пару открытый/закрытый ключ (асимметричных ключей или сертификатов) для шифрование и расшифровки данных. Производительность алгоритмов асимметричного ключ является весьма неудовлетворительным. Реальное преимущество с помощью пары ключ — что любой можно шифровать, но может расшифровать только владельцем закрытого ключ . Другими словами, асимметричные ключи и сертификаты решить проблему коммуникации между отправителем и получателем — проблема, вероятно, не применяется к компоненту database engine. В вариант системы баз данных, таких как SQL Server почти наверняка было бы же агент, шифрование и расшифровки (двигатель или учетной записи служба агента). Это делает использование асимметричных ключей бессмысленно, и результатом этого является неоправданно низкой производительности.

В тех редких вариант когда либо шифрование или расшифровки не обрабатывается локально или должны быть обработаны различных агентов она может иметь смысл для использования сертификатов. В этом вариантрекомендуется диктует шифровать данные с большой, случайные симметричный ключи затем использовать сертификат для шифрования только этого шифрование ключ. (С.NET криптографический симметричный ключ классы имеют способность генерировать случайные симметричный ключ). Расшифровка агент может использовать свой закрытый ключ для расшифровки только симметричный ключи затем использовать гораздо эффективнее симметричный ключ для расшифровки остальной части сообщения.

Данные, зашифрованные SQL Server должен храниться в varbinary столбец и, следовательно, зашифрованное значение не может превышать 8 000 байт. Обратите внимание, что поскольку зашифрованные значения, как правило, больше, чем обычный текст источник , максимальный размер encryptable текстовых данных немного меньше, чем 8 000 байт. Влияние шифрование на размер хранения зависит от используемого алгоритма. После того, как у вас есть некоторый опыт работы с конкретного алгоритма, вы должны иметь возможность достаточно точно предсказать это. Если необходимо точно знать это, выполните некоторые тесты. SQL Server 2005 шифрования: шифрования и данных ограничения длины запись блога является хорошим местом для старта.

Может быть можно использовать длину зашифрованные данные для определения другой информации об источник данных. К примеру имеющих сомнительную репутацию страховая компания может быть заинтересован в том, что потенциальный подписчик зашифрованных медицинской истории имеет тысячи байт данных, даже если содержимое является недоступным. Однако так как алгоритмы шифрование обычно имеют фиксированные размеры блок , как правило не представляется возможным оценить зашифрованное значение длины для ключи для длины текстового значения (только большие текстовые поля обычно уязвимы к этому).

Злонамеренно используя зашифрованные данные не нарушая шифрования

Помимо того, что может быть выведено из общего размера зашифрованных данных наивно зашифрованных данных подвержен несколько нападений, которым не требуется доступ к ключи дешифрования.

• Предположим, что злонамеренный пользователь имеет доступ к личным делам. Зная, что Генеральный директор заработной платы значительно выше, чем его или ее собственной зарплаты даже несмотря на то, не зная точной суммы, пользователь просто может обновить содержание своих собственных запись с зашифрованное значение ГАС заработной платы.
• Пользователь-злоумышленник может также обновить его или ее личный рекорд с конкретной информацией и захватить результата. Впоследствии пользователь может искать в таблица для других записей, содержащих тот же зашифрованный результат; все зашифрованные значения, совпадающие должны содержать то же значение обычный текст. Таким образом пользователь может определить значение зашифрованных поле просто, подтвердив ранее догадываться.

К счастью внутренней реализации SQL Server защищает от обеих этих атак. База данных -уровень или объем -уровень шифрование не зависит от этих проблем, как любой пользователь, имеющий доступ на чтение к таблицам не увидит зашифрованных данных.

Для открытия текстового содержимого путем сравнения зашифрованные значения (второго нападения), большинство алгоритмов шифрование включать расширяющее значение. Указав другое значение соли генерирует очень разные зашифрованных вывод. При использовании.Чистый криптографические классы, можно указать соль как вектор инициализации аргумент. В SQL Server случайного расширяющего значения всегда применяется для шифрование.

Так как расширяющее значение неявно создается и комплектацию зашифрованного вывода, нельзя сравнивать значения зашифрованы с функциональность внутренней шифрование SQL Server для просмотра, равны ли они. Однако, это возможно с зашифрованных данных.Чистый классы до тех пор, пока же вектор инициализации используется. Это не позволяет задать значение привязки в SQL Server.

Чтобы защитить от другого нападения, принимать функций шифрование SQL Server проверки подлинности, также известен как параметров целостности данных. В идеале это должно соответствовать первичный ключ для записи или другое поле , уникальное для любой заданной строке. После расшифровки должны быть предоставлены одинаковые значения проверки подлинности; в случае несоответствия шифрование прекращается и возникает ошибка. Эта архитектура делает невозможным выполнение атаки типа «копировать и вставить», как зашифрованное значение в новой записи будет содержать значение неправильно проверки подлинности.

SQL Server проверки подлинности аргумент varbinary, так что значение может сод��ржать целые числа, uniqueidentifiers (GUID), или даже строк. Вектор инициализации в.Чистый криптографические классы также является двоичный массив; можно было бы использовать этот аргумент в.Чистая классы для аналогичных целей. С помощью столбцов identity может показаться естественным для этого, но значение идентификатора должны быть известны перед проведением операции шифрование . Не ясно для меня как это будет происходить, когда вставляется запись. Откровенно говоря, это представляется другой экземпляр , где uniqueidentifier (GUID) может быть гораздо более полезным как первичный ключ таблица. Кроме того, с помощью GUID можно выполнить шифрование на другом сервере, используя.Чистый шифрование классов и GUID первичный ключ и зашифрованные значения могут быть вставлены в таблица без страха конфликтов первичный ключ .

Поиск соленые поля

Это может показаться хорошей идеей для шифрования номера социального страхования (США номера налогоплательщика), но что происходит, когда вам нужно найти запись, номер социального страхования? Некоторые торговцы позволяют вернуть элемент без квитанцию, потому, что они могут найти запись покупки, основанный на номер вашей кредитной карты.  Что происходит при шифровании номера кредитных карт?

Жи��нь хороша, при условии, что ядро СУБД SQL Server используется просто для хранения и извлечения зашифрованных сведений. Когда двигатель должен искать, сортировать или сравнить эти данные, возникают быстродействие. К сожалению весьма засолки метод, который не позволяет пользователям сравнения значений также предотвращает SQL engine делает то же самое! Для уточняющего запроса, двигатель должен индивидуально расшифровать каждую запись, как это выглядит для совпадающих записей. Хотя есть веские причины для шифрования номера социального страхования и номера кредитных карт, тот факт, эффективно соленые эти зашифрованные значения не исключает возможность выполнять эти обыски без индивидуально расшифровки значения.

Несколько подходов можно сделать поиск зашифрованную информацию более мощные, но также делают менее безопасным в различной степени защищенной информации. Обратите внимание, что это также справедливо в отношении поставщиков баз данных, которые утверждают, что их зашифрованные данные могут быть проиндексированы: они по-прежнему утечка информации.

Метод первый

Зашифровать обычный текст без использования расширяющее значение (или используйте значение последовательного соли). При выполнении поиска, зашифровать условия поиска, используя то же значение соли и сравнить двоичного вывода с зашифрованные значения в базе данных. Идентичные обычный текст должен создавать одинаковые кодировки. Обратите внимание, что несоленое данных имеют увеличение подверженности несколько нападений и позволить пользователям подтверждать правильно догадались текстовых значений. Аналогичным образом данные будут также не защищаться от атак, копировать и вставить аргумент проверки подлинности.

Конечно, этот метод может осуществляться только с помощью.NET классов, как криптографические функции SQL Server всегда солей зашифрованных данных. Для этого можно использовать SQL-CLR. Поиск не будет вариант-не учитывается.

Способ 2

Использовать внутренние шифрование SQL Serverфункция (всегда использовать функции EncryptByKeyфункция если другой ключшифрования) и проверки подлинности аргумент.   Это создает полностью соленые зашифрованные значения, которые надежно защищены от атак.

Кроме того создайте столбец , содержащий хэш-значение исходное значение обычный текст. Если вы хотите, чтобы поиск вариант-не учитывается, сначала воспользуйтесь lowercase() функция на значение обычный текст. При выполнении поиска, создать хэш значение (строчная) поиска и сравнить значения в новый столбец. Хэш сравнения позволяют очень быстро выполнять поиск.

С помощью нее функцию HashBytes функция и указав алгоритм SHA-1 дает вам 20‑результат хеширования байт. Он вероятно будет иметь смысл для приведения этого вывода на binary(20) и убедитесь, что столбец сам использует соответствующий тип данных. Фиксированного размера столбец может выполнять несколько лучше, чем varbinary(20). Определение алгоритма MD4 или MD5 для нее функцию HashBytes функция возвращает 16‑байт результат, который может также привести uniqueidentifier.

Обратите внимание, что это возможно (хотя и очень маловероятно) что несколько записей может совпадает с хэшем, поэтому любые записи совпадает с хэшем следует быть расшифрованы и по сравнению с условия поиска обычного текста. С продуманной SQL это может быть сделано в одном запрос.

Этот подход по-прежнему оставляет шифрование уязвимых пользователю угадать зашифрованное значение и подтверждающие сравнивая хэши, однако пользователь-злоумышленник не удалось скопировать зашифрованное значение в другой записи. Поскольку хэшированные значения не соленые, это также подвержен «rainbow атака», который, как правило, требуется только время и хранения раскрыть обычного текста из хэша, и это также уязвимы для частотного анализа.

Чтобы обойти некоторые из этих проблем, Рауль Гарсия имеет прекрасную запись блога подробно как зашифровать хэша, сам с помощью кода проверки подлинности сообщения с ключом hash (КСОМ). Это решает проблему Радуга атаки против хэш-значение и также несколько ограничивает злонамеренных пользователей от подтверждающее правильные догадки, сравнивая хэшей. К сожалению если злонамеренный пользователь имеет возможность записи в таблица (скажем, обновляя свои собственные записи), он или она по-прежнему можно создавать значения, которые подтверждаются хэш совпадениям. Потому что хэши весовое, может оказаться возможным определить зашифрованные значения, основанные на их частоту. Например если таблица содержит список шпионов "холодной войны", я не сможет расшифровать city столбец, но он не будет трудно определить, какое значение представляет «Москва.»

Три метода (рекомендуется)

Третий подход заключается в том, как предыдущий (соль зашифрованные значения и добавить дополнительные несоленое хэш столбец), но хэш-значения усекаются, или имеют ограниченные числовая точность. Тогда как предыдущий метод должны обрабатывать возможность повторяющихся хэш матчей, устраняет этот метод вероятность дубликатов матчей. Преимуществом такого подхода является, что злонамеренный пользователь не может подтвердить правильно подобрать текстовые значения с уверенностью потому, что низкое разрешение хэш-значения позволяют что любые два случайных plain text значения будет генерировать же хэш-код. Хэши гораздо менее уязвимы для частотного анализа.

Помните, что криптографическое хэширование предназначены главным образом для подписи: их длина обеспечивает очень высокий уровень доверия, что два сообщения не будет генерировать же хэш-значение. В самом деле, это невероятное (хотя и не невозможными) еще одно сообщение будет когда-либо создать который будет генерировать же хэш-код. В нашем вариантэто функция, которую мы не хотим, потому что он позволяет злоумышленнику для подтверждения их угадать нашего текстового значения.

Как крайний пример этого подхода, предположим, что наш хэш были сокращены до одного байта (tinyint), или 256 различных значений. Наш поиск через records соленые шифрование по-прежнему будет существенно быстрее, потому что количество записей, требующих индивидуальный расшифровки бы около 256 раз меньше (при условии равномерное распределение). Однако любой злоумышленник пытается проверить догадку зашифрованные значения будет иметь 1:256 фор хэш-совпадения по чистой случайности, который предлагает весьма ограниченные подтверждения правильно угадать.

Естественно, таблица , содержащая несколько сотен строк будет обычно иметь одного-трех хэш соответствует когда tinyint используется хэш столбец , который обеспечивает хорошую производительность и утечка почти никаких данных о текстовом источник значения. С другой стороны, таблица с миллиона строк скорее всего предложит 3900 совпадающие записи хэш, каждый из которых должен быть расшифрованы завершения поиска. Это вероятно не приведет в хорошую производительность. В этом вариантповышение резолюции хэш-код для двух байтов (smallint), сокращения соответствующий набор хэшей в около 15 записей, но она также предлагает 1:65,535 злоумышленник шансы, что подобрать значение является правильным.

Калибровки числовая точность результата хеширования с помощью Bitwise- И (&) оператор для фильтрации нежелательных старшие биты. Этот подход также позволяет указать хэш резолюции точно, как можно указать точно количество битов, вы хотите. Используя этот подход, это также можно выполнять автономные изменения с точностью хэш-значения.

Альтернативный подход к созданию этих «сегменты» хэш матчей — для усечения или снизить точность значения текста и затем создать несоленое хэш из этого значения. Это может предложить более предсказуемого контроля над распределением и точность совпадения хеш.

Она может быть хорошей идеей для создания триггеров на таблица , которая автоматически вычисляет хэш-значение и заполняет хэш столбец. Должным образом выполнены, этот подход обеспечивает ограниченное (и контролируемых) уязвимость к вредоносной атаки, в то же время по-прежнему предлагая производительность хорошие поиска

Явно существует баланс между безопасность данных, размер таблицаи производительность от поисков. Увеличение точность чисел (количество бит) хеш-значения дает злоумышленнику больше подтверждения правильно угадать, но также улучшает производительность поиска. Существует не «один размер» решение, так как правильный ответ зависит от размера таблица, частоту поисков и критичности необходимость сохранять тайну текстовых данных.

.NET классы vs.  SQL Server Внутренние криптографии

Оба SQL Server внутреннего криптографические возможности и.NET криптографические классы используют Windows Crypto API, поэтому не ожидаем производительности или безопасности одного существенно лучше, чем другие. В целом, SQL Server внутреннего криптографические возможности гораздо проще в использовании и.NET классы являются более гибкими.

Обратите внимание, что существует мало вы можете делать с.Чистая гибкость, чтобы сделать данные более безопасным, чем то, что внутренние функции SQL Server предоставляют; Функции SQL Server уже являются весьма надежными. Исключением является, что у вас есть доступ к новые, зависящей от платформы алгоритмов при использовании.NET классы. Например если вы хотите использовать алгоритмы эллиптических поле , которые посещают Vista и Windows Server 2008, вы можете сделать это с текущим.NET классов, но не с помощью SQL Server функции. Если SQL Server позволяет это, вы не сможете расшифровать ваши данные, если вы переехали на резервный сервер или зеркало.

.ЧИСТЫЕ преимущества классов

• Криптографические функциональность доступна как в SQL Server (через SQL-CLR интеграция) и среднего уровня или даже клиент машин (быть очень осторожным расшифровки на клиент компьютерах, которые не являются безопасными, как это может подвергнуть самих ключей.) Это означает, что криптографические Загрузка процессора можно переехал или совместно с другими серверами.
• Поскольку несколько компьютеров могут участвовать в криптографической обработке, зашифрованные данные можно струились по-прежнему зашифрован, а затем расшифрованы в нижнем течении процесса.
• В зависимости от платформы все больше и более новые алгоритмы доступны и у вас есть явный контроль над все аргументы.
• С.NET классы могут быть расширены для участия в инфраструктуре PKI. К примеру сертификаты могут быть опробованы за их присутствие на списка отзыва сертификатов.
• Функциональность изначально доступна в SQL Server. (Хотя криптографических функций, созданных через SQL-CLR также могут вызываться через SQL, это необходимо установить на каждом сервере, на котором требуется его.)
• Криптографические возможности простой и надежный, тогда как в вариант .NET классы, определенные аргументы и практики должны использоваться явно предоставить эквивалентный уровень безопасности.
• Данные могут быть перемещены на другой сервер, такой как резервный сервер или зеркало, и он все еще может быть расшифрован — даже если размещенных на пожилых OS платформе.
• Окружающей среды использует встроенные разрешения архитектуры для управления доступом к ключей. Сравните это с.НЕТТО классы, где должны быть загружены ключи, сохраняется, а в некоторых внешних store, который может создать доступ к вопросам контроля.

SQL Server Внутренние преимущества криптографии

Заключение

Самая распространенная проблема с криптографические возможности является, что она используется для решения проблем, которые он не предназначен для решения. Наиболее распространенные примеры:

• Использование асимметричного ключ пары в ситуациях, когда ключ сообщение является не возникает, например, с данными, хранящимися в базе данных SQL Server.
• Использование шифрование для управления доступом к данным. Разрешения SQL Server являются надежными и предназначены для этого. Если доступ к хранения средств массовой информации может быть нарушена (через потеряли портативных дисков, незашифрованный лентах, общее хранилище и так далее), шифрование добавить значимых безопасности.

В вариант подписей, это не широко оценили как эта функциональность решает важную проблему.

Лучшая часть криптографические функции SQL Server является относительно простым для создания надежной безопасности. Родной функциональность предлагает ключ хранения и управления доступом и функциональность встроенного шифрование предлагает надежную защиту (в том числе случайных соли, значения про��ерки подлинности и так далее). Простота осуществления помогает гарантировать, что те, кто зависит защитить свои данные или процессы не будут разочарованы.

Об авторе

Джон Хикс — архитектор в группа отраслевых решений в корпорации Майкрософт. Вы можете связаться с ним в john.hicks@microsoft.com или через его блог на http://blogs.msdn.com/johnhicks.

** **

Для получения дополнительной информации:

SQL Server веб-сайт: http://www.microsoft.com/sqlserver/

SQL Server Технический центр: http://technet.microsoft.com/en-us/sqlserver/default.aspx

SQL Server DevCenter: http://msdn2.microsoft.com/en-us/sqlserver/default.aspx

** **