Почему я не должен давать посторонним доступ к моей базе данных?

Многие сайты сегодня имеют API-интерфейсы, которые позволяют пользователям получать данные с сайта в виде XML или JSON, используя HTTP-запрос GET. Flickr и del.icio.us являются примерами сайтов с API. Эти API требуют от сервера доступа к базе данных, а затем выводят результат в виде XML или JSON.

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

13.10.2009 12:25:43
Дайте мне доступ к базе данных, и я показать вам , почему вы не должны давать посторонним доступ к вашей базе данных.
MusiGenesis 13.10.2009 22:32:48
10 ОТВЕТОВ
РЕШЕНИЕ

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

32
13.10.2009 12:30:03
О, хорошая мысль. Уровень абстракции, обеспечивающий гибкость, огромен.
Bob Aman 13.10.2009 12:31:50

Можете ли вы помешать злоумышленнику создать сверхсложный SQL-запрос, который будет привязывать ЦП вашей базы данных к 100%? Можете ли вы помешать многим невинным программистам создавать неэффективные запросы, которые никогда не будут оптимизированы и будут выполнять то же самое?

28
13.10.2009 12:29:50
Нет ли доступных инструментов для установки таймаута в сценарии SQL?
Marius 13.10.2009 12:48:27
Конечно. Но запросы поступают асинхронно, и пока вы не достигнете тайм-аута, база данных (почти всегда ваше узкое место даже без этой схемы) будет по-прежнему выполнять тонну циклов ЦП. Мне все равно, как мало вы установите тайм-аут, я могу его использовать.
Bob Aman 13.10.2009 13:05:48
И даже в этом случае ни одна из этих проблем не затрагивает вопросы, которые поднимали все остальные: ни кеширование, ни масштабирование, ни гибкость, ни возможность изменять схемы, ни переносимость. Причин не делать этого бесчисленное множество. Это отличный вопрос, и я полностью понимаю, почему кто-то может кратко рассмотреть это, но никто никогда не должен пытаться делать это с тем, что им небезразлично. В качестве эксперимента попробуйте когда-нибудь выставить базу данных с заблокированным пользователем на виртуальной машине. Пригласите людей поиграть с этим. Я буду ошеломлен, если это продлится час.
Bob Aman 13.10.2009 13:13:05

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

-don

2
13.10.2009 12:30:52

Переносимость тоже. Допустим, по причинам лицензирования и масштабирования вы принимаете бизнес-решение перейти с MSSQL на MySql. Синтаксис не совсем одинаков, и все ваши клиенты должны будут изменить свой код.

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

3
13.10.2009 12:38:20

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

1
13.10.2009 12:34:14

API:

  • Упрощает мониторинг и контроль использования (реализация «ограниченных запросов на X» для пользователей БД может быть сложнее)
  • Позволяет представить пользователю более простые структуры, чем может использоваться в БД.
  • Означает, что пользователь не должен понимать структуру вашей БД.
  • Позволяет переносимость БД. (О, вы выросли массивно и теперь должны реализовать: шардинг, переход на bigtable и т. Д. - С API пользователь не должен знать)
  • Допускает различное (лучше? / Переменное?) Кеширование запросов.
  • Означает, что вам не нужно платить за дополнительных пользователей БД (если так лицензируется БД).
11
13.10.2009 14:01:44

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

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

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

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

10
13.10.2009 12:37:43

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

0
13.10.2009 13:59:57

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

Помимо этого, почему слой абстракции?

  • Возможно, вы когда-нибудь захотите добавить журналирование в запросы к базе данных для диагностики скорости или для отладки?
  • Можете ли вы когда-нибудь перейти с MySQL на MS SQL или наоборот, где SQL, кроме чистого ANSI, может сломаться?
  • Должен ли клиент действительно изучать вашу схему, а не более логическую абстракцию?
  • Когда новый программист узнает о нормализации и теперь может видеть всю вашу схему, включая ваши тщательно сбалансированные денормализации, вы хотите терпеть каждую неосведомленную критику?
  • Когда более опытный специалист по БД указывает на улучшения, вы хотите застрять в своей старой схеме?

Почему использовать API - это вопрос, почему стоит использовать абстракции, и мой список здесь едва царапает поверхность.

3
13.10.2009 12:51:47

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

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

1
13.10.2009 14:10:00
И действительно ли вы уверены, что ваша СУБД не содержит ошибок и что в анализаторе SQL нет ошибок повышения прав пользователя? Если есть такая ошибка, то она довольно катастрофическая («ооооооооооооооооооооооооучить в том, чтобы выполнить DROP DATABASE master» Простой хорошо продуманный API может создать дополнительный барьер (все же возможно, если вы запутались или плохо спроектировали свой API).
Chris J 13.10.2009 14:21:13