Jak dbamy o bezpieczeństwo danych

Definicje

Asystent - aplikacja uruchomiona na urządzeniach końcowych wraz z wymaganym zapleczem serwerowym (back-end).

Urządzenie końcowe - telefon komórkowy lub komputer osobisty na którym uruchomione jest oprogramowanie asystenta z którym pracuje użytkownik końcowy.

Back-end - zaplecze w postaci infrastruktury serwerowej wymaganej do poprawnej pracy asystenta.

Serwer aplikacyjny - serwer lub zbiór serwerów odpowiedzialnych za przetwarzanie danych oraz realizację logiki biznesowej asystenta.

Serwer indeksujący - serwer lub zbiór serwerów odpowiedzialnych za indeksowanie danych oraz zapewnienie szybkiego przeszukiwania oraz szybkiej agregacji zaindeksowanych danych.

TLS (Transport Layer Security) – protokół kryptograficzny zapewniający poufność transmisji w sieciach publicznych.

Android KeyStore - mechanizm bezpiecznego przechowywania kluczy kryptograficznych. W przypadku telefonów posiadających sprzętowe wsparcie dla Android KeyStore (większość nowych  telefonów) klucz kryptograficzny generowany jest w warstwie sprzętowej i nie jest dostępny dla systemu operacyjnego. System może wtedy wykonywać operacje kryptograficzne z użyciem tego klucza, ale nie może go poznać lub skopiować. Mechanizm jest odpowiednikiem mechanizmu Secure Enclave z Apple iOS.

Tymczasowy Certyfikat Kliencki - certyfikat mający na celu tymczasowe uwierzytelnienie urządzenia oraz zapewnienie tymczasowej możliwości stosowania podpisu cyfrowego – wydawany na krótki okres czasu, aby doprowadzić w procesie onboardingu użytkownika do wydania Produkcyjnego Certyfikatu Klienckiego.

Produkcyjny Certyfikat Kliencki - certyfikat mający na celu produkcyjne uwierzytelnienie urządzenia oraz zapewnienie możliwości stosowania podpisu cyfrowego – wydawany na długi okres czasu, stosowany w normalnej eksploatacji Asystenta.

Ogólne wprowadzenie do zagadnień bezpieczeństwa

Asystent ze względu na swoją specyfikę pracy stosuje szereg zabezpieczeń, aby chronić przetwarzane dane. Dokument opisuje jedynie wybrane zabezpieczenia stosowane przez Asystenta. Jeśli dokument nie zawiera opisu zabezpieczenia, który jest wymagany przez użytkownika proszę o zwrócenie się z pytaniem, czy dane zabezpieczenie jest stosowane.

Szyfrowanie danych

Asystent stosuje silne szyfrowanie dla danych przesyłanych oraz przechowywanych. Szczegółowy opis zastosowanych zabezpieczeń szyfrowania znajduje się w poniższych sekcjach.

W tranzycie

Wszystkie dane przesyłane pomiędzy Back-end, a urządzeniami końcowymi są szyfrowane z zastosowaniem silnego szyfrowania.

Protokół TLS

Asystent wykorzystuje do szyfrowania połączeń protokół TLS, który jest bezpiecznym następcą szyfrowania SSL.

Charakterystyka komunikacji:

  1. Aplikacja Android wykorzystuje bezpieczne szyfrowanie TLS v1.2 oraz TLSv1.1 (stosowane w podanej kolejności),
  1. Aplikacja Android odrzuca starsze, niebezpieczne wersje protokołów szyfrujących (np. SSLv3),
  1. Kliknij tutaj, by sprawdzić więcej informacji o TLS.

Certificate Pinning

Aby dodatkowo zabezpieczyć komunikację z Back-end zastosowana jest technika Certificate Pinning polegająca na weryfikacji sumy kontrolnej klucza publicznego wystawcy certyfikatu dla serwera HTTPS.

Zabezpieczenie to jest stosowane w aplikacji Android, która posiada wbudowane sumy kontrolne zaufanych wystawców (urzędów głównych i/lub pośrednich). Wszystkie połączenia z serwerem API weryfikowane w oparciu o te sumy kontrolne.

Cele stosowania zabezpieczenia:

  1. Utrudnienie ataków „Man in The Middle” – analiza komunikacji pomiędzy urządzeniem końcowym, a serwerem wymaga dodatkowej pracy, co w praktyce wydłuża czas potrzebny na zrozumienie struktur danych oraz protokołu komunikacji,
  1. Zabezpieczenie użytkownika przed nieświadomym korzystaniem z telefonu na którym atakujący dodał do magazynu certyfikatów własne urzędy certyfikacji, co w praktyce może w sposób znaczący ułatwić przechwytywanie szyfrowanej transmisji.
Certyfikaty klienckie

Dodatkowym zabezpieczeniem komunikacji z Back-end jest stosowanie certyfikatów klienckich. Aplikacja Android przy nawiązywaniu połączenia przedstawia się certyfikatem, który weryfikowany jest po stronie serwera HTTPS. Serwer odrzuci połączenie jeśli certyfikat nie jest poprawny lub wygasły, dodatkowo serwer API nie będzie komunikował się z aplikacją Android, jeśli certyfikat nie zostanie uznany za poprawnie wystawiony i uwierzytelniony.

Cele stosowania zabezpieczenia:

  1. Rzadko spotykane zabezpieczenie dodatkowo utrudniające atak typu „Man in The Middle” – aby móc analizować komunikację należy nie tylko skutecznie obejść zabezpieczenie Certificate Pinning, ale także posiadać dostęp do magazynu z kluczami prywatnymi w Android KeyStore.
Automatyczna aktualizacja bibliotek szyfrujących

Ze względu na stopień skomplikowania protokołów szyfrujących oraz algorytmów szyfrowania konieczne jest bieżące aktualizowanie bibliotek służących do szyfrowania. Producent telefonu może już nie zapewniać wsparcia dla danego modelu telefonu, jednakże Asystent korzysta z usługi „Google Play Services Security Provider”, która zapewnia aktualizację bibliotek szyfrujących bez konieczności aktualizacji oprogramowania systemowego telefonu.

Cele stosowania zabezpieczenia:

  1. Zapewnienie bezpiecznej transmisji danych także na starszych urządzeniach, które już nie są wspierane przez producenta.

W spoczynku

Dane przechowywane na urządzeniach końcowych (Android) oraz na serwerze są zabezpieczone dzięki zastosowanym technikom szyfrowania opisanym w poniższych sekcjach.

Android

Ze względu na wysokie ryzyko utraty telefonu komórkowego i/lub błędnej konfiguracji telefonu (brak włączonego szyfrowania telefonu) aplikacja Android stosuje własne zabezpieczenie danych – tj. szyfruje dane przechowywane na urządzeniu.

Obszary danych podlegające szyfrowaniu:

  1. SQLite oraz Realm - lokalne bazy danych na telefonie

Dane przechowywane w lokalnych bazach danych na telefonie są zaszyfrowane z wykorzystaniem szyfrowania symetrycznego, klucz szyfrujący przechowywany jest w Android KeyStore (szyfrowanie klucza symetrycznego poprzez szyfrowanie asymetryczne),

  1. Pliki na telefonie

Szyfrowane notatki – pliki audio przechowywane są na telefonie i podlegają szyfrowaniu symetrycznemu, klucz szyfrujący przechowywany jest w Android KeyStore (szyfrowanie klucza symetrycznego poprzez szyfrowanie asymetryczne).

Cele stosowania zabezpieczenia:

  1. Zabezpieczenie przed nieuprawnionym dostępem do danych w przypadku utraty urządzenia przenośnego,
  1. Zastosowane szyfrowanie dodatkowo zapewnia weryfikację integralności danych.
Back-end

Dane przechowywane w infrastrukturze Back-end Asystenta są przechowywane na zaszyfrowanych dyskach (system operacyjny oraz dane). Kopie zapasowe są szyfrowane poprzez PGP/GnuPG. Hasła przechowywane są z wykorzystaniem szyfrowania symetrycznego i/lub rozwiązania HashiCorp Vault.

Cele stosowania zabezpieczenia:

  1. Zabezpieczenie dostępu do danych na wypadek nieautoryzowanego dostępu do infrastruktury,
  1. Zabezpieczenie kopii zapasowych na wypadek nieautoryzowanego dostępu.

Uwierzytelnianie i autoryzacja

Aplikacja Android

Aplikacja stosuje metody uwierzytelniania podczas komunikacji z Back-end opisane poniżej.

Certyfikaty klienckie

Aplikacja do uwierzytelnienia urządzenia użytkownika stosuje certyfikaty klienckie (standard X.509). Proces wydania certyfikatu klienckiego składa się z dwóch etapów – wydania certyfikatu tymczasowego, który służy do podstawowej łączności z serwerem i ma na celu umożliwić przejście procesu onboardingu i uwierzytelnienie użytkownika. Po uwierzytelnieniu użytkownika wydawany jest certyfikat produkcyjny umożliwiający dostęp do pozostałych metod API.

Proces wydania certyfikatu klienckiego:

  1. Aplikacja Android generuje klucz prywatny, który jest przechowany w Android KeyStore i nie jest dostępny bezpośrednio dla aplikacji,
  1. Aplikacja generuje żądanie podpisania certyfikatu tymczasowego (Certificate Signing Request - CSR), które wysyła na serwer w celu podpisania przez Urząd Certyfikacji właściwy dla instalacji Edward.ai,
  1. Serwer podpisuje Urzędem Certyfikacji (Certificate Authority – CA) właściwym dla Back-end żądanie podpisania certyfikatu tymczasowego (CSR) z krótkim czasem ważności certyfikatu (1 godzina),
  1. Aplikacja Android odbiera podpisany certyfikat i wszystkie żądania do API uwierzytelnia z zastosowaniem wydanego Tymczasowego Certyfikatu Klienckiego,
  1. Następnie użytkownik przechodzi proces onboardingu poprzez uwierzytelnienie konta użytkownika (sposób uwierzytelnienia zależny od wersji Asystenta – domyślnie kod SMS),
  1. Po pomyślnym uwierzytelnieniu konta użytkownika serwer prosi Aplikację Android o przygotowanie żądania podpisania certyfikatu produkcyjnego (CSR) i żądanie takie jest dopuszczone przez serwer,
  1. Serwer podpisuje Urzędem Certyfikacji (CA) właściwym dla Back-end certyfikat produkcyjny z długim czasem ważności (1 rok),
  1. Aplikacja Android odbiera podpisany certyfikat produkcyjny i wszystkie żądania do API uwierzytelnia z zastosowaniem wydanego produkcyjnego certyfikatu klienckiego.

Odnawianie Produkcyjnego Certyfikatu Klienckiego:

  1. Na 2 miesiące przed upływem terminu ważności klienckiego certyfikatu produkcyjnego serwer wysyła prośbę do Aplikacji Android o wygenerowanie nowego żądania podpisania certyfikatu produkcyjnego (CSR),
  1. Aplikacja Android generuje nowe żądanie podpisania certyfikatu produkcyjnego (CSR) i serwer odbiera żądanie,
  1. Serwer podpisuje Urzędem Certyfikacji (CA) właściwym dla Back-end żądanie podpisania certyfikatu produkcyjnego (CSR) z długim czasem ważności (1 rok),
  1. Aplikacja Android odbiera podpisany nowy certyfikat produkcyjny i wszystkie żądania do API uwierzytelnia z zastosowaniem wydanego Produkcyjnego Certyfikatu Klienckiego.
Podpis cyfrowy

Aplikacja do uwierzytelnienia urządzenia użytkownika stosuje dodatkowo podpis cyfrowy z wykorzystaniem certyfikatu klienckiego. Proces ten ma na celu wprowadzenie dodatkowej warstwy zabezpieczeń.

Do każdego wywołania API przez Aplikację Android dołączany jest nagłówek HTTP zawierający podpisywaną wiadomość oraz nagłówek HTTP z podpisem cyfrowym tej wiadomości uwierzytelniającym urządzenie użytkownika z wykorzystaniem certyfikatu klienckiego.

Podpisywana wiadomość zawiera w sobie m.in. Token TOTP, który ważny jest jedynie krótki okres czasu, token ten dodatkowo podlega weryfikacji po stronie serwera.

W przypadku dedykowanej wersji Asystenta możliwe jest zastosowanie:

  1. Inspekcji oraz kontroli ruchu sieciowego z zastosowaniem rozwiązań typu Web Application Firewall (np. F5 Networks),
  1. Delegacja szyfrowania ruchu na urządzenia krańcowe z zastosowaniem rozwiązań typu SSL Offloading.

W przypadku zastosowania powyższych technik i braku kontroli Back-end nad weryfikacją certyfikatu klienckiego podpis cyfrowy przekazywany w nagłówku HTTP uwierzytelnia urządzenie w sposób przeźroczysty dla samej warstwy transmisji TLS.

Tokeny TOTP (Time-based One-Time Password algorithm)

Aplikacja Android stosuje dodatkowo tokeny TOTP (RFC 6238) mające na celu zabezpieczyć komunikację przed potencjalnymi atakami związanymi z czasem żądania. Klucz wykorzystywany do generowania tokenów jest generowany po stronie serwera i przekazywany jest do Aplikacji Android w procesie onboardingu. Po jednorazowej wymienia klucza nie jest on już dalej wymieniany, jedynie generowane są kody jednorazowe ważne określony, krótki czas.  

Domyślne okienko dla weryfikacji tokenu TOTP to 30 sekund.

Back-end

Uwierzytelnianie jednorazowym hasłem (kodem QR)

Dostęp do panelów użytkownika Asystenta oraz managera zespołu użytkowników Asystenta jest możliwy za pomocą nadanego loginu i hasła lub jednorazowego hasła generowanego przez aplikację Android.

Użytkownik wchodzi na stronę logowania do panelu, włącza Asystenta i skanuje kod QR, co w efekcie prowadzi do zalogowania użytkownika. Użytkownik potwierdza tym samym, że jest w posiadaniu urządzenia z aktywnym Asystentem, tj. posiada już dostęp do danych, jakie przetwarza Asystent.

Serwer weryfikuje jednorazowy kod TOTP wygenerowany przez Aplikację Android ważny 30 sekund. Klucz do tokenu TOTP wymieniany jest w procesie onboardingu i uwierzytelniania konta użytkownika po instalacji Aplikacji Android.

W szczególnych przypadkach istnieje możliwość wyłączenia tej metody uwierzytelniania.

Uwierzytelnianie loginem i hasłem

Istnieje możliwość nadania loginu i hasła użytkownika. Jest to klasyczna metoda uwierzytelniania. Stosowana głównie dla kont managera zespołu użytkowników Asystenta.

Użytkownik ma możliwość zresetowania hasła poprzez wysłanie linku resetującego na przypisany do konta adres e-mail.

Uwierzytelnianie poprzez poświadczenia Active Directory / LDAP

Dostęp do panelów administracyjnych Asystenta jest ograniczony do wybranych, zaufanych adresów IP oraz dodatkowo zabezpieczony jest logowaniem z wykorzystaniem poświadczeń Active Directory / LDAP.

W dedykowanej wersji Asystenta istnieje możliwość podłączenia uwierzytelniania Active Directory / LDAP jako głównej metody uwierzytelniania dla użytkowników Asystenta.

Dodatkowe zabezpieczenia

Aplikacja Android

Aplikacja Android stosuje szereg dodatkowych zabezpieczeń, które są włączane lub wyłączane w zależności od wersji Asystenta.

Blokada możliwości wykonania kopii zapasowej aplikacji i danych

Asystent domyślnie ma włączoną blokadę wykonania kopii zapasowej aplikacji oraz danych przechowywanych przez aplikację Android.

Cele stosowania zabezpieczenia:

  1. Uniknięcie utraty danych poprzez wykonanie kopii zapasowej Aplikacji Android oraz jej danych przez nieświadomego użytkownika. Ze względu na stosowane szyfrowanie danych oraz przechowywanie kluczy szyfrujących w Android KeyStore nie ma możliwości odtworzenia danych z kopii zapasowej na nowym urządzeniu – nie będzie dostępny klucz szyfrujący,
  1. Utrudnienie wykonania kopii zaszyfrowanych danych użytkownika w sytuacji nieuprawnionego dostępu do telefonu użytkownika.

W dedykowanej wersji Asystenta istnieje możliwość włączenia lub wyłączenia tego zabezpieczenia.

  1. Blokada możliwości wykonania zrzutu ekranu (screenshot)

Asystent domyślnie umożliwia wykonanie zrzutu ekranu (screenshot) każdego widoku aplikacji Android. Jest to podyktowane względami użyteczności oraz możliwości diagnozowania zgłoszeń serwisowych.

W dedykowanej wersji Asystenta istnieje możliwość włączenia lub wyłączenia tego zabezpieczenia.

Blokada podglądu ekranu aplikacji z widoku przełączania aplikacji

Asystent domyślnie umożliwia podgląd ekranu aplikacji w widoku przełączania pomiędzy aplikacjami Android. Jest to podyktowane względami użyteczności.

W dedykowanej wersji Asystenta istnieje możliwość włączenia lub wyłączenia tego zabezpieczenia.

Brak przechowywania danych poza kontenerem aplikacji (External Storage)

Asystent domyślnie przechowuje zaszyfrowane pliki audio z notatkami głosowymi poza kontenerem aplikacji w tzw. zewnętrznym kontenerze (External Storage). Podyktowane jest to ograniczeniami dostępnej przestrzeni dyskowej na starszych telefonach. Dane przechowywane w zewnętrznym kontenerze są szyfrowane.

W dedykowanej wersji Asystenta istnieje możliwość włączenia lub wyłączenia tego zabezpieczenia (tj. przechowywania danych jedynie w kontenerze aplikacji).

Wyłączone logowanie do dziennika systemowego

Asystent domyślnie nie loguje do dziennika systemowego. Aplikacja Android nie posiada kontroli nad dziennikiem systemowym i nie jest w stanie zapewnić bezpiecznego przechowywania logów. Dlatego też domyślnie logi nie są przekazywane do dziennika systemowego. Aplikacja zapisuje log w swoim kontenerze i przy pierwszym połączeniu z Back-end po utworzeniu logów jest on wysyłany na serwer i bezpiecznie kasowany z urządzenia. Logi nie zawierają danych osobowych.

W dedykowanej wersji Asystenta istnieje możliwość włączenia lub wyłączenia tego zabezpieczenia.

Bezpieczne kasowanie plików poprzez wielokrotne nadpisanie

Asystent domyślnie kasuje utworzone przez siebie pliki w sposób bezpieczny – tj. poprzez wielokrotne nadpisanie pliku, a następnie usunięcie.

Ograniczone wykorzystanie usług firm trzecich

Asystent ogranicza do minimum wykorzystanie usług firm trzecich ze względu na bezpieczne praktyki przetwarzania danych.

Domyślnie Asystent wykorzystuje usługi firmy Google:

  1. Rozpoznawanie mowy – głos wysyłany jest strumieniowo do Back-end następnie do usługi rozpoznawania mowy Google (w dedykowanych wersjach Asystenta istnieje możliwość zastąpienia po stronie serwera innym silnikiem),  
  1. Firebase Cloud Messaging (dawne Google Cloud Messaging) – do natychmiastowego wyzwolenia scenariusza lub synchronizacji z poziomu serwera wykorzystywany jest mechanizm wypychania „push”, który wzbudza Aplikację Android. W ramach tego kanału komunikacji nie są przesyłane dane osobowe - jedynie prośby o synchronizację z serwerem,
  1. Analityka oraz raportowanie błędów – usługi te pomocne są przy rozwiązywaniu zgłoszeń serwisowych oraz statystyce użytkowania Asystenta.

W dedykowanej wersji Asystenta istnieje możliwość włączenia lub wyłączenia korzystania z usług firm trzecich (nie są one krytyczne do pracy Asystenta lub posiadają swoje zamienniki).

Zaciemnianie kodu aplikacji

Aplikacja Android domyślnie posiada zaciemniony (obfuscated) kod. Taka technika ma na celu utrudnienie atakującemu analizę aplikacji, co w efekcie może wydłużyć czas potrzebny na przeprowadzenie potencjalnego ataku.

W dedykowanej wersji Asystenta istnieje możliwość włączenia lub wyłączenia tego zabezpieczenia.

Back-end

Asystent stosuje szereg zabezpieczeń po stronie Back-end. Poniższa sekcja opisuje wybrane zagadnienia z punktu widzenia użytkownika końcowego.

Wymuszenie stosowania szyfrowanej transmisji HTTPS

Back-end domyślnie wysyła nagłówki HSTS (HTTP Strict Transport Security), które mają na celu zabezpieczyć użytkownika przed atakiem polegającym na przechwyceniu sesji użytkownika poprzez wejście poprzez protokół HTTP bez szyfrowania. Przeglądarka przechowuje informacje o tym, że Back-end oczekuje szyfrowanej transmisji i uniemożliwia wejście na serwer bez szyfrowania.

Ochrona przed atakami typu XSS (Cross-Site Scripting)

Back-end domyślnie stosuje szereg zabezpieczeń przed atakami typu XSS (Cross-Site Scripting). Poniższa sekcja opisuje zastosowane zabezpieczenia.

Back-end stosuje jednocześnie zabezpieczenia dla nowszych oraz starszych przeglądarek:

  1. Ochrona nowego typu – dla nowszych przeglądarek

Content Security Policy (CSP) – kompleksowa ochrona przed atakami typu XSS definiująca politykę bezpieczeństwa dla całego serwisu oraz wybranych podstron. Back-end ogranicza do minimum wykorzystanie zewnętrznych skryptów oraz posiada restrykcyjną domyślną politykę „none” blokującą przetwarzanie przez przeglądarkę wszystkich elementów strony. Przetwarzanie dla wybranych elementów strony jest włączane jawnie, co pozwala uniknąć potencjalnych błędów bezpieczeństwa,

  1. Ochrona dla starszych przeglądarek

Zabezpieczenie przeciwko atakom typu Clickjacking poprzez zabronienie osadzania ramek (iframe) - serwer wysyła nagłówek „X-Frame-Options deny”

Zabezpieczenie przed zmianą typu MIME ogłaszanego przez serwer - serwer wysyła nagłówek “X-Content-Type-Options nosniff”

Zabezpieczenie przed różnymi atakami typu XSS (Cross-Site Scripting) - serwer wysyła nagłówek “X-XSS-Protection "1; mode=block";”

Jesteś gotów, by sprzedawać więcej?
Wypróbuj Edwarda w swoim zespole sprzedaży!
Sprawdź Edwarda
EDWARD to inteligentny asystent wykorzystywany z sukcesem przez zespoły sprzedaży w całej Polsce.

Czekamy na Ciebie! Zostań jednym z Klientów!
Masz pytania? meet@edward.ai
2040 Sp. z o.o. | All rights reserved.