Dlaczego nie zaleca się posiadania bazy danych i serwera WWW na tym samym komputerze?

Słuchając wywiadu Scotta Hanselmana z zespołem Stack Overflow ( część 1 i 2 ), był nieugięty, że serwer SQL i serwer aplikacji powinny znajdować się na osobnych maszynach. Czy ma to na celu upewnienie się, że w przypadku naruszenia bezpieczeństwa jednego serwera oba systemy nie będą dostępne? Czy obawy dotyczące bezpieczeństwa przewyższają złożoność dwóch serwerów (dodatkowy koszt, dedykowane połączenie sieciowe między nimi, więcej konserwacji itp.), Szczególnie w przypadku małej aplikacji, w której żaden z elementów nie zużywa zbyt dużo procesora lub pamięci? Nawet w przypadku dwóch serwerów, z których jeden zostałby przejęty, osoba atakująca może wyrządzić poważne szkody, usuwając bazę danych lub mieszając kod aplikacji.

Dlaczego miałoby to być takie ważne, jeśli wydajność nie jest problemem?

1. Bezpieczeństwo. Twój serwer sieciowy znajduje się w strefie DMZ, dostępnej dla publicznego Internetu i przyjmującej niezaufane dane od anonimowych użytkowników. Jeśli Twój serwer sieciowy zostanie naruszony, a podczas łączenia się z bazą danych przestrzegałeś zasad najmniejszych uprawnień, maksymalna ekspozycja to to, co Twoja aplikacja może zrobić za pośrednictwem interfejsu API bazy danych. Jeśli masz pośrednią warstwę biznesową, masz jeszcze jeden krok między napastnikiem a danymi. Z drugiej strony, jeśli Twoja baza danych znajduje się na tym samym serwerze, osoba atakująca ma teraz uprawnienia administratora do Twoich danych i serwera.
2. Skalowalność. Utrzymanie bezstanowego serwera WWW umożliwia bezproblemowe skalowanie serwerów WWW w poziomie. Skalowanie w poziomie serwera bazy danych jest bardzo trudne.
3. Występ. 2 pudełka = 2 razy procesor, 2 razy pamięć RAM i 2 razy wrzeciona dla dostępu do dysku.

Biorąc to wszystko pod uwagę, z pewnością widzę rozsądne przypadki, w których żaden z tych punktów nie ma znaczenia.

To nie naprawdę materia (można dość szczęśliwie uruchomić stronę z internetowej / bazy danych na tym samym komputerze), to po prostu najłatwiejszy krok w skalowaniu ..

To jest dokładnie to, co zrobił StackOverflow - zaczynając od jednej maszyny z uruchomionym IIS / SQL Server, a potem, kiedy zaczął się mocno obciążać, kupiono drugi serwer i przeniesiono na niego serwer SQL.

Jeśli wydajność nie jest problemem, nie trać pieniędzy na zakup / utrzymanie dwóch serwerów.

Z drugiej strony, odnosząc się do innego blogującego Scotta (Watermasyck, z Telligent) - odkryli, że większość użytkowników może przyspieszyć działanie witryn internetowych (korzystając z serwera społeczności Telligent), umieszczając bazę danych na tym samym komputerze co strona internetowa. Jednak w przypadku ich klientów zazwyczaj serwery db i web są jedynymi aplikacjami na tym komputerze, a strona internetowa nie obciąża zbytnio maszyny. Następnie wydajność polegająca na tym, że nie trzeba przesyłać danych przez sieć więcej, niż rekompensuje zwiększone obciążenie.

Myślę, że dużym czynnikiem będzie wydajność. Zarówno kod serwera internetowego / aplikacji, jak i SQL Server buforowałyby w pamięci często żądane dane, a Ty zmniejszasz wydajność pamięci podręcznej, uruchamiając je w tej samej przestrzeni pamięci.

Tom ma rację w tej kwestii. Z innych powodów jest to nieopłacalne i istnieją dodatkowe zagrożenia bezpieczeństwa.

Serwery WWW mają inne wymagania sprzętowe niż serwery baz danych. Serwery baz danych radzą sobie lepiej z dużą ilością pamięci i naprawdę szybką macierzą dyskową, podczas gdy serwery WWW wymagają tylko wystarczającej ilości pamięci do buforowania plików i częstych żądań bazy danych (w zależności od konfiguracji). Jeśli chodzi o efektywność kosztową, oba serwery niekoniecznie będą tańsze, jednak stosunek wydajności do kosztów powinien być wyższy, ponieważ nie musisz konkurować o zasoby z różnymi aplikacjami. Z tego powodu prawdopodobnie będziesz musiał wydać dużo więcej na jeden serwer, który obsługuje oba i oferuje wydajność równoważną 2 wyspecjalizowanym.

Problem z bezpieczeństwem polega na tym, że jeśli pojedyncza maszyna zostanie naruszona, zarówno serwer sieciowy, jak i baza danych są podatne na ataki. Mając dwa serwery, masz trochę wolnego miejsca, ponieważ drugi serwer będzie nadal bezpieczny (przynajmniej przez chwilę).

