FileStream: T-SQL против Win32

Question

Одна из наших команд создает базу данных (и приложение), которая будет использовать функцию FileStream в SQL 2008 для хранения документов. В соответствии с рекомендациями MS для файлового потока, Win32 API являются предпочтительным способом доступа к данным FileStream по сравнению с использованием T-SQL.

Однако использование Win32 API требует использования встроенной аутентификации для подключения к базе данных. Это беспокоит команду, потому что они не хотят предоставлять пользователям прямой доступ к базе данных. Они хотят, чтобы приложение подключалось с использованием имени пользователя и пароля SQL.

Каковы плюсы / минусы использования Win32 против T-SQL для доступа к данным файлового потока? Есть ли факторы, которые делают использование T-SQL невозможным?

Answer 1

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

По мере увеличения размера большого двоичного объекта накладные расходы на открытие файла и передачу через механизм становятся меньшими процентами от общего времени, необходимого для завершения передачи данных. Недавние тесты для очень специфического конкретного случая установили пороговые значения в 60 КБ для встроенного (максимальное хранилище varbinary), 60 КБ-1,2 МБ для передачи T-SQL и> 1,2 МБ для передачи Win32. Как я уже упоминал, это было для очень конкретного случая, поэтому YMMV.

Что касается безопасности, я вижу ряд проблем с использованием безопасности SQL таким образом, но трудно предлагать предложения без некоторого дополнительного контекста. Вы действительно ограничены в использовании Filestream, получая доступ к нему исключительно через T-SQL.

Answer 2

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

Если вам нужна схема защиты, которая позволяет пользователям получать доступ только к определенным функциям (т. Е. Они могут обновлять данные только таким способом , а не писать произвольные ОБНОВЛЕНИЯ), используйте команду good ole 'try and проверенные методы цепочек владения с помощью хранимых процедур и предоставление только EXECUTE доступа для аутентифицированного пользователя true . Для еще лучшего решения используйте подпись кода .

Что касается доступа T-SQL и Win32, документ FILESTREAM Best Practices содержит следующую формулировку:

• FILESTREAM API предназначен для Win32 потоковый доступ к данным. избежать использование Transact-SQL для чтения или записи FILESTREAM бинарные большие объекты (BLOB), размер которых превышает 2 МБ. Если Вы должны читать или записывать данные BLOB из Transact-SQL, убедитесь, что все BLOB данные потребляются, прежде чем пытаться Откройте BLOB FILESTREAM из Win32. Неспособность потреблять все Данные Transact-SQL могут вызывать любые последовательный FILESTREAM открыть или закрыть сбой операции.
• Избегайте операторов Transact-SQL, которые обновить, добавить или добавить данные в FILESTREAM BLOB. Это вызывает BLOB данные, которые будут помещены в буфер базы данных базы данных, а затем обратно в новый физический файл.