Wybierz chmurę, gdy ważne są szybkie uruchomienie, zdalny dostęp i przeniesienie bieżącej administracji na dostawcę. Wybierz on-premise, gdy konkretne wymaganie prawne, sieciowe lub operacyjne wymaga środowiska klienta – i masz zespół, który je utrzyma. Jeżeli żaden wariant nie spełnia RTO, RPO, łączności albo bezpieczeństwa, wynik powinien brzmieć „no-go” do czasu zmiany architektury.
W skrócie
- „Chmura” i „on-premise” opisują miejsce odpowiedzialności, nie poziom bezpieczeństwa.
- Zacznij od skutków awarii, RTO, RPO, łączności i procedury alarmowej.
- On-premise bez aktualizacji, kopii i dyżuru daje kontrolę formalną, ale może zwiększać ryzyko operacyjne.
- SaaS nadal wymaga zarządzania kontami, integracją, umową i planem wyjścia po stronie klienta.
- Tryb no-go jest poprawną decyzją, jeśli platforma ma zastępować lokalne zabezpieczenie czasu rzeczywistego.
To nie jest spór o serwer. To podział odpowiedzialności
NIST SP 800-145 definiuje chmurę przez dostęp sieciowy na żądanie do współdzielonej puli konfigurowalnych zasobów, które można szybko przydzielać i zwalniać. W modelu SaaS użytkownik korzysta z aplikacji, a większa część stosu technicznego pozostaje po stronie dostawcy. On-premise oznacza, że oprogramowanie działa w infrastrukturze kontrolowanej przez klienta lub wskazanego przez niego operatora.
RTO (recovery time objective) to docelowy czas przywrócenia usługi po zakłóceniu. RPO (recovery point objective) to dopuszczalny punkt utraty danych wyrażony w czasie. Są ważniejsze od etykiety hostingu, bo odpowiadają na dwa biznesowe pytania: jak długo możemy nie mieć platformy i ile ostatnich danych możemy utracić.
W monitoringu konstrukcji trzeba dodać trzecie pytanie: co dzieje się w terenie, gdy platforma lub łącze są niedostępne? Jeżeli urządzenie pomiarowe zapisuje dane lokalnie i później je dosyła, chwilowy brak panelu ma inne konsekwencje niż w architekturze, która bez łącza traci pomiar. Jeżeli od sygnału zależy natychmiastowe zatrzymanie maszyny, zdalna aplikacja nie powinna być jedyną warstwą zabezpieczenia; potrzebna jest odpowiednia logika lokalna i procedura zaprojektowana przez właściwych specjalistów.
Dlatego pytanie nie brzmi „czy obiekt jest krytyczny?”. Brzmi: które funkcje muszą działać lokalnie, które mogą wrócić w czasie RTO, gdzie buforują się dane, kto odpowiada za aktualizacje i jak udowodnimy odtworzenie.
Macierz cloud / on-premise / no-go
Tabela służy do wstępnego screeningu. Pojedyncza odpowiedź nie rozstrzyga całości, ale czerwone pole powinno stać się warunkiem blokującym lub zadaniem architektonicznym.
| Warunek | Cloud/SaaS | On-premise | No-go do zmiany |
|---|---|---|---|
| Dostęp zespołu z wielu lokalizacji | Naturalne dopasowanie | Wymaga bezpiecznego dostępu zdalnego | Brak zatwierdzonej drogi dostępu |
| Łącze obiektu bywa niedostępne | Działa z buforem po stronie pola | Także wymaga bufora pola | Dane znikają bez internetu |
| Zakaz przechowywania poza środowiskiem klienta | Zwykle nie pasuje | Naturalne dopasowanie | Brak zgodnego wariantu wdrożenia |
| Brak zespołu administracji 24/7 | Dostawca utrzymuje stos usługi | Wysokie ryzyko operacyjne | Nikt nie odpowiada za incydent |
| Bardzo krótki czas uruchomienia | Zwykle korzystniejszy | Zależny od procesu IT klienta | Termin pomija testy bezpieczeństwa |
| Wymagana integracja z izolowaną siecią OT | Wymaga kontrolowanej bramy | Może pasować do segmentu lokalnego | Zakazana i nieudokumentowana granica |
| Wymagane własne okna aktualizacji | Uzgadniane w SLA usługi | Pełna kontrola klienta | Brak procesu aktualizacji |
| Wymagana skalowalność wielu obiektów | Naturalne dopasowanie | Klient planuje pojemność | Brak właściciela capacity planning |
| RTO i RPO potwierdzone testem | Zależne od umowy dostawcy | Zależne od zespołu klienta | Są tylko deklaracją |
| Funkcja bezpieczeństwa czasu rzeczywistego | Nie jako jedyna warstwa | Tylko przy właściwej architekturze | Platforma ma zastąpić zabezpieczenie |
„Naturalne dopasowanie” nie oznacza automatycznie zaliczonego wymogu. Dostawca SaaS musi pokazać zakres kopii i odtworzenia. Klient on-premise musi wykazać ten sam poziom konkretu własnym procesem. W obu wariantach dowodem jest test, nie miejsce szafy serwerowej.
Pięć obszarów decyzji: od skutku awarii do planu wyjścia
1. Funkcja biznesowa i skutek niedostępności
Wypisz oddzielnie: przyjmowanie pomiarów, przechowywanie, wyświetlanie, obliczenia, alarmowanie, potwierdzanie alarmu, eksport i administrację. Dla każdej funkcji określ maksymalny tolerowany czas przerwy. Być może panel może być niedostępny godzinę, ale dane nie mogą zniknąć. Być może raport może poczekać dzień, lecz dyżurny musi dostać informację o braku transmisji szybciej.
Taka analiza zapobiega kupowaniu „wysokiej dostępności” całej aplikacji, gdy krytyczne są tylko dwie ścieżki. Pozwala też zauważyć funkcję, której platforma nie powinna pełnić – na przykład bezpośredniego lokalnego wyłączenia urządzenia technologicznego.
2. Przepływ IT/OT i tożsamość
NIST SP 1800-32 pokazuje dla przemysłowego IoT znaczenie integralności komunikacji, monitorowania sieci, uwierzytelniania, kontroli dostępu oraz bezpiecznego przepływu edge–cloud. Nie jest to gotowy wzór dla monitoringu konstrukcji, ale dobry katalog pytań o granice.
Narysuj drogę od sensora do użytkownika: urządzenie, rejestrator, sieć terenowa, operator telekomunikacyjny, brama, API, baza, przeglądarka i kanał powiadomień. Przy każdej granicy wskaż protokół, uwierzytelnianie, właściciela certyfikatów lub sekretów i sposób ich rotacji. On-premise nie usuwa tych granic; często dodaje VPN, reverse proxy i zależność od katalogu tożsamości klienta.
3. Operacje, aktualizacje i podatności
W SaaS dostawca zwykle aktualizuje aplikację i infrastrukturę, ale klient nadal odpowiada za własne konta, odbiorców alarmów, urządzenia oraz konfigurację. W on-premise trzeba przypisać aktualizacje systemu, bazy, kontenerów, bibliotek, certyfikatów i kopii. „Dział IT” nie jest właścicielem, dopóki konkretna usługa nie trafi do jego katalogu, monitoringu i dyżuru.
Ustal także okna serwisowe i procedurę poprawki krytycznej. Pełna kontrola wersji po stronie klienta jest zaletą tylko wtedy, gdy organizacja rzeczywiście instaluje poprawki, testuje je i potrafi szybko zareagować.
4. Ciągłość, kopie i test odtworzenia
NIST SP 800-34 Rev. 1 porządkuje planowanie ciągłości jako część zarządzania ryzykiem i cyklu życia systemu. Dla platformy monitoringu potrzebujesz co najmniej inwentaryzacji zależności, priorytetu funkcji, RTO, RPO, procedury odtworzenia, komunikacji podczas incydentu i cyklicznego testu.
Zapytaj, czy kopia obejmuje tylko pomiary, czy także konfigurację, konta, progi, audyt i pliki. Przetestuj odtworzenie pełnego projektu w izolowanym środowisku. Kopia, której nikt nigdy nie odtworzył, jest hipotezą.
5. Koszt oraz wyjście
SaaS ma widoczny abonament, a on-premise ukrywa część kosztu w czasie infrastruktury, administratorów, cyberbezpieczeństwa, kopii i aktualizacji. Porównaj te same pięć lat oraz ten sam RTO/RPO. Dodaj transfer danych, wiadomości SMS, środowisko testowe, monitoring, certyfikaty, audyt, wsparcie i migrację.
W obu wariantach ustal format pełnego wydania danych, termin, koszt i pomoc. Pomaga w tym 12 klauzul o własności danych. Serwer stojący u klienta nie gwarantuje przenośności, jeżeli baza ma zamknięty schemat i tylko dostawca zna konfigurację.
Piętnaście pytań do IT/OT przed wyborem hostingu
Funkcja i dostępność
- Które funkcje muszą działać podczas utraty łącza z obiektem?
- Jakie RTO i RPO ma każda krytyczna funkcja?
- Czy urządzenia przechowują dane do późniejszego dosłania?
- Czy zdalna platforma jest informacyjna, czy ma sterować procesem?
Dane i integracje
- Jakie klasy danych powstają i gdzie może znajdować się każda z nich?
- Jak dane przechodzą przez granice IT/OT i kto zatwierdza połączenie?
- Czy potrzebna jest integracja z katalogiem tożsamości, SIEM albo archiwum?
Bezpieczeństwo
- Kto nadaje, przegląda i odbiera konta oraz role?
- Kto rotuje sekrety, certyfikaty i dane dostępowe urządzeń?
- Jak wykrywany, zgłaszany i obsługiwany jest incydent?
Utrzymanie
- Kto aktualizuje każdą warstwę i w jakim oknie?
- Kto monitoruje usługę całodobowo i kto przyjmuje alarm techniczny?
- Kiedy ostatnio odtworzono pełny projekt z kopii?
Umowa i wyjście
- Jaki jest pięcioletni TCO przy tych samych poziomach usługi?
- Jak odbierzemy dane, konfigurację i audyt po zakończeniu współpracy?
Każda odpowiedź powinna zawierać osobę lub zespół, dowód i termin. Jeżeli odpowiedź brzmi „to zależy od dostawcy”, wymaganie trafia do zapytania. Jeżeli brzmi „zrobi to klient”, musi trafić do jego modelu operacyjnego i budżetu.
Przykład ilustracyjny: obiekt z niestabilnym łączem
Przykład ilustracyjny. Zdalny obiekt ma okresowe przerwy w transmisji. Zespół zakłada, że instalacja on-premise w centrali rozwiąże problem. Nie rozwiązuje – pomiędzy obiektem i centralą nadal działa to samo łącze. Zmieniło się miejsce aplikacji, nie odporność pola.
Analiza funkcji pokazuje, że rejestrator musi zachować pomiary lokalnie, a po powrocie łączności wysłać je z oryginalnymi czasami. Platforma powinna przyjąć historię, nie tworząc duplikatów. Osobno trzeba określić, kiedy brak świeżych danych uruchamia stan NO_DATA i kto reaguje.
Po spełnieniu tych warunków zarówno SaaS, jak i on-premise mogą być technicznie możliwe. Decyzję rozstrzygają wtedy wymagania organizacyjne, bezpieczeństwo, koszt utrzymania i wyjście. Liczby oraz czasy w realnym projekcie muszą wynikać z analizy ryzyka; scenariusz jest wyłącznie ilustracyjny.
Jak to wygląda w Inclify
Inclify jest standardowo dostarczane jako usługa online dostępna przez przeglądarkę. Platforma działa technicznie jako zestaw kontenerów, dlatego wariant w infrastrukturze klienta jest możliwy do rozmowy, lecz wymaga indywidualnego uzgodnienia i nie stanowi standardowej oferty. Nie należy zakładać zgodności on-premise bez potwierdzenia zakresu, odpowiedzialności, aktualizacji i wsparcia w konkretnej umowie.
Pomiary trafiają do platformy przez HTTP/JSON z czasem UTC. Pomiary nie są automatycznie usuwane, a starsza historia jest kompresowana. Surowe logi żądań i odpowiedzi urządzeń mają osobną, konfigurowalną retencję, domyślnie siedem dni. Dostęp jest rozdzielony między trzy role organizacyjne, a dane klientów są izolowane. Eksport obejmuje CSV dla danych tabelarycznych, obraz wykresu i XLSX dla analiz dynamicznych; nie ma eksportu PDF.
Przed wyborem modelu wdrożenia zespół powinien uzgodnić RTO, RPO, odpowiedzialność za urządzenia i łącza oraz techniczny sposób wydania danych. Szersze wymagania funkcjonalne porządkuje checklista wyboru platformy. Sama platforma nie powinna być traktowana jako lokalny sterownik bezpieczeństwa czasu rzeczywistego.
Checklista decyzji hostingowej
- [ ] Zmapowaliśmy funkcje, a nie tylko komponenty infrastruktury.
- [ ] Każda krytyczna funkcja ma RTO, RPO i właściciela.
- [ ] Wiemy, co dzieje się z pomiarem podczas utraty łącza.
- [ ] Zdalna platforma nie jest jedynym zabezpieczeniem czasu rzeczywistego.
- [ ] Mamy diagram przepływu danych i granic IT/OT.
- [ ] Lokalizacja i klasy danych są zatwierdzone.
- [ ] Tożsamość urządzeń, użytkowników i usług ma proces cyklu życia.
- [ ] Role klienta i dostawcy są zapisane dla każdej warstwy.
- [ ] Aktualizacje krytyczne mają ścieżkę poza zwykłym oknem.
- [ ] Kopie obejmują pomiary, konfigurację, audyt i pliki wymagane do odtworzenia.
- [ ] Pełne odtworzenie zostało przetestowane.
- [ ] Pięcioletni TCO obejmuje ludzi, narzędzia i bezpieczeństwo.
- [ ] Eksport oraz wyjście zostały sprawdzone na próbce.
- [ ] Wymagania on-premise zostały potwierdzone przez dostawcę, nie założone.
- [ ] Potrafimy powiedzieć „no-go”, jeśli architektura nie spełnia warunku krytycznego.
Jeżeli decyzja „zbudujemy lokalnie” pojawia się jako alternatywa dla zakupu, przeczytaj też porównanie build, buy i hybrid. Hosting jest tylko jedną z jego osi.
Ograniczenia: kiedy potrzebna jest osobna analiza
Ta macierz nie zastępuje analizy ryzyka cyberbezpieczeństwa, klasyfikacji informacji, wymagań sektorowych ani projektu funkcjonalnego bezpieczeństwa. Dla obiektów i organizacji objętych szczególnymi regulacjami potrzebna jest ocena prawna oraz udział zespołów odpowiedzialnych za OT, ciągłość działania i ochronę danych.
NIST SP 1800-32 dotyczy konkretnego przykładu przemysłowego IoT w energetyce. Wykorzystujemy go jako katalog wzorców – integralność komunikacji, monitoring sieci, uwierzytelnianie, kontrola dostępu – nie jako deklarację zgodności platformy monitoringu konstrukcji z rozwiązaniem referencyjnym.
Publiczne strony produktów pokazują, że rynek oferuje różne modele. Bentley opisuje iTwin IoT jako aplikację webową i produkt cloud-native, a Sixense podaje dla Beyond Monitoring SaaS w chmurze oraz wariant on-premise dla obiektów wrażliwych. Nie oznacza to równoważności zakresów, zabezpieczeń ani warunków umownych. Te trzeba porównać w aktualnej ofercie.
FAQ
Czy on-premise jest bezpieczniejsze od chmury?
Nie z definicji. On-premise daje klientowi większą kontrolę nad środowiskiem, ale także odpowiedzialność za aktualizacje, konta, kopie, monitoring i incydenty. Chmura przenosi część tych zadań na dostawcę, lecz wymaga oceny jego zabezpieczeń oraz umowy. Bezpieczeństwo wynika z architektury, procesu, ludzi i testów, a nie z fizycznego położenia serwera.
Czy infrastruktura krytyczna zawsze wymaga instalacji lokalnej?
Nie można przyjąć takiej uniwersalnej zasady. Wymagania zależą od sektora, klasy danych, konkretnej funkcji, modelu zagrożeń i obowiązujących przepisów lub polityk organizacji. Część funkcji może wymagać lokalności, a inne mogą działać zdalnie. Decyzję należy udokumentować analizą ryzyka i zatwierdzić z właściwymi zespołami prawnymi oraz IT/OT.
Czy monitoring będzie działał bez internetu?
To zależy od całej architektury, nie od hostingu platformy. Kluczowe jest, czy urządzenie lub rejestrator przechowuje pomiary podczas przerwy i dosyła je później z oryginalnym czasem. Dostęp do zdalnego panelu oraz powiadomień może być wtedy niedostępny. Wymagane zachowanie należy przetestować na rzeczywistym urządzeniu i łączu.
Jak ustalić RTO i RPO dla platformy monitoringu?
Zacznij od skutku biznesowego: ile czasu można nie widzieć danych i jaka utrata historii jest akceptowalna. Ustal wartości osobno dla ingestu, alarmowania, panelu, raportów i administracji. Dopasuj je do kadencji pomiaru oraz procedury reakcji. Następnie zweryfikuj, czy architektura i umowa pozwalają osiągnąć cele, oraz potwierdź je testem odtworzeniowym.
Kto odpowiada za bezpieczeństwo w SaaS?
Odpowiedzialność jest współdzielona. Dostawca zwykle utrzymuje aplikację i infrastrukturę usługi. Klient nadal zarządza własnymi użytkownikami, odbiorcami powiadomień, urządzeniami, poprawnością konfiguracji, klasyfikacją danych i użyciem eksportów. Dokładną granicę trzeba opisać w umowie, łącznie z incydentami, podwykonawcami, terminami powiadomień i sposobem odebrania danych.
Kiedy wybrać „no-go” zamiast kompromisu?
Gdy nierozwiązany warunek może uniemożliwić bezpieczne działanie: brak bufora przy niestabilnym łączu, platforma jako jedyne zabezpieczenie czasu rzeczywistego, nieakceptowana lokalizacja danych, brak właściciela aktualizacji albo nieprzetestowane odtworzenie przy wymaganym RTO. No-go nie musi kończyć projektu. Oznacza, że najpierw trzeba zmienić architekturę lub zakres.
Źródła i dalsza lektura
- NIST SP 800-145 – The NIST Definition of Cloud Computing, NIST.
- NIST SP 1800-32 – Securing Distributed Energy Resources: An IIoT Cybersecurity Example, NIST.
- NIST SP 800-34 Rev. 1 – Contingency Planning Guide, NIST.
- iTwin IoT – oficjalna strona produktu, Bentley Systems.
- Beyond Monitoring – oficjalna strona platformy, Sixense.
- NIST SP 800-218 – Secure Software Development Framework, NIST.
Co dalej: przynieś wymagania, nie preferencję hostingu
Na krótkim spotkaniu przejdziemy przez RTO, RPO, przepływ IT/OT, retencję, role i wyjście. Na tej podstawie ocenimy standardową usługę online oraz to, czy istnieje uzasadnienie do indywidualnej rozmowy o środowisku klienta. Umów przegląd wymagań wdrożeniowych – wynik może równie dobrze wskazać warunek no-go.