Один из клиентов компании, в которой я работаю, решил, что хочет хранить файлы в базе данных SQL (скорее всего, mySQL). Насколько я знаю, это возможно, просто сохраняя двоичный файл или содержащий файл внутри. Но вопрос не в этом.
Основная схема будет заключаться в том, что веб-страница хранится на одном сервере и в базе данных, а загруженные файлы на другом ИЛИ веб-странице в одной базе данных сервера в другой, а загруженные файлы внутри базы данных. У нас есть сомнения в следующем решении.
Основная причина - безопасность. Какие лучшие защитные решения в этой ситуации вы можете предложить? Меня беспокоит, что, взламывая sql-сервер, они получают файлы, так как sql-инъекционные разрывы более распространены, чем сервер, более того, что серверы внутри компании доступны только для истинного безопасного соединения, более того, если sql-сервер выйдет из строя, это будет боль в жопа восстанавливать все т.к. sql dumps будут весить тонну.
Я прошу аргументов и других решений этой ситуации.
Хранение файлов в базе данных означает добавление специального кода для обработки доступа к файлам. Хотя это дает возможность реализовать сложные модели безопасности, которые напрямую не поддерживаются базовой операционной системой, чем больше кода вы добавляете, тем выше вероятность внедрения ошибок, которые могут поставить под угрозу безопасность / целостность данных.
Хотя я должен признать, что я не большой специалист по SQL Server (но я кое-что знаю о mysql), этот подход требует, чтобы код выполнялся с привилегиями суперпользователя в домене данных; в отличие от обычного доступа к файлам, здесь нет разделения привилегий. Таким образом, если система скомпрометирована, она будет полностью скомпрометирована. В отличие от ситуации, когда учетная запись пользователя ОС скомпрометирована - уязвимость значительно снижается. Сравните это с проблемами, связанными с вирусами на платформах Microsoft по сравнению с платформами Unix - писать вирусы для Unix несложно, - но до недавнего времени большинство систем Microsoft не требовали разделения привилегий.
серверы внутри компании доступны только истинное безопасное соединение
Не очень большое преимущество - посмотрите статистику компрометации данных - в любом случае большинство из них являются внутренними.
восстановить все будет головной болью, так как sql-дампы будут весить тонну
Верно, хотя делать многораздельное / инкрементное резервное копирование в базе данных намного проще, чем в файловой системе, но опять же это означает добавление большего количества кода = добавление большего количества ошибок. Большая проблема в том, что это нестандартный способ работы. Хотя вы можете быть уверены, что младший сотрудник может появиться на вашем сайте аварийного восстановления с резервной копией файловой системы и легко восстановить данные, сделать то же самое с резервной копией приложения - это совсем другое дело. И, конечно, вы гораздо более ограничены в выборе инструментов, которые вы используете для автоматического доступа к вашим файлам (резервное копирование, антивирусное сканирование, дедупликация, архивирование ...).
Кроме того, доставив файлы через HTTP, вы потеряли контроль над параллелизмом над файлами.
Еще одно соображение заключается в том, что, конечно же, с mysql, когда таблица превышает пространство на одном диске, добавление дополнительной емкости не является тривиальным.
Некоторые из этих эффектов можно смягчить, сохранив файлы в файловой системе, но предоставив веб-интерфейс. Если вы все сделаете правильно, вы все равно сможете использовать разделение привилегий (запустив веб-сервер в качестве прокси между браузером и отдельным пользователем / сеансом, обрабатывающим фактический ввод-вывод, выполняемый с привилегией аутентифицированного пользователя). Но вы все еще потеряли контроль над параллелизмом, и есть другие типы уязвимостей, которые можно использовать.
Как компания, оказывающая ИТ-услуги, это отличный способ получить деньги от вашего клиента - продать им то, что им не нужно, заставить их хранить свои ключевые активы, используя это, а затем выставить счет за поддержку. Но с точки зрения клиента это очень плохая идея.