Umów się na prezentację już dziś i zobacz na własne oczy, jak działa Edward!
Sprawdź Edwarda
MENU
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.
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.
Asystent stosuje silne szyfrowanie dla danych przesyłanych oraz przechowywanych. Szczegółowy opis zastosowanych zabezpieczeń szyfrowania znajduje się w poniższych sekcjach.
Wszystkie dane przesyłane pomiędzy Back-end, a urządzeniami końcowymi są szyfrowane z zastosowaniem silnego szyfrowania.
Asystent wykorzystuje do szyfrowania połączeń protokół TLS, który jest bezpiecznym następcą szyfrowania SSL.
Charakterystyka komunikacji:
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:
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:
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:
Dane przechowywane na urządzeniach końcowych (Android) oraz na serwerze są zabezpieczone dzięki zastosowanym technikom szyfrowania opisanym w poniższych sekcjach.
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:
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),
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:
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:
Aplikacja stosuje metody uwierzytelniania podczas komunikacji z Back-end opisane poniżej.
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:
Odnawianie Produkcyjnego Certyfikatu Klienckiego:
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:
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.
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.
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.
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.
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.
Aplikacja Android stosuje szereg dodatkowych zabezpieczeń, które są włączane lub wyłączane w zależności od wersji Asystenta.
Asystent domyślnie ma włączoną blokadę wykonania kopii zapasowej aplikacji oraz danych przechowywanych przez aplikację Android.
Cele stosowania zabezpieczenia:
W dedykowanej wersji Asystenta istnieje możliwość włączenia lub wyłączenia tego zabezpieczenia.
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.
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.
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).
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.
Asystent domyślnie kasuje utworzone przez siebie pliki w sposób bezpieczny – tj. poprzez wielokrotne nadpisanie pliku, a następnie usunięcie.
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:
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).
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.
Asystent stosuje szereg zabezpieczeń po stronie Back-end. Poniższa sekcja opisuje wybrane zagadnienia z punktu widzenia użytkownika końcowego.
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.
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:
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,
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";”
