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]

1. Każda aplikacja w obrębie Twojej platformy powinna działać na osobnej bazie danych.
1.1. Pomyśl tylko co by było w przypadku gdyby klient A chciał korzystać z wersji 1.0.0, a klient B 1.1.0. Utrzymywanie aplikacji polegających na innych schematach bazy danych (zakładamy, że pomiędzy wersjami coś się pozmieniało) byłoby koszmarem.
1.2. Łatwość zarządzania. Utworzenie nowej bazy danych to na dobrą sprawę dwa polecenia SQL. Jedno tworzące bazę danych i drugie tworzące jej całą strukturę wraz z wymaganymi danymi początkowymi wykonywane z poziomu odpowiednio przygotowanego wcześniej pliku (LOAD FILE). Dzięki temu operacje na bazie z poziomu samej aplikacji nie muszą uwzględniać występowania innych serwisów w tej samej bazie co musiałbyś robić przy absolutnie każdym zapytaniu, podzapytaniu czy innych procedurach i wyzwalaczach - kolejny koszmar.
1.3. Bezpieczeństwo. Łatwo możesz utworzyć dla takiej bazy danych użytkowników z odpowiednimi uprawnieniami, a w przypadku ataku na daną aplikację i wycieku jej bazy danych dane innych klientów prawdopodobnie zostaną nietknięte.
2. Aplikacja obsługująca całą platformę powinna działać jako kompletnie osobny projekt - w końcu będzie ona zajmować się zupełnie innymi sprawami i operować na innych danych.
3. Od samego początku powinieneś pomyśleć nad skalowalnością Twojej platformy. Jeżeli nie masz środków/możliwości skorzystania z własnej infrastruktury w tym celu pomyśl nad wykorzystaniem popularnych ostatnim czasy chmur.