Aplikacja typu saas - architektura Opcje

[tczajka]

Witam wszystkich.
Zaczynam pracę nad projektowaniem i pisaniem pewnej aplikacji w modelu saas gdzie przewiduję takie mniej więcej elementy:
- panel admin najwyższego rzędu gdzie będą zakładane/generowane konta klientów w skład których będa wchodzić poniższe części:
- panel admin (klienta) dla zarządzania bazą użytkowników, przydzielaniem usług, definiowaniem usług itp (wszystko w ramach jednego klienta)
- panel usera do zarządzania i do-konfigurowania przez usera założonego na poziomie wyżej
- strona usera do prezentacji treści usera (np konkretnych usług oferowanych przez usera-klienta)
Przykładem może tu być aplikacja do zarządzania hurtowniami gdzie zakładamy konta np dla Hurtowni 1, Hurtowni 2 itpp. W nich tworzeni są konta dla pracowników do zarządzania ofertą itp.

Zastanawiam się tutaj nad 3 możliwościami:
1. Tworzyć wszystko na jednym adresie, jednej bazie danych (jeden handler dla wszystkich kont) i ograniczać dostęp do poszczególnych danych odpowiednio implementując system autoryzacji itp
2. Tworzyć wszystko na jednym adresie , ale każdy klient będzie na osobnej bazie danych separując tym samym dane jednego klienta od drugiego (istotne w razie włamu)
3. Tworzyć osobną aplikację do admina adminów np na innym adresie (gdzie będą zakładani Ci duzi klienci, np hurtownie), oraz osobną dla klientów (tutaj to samo jak wyżej albo na jednej bazie wszyscy klienci albo każdy na osobnej)

Podział na osobne bazy danych rodzi tylko więcej roboty z zakładaniem kont (jakiś manager handlerów do DB). Z założenia nie będzie tam dziur ale moje rozważania wynikają głównie z obawy że podczas włamu atakujący dostanie dostęp do wszystkich klientów, podczas gdy gdyby każdy klient był na osobnej bazie szkody mogą zostać ograniczone.

Co o tym sądzicie? Które rozwiązanie wg Was jest lepsze i dlaczego lub dlaczego nie? Inne rozwiązanie?
pozdrawiam

[Crozin]

Tak tylko dla upewnienia się, że rozmawiamy o tym samym. Rozważamy dwa podejścia:

1. Proponowane przez @nrm, jedna baza danych dla wszystkich aplikacji w obrębie platformy.
   Takie podejście wiązało by się z koniecznością dodania w niemal każdej tabeli, kolumny pozwalającej na ustalenie, której aplikacji dotyczy dany wpis. Kolumna ta musiałaby być również ujęta w niemal każdym zapytaniu SQL.

   [SQL] pobierz, plaintext 
   CREATE TABLE users (
       id ...,
       username ...,
       ...,
       application ...
   ) ... ;
   [SQL] pobierz, plaintext 

   [SQL] pobierz, plaintext 
   SELECT ... FROM users WHERE ... AND application = 'aplikacja #1';
   [SQL] pobierz, plaintext 

   Napisałem, że w niemal każdym, ponieważ są przypadki gdzie przykładowo dane z tabeli z preferencjami użytkownika będą wybierane wyłącznie w połączeniu (JOIN) z tabelą samych użytkowników, a w tym przypadku wystarczy nam kolumna rozróżniająca jedynie w drugiej tabeli.
2. Proponowane przeze mnie, osobna baza danych dla każdej aplikacji w platformie. Tutaj chyba nie trzeba niczego przedstawiać.

Odnośnie PO CO padł tutaj tylko jeden argument - bezpieczeństwa - który dla mnie akurat jest złudny. Jeżeli przejrzysz historię jakiś ostatnich popularnych "włamów" to zobaczysz, że na ogół kończyło się to całym dostępem roota tudzież całym wejściem na bazę, w takich sytuacjach bez znaczenia ile tych baz masz z osobna.

Oczywiście, w przypadku gdy włamywacz uzyskuje dostęp do roota, uprawnienia poszczególnych użytkowników nie mają już znaczenia. Jednak zdarzają się sytuacje, gdzie włamywacz uzyskuje dostęp jedynie do lokalnego użytkownika (nie wiem, które z nich są częstsze), a tutaj taka forma zabezpieczenia jest już bez wątpienia przydatna. Nie nazwałbym tego zabezpieczenia złudnym. Co najwyżej powiedziałbym, że chroni w określonych przypadkach i raczej nigdy nie szkodzi.

Po trzecie, nie wyobrażam sobie zarządzania taką aplikacją, która ma setki tysięcy osobnych baz

Jak rozumiem, chodziło Ci o zarządzanie całą platformą (która posiada wiele aplikacji i wiele baz), nie pojedynczą aplikacją (która posiada jedną bazę), tak? Tutaj właściwie jedyny problem jaki widzę to zbieranie informacji z wielu aplikacji na raz, przykładowo "łączna ilość użytkowników we wszystkich aplikacjach", albo "najczęściej używana domena w adresach email we wszystkich aplikacjach" - czyli głównie dane statystyczne. Tutaj jedna baza danych dla wszystkich faktycznie ułatwia życie (zwykłe, pojedyncze zapytanie ignorujące kolumnę application, bez żadnego dodatkowego przetwarzania danych). W przypadku wielu baz danych musielibyśmy osobno pobrać dane z każdej z baz i dopiero na końcu - mając już wszystkie dane - jeszcze raz je przetworzyć w celu uzyskania finalnych wyników. Jest też drugie rozwiązanie jakie na szybko przychodzi mi do głowy, tj. każda z aplikacji samodzielnie publikuje te dane, po czym aplikacja od zarządzania całą platformą sczytuje jedynie te dane.

Poczynając od kwestii deweloperki, a kończąc na kopiach bezpieczeństwa.

Jeżeli chodzi o deweloperkę to szczerze nie rozumiem w czym problem. Niezależnie od tego, które rozwiązanie wybierzemy będziemy potrzebowali osobnej kopii bazy danych z przykładowymi danymi (w przypadku rozwiązania #1) bądź kilku w przypadku punktu (chociaż w przypadku rozwiązania #2 i tak większość czasu będziemy pracowali wyłącznie z jedną bazą). Tutaj zapewne chodziło Ci o problem przy wprowadzaniu zmian w strukturze bazy danych. Powiedzmy, że chcemy dodać dodatkową kolumnę do jakiejś tabeli. W przypadku pierwszego rozwiązania odpalamy po prostu w konsoli bazy danych ALTER TABLE ..., w przypadku drugiego wpisujemy to do jakiegoś pliku i odpalamy bardzo prosty skrypt synchronizujący to pomiędzy wszystkimi deweloperskimi bazami - na prawdę nie jest to zbyt duży nakład pracy, a przy okazji mamy rozwiązany problem wersjonowania bazy danych. (IMG:style_emoticons/default/wink.gif) Jeżeli chodzi o kopie bezpieczeństwa również nie wiem gdzie może leżeć problem.

Teraz chciałbym jeszcze przedstawić na szybko kilka wad i zalet każdego rozwiązania.

• Rozwiązanie #1 - jedna baza danych.
  • Zalety:
    1. łatwiejsze operowanie na danych dot. wielu aplikacji
    2. jedna baza danych to jeden problem na głowie, nie trzeba przygotowywać skryptów do instalacji nowych; nadal trzeba przygotować takowe dla instalacji samej aplikacji - więc nie jest to jakiś wielki postęp,
    3. ?
• Wady:
  1. brak możliwości ustawienia indywidualnych "ficzerów" dla konkretnej aplikacji - przykładowo klient A chciałby za dopłatą korzystać z bardziej stabilnej bazy danych, która ma włączoną replikację na wiele serwerów, podczas gdy klientowi B nie zależy na czymś takim; innym przykładem może być konieczność dodania jakiejś procedury/wyzwalacza, która pracuje na tabelach dostępnych dla wszystkich klientów oraz tabelach dostępnych tylko dla niektórych użytkowników, którzy wykupili jakąś usługę dodatkową - w takim przypadku trzeba albo się solidnie nagimnastykować przy implementacji tego, albo wykonywać to dla wszystkich, a użytkownikom bez dodatkowej usługi po prostu nie wyświetlać pewnych danych/informacji - to może nieść za sobą duże koszty,
  2. wszystkie aplikacje muszą muszą korzystać z dokładnie tej samej struktury bazy danych,
  3. trzeba w bardzo wielu miejscach uwzględniać tą nieszczęsną kolumnę rozróżniającą aplikacje,
  4. konieczność wyłączenia wszystkich aplikacji w platformie w przypadku jakichkolwiek modyfikacji bazy danych, a to potrafi przy dużych bazach danych trwać naprawdę długo - ogromny minus

Rozwiązanie #2 - wiele baz danych., to właściwie to odwrotność powyższej listy.

• Zalety:
  1. możliwość nieograniczonego "customizowania" poszczególnych baz danych - jednak trzeba tutaj pamiętać o zachowaniu rozsądku, inaczej może się to przerodzić w wadę
  2. możliwość modyfikowania kolejnych baz danych bez konieczności wyłączania całej platformy
  3. nieco zwiększone bezpieczeństwo
  4. łatwiejsza praca na poziomie aplikacji (klienta)
  5. bezproblemowa możliwość wykorzystaniu wielu maszyn do obsługi baz danych w obrębie platformy

Wady:

1. konieczność przygotowania pewnych narzędzi pozwalających nanieść zmiany na wszystkie bazy danych
2. trudniejsza praca na poziomie aplikacji do obsługi platformy
3. przy ilości baz danych liczonych w dziesiątkach tysięcy zapewne pojawią się problemy przy zarządzaniu tym, ale myślę, że mniejsze niż w przypadku jednej gigantycznej bazie, której rozmiar liczony byłby w setkach GiB czy nawet TiB

Wygląda na to, że autor jednak nie będzie miał do czynienia z SaaS, nie mniej jednak chciałbym pociągnąć ten wątek. (IMG:style_emoticons/default/wink.gif)