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



слушая интервью Скотта Хансельмана с командой переполнение стека (часть 1 и 2), Он был непреклонен в том, что SQL server и сервер приложений должны быть на разных машинах. Это просто чтобы убедиться, что если один сервер скомпрометирован, обе системы недоступны? Проблемы безопасности перевешивают сложность двух серверов (дополнительные расходы, выделенное сетевое соединение между ними, дополнительное обслуживание и т. д.), особенно для небольшого применения, где ни одна часть не использует слишком много процессора или памяти? Даже с двумя серверами, с одним сервером, скомпрометированным, злоумышленник все равно может нанести серьезный ущерб, либо удалив базу данных, либо испортив код приложения.



Почему это было бы большой проблемой, если производительность не является проблемой?

680   18  

18 ответов:

  1. безопасность. Ваш веб-сервер живет в DMZ, доступной для общего доступа в интернет и принимая ненадежные входные данные от анонимных пользователей. Если ваш веб-сервер скомпрометирован, и вы следовали правилам наименьших привилегий при подключении к своей БД, максимальное воздействие-это то, что ваше приложение может сделать через API базы данных. Если у вас есть бизнес-уровень между ними, у вас есть еще один шаг между вашим злоумышленником и вашими данными. Если, с другой стороны, ваша база данных находится на том же сервере, злоумышленник сейчас имеет корневой доступ к вашим данным и сервера.
  2. масштабируемость. Сохранение состояния веб-сервера позволяет вам горизонтально масштабировать веб-серверы довольно легко. Это очень трудно горизонтально масштабировать сервер баз данных.
  3. производительность. 2 коробки = 2 раза ЦП, 2 раза ОЗУ и 2 раза шпиндели для доступа к диску.

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

Это не действительно matter (вы можете вполне счастливо запустить свой сайт с web/database на той же машине), это просто самый простой шаг в масштабировании..

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

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

с другой стороны, ссылаясь на другой блог Скотта (Watermasyck, из Telligent) - они обнаружили, что большинство пользователей могут ускорить веб-сайты (используя сервер сообщества Telligent), поместив базу данных на ту же машину, что и веб-сайт. Однако в случае их клиента обычно сервер db & web является единственным приложением на этой машине, и веб-сайт не напрягает машину так сильно. Затем, эффективность не нужно отправлять данные по сети больше, что сделал для повышенных нагрузок.

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

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

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

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

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

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

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

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

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

Я согласен с Даниэлем Earwicker-вопрос безопасности в значительной степени ошибочен.

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

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

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

аналогично, на вопрос, заданный Kev ' как насчет всех других баз данных, находящихся на сервере БД? Все, что ты потерял-это один база данных.-

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

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

Вау, никто не поднимает тот факт, что если вы действительно покупаете SQL server за 5 тысяч долларов, вы можете использовать его для большего, чем ваше веб-приложение. Если вы используете экспресс, возможно, вам все равно. Я вижу, что SQL-серверы запускают базы данных для 20 до 30 приложений, поэтому размещение его на веб-сервере не было бы умным.

во-вторых, зависит от того, для кого предназначен сервер. Я работаю на финансовые компании и правительство. Поэтому мы используем сумасшедшую боль в заднице, используя только sprocs и ограничивая порты от веб-сервера до SQL. Поэтому, если веб-приложение будет взломано. Единственное, что может сделать хакер, это вызвать sprocs, поскольку учетная запись пользователя на веб-сервере заблокирована, чтобы видеть / вызывать sprocs в БД. Так что теперь хакер должен выяснить, как попасть в БД. Если на веб-сервере и его легко получить.

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

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

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

интересно, что могут сказать другие.

Я слушал этот подкаст, и это было забавно, но аргумент безопасности не имеет смысла для меня. Если вы скомпрометировали сервер A, и этот сервер может получить доступ к данным на сервере B, то вы мгновенно получаете доступ к данным на сервере B.

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

например, если у вас есть 1 сервер, выполняющий как веб-сайт, так и базу данных, содержащую 8 процессоров, вам придется заплатить за лицензию на 8 процессоров. Однако если у вас есть два сервера каждый с 4 процессорами и работает база данных на одном сервере вам придется платить только за 4 Лицензии процессора

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

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

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

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

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

операционная система-это еще одно соображение. Хотя для вашей базы данных может потребоваться больше места в памяти и, следовательно, UNIX, ваш веб - сервер или, более конкретно, ваш сервер приложений, поскольку вы упоминаете только два уровня, может быть основан на .Net и поэтому требует Windows.

ОК! Вот в чем дело, это более безопасно, чтобы ваш сервер БД установлен на другой машине и Ваше приложение на веб-сервере. Затем вы подключаете свое приложение к БД с помощью веб-ссылки. Спасибо ему.

Comments

    Ничего не найдено.