Wstęp
Gdy aplikacja działa prawidłowo, to może wydawać się magiczne. Bezproblemowe zameldowanie. Twój klucz cyfrowy otwiera drzwi. Obsługa pokoju przyjeżdża szybko. Nigdy nie kontaktujesz się z recepcją.
Prawda jest taka, że im lepsze doświadczenia zapewnisz gościowi, tym większe zaufanie zbudujesz.
Aplikacje hotelowe mają dostęp do danych osobowych (PII), tożsamości, płatności, dostępu do pokoi, urządzeń i komunikacji. Środowisko hotelarskie różni się od większości: współdzielone urządzenia, zapracowany personel, obiekt w trakcie transformacji (zmiana właściciela) i wielu użytkowników przez krótki czas to normalne zjawiska w hotelarstwie.
Ten blog to przewodnik po tworzeniu bezpiecznych i prywatnych aplikacji hotelowych. Jest przeznaczony dla założycieli i operatorów hoteli, którzy chcą postępować właściwie, ale nie chcą tworzyć kolejnej aplikacji bankowej. Obejmuje on: minimalizację danych, zarządzanie danymi osobowymi, nadawanie uprawnień, bezpieczne przesyłanie wiadomości/zabezpieczanie (ochronę aplikacji przed hakowaniem) oraz reagowanie na incydenty – dostosowane specjalnie do potrzeb branży hotelarskiej. W tekście odwoływać się będziemy do sprawdzonych benchmarków (np. standardu OWASP MASVS dla bezpieczeństwa aplikacji mobilnych).
Istnieją dwa podstawowe ograniczenia w świecie hotelarstwa:
1. Twoja klientela składa się wyłącznie z “użytkowników tymczasowych”. Zainstalują Twoją aplikację (lub skorzystają z niej jednorazowo), będą aktywnie z nią korzystać przez okres od jednego do pięciu dni, po czym znikną.
Środowisko operacyjne (rzeczywistość) bierze górę nad teorią (projektem).
2. Pracownicy korzystają z tabletów w podróży, zasięg sieci jest niestabilny, integracje mają kluczowe znaczenie dla realizacji misji; obciążenie pracą zespołu wsparcia oznacza, że jest bardzo mało okazji, aby zbudować idealny proces (teoria).
Jest jednak też dobra wiadomość: jeśli usprawnisz swoje projekty, uwzględniając te ograniczenia, możesz jednocześnie stworzyć bezpieczny i przyjazny dla użytkownika system. Bezpieczeństwo nie musi być postrzegane jako tarcie – gdy jest częścią procesu projektowania!
1. Najprostszym sposobem zapewnienia bezpieczeństwa danych jest minimalizacja danych.
Jeśli miałbyś zapamiętać z tego artykułu tylko jedną informację, to powinno to być:
Najbezpieczniejsze dane to te, których nie zbierasz.
Minimalizacja danych jest również jedną z zasad standardów prywatności RODO, ustanowionych w artykule 5 RODO (dane muszą być odpowiednie, istotne i ograniczone do tego, co niezbędne). Organy regulacyjne doceniają to, ponieważ mogą szybko określić, czy gromadzisz zbyt dużo danych (tj. “na wszelki wypadek”).
Kroki, które pozwolą Ci mieć pewność, że minimalizujesz gromadzenie danych w aplikacjach hotelowych skierowanych do gości (np. cyfrowy konsjerż, wiadomości, usługa składania zamówień, sprzedaż dodatkowa):
- Zadaj sobie następujące pytania dotyczące każdego obszaru danych, które zbierasz:
- Czy jest to naprawdę konieczne, aby dostarczyć tę funkcję?
- Czy możemy poprosić użytkownika, aby poinformował nas o tym po dokonaniu zakupu, zamiast zbierać te dane od razu na potrzeby danej funkcji?
- Jeśli uznasz, że nie jest to konieczne, czy możesz znaleźć sposób na stworzenie tej informacji bez jej przechowywania?
- Jak długo musimy przechowywać te dane – godziny, dni, miesiące?
- Czy możemy zanonimizować lub zagregować dane przed usunięciem gościa z aplikacji?
Poniżej przedstawiono kilka przykładów danych powszechnie gromadzonych w aplikacjach hotelowych:
- Pełna data urodzenia (zwykle można sprawdzić, czy klient jest pełnoletni, bez konieczności sprawdzania daty).
- Adres zamieszkania (zazwyczaj nie jest konieczny, aby gość dobrze się bawił).
- Zdjęcia paszportu/prawa jazdy gościa (zabierz tylko jeśli jest to wymagane).
- Śledzenie lokalizacji gościa (zwykle można to zrobić, korzystając z “kontekstu obiektu”, aby dowiedzieć się, gdzie w obrębie obiektu znajduje się gość).
- Prośba o dostęp do listy kontaktów gościa (ogólnie rzecz biorąc, uznaje się to za niepotrzebne).
- Ustal zasady przechowywania danych z wyprzedzeniem (nie później)
W branży hotelarskiej rotacja jest duża. To idealne miejsce do wdrożenia zasady „Prywatność w fazie projektowania”:
- Dane sesji gościa – przechowujemy wyłącznie przez okres pobytu oraz dodatkowo przez krótki okres czasu ze względów alimentacyjnych.
- Treść wiadomości – przechowywać przez określony czas (np. 30–90 dni) w zależności od operacji biznesowych i/lub sporów.
- Analityka – agreguj wcześnie; przechowuj surowe wydarzenia przez krótki okres czasu.
- Rejestry awarii – zamknij wszelkie informacje PII, często wymieniaj.
Silna pozycja prywatności = domyślna krótka pamięć.
Przewodnik ICO po decyzjach minimalizacyjnych w Wielkiej Brytanii to dobry, ogólny podręcznik w języku angielskim, który pomoże Ci podejmować decyzje minimalizacyjne.
2. Obsługa danych osobowych – traktuj tożsamość gościa jak "gorący kartofel"."
Podczas opracowywania aplikacji hotelowych istnieje wiele sytuacji, w których dane osobowe mogą pojawić się niespodziewanie:
- Informacje o rezerwacji (imię i nazwisko, adres e-mail, numer telefonu)
- Numer pokoju (tak, w tym kontekście można to uznać za kwestię poufną)
- Historia wiadomości (wiadomości do/z hotelu mogą zawierać prośby o pomoc medyczną, harmonogramy dnia, cenne przedmioty)
- Płatności/folio
- Identyfikatory urządzeń i sesji
Złote zasady dotyczące przetwarzania danych osobowych w aplikacjach gościnnych obejmują:
Zasada A: Nie umieszczaj danych osobowych w logach
- Rejestry są kopiowane, wysyłane, indeksowane i udostępniane. W związku z tym, gdy dane osobowe znajdą się w rejestrze, mogą łatwo się rozprzestrzeniać.
Zasada B: Szyfruj swoje dane zarówno podczas przesyłu, jak i w stanie spoczynku.
TLS (Transport Layer Security) i szyfrowanie baz danych (szyfrowanie danych w bazie danych) są “podstawowymi zasadami”. Twoje rzeczywiste zyski to:
- Kontrola dostępu – ograniczanie dostępu do danych osobowych w Twoim środowisku
Zasada C: Stosuj identyfikatory tokenizowane zamiast surowych identyfikatorów.
Zamiast uzyskiwać dostęp do rezerwacji bezpośrednio za pomocą “identyfikatorów rezerwacji” lub “identyfikatorów PMS”, goście powinni mieć dostęp wyłącznie za pośrednictwem identyfikatorów na poziomie aplikacji, które zostały bezpiecznie zmapowane po stronie serwera.
Zasada D: Domyślne maskowanie danych w interfejsie użytkownika.
Przykład: Pokaż “J. Smith” dopóki użytkownik nie poprosi o podanie pełnego imienia i nazwiska; ukryj numer pokoju, chyba że jest to konieczne.
Kilka praktycznych przykładów “zrób to, a nie tamto”
- Powiadomienie push
✅ “Twoje żądanie zostało zrealizowane”.”
❌ “Twoja prośba o dodatkowe ręczniki dla pokoju 1208 została zrealizowana”. Ekrany blokady powinny być traktowane jako wspólny dostęp dla wszystkich..
- Magiczne linki e-mail / weryfikacja
✅ Krótkotrwałe, jednorazowe lub przywiązane do urządzenia, jeśli dotyczy
❌ Przebywa przez dłuższy okres czasu; jeden użyty link można przekazać dalej lub ponownie wykorzystać
- Wyszukiwanie rezerwacji
✅ Proszę o potwierdzenie wniosku za pomocą drugiego czynnika, np. adresu e-mail (jednorazowego hasła) lub nazwiska i kodu potwierdzającego.
❌ Proszę podać nazwisko i wybrać rezerwację z listy.
3. Uzyskaj pozwolenie, zarabiając na nie, a nie zakładając je
Zaufanie gości to niezwykle delikatna kwestia. Jeśli aplikacja hotelowa zbyt wcześnie spróbuje uzyskać zbyt wiele uprawnień, goście po prostu ją usuną.
Aplikacje ze zbyt wieloma uprawnieniami również narażają się na niepotrzebne ryzyko. Zasada minimalizacji danych powinna mieć również zastosowanie do uprawnień, o które ubiega się urządzenie.
Oto model uprawnień, który sprawdza się w branży hotelarskiej
Poproś o pozwolenie później, proś wyraźnie i proś tylko raz.
- Jeśli chcesz powiadomić gościa, poproś o pozwolenie na powiadamianie go, gdy gość będzie zarządzał aktualizacjami urządzenia.
- Jeśli chcesz używać technologii Bluetooth, poproś o pozwolenie na jej użycie podczas konfigurowania przepływu klucza cyfrowego.
- Jeśli chcesz, aby gość zrobił zdjęcie swojego dokumentu tożsamości, poproś go o pozwolenie na użycie aparatu do zrobienia zdjęcia dokumentu.
Powinieneś również poinformować gościa o powodzie, dla którego prosisz o tę zgodę:
- Dostęp do pokoju gościnnego będzie możliwy poprzez Bluetooth.
- Powiadomienia będą wykorzystywane do informowania gości o wszelkich oczekujących na wykonanie czynności, o które poprosili.
- Goście i personel otrzymają oddzielne pozwolenia.
Większość aplikacji gościnnych ma:
- Aplikacja gościnna;
- Aplikacja dla personelu;
- Portal administracyjny;
- Tryb kiosku/tabletu.
Typowym błędem jest próba połączenia dwóch aplikacji w jedną dla wygody (w ten sposób dochodzi do przekraczania granic uprawnień).
- Oddziel tożsamość gościa od tożsamości personelu.
- Wykorzystaj kontrolę dostępu opartą na rolach (RBAC) dla personelu;
- Podczas świadczenia usług integracyjnych dla systemu PMS, menedżera kanałów lub systemu rezerwacji obejmującego wiele obiektów należy dokładnie rozważyć uprawnienia obejmujące dany obiekt.
Ponieważ systemy te często zapewniają dostęp wszystkim użytkownikom, chyba że wyraźnie ograniczysz dostęp.
4. Bezpieczne wiadomości: funkcja wysokiego ryzyka w aplikacjach hotelowych, która nie jest dobrze znana
Wiadomości wydają się nieszkodliwe (np. “Czy mogę dostać dodatkowe ręczniki?”).
Wiadomości od gości mogą jednak obejmować:
- plany podróży (np. “Wyjeżdżamy o 7 rano”)
- informacje medyczne
- informacje o dziecku
- problemy bezpieczeństwa związane z gośćmi
- skargi i dowody sporów
Powinniśmy traktować przesyłanie wiadomości jako wrażliwy system komunikacji.
Podstawy bezpieczeństwa wiadomości (stworzone z myślą o hotelowych realiach)
1. Zawsze korzystaj z sesji uwierzytelnianych.
- Brak publicznych linków do czatów.
- Brak udostępnialnych adresów URL skrzynki odbiorczej.
2. Zabezpiecz podgląd wiadomości.
- Jak już wcześniej wspomniano, należy zadbać o to, aby powiadomienia push miały charakter ogólny.
3. Ogranicz dostęp personelu do wiadomości.
- Personel powinien mieć dostęp wyłącznie do
- wiadomości, które są dla nich
- wiadomości, które są istotne dla ich pracy
- historia wiadomości zgodna z wymaganiami dotyczącymi przechowywania wiadomości.
4. Twórz zabezpieczone przed manipulacją ścieżki audytu.
- W przypadku poważnego incydentu, gdy prowadzisz dochodzenie, chcesz o tym wiedzieć.
– kto uzyskał dostęp do wiadomości,
– kto zmienił status,
– kto przypisał wiadomość,
– i kiedy powyższe działania miały miejsce. - Ślady audytu to również funkcja zapewniająca lepszą jakość życia (mniej chaotyczne działania), dlatego należy ją uwzględnić w skalowalnej architekturze aplikacji hotelowej.
5. Zachowaj szczególną ostrożność przy przesyłaniu “bezpiecznych załączników” (np. jeśli masz pozwolenie na przesłanie zdjęcia problemu konserwacyjnego).
- Przeskanuj przesłane pliki.
- Ogranicz typy przesyłanych plików.
- Przechowuj przesłane pliki bezpiecznie.
- Wydaj łącza o ograniczonym czasie dostępu.
- Nie publikuj adresów URL przechowywania przesłanych plików.
Krótkie przypomnienie, czym jest “szyfrowanie typu end-to-end”:
Wiadomości hotelowe nie muszą korzystać z pełnego szyfrowania end-to-end (E2EE). W większości przypadków rzeczywistym celem jest:
- Ochrona przed przypadkowymi wyciekami
- Zapobieganie nieautoryzowanemu dostępowi wewnętrznemu
- Ograniczanie retencji
- Umożliwianie audytowalności
Jeśli korzystasz z modelu E2EE, zastanów się nad sposobem rozwiązywania sporów w hotelach, sposobem radzenia sobie z eskalacją problemów i zachowaniem ciągłości między zmianami.
5. Reagowanie na incydenty: proste plany są lepsze niż brak planów
Trzeba stawić czoła faktowi, że każdy dzień niesie ze sobą inne ryzyko. Dlatego najlepsi specjaliści w branży hotelarskiej przygotowują się tak, jakby nic nie mogło pójść źle; następnie ograniczają awarię do niewielkiego obszaru i odpowiednio reagują.
Jednym z lepiej opracowanych źródeł informacji wykorzystywanych przy opracowywaniu części dotyczącej reagowania na incydenty jest Przewodnik NIST dotyczący postępowania w przypadku incydentów.
Oto podstawowe rzeczy, które każda firma hotelarska powinna mieć w zanadrzu, aby móc reagować na wszelkie incydenty:
1. Jasno określone obowiązki
- Kto jest odpowiedzialny za podjęcie decyzji
- Kto przekaże decyzję?
- Kto może wyłączyć funkcje systemowe?
- Kto będzie się kontaktował z dostawcami zewnętrznymi, których zintegrujesz ze swoim rozwiązaniem (PMS, firma przetwarzająca płatności, firma obsługująca wiadomości)?
2. Lista kontrolna “Zatrzymaj krwawienie”
- Odwołaj i obróć tokeny
- Wymuś wylogowanie w segmentach, których dotyczy problem
- Tymczasowo wyłącz określoną integrację
- Wstrzymaj wysyłanie załączników w wiadomościach
- Wyłącz poufne powiadomienia
3. “Szablony komunikacji z gośćmi” do powiadomień i alertów
Podstawowe elementy, które należy uwzględnić w alertach/powiadomieniach dla gości:
- Co się stało?
- Jakie dane były związane z incydentem (jeśli wiadomo)?
- Co obecnie robisz w odpowiedzi?
- Co goście muszą zrobić (jeśli w ogóle coś zrobić), aby chronić swoją tożsamość?
- Gdzie szukać pomocy i wsparcia?
4. Ścieżki eskalacji dostawcy
W stosie technologii hotelarskich kod jest zazwyczaj tworzony i utrzymywany przez kilku zewnętrznych dostawców. Tworząc plan reagowania na incydenty dla swojej firmy hotelarskiej, musisz uwzględnić integrację z:
- Dostawca PMS
- Dostawca płatności
- Dostawca wiadomości
- Dostawca chmury (ścieżka eskalacji)
5. Wyciąganie wniosków ze zdarzenia
Organizacje odnoszące sukcesy traktują wydarzenia jako informację zwrotną na temat produktu.
Rozważ następujące pytania:
- Co poszło nie tak?
- Jakie metody wykrywania zapobiegłyby temu zdarzeniu?
- Co można zautomatyzować?
- Co mogło zostać wyłączone z automatyzacji?
Kluczowe sygnały wykrywania, które mogą być przydatne dla aplikacji hotelowych:
- Nietypowe wzorce logowania na kontach pracowników/administratorów
- Nagły wzrost liczby nieudanych prób uwierzytelnienia za pomocą OTP.
- Nienaturalny poziom dostępu do wiadomości.
- Generowana jest nieoczekiwana liczba eksportów.
- Podejrzanie wysoka częstotliwość żądań odświeżenia tokenów.
- Zmiany w danych uwierzytelniających integrację.
Nawet proste systemy alarmowe mogą pomóc wykryć problemy zanim się pojawią.
6. Plan zapewniający bezpieczeństwo aplikacji hotelowej już na etapie projektowania
Projektując aplikację do obsługi cyfrowego concierge'a, zamawiania usług pokojowych lub do obsługi gości w wielu obiektach, pamiętaj o stworzeniu praktycznego planu działania uwzględniającego bezpieczeństwo, który będzie odpowiadał potrzebom użytkowników.
Zasady bezpieczeństwa w fazie projektowania:
- Ogranicz gromadzone dane
- Ogranicz dostęp do danych
- Ogranicz czas przechowywania danych
- Zadbaj o to, aby wszystkie wrażliwe działania były wyraźnie opisane w UX
- Przechowuj zapisy wszystkich działań użytkowników (rejestrowanie audytów)
- Zaprojektuj swoje środowisko, zakładając, że urządzenia i/lub sieci są zagrożone
Ustal punkt zaczepienia w kwestii bezpieczeństwa (tj. nieopierając się na osobistej opinii)
W przypadku aplikacji mobilnych jako punkt odniesienia należy używać OWASP MASVS. Jest to szczególnie przydatne, gdy potrzebny jest wspólny język dla zarządzania produktem, inżynierii i zapewnienia jakości.
Nacisk położony na zasady bezpieczeństwa w fazie projektowania zapewni Ci:
- Mniejsze narażenie
- Większa solidność w zakresie testowania
- Większa przejrzystość w kwestii tego, co jest priorytetem
Błędy związane z rozwojem aplikacji hotelowych
- Dane zbierane w celu późniejszej personalizacji
Posiadanie dużej ilości danych jest korzystne. Jeśli jednak danych jest za dużo, Twoja firma staje się odpowiedzialna za wszystkie informacje o użytkownikach. - Brak rozdzielenia systemów dla gości i personelu
Wykorzystanie najnowocześniejszych technologii do realizacji codziennych operacji i rozdzielania systemów przy użyciu wydajnej tablicy. - Włączanie numerów pokoi do powiadomień
Posiadanie tylko jednego urządzenia, które wysyła i odbiera powiadomienia, nie jest idealnym rozwiązaniem, ponieważ obniża bezpieczeństwo w hotelu. - Długowieczne tokeny dostępu
Stary, utracony token dostępu jest bardzo trudny do odzyskania. - Brak planowania odejścia po wymeldowaniu
Zarówno dane gościa, jak i stany sesji muszą zostać celowo zakończone w momencie realizacji transakcji.
Jak Appricotsoft podchodzi do kwestii bezpieczeństwa i prywatności w aplikacjach hotelarskich
W Appricotsoft wolimy tworzyć oprogramowanie, za którym możemy się opowiadać – proste, funkcjonalne i niezawodne. To nie jest slogan marketingowy; to część sposobu, w jaki decydujemy, co zamierzamy wydać (wydać), a co usunąć.
Pomagając zespołom w tworzeniu aplikacji hotelowych, dbamy o bezpieczeństwo i prywatność, które stanowią część naszego wczesnego etapu planowania (odkrywanie i architektura), a nie tylko końcowego “sprintu wzmacniającego”. Sztuczna inteligencja w naszym Unison Framework (naszym podejściu stawiającym sztuczną inteligencję na pierwszym miejscu) pozwala nam działać szybciej w niemal każdym przypadku, ponieważ decyzje dotyczące bezpieczeństwa zależą od rzeczywistego zaufania gości.
Przyjrzyjmy się, jak to się dzieje.
1) Mapujemy i minimalizujemy dane.
Przed utworzeniem funkcji mapujemy:
- Jakie dane są zbierane?
- Gdzie to płynie? (np. PMS)
- Gdzie jest przechowywany?
- Kto ma do niego dostęp?
Następnie usuwamy wszystko, co nie jest potrzebne.
2) Definiujemy uprawnienia i role, takie jak funkcje produktu.
RBAC (dostęp oparty na rolach) i zakresy obiektów w branży hotelarskiej to nie tylko “zaplecze”. To siatki bezpieczeństwa dla całego przedsiębiorstwa. Projektujemy je z myślą o rzeczywistym przepływie pracy.
3) Systemy przesyłania wiadomości (np. powiadomienia, prośby o serwis itp.) traktujemy jako systemy bardzo wrażliwe.
- Zapewniamy podglądy
- Zakres dostępu personelu
- Śledzimy komunikaty audytu
- Ustanawiamy i egzekwujemy zasady przechowywania danych
4) Uwzględniamy gotowość na wypadek incydentu na listach kontrolnych przed startem.
Jesteśmy zgodni co do:
- Kto za co odpowiada i jak
- Jaka jest ścieżka eskalacji dla każdego dostawcy
- Rotacja kluczy i unieważnianie tokenów.
5) Jesteśmy transparentni w kwestii realizacji (cotygodniowe pokazy, widoczne ryzyko)
Produkty dla branży hotelarskiej rozwijają się dynamicznie, ponieważ rynek nieruchomości zaczyna z nich korzystać. Dlatego będziemy co tydzień prezentować produkty w wersji demonstracyjnej, aby jak najszybciej potwierdzić założenia i uniknąć kosztownych przeróbek.
Jeśli planujesz wdrożenie swojego produktu, przygotowaliśmy również kilka dodatkowych materiałów, które pomogą Ci w tym procesie. Możesz zapoznać się z poniższymi dwoma materiałami:
Wniosek
Bezpieczeństwo i prywatność aplikacji hotelowych nie polega na tworzeniu schronu. Chodzi o budowanie zaufania między gośćmi, pracownikami i marką.
Aby zapewnić gościom wspaniałe wrażenia, a także zapewnić im godne zaufania i płynne doświadczenie, należy wziąć pod uwagę następujące aspekty:
- Minimalizacja danych
- Ostrożne obchodzenie się z danymi osobowymi
- Pozwolenie/Dyscyplina
- Korzystanie z bezpiecznych wiadomości
- Wzory
- Reagowanie na incydenty
Jeśli chcesz, aby cały Twój zespół stosował się do pewnego standardu, OWASP MASVS jest doskonałym źródłem informacji pozwalającym określić wymagania dotyczące bezpieczeństwa urządzeń mobilnych.
Jeśli chcesz stworzyć cyfrową aplikację do obsługi gości, aplikację do zarządzania konsjerżem lub platformę dla wielu obiektów i potrzebujesz partnera, który pomoże Ci dostarczyć produkt, który ma praktyczne i ludzkie podejście do bezpieczeństwa, Appricotsoft może Ci pomóc w osiągnięciu tego celu.
