We wdrażaniu oprogramowania systemy z wieloma dzierżawcami mają sens w przypadku oddzielania zespołów lub różnych klientów z różnymi przypadkami użycia. W idealnym przypadku dzierżawca jest oddzielony tak, jakby działał w swoim własnym systemie i ma wszystkie opcje konfiguracji i opcje bezpieczeństwa sieci indywidualnie skonfigurowane.

Z drugiej strony, złożoność powinna być nadal możliwa do zarządzania, aby zapewnić szybką analizę błędów i szybkie wdrożenie nowego personelu.

W tym wpisie chciałbym przeanalizować niektóre koncepcje i pomysły, a także najlepsze praktyki. Najpierw przyjrzyjmy się wspólnym koncepcjom i pomysłom.

Ogólnie rzecz biorąc, domyślne wzorce są przydatne do wdrażania nowych funkcji. Oczywiście każdy cel/rozwiązanie programowe jest unikalne i musi być planowane indywidualnie.

Jestem wdzięczny za wszelkie komentarze i dyskusje. To jest mój obecny punkt widzenia, który może ulec zmianie w przyszłości.

Bazy danych

Większość środowisk ma trwałość w jakiejś bazie danych. Może to być dokument, graf, relacja lub inna koncepcja.

Możliwe są następujące podziały:

• Wszystkie dane w jednym schemacie: połączenie dzierżawcy określone poprzez odniesienia do dzierżawcy. Połączenie krzyżowe jest łatwe.
• Własny schemat dla każdego dzierżawcy: dostęp każdego dzierżawcy wymaga oddzielnego uwierzytelnienia.

Dodatkowo może istnieć schemat zarządzania, zawierający ogólne informacje i odniesienia do dzierżawców, może to być ogólny schemat bazy danych lub może być zdefiniowany w konfiguracji.

Chociaż złożoność jest wyższa, najczęściej wybierałbym podejście oparte na wielu schematach. Większa złożoność dotarcia do danych innych dzierżawców z kontekstu jest znacznie trudniejsza. W tym podejściu trwałe dane mogą być nawet fizycznie oddzielone.

Uwierzytelnianie

Autoryzacja jest jedną z podstawowych bram bezpieczeństwa. Ogólnie rzecz biorąc, należy stosować ustandaryzowane i przetestowane podejścia. Aktualnym stanem techniki jest OAuth2/OIDC, który jest otwartym standardem, zintegrowanym z wieloma frameworkami, a bezpieczeństwo i najlepsze praktyki są szeroko dostępne.

Oto dwie koncepcje:

• Jeden dostawca tożsamości
• Oddzielni dostawcy tożsamości

Dostawca tożsamości (IDP) może być również REALM lub aplikacją, w zależności od sformułowania.

Pod względem technologicznym najłatwiej jest mieć jednego dostawcę. w kodzie źródłowym należy sprawdzić tylko jeden IAM, a zmiany w informacjach/strukturze tokena należy wprowadzić dla wszystkich dostawców tożsamości. W przypadku jednego dostawcy tożsamości dzierżawca musi znajdować się w tokenie, aby zweryfikować dostęp do zasobów.

Z drugiej strony znacznie trudniej jest uzyskać ważny token dostępu z eskalowanymi uprawnieniami od innego dostawcy tożsamości. W tym przypadku na przykład podczas logowania strona logowania przekierowuje do właściwego IDP lub odniesienie do właściwego IDP znajduje się w adresie URL / FQDN.

Usługi

Patrząc na koszty zasobów, celem jest przydzielenie jak najmniejszej liczby zasobów. Dlatego w większości przypadków sensowne jest współdzielenie instancji usługi i sprawdzanie dzierżawcy w jej obrębie.

W przypadku bezpieczniejszych środowisk sensowne może być wdrożenie oddzielnej usługi, która uzyskuje dostęp tylko do danych podłączonego dzierżawcy. W takim przypadku tylko usługi zajmujące się wrażliwymi danymi powinny być skalowane w ten sposób. Dane mogą być następnie przekazywane do właściwej usługi przez bramę. Ma to sens, gdy wszystkie usługi między wywołaniem użytkownika a usługą obsługującą informacje są oddzielnymi usługami, aby zapewnić brak dostępu z innych dzierżawców.

Konfiguracja

Wyzwanie związane z konfiguracją polega na tym, że jest ona często ładowana wraz z uruchomieniem usługi. Jedną z możliwości jest nieużywanie natywnej logiki konfiguracji i ładowanie wszystkich konfiguracji z bazy danych/danych dzierżawcy, gdy są one dostępne. Inną możliwością jest załadowanie mapy konfiguracji.

Niektóre ustawienia dotyczące całej usługi, takie jak port, nagłówki TLS lub takie parametry, można skonfigurować tylko dla usługi, w takim przypadku należy zweryfikować podejście wielousługowe, jak opisano wcześniej.

Logowanie

Każde rejestrowanie specyficzne dla dzierżawcy musi zawierać odniesienie do dzierżawcy w metadanych.

W środowisku zorientowanym na usługi centralne rejestrowanie powinno być zawsze ustanowione dla SIEM i ogólnego przeglądu audytu. Istnieje więc możliwość filtrowania wszystkich dzienników dla określonego dzierżawcy.