Use case

Załóżmy, że pojedyńczy użytkownik ma $N$ domów, w których podpiętych ma $N_2$ czujników oraz $N_3$ urządzeń wykonawczych pod hub. Chciałby móc zdalnie, z poziomu przeglądarki podglądać stan czujników z wszystkich domów i sterować urządzeniami wykonawczymi, jednocześnie będąc odpornym na włamania z zewnątrz. Użytkownik chce dodatkowo zarządzać konfiguracją urządzeń.

Założenia projektowe

• on-premise - oprogramowanie jest instalowane bezpośrednio u użytkownika,
• single tenant - dla każdego kolejnego użytkownika tworzona jest nowa sieć, wymagana jest też w takiej sytuacji instalacja nowych certyfikatów CA na każdym z serwerów
• rozwiązanie do zastosowań domowych
• proporcjonalne formy uwierzytelniania do wymagań środowiska wdrożenia:
  • podejście zaufania do środowisko wewnętrznego
  • podejście skrajnego braku zaufania do środowiska zewnętrznego – niektóre elementy dostępne w sieci Internet
  • w celu skutecznego, wiarygodnego i audytowalnego uwierzytelniania wybrano powszechnie akceptowane rynkowo rozwiązania oparte o mTLS oraz o lokalne centrum certyfikacji (CA)
  • gwarantuje to uwierzytelniania każdego serwera i każdego klienta przyłączonego do systemu pochodzącego z środowiska zewnętrznego (Internetu)
  • wykorzystanie mTLS gwarantuje także pełną poufność i integralność treści transmisji, co jest szczególnie istotne w przypadku transmisji w sieci Internet
  • wykorzystano klasyczne mechanizmy, więc podatności zostały zidentyfikowane i opisane, a wszelkie ewentualne niepoprawności naprawione
  • dzięki temu użytkownik nie musi logować się do usługi (przy założeniu, że używa przeglądarki z kluczem podpisanym przez CA)
  • dla instancji systemu dla jednego użytkownika wymagana jest tylko jednorazowa certyfikacja wszystkich serwerów
  • każdorazowe stworzenie huba wymaga od CA jedynie stworzenia nowego certyfikatu dla tego huba
  • w przypadku wykradzenia danego huba wystarczy, że stworzymy nowe CA, które następnie wygeneruje ponowne certyfikaty dla wszystkich serwerów oraz hubów

Funkcjonalności

• przechowywanie odczytów z czujników w bazie influxdb - baza dostaje odczyty z czujników podpiętych pod hub
• przechowywanie komunikatów z urządzeń wykonawczych w bazie influxdb (na przykład stan bramy - zamknięta / otwarta)
• każdy hub ma oddzielną konfigurację przechowywaną w bazie sqlite-device-configs
• wyświetlanie danych z bazy w aplikacji webowej
• zarządzanie czujnikami i urządzeniami wykonawczymi z poziomu aplikacji webowej
• sterowanie czujnikami - modyfikacja listy dostępnych czujników, włączanie ich i wyłączanie, modyfikacja częstości generowania przez nie danych
• sterowanie urządzeniami wykonawczynymi - modyfikacja listy urządzeń oraz możliwych komunikatów, włączanie ich i wyłączanie, wysyłanie zdefiniowanych przez użytkownika poleceń, obserwowanie odpowiedzi zwrotnej urządzenia wykonawczego
• tworzenie nowych hubów i podpinanie ich pod sieć
• w przypadku zerwania połączenia pomiędzy hubem a influxdb dane z czujników oraz komunikaty urządzeń wykonawczych będą buforowane do czasu przywrócenia połączenia