Istnieją również pewne korzyści związane ze skalowalnością, ponieważ może być konieczne utrzymywanie tylko kilku serwerów baz danych, które są używane przez kilka różnych aplikacji internetowych. W ten sposób masz mniej pracy do wykonania przy stosowaniu uaktualnień lub poprawek i dostrajaniu wydajności. Uważam jednak, że istnieją narzędzia do zarządzania serwerem, które ułatwiają te zadania (w przypadku pojedynczego komputera).

Bezpieczeństwo jest głównym problemem. W idealnym przypadku serwer bazy danych powinien znajdować się za zaporą ogniową z otwartymi tylko portami wymaganymi do uzyskania dostępu do danych. Twoja aplikacja internetowa powinna łączyć się z serwerem bazy danych za pomocą konta SQL, które ma wystarczające uprawnienia do działania aplikacji i nic więcej. Na przykład powinieneś usunąć prawa, które pozwalają na upuszczanie obiektów, a na pewno nie powinieneś łączyć się przy użyciu kont takich jak „sa”.

W przypadku utraty serwera WWW w wyniku przejęcia (tj. Pełnej eskalacji uprawnień do uprawnień administratora), najgorszym scenariuszem jest to, że baza danych aplikacji może zostać naruszona, ale nie cały serwer bazy danych (tak jak w przypadku serwer bazy danych i serwer WWW to ta sama maszyna). Jeśli zaszyfrowałeś parametry połączenia z bazą danych, a haker nie jest wystarczająco sprytny, aby je odszyfrować, straciłeś tylko serwer sieciowy.

Jednym z czynników, o których jeszcze nie wspomniano, jest równoważenie obciążenia. Jeśli zaczniesz myśleć o serwerze WWW i bazie danych jako oddzielnych maszynach, zoptymalizujesz je pod kątem mniejszej liczby obiegów sieci, a także łatwiej będzie dodać drugi serwer WWW lub drugi silnik bazy danych w miarę wzrostu potrzeb.

Z własnego doświadczenia mogę powiedzieć, że często dobrym pomysłem jest umieszczenie serwera WWW i bazy danych na różnych maszynach. Jeśli masz aplikację, która wymaga dużej ilości zasobów, może łatwo spowodować szczytowe cykle procesora na komputerze, co zasadniczo spowoduje jej zatrzymanie. Jeśli jednak Twoja aplikacja ma ograniczone wykorzystanie bazy danych, prawdopodobnie nie byłoby problemu, gdyby współużytkowali serwer.

Wow, nikt nie wspomina o tym, że jeśli faktycznie kupisz serwer SQL za 5 tysięcy dolarów, możesz chcieć używać go do czegoś więcej niż tylko aplikacji internetowej. Jeśli używasz ekspresu, może cię to nie obchodzi. Widzę, że serwery SQL obsługują bazy danych dla 20 do 30 aplikacji, więc umieszczenie ich na serwerze WWW nie byłoby mądre.

Po drugie, zależy od tego, dla kogo jest przeznaczony serwer. Pracuję dla firm finansowych i rządu. Więc używamy szalonego podejścia do używania tylko SPROC i ograniczania portów z serwera WWW do SQL. Więc jeśli aplikacja internetowa zostanie zhakowana. Jedyną rzeczą, jaką może zrobić haker, jest wywołanie sprocsów, ponieważ konto użytkownika na serwerze WWW jest zablokowane, aby widzieć / wywoływać sproces tylko w bazie danych. Więc teraz haker musi dowiedzieć się, jak dostać się do bazy danych. Jeśli jest na serwerze internetowym, łatwo się do niego dostać.

Zgadzam się z Danielem Earwickerem - pytanie zabezpieczające jest prawie błędne.

Jeśli masz konfigurację pojedynczego urządzenia z serwerem WWW i tylko bazą danych dla tego serwera WWW, jeśli ten serwer sieciowy zostanie naruszony, tracisz zarówno serwer WWW, jak i bazę danych tylko dla tej konkretnej aplikacji.

To jest dokładnie to samo, co dzieje się, jeśli stracisz serwer WWW w konfiguracji z dwoma serwerami. Utracisz serwer WWW i bazę danych dla tej konkretnej aplikacji.

Argument, że `` pozostała integralność serwera bazy danych jest zachowana '', gdy masz konfigurację z dwoma serwerami, jest nieistotny, ponieważ w pierwszym scenariuszu każdy inny serwer bazy danych powiązany z każdą inną aplikacją (jeśli istnieje) również pozostaje nienaruszony - przebywanie w obecnej postaci w innym miejscu.

Podobnie jak w przypadku pytania zadanego przez Keva: „A co ze wszystkimi innymi bazami danych znajdującymi się na serwerze DB? Straciłeś tylko jedną bazę danych.

• gdybyś hostował aplikację i bazę danych na jednym serwerze, udostępniałbyś tylko bazy danych na tym serwerze, które są powiązane z tą aplikacją. Dzięki temu nie stracisz żadnych dodatkowych baz danych w konfiguracji z jednym serwerem w porównaniu z konfiguracją z wieloma serwerami.

Z kolei w konfiguracji z dwoma serwerami, gdzie osoba atakująca miała dostęp do serwera internetowego i przez proxy, ograniczone prawa (w najlepszym przypadku) do serwera bazy danych, może narazić bazy danych każdej innej aplikacji na ryzyko, przenosząc wolne, wymagające dużej ilości pamięci zapytania lub maksymalizacja dostępnego miejsca na serwerze bazy danych. Rozdzielając aplikacje na ich własne problemy, podobnie jak w przypadku wirtualizacji, izolujesz je również ze względów bezpieczeństwa w pozytywny sposób.

To zależy od zastosowania i celu. Gdy wysoka dostępność i wydajność nie są krytyczne, nie jest źle nie oddzielać bazy danych od serwera WWW. Zwłaszcza biorąc pod uwagę wzrost wydajności - jeśli aplikacja wykonuje dużą liczbę zapytań do bazy danych, można usunąć znaczną część obciążenia sieci, utrzymując ją w tym samym systemie, utrzymując krótkie czasy odpowiedzi.

Myślę, że to dlatego, że te dwie maszyny zwykle wymagałyby optymalizacji na różne sposoby. Poza tym nie mam pojęcia, uruchamiamy wszystkie nasze aplikacje z bazą danych serwera na tej samej maszynie - zakładając, że nie jesteśmy publicznie dostępni - ale nie mieliśmy żadnych problemów.

Nie mogę sobie wyobrazić, że zbyt wiele osób przejmuje się zagrożeniem dla jednej maszyny z obu, ponieważ aplikacja internetowa będzie miała zwykle prawie nieograniczony dostęp do przynajmniej danych, jeśli nie schematu w bazie danych.

Zainteresowany tym, co mogą powiedzieć inni.

Słuchałem tego podcastu i było to zabawne, ale argument dotyczący bezpieczeństwa nie miał dla mnie sensu. Jeśli włamałeś się na serwer A, a serwer ten może uzyskać dostęp do danych na serwerze B, natychmiast masz dostęp do danych na serwerze B.

Licencje na bazy danych nie są tanie i często są naliczane według liczby procesorów, dlatego oddzielając serwery internetowe, można obniżyć koszt licencji na bazy danych.

Np. Jeśli masz 1 serwer obsługujący zarówno sieć, jak i bazę danych, który zawiera 8 procesorów, będziesz musiał zapłacić za licencję na 8 procesorów. Jeśli jednak masz dwa serwery, każdy z 4 procesorami i uruchomisz bazę danych na jednym serwerze, będziesz musiał zapłacić tylko za licencje na 4 procesory

Dodatkowym problemem jest to, że bazy danych lubią zajmować całą dostępną pamięć i przechowywać ją w rezerwie, gdy chcą z niej skorzystać. Możesz wymusić ograniczenie pamięci, ale może to znacznie spowolnić dostęp do danych.

Twierdzenie, że uruchomienie serwera bazy danych na serwerze sieciowym daje rzeczywisty wzrost wydajności, jest błędnym argumentem.

Ponieważ serwery baz danych pobierają ciągi zapytań i zwracają zestawy wyników, dane faktycznie przepływające z serwera danych do serwera WWW są stosunkowo małe, ale moc wymagana do przetworzenia zapytania i wygenerowania zestawu wyników jest stosunkowo duża. Dlatego optymalizacja wydajności w zakresie czasu przesyłania danych polega na optymalizacji pod kątem niewłaściwych rzeczy.

Jeśli chodzi o bezpieczeństwo, posiadanie serwera danych w innym urządzeniu niż serwer WWW ma zalety. Posiadanie takiej konfiguracji to nie wszystko i koniec z bezpieczeństwem, ale to krok we właściwym kierunku.

Jeśli chodzi o skalowalność, dodawanie serwerów internetowych i umieszczanie ich w klastrze w celu obsługi zwiększonego ruchu jest łatwe i stosunkowo tanie. Dodanie serwerów danych i ich klaster nie jest takie proste i tanie. Ponadto serwery internetowe i serwery danych mają różne wymagania sprzętowe, więc wiele pudełek pomaga w skalowalności.

Jeśli zaczynasz od małego i masz tylko jedno pudełko, dobrym sposobem byłoby użycie maszyn wirtualnych. Uruchomienie serwera WWW i serwera danych na różnych maszynach wirtualnych na jednym hoście daje wszystkie korzyści z oddzielnych pudełek za cenę jednego dużego pudełka.

System operacyjny to kolejna kwestia. Chociaż Twoja baza danych może wymagać większych przestrzeni pamięci, a tym samym systemu UNIX, Twój serwer sieci Web - a dokładniej serwer aplikacji, ponieważ wymieniasz tylko dwie warstwy - może być oparty na .Net i dlatego może wymagać systemu Windows.

Dobrze! Chodzi o to, że bezpieczniej jest mieć serwer bazy danych zainstalowany na innym komputerze, a aplikację na serwerze internetowym. Następnie łączysz swoją aplikację z bazą danych za pomocą łącza internetowego. Dzięki.