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


126

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?

Odpowiedzi:


158
  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.


27
Ale z 2 maszynami masz dwukrotnie
większe

4
@ TWith2Sugars - w przeciwieństwie do czego?
Kev,

3
Nr ref. punkt 1. Jeśli należy do warstwy internetowej, czego więcej chcesz lub potrzebujesz niż interfejs API aplikacji / bazy danych? Z pewnością w tym momencie gra się skończyła? Rzeczy stają się wtedy bardzo interesujące, jeśli chodzi o usługi wymagane do obsługi infrastruktury DMZ, np. Jakiekolwiek usługi AD lub Microsoft w grze?
Noelie Dunne

4
@Noelie - Twój poziom sieci nie miałby dostępu, aby powiedzieć, wykonać kopię zapasową bazy danych do pliku i przesłać ten plik do ftp.hackers.com za pomocą xp_cmdshell. Lub upuść bazę danych. Lub zmień wartości konfiguracyjne. itd.
Mark Brackett,

6
@kirgy - ponieważ te dwie maszyny są równoległe i każda z nich stanowi pojedynczy punkt awarii, ogólna niezawodność jest mniejsza; nie jest technicznie podwójny (w rzeczywistości wynosi 1 - (r1 * r2)), ale wystarczająco blisko, aby zapewnić dużą niezawodność i małe węzły .... W przypadku 0,01% byłoby to 0,0199%. Ale dla 100 węzłów byłoby to 36,6% zamiast 100% sugerowanych przez instrukcję podwajania.
Mark Brackett

45

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.


3
Zgadzam się, można to zrobić, gdy obciążenie jest małe ... wraz ze wzrostem obciążenia łatwo je rozdzielić na 2 lub więcej maszyn.
EJ Brennan

4
Wszedłem i zamierzałem skomentować to samo. Przełączenie serwera DB jest tak proste, jak zmiana parametrów połączenia (w większości przypadków).
CitizenBane

Uuh, podoba mi się to. Ktoś zastanawia się nad kontekstem, zanim zaproponuje rozwiązanie!
demisx

22

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.


4
... dopóki nie zwiększy się użycie równoczesne, a serwer db potrzebuje więcej pamięci, aby efektywnie wykorzystać bufory i pamięci podręczne. Gdy serwery WWW / aplikacji i bazy danych potrzebują więcej pamięci, niż mogą współdzielić w jednym urządzeniu, zwiększa się stronicowanie i dyskowe operacje wejścia / wyjścia, a wydajność spada.
kermatt

@MattK - ale co, jeśli masz ogromne ilości pamięci? Mamy aplikację, w której każdy klient ma własną bazę danych, więc zarówno baza danych, jak i serwery internetowe można bardzo łatwo skalować w poziomie. Biorąc pod uwagę, że mamy więcej pamięci niż używanego dysku (64 GB w porównaniu z ~ 40 GB), czy nie byłoby lepiej, gdyby wydajność była zachowana na tym samym komputerze?
Sygnał dźwiękowy

1
Jeśli twój zestaw roboczy mieści się w pamięci, możesz nie zauważyć żadnego z problemów z wydajnością, o których wspomniałem. Częściej serwery mają więcej dysku niż pamięci RAM, ale w twoim przypadku wydaje się, że masz bazy danych, które zmieszczą się w całości w pamięci RAM - o ile aplikacje na współdzielonym serwerze nie zużyją jej zbyt dużo.
kermatt

15

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.


12
A co, jeśli masz małą (ish) bazę danych, ale z mnóstwem pamięci? Czy koszt przejścia przez sieć dla każdego wywołania bazy danych, zwłaszcza jeśli jest ich wiele, nie przeważyłby nad korzyściami?
Sygnał dźwiękowy

1
@Tom Ritter Chociaż wydajność jest problemem (na tę odpowiedź i punkt # 3 w odpowiedzi Marka Bracketta) Wiem, że niektórzy ludzie (w tym ja) prawdopodobnie zainwestowaliby zaoszczędzone pieniądze, NIE mając oddzielnego serwera DB na WIĘCEJ procesora / pamięci RAM / itp. na jedynym serwerze, który go zastąpił. Dlatego należy to wziąć pod uwagę. Jeśli chodzi o pamięć oddzielną, usługi IIS i SQL można skonfigurować tak, aby uwzględniały ich konkurencję o zasoby. Osobiście „kicker” dla mnie był pierwszym punktem Marka ... bezpieczeństwo. Podoba mi się myśl o ograniczonym dostępie, jaki serwer WWW miałby do oddzielnego serwera DB.
Dylan - INNO Software,

@Tom, zawsze możesz podzielić przestrzeń pamięci na dwie oddzielne jednostki. Połowa dla serwera i połowa dla bazy danych.
Pacerier

15

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).


2
Jeśli korzystasz z czegoś innego niż SP, Twój serwer prawdopodobnie i tak ma pełny dostęp do danych w Twojej bazie danych
George Mauer

Dlaczego nie jest to opłacalne? Proszę sprecyzuj.
Robert Jeppesen

Robert, rozszerzyłem to i dodałem kilka uwag na temat skalowalności i utrzymania.
Dana the Sane

9

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.


Ale tworzysz kopię zapasową bazy danych, prawda? W przeciwnym razie byłbyś tak samo narażony na utratę go z powodu awarii sprzętu lub rzadko wzbudzanego błędu. Atak, który zabije serwer sieciowy, samoczynnie spowoduje przestój. Wystarczające uprawnienia do dodawania rekordów do tabel wystarczą, aby witryna stała się bezużyteczna.
Daniel Earwicker,

Oczywiście tworzysz kopię zapasową bazy danych, to niejawne, gdzie w moim poście zasugerowałem inaczej.
Kev

1
Tak, ale wniosek jest taki, że atak mający na celu wyłączenie witryny może to zrobić przez zniszczenie konfiguracji serwera WWW lub bazy danych, a rozwiązanie jest takie samo dla obu: przywrócenie z kopii zapasowej. Specjalna ochrona bazy danych jest (a) niepotrzebna i (b) i tak niemożliwa.
Daniel Earwicker,

@Earwicker - co ze wszystkimi innymi bazami danych znajdującymi się na serwerze DB? Straciłeś tylko jedną bazę danych.
Kev

8
Oprócz Daniela brakuje Ci OGROMNEGO punktu. Nie chodzi o kopię zapasową bazy danych, chodzi o zainfekowane dane. Czy Twoi klienci byliby w porządku, gdyby „haker ukradł wszystkie dane klientów i sprzedaży, ale nie martw się, mam kopię zapasową”. :)
Dylan - INNO Software

9

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.


6

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.


6

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ć.


5

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.


4

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.


2

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.


1
George, myślę, że powinieneś zapoznać się z odpowiedzią Marka Bracketta. Bezpieczeństwo twojego serwera WWW dla bazy danych NIE byłoby takie samo, jak byłoby, gdyby serwer był oddzielny. W szczególności „dysk lokalny” nie byłby dostępny. Ponadto, jeśli tylko jedna witryna (z wielu) została zhakowana, prawdopodobnie włamaliby się tylko na dostęp do bazy danych TEJ WITRYNY (chyba że używasz zbyt potężnego użytkownika dla tego ciągu połączenia). Istnieje niezliczona ilość innych scenariuszy, po prostu nie sądzę, aby komentarz tutaj był dla nich miejscem.
Dylan - INNO Software

2

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.


Nie prawda. Masz dostęp do wszelkich danych lub uprawnień, które Box A miał względem Box B. W bezpiecznej konfiguracji oznaczałoby to, że masz najwyższy poziom dostępu do bazy danych, jaki ma aplikacja na Box A. Nie masz jednak uprawnień do bazy danych ani rootowania w systemie operacyjnym Box B.
Mark Brackett,

2
„Masz dostęp do wszelkich danych lub uprawnień, które skrzynka A miała względem skrzynki B” - to właśnie miałem na myśli, mówiąc, że „masz natychmiastowy dostęp do danych na serwerze B”. Gdyby RDBMS znajdował się w pudełku A i nie było skrzynki B, jaka to różnica? NB. zakładamy, że zhakowałeś już pudełko A, tak czy inaczej.
Daniel Earwicker,

W konfiguracji dwuczęściowej, jeśli stosujesz zasadę najmniejszego przywileju, jeśli włamanie do skrzynki A (sieć) jest zagrożone, najgorsze, co powinno się stać, to utrata bazy danych w skrzynce B i nic więcej.
Kev

1
A w konfiguracji z jednym pudełkiem, jeśli to jedno pudełko zostanie naruszone, stracisz to jedno pudełko, które zawiera DB. Co za różnica?
Daniel Earwicker,

2
Różnica polega na tym, że w konfiguracji dwuskładnikowej, jeśli serwer WWW jest zagrożony, wszystko, co stracisz, to serwer WWW, aw najgorszym przypadku DB. Reszta integralności serwera DB jest zachowana.
Kev,

2

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


Proszę wyjaśnić, jak to przekłada się na oszczędności.
John Saunders

1
John - mówi, że aby uzyskać równoważną wydajność 2 maszyn, należałoby podwoić liczbę rdzeni, co podwoiłoby koszty licencjonowania SQL Server. Po co płacić dodatkowe 10-20 000 $ za SQL Server, skoro wszystko, co dostajesz, to taka sama wydajność, jak przy wykorzystaniu 2 maszyn.
Sygnał dźwiękowy

prawdziwe tylko wtedy, gdy wydajność / wykorzystanie zasobów (np. procesora) jest zdominowane przez serwery aplikacji, a nie przez serwer bazy danych. jeśli db potrzebuje 8 procesorów, to nie zadziała.
Andreas Dietrich

1

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.


-1

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.


1
Pierwotne pytanie dotyczyło serwerów aplikacji, niekoniecznie publicznych serwerów WWW z dostępem do Internetu.
João Bragança

-2

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.


Nie głosowałem negatywnie, ale „Twoja baza danych może wymagać większej ilości pamięci, a tym samym systemu UNIX” - jeśli używasz 64-bitowego systemu Windows i 64-bitowego języka SQL, jest mnóstwo pamięci do zabawy.
Kev

Przepraszamy, pamięć została pomyślana jako przykładowy powód do wdrożenia w podzielonych systemach operacyjnych. Inne powody to: wydajność, bezpieczeństwo, standardy korporacyjne / licencje, wsparcie dostawców itp.
Chris Noe,

-6

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.


3
dlaczego jest bezpieczniejszy?
Bryan Chen
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.