(Возврат на основную страницу)
Излишний вред общих баз данных разработки
Трой Хант
Инъекции SQL: глубокая защита
Тимати Вайсман
Когда последний раз была синхронизация?
Кимберли Киллиан (Kimberly Killian)
Сценарий DBUser для определения ролей
Прадиотхана Шастри (Pradyothana Shastry )
Сгенерируйте скрипт alter datatype для всей БД
Венугопал Сариде (Venugopal Saride)
Излишний вред общих баз данных разработки
Трой Хант
Одной из болевых точек в ходе разработки приложения, управляемого базой данных,
является ситуация, когда для приложения выполняется версионный контроль, а для
базы данных – нет. Проблема становится серьезнее, когда база данных разработки
находится в общем доступе, и контроль версий лишь приложения никак не облегчает
положение. Трой Хант описывает причины, по которым каждому разработчику баз
данных следует иметь свою собственную версию базы данных.
Помню, как в конце 90х, занимаясь вместе с моими напарниками-разработчиками
разработкой классических ASP-приложений с использованием VB Script с помощью
DreamViewer, работали с одним набором файлов, используя один и тот же
сопоставленный путь (mapped path). Постоянно звучали фразы вроде: «Ты закрыл
файл CSS? Мне нужно добавить класс». И я помню болезненный процесс «поиска и
замены», который становился безопасным для выполнения только после того, как
каждый из разработчиков сохранял свою работу и закрывал файлы. Мы толкались
вокруг общих дисков, ассоциированных с одним UNC-путем и опрометчиво работали с
одним и тем же набором файлов перед тем, как проверить их в браузере на одном и
том же сервере.
В то время существовали некоторые средства контроля версий Visual Source Safe,
CVS или даже Rational ClearCase: Но обычно это сводилось к классическому
варианту с выбором корневой папки приложения, после чего выполнялась
последовательность «скопировать > вставить > переименовать» с добавлением даты
ключевой точки проекта.
Оглядываясь назад, лет десять как можно было поступать иначе; но те методы были
общепринятыми. Сегодня никто в здравом уме не станет создавать приложения
подобным образом. Так почему же еще так много тех, кто использует те же самые
методы при создании баз данных для своих web-приложений? Неужели уровень данных
на самом деле требует иного подхода? С трудом выученные на протяжении прошлого
столетия уроки не годятся при разработке баз данных?
О чем мы говорим?
Чтобы не создавать путаницы, давайте точно определимся с предметом нашего
обсуждения. При использовании модели разработки с использованием общей базы
данных, разработчики строят уровень web-приложения на обычный манер (приложение
Visual Studio запущено локально, файлы хранятся на компьютере разработчика),
подключаясь к удаленному серверу баз данных и работая непосредственно с одной и
той же базой банных.
Обычно они работают с помощью SQL Management Studio, запуская его локально и
подключаясь к удаленному серверу баз данных. Когда приложение фактически
работает локально, все соединения исходят к общей центральной базе данных
разработки. Локальных экземпляров SQL Server на машинах разработчиков не
установлено.
Другим вариантом, конечно, может быть выделенная база данных разработки. Теперь
это выглядит немного сложнее.
Очевидно, у каждого разработчика есть собственная версия базы данных, но
существенная разница с ранней моделью заключается в системе контроля версий.
Почему?
Проблемы общей базы данных разработки
Проблема «преимущества последнего изменения»
Очевидно, что проблема совместной работы с общей базой данных возникает, когда
множество разработчиков работают с одним и тем же объектом одновременно, это как
раз тот случай, когда «последнее изменение имеет преимущество». Нет слияния, нет
управления конфликтами редактирования, лишь тот, кто последним внес изменения,
определяет конечный результат.
Чтобы снизить риск возникновения этой ситуации, надо внедрять социальные
механизмы работы над этой проблемой. Таким образом, возвращаемся к
разработчикам, которые постоянно обмениваются просьбами «отпустить» файл, в
попытке уберечь свою работу от товарищей по команде. Это неуклюже, трудоемко и в
итоге перестанет работать. Это лишь вопрос времени.
Инъекции SQL: глубокая защита
Тимати Вайсман
Несмотря на то, что об инъекциях SQL написано много статей и для защиты сайтов
пользуются услугами консультантов, все еще происходят удачные атаки. Зачастую
проблема в том, что описана только часть решения, несмотря на то, что для
максимальной надежности требуется защита на всю глубину.
Несмотря на угрозу данным, которую представляют инъекции SQL, многие
программисты и администраторы баз данных либо не владеют информацией о них, либо
не знают о том, как правильно защищаться. Это отчастисвязано с тем, что инъекции
SQL и способы борьбы с ними редко рассматриваются в процессе обучения: я прошел
два класса теории баз данных, прочел несколько книг по SQL Server и получил
статус сертифицированного администратора баз данных Microsoft (MCDBA) до того,
как впервые узнал об инъекциях SQL в статье Эрланда Соммарскога (Erland
Sommarskog) «Проклятие и благословение динамического SQL» (The curse and
blessings of dynamic SQL)
По этой причине инъекции SQL остаются распространенным и эффективным видом атак.
Не так давно стал известен громкий случай; даже компания, специализирующаяся на
безопасности, частично подверглась угрозе атаки с помощью инъекции SQL (см. «Anonymous
speaks: the inside story of the HBGary hack»), тем самым дав урок всей отрасли,
показывающий, что дела могут пойти не так, как надо.
О защите SQL Server от инъекций написано немало статей. Тем не менее, немногие
из них отмечают, что лучшим способом защиты от подобных атак является глубокая
защита со всеми предосторожностями. Многие из этих статей целиком
сосредотачивают внимание на параметризации SQL, как на защите от инъекций.
Несмотря на то, что параметризация первая и лучшая защита против инъекций SQL,
она не должна быть единственным вариантом. Таким образом, я решил добавить еще
один уровень проверки и использовать Python для подготовки примеров.
Что такое инъекция SQL?
Атака инъекцией SQL производится путем передачи специальным образом
отформатированной строки в качестве входного параметра. При успешной атаке, эти
специальные строки передаются в базу данных либо для выполнения произвольного
кода, либо с целью вынудить сервер вернуть необходимые результаты.
Когда последний раз была синхронизация?
Кимберли Киллиан (Kimberly Killian)
После перехода на новую работу в качестве администратора баз данных, я
обнаружил, что мои пользователи с портативными компьютерами используют merge
replication и должны синхронизироваться с издателем в течение 30 дней. Очевидно,
это не новая технология, но за мои более чем 16 лет карьеры на этом поприще я
впервые столкнулся с ней.
Для организации автоматизированного процесса синхронизация создал БД, которую
назвал DBA_Reports, если ваша будет иметь другое имя, не забудьте поменять имена
в приведенных скриптах. Перед началом нужно обеспечить следующее:
• Активизировать DBMail на сервер, без этого ничего не будет работать
• Активизировать xp_cmdShell на каждом удаленном сервере, это позволит видеть,
какие серверы находятся в сети и записать их имена в таблицу.
• В зависимости от настроек и того, какие серверы вы наблюдаете, вы можете
создать связанный сервер для каждого сервера сотрудника. В моем случае, так как
сотрудники используют ноутбуки и установленный SQL Express, мне пришлось именно
так и поступить. Из кода задания и/или хранимой процедуры, исполняющейся в
контексте DBA_Reports мне нужно выполнять запись в таблицы tempDb.
• Создайте оператора, который будет получать уведомления о сбое в работе
задания. Лично я создаю уведомление на каждое задание.
Сценарий DBUser для определения ролей
Прадиотхана Шастри (Pradyothana Shastry )
Код позволяет вывести список пользователей и их привилегий на уровне БД. Код
можно использовать при замене существующей БД.
Сгенерируйте скрипт alter datatype для всей БД
Венугопал Сариде (Venugopal Saride)
(Возврат на основную страницу)