Najlepsze praktyki w zakresie bezpieczeństwa systemu

W tej sekcji znajdują się zalecenia dotyczące zapewnienia bezpieczeństwa podstawowego systemu operacyjnego Android i urządzeń.

Uwierzytelnianie biometryczne

Ostrożnie pozyskuj, przechowuj i przetwarzaj dane biometryczne w celu uwierzytelnienia użytkownika. Powinieneś:

  • Przed użyciem jakiejkolwiek innej formy uwierzytelnienia (w tym biometrii) należy zastosować podstawową metodę uwierzytelniania.
  • Wymagaj wyraźnego potwierdzenia, aby wskazać zamiar w przypadku korzystania z pasywnych metod biometrycznych, takich jak rozpoznawanie twarzy, w przypadku transakcji (na przykład płatności) wymagających kluczy powiązanych z uwierzytelnianiem.
  • Wymagaj podstawowej metody uwierzytelniania co 72 godziny.
  • Korzystaj z w pełni bezpiecznego rurociągu dla wszystkich danych biometrycznych i ich obsługi.
  • Nigdy nie wysyłaj danych biometrycznych (w tym nieprzetworzonych pomiarów czujników i funkcji pochodnych) poza urządzenie. Jeśli to możliwe, przechowuj te dane w bezpiecznym, izolowanym środowisku, takim jak Trusted Execution Environment (TEE) lub Secure Element.

Urządzenia z danymi biometrycznymi powinny obsługiwać interfejs API BiometricPrompt , który zapewnia twórcom aplikacji wspólny i spójny interfejs umożliwiający korzystanie z uwierzytelniania opartego na danych biometrycznych w swoich aplikacjach. Tylko silne dane biometryczne można zintegrować z BiometricPrompt , a integracje muszą być zgodne z wytycznymi dokumentu definicji zgodności z systemem Android (CDD).

Więcej wskazówek dotyczących biometrii można znaleźć w artykule Wytyczne dotyczące wdrażania biometrycznej HAL .

SELinux

SELinux zapewnia definicję i egzekwowanie większości modelu bezpieczeństwa Androida. Prawidłowe korzystanie z SELinux ma kluczowe znaczenie dla bezpieczeństwa urządzeń z systemem Android i może pomóc złagodzić wpływ luk w zabezpieczeniach. Z tego powodu wszystkie urządzenia z Androidem powinny wdrożyć solidną politykę SELinux .

  • Zaimplementuj politykę najmniejszych uprawnień.
  • Unikaj udzielania uprawnień CAP_DAC_OVERRIDE , CAP_SYS_ADMIN i CAP_NET_ADMIN .
  • Nie zapisuj danych systemowych na karcie SD.
  • Użyj dostarczonych typów dostępu do sterowników, takich jak gpu_device , audio_device itp.
  • Używaj znaczących nazw procesów, plików i typów SELinux.
    • Upewnij się, że nie są używane etykiety domyślne i nie ma do nich dostępu.
  • Zasady specyficzne dla urządzenia powinny stanowić 5–10% ogólnej polityki działającej na urządzeniu. Dostosowania w zakresie 20%+ prawie na pewno zawierają domeny nadmiernie uprzywilejowane i martwe zasady. Niepotrzebnie duże zasady marnują pamięć, marnują miejsce na dysku, wymagając większego obrazu rozruchowego i negatywnie wpływają na czas wyszukiwania zasad w czasie wykonywania.

Dynamiczne ładowanie polityki SELinux

Nie ładuj dynamicznie zasad SELinux na urządzeniach z Androidem. Może to spowodować problemy, takie jak:

  • Zapobieganie akceptowaniu krytycznych poprawek bezpieczeństwa.
  • Ujawnienie możliwości zrootowania urządzenia poprzez ponowne załadowanie zasad.
  • Ujawnianie wektora ataków typu „man-in-the-middle” na aktualizatora zasad.
  • Powoduje to zablokowanie urządzeń z powodu błędów w aktualizacjach zasad.

Tylne drzwi

Aplikacje na Androida nie powinny mieć żadnych backdoorów ani sposobów dostępu do systemu lub danych omijających normalne mechanizmy bezpieczeństwa. Obejmuje to diagnostykę, debugowanie, rozwój lub naprawę gwarancyjną specjalny dostęp chroniony tajemnicami znanymi programiście. Aby zapobiec backdoorom:

  • Skanuj wszystkie aplikacje innych firm za pomocą uznanego w branży narzędzia do skanowania pod kątem luk w zabezpieczeniach aplikacji.
  • Wykonuj przeglądy całego kodu z poufnym dostępem, w tym bibliotek innych firm.
  • Skorzystaj z Google Play Protect, przesyłając aplikacje do Google Play w celu skanowania. Możesz przesyłać aplikacje do skanowania bez publikowania w Google Play.
  • Nie ładuj wstępnie narzędzi diagnostycznych lub naprawczych w kompilacjach wydań. Instaluj te narzędzia tylko na żądanie, aby rozwiązać określone problemy. Ponadto narzędzia te nie mogą wykorzystywać ani przesyłać żadnych danych specyficznych dla konta.

Narzędzia programistyczne

Narzędzia programistyczne, takie jak narzędzia do debugowania, testowania i diagnostyki, często mogą tworzyć niezamierzone luki w zabezpieczeniach urządzenia, ujawniając sposób ich działania i gromadzone dane. Aby mieć pewność, że narzędzia programistyczne nie przedostaną się do wersji produkcyjnych:

  • Przed użyciem obrazu systemu utwórz czarną listę skrótów narzędzi do debugowania i testowania oraz kompilacji skanowania dla tych plików APK.
  • Skanuj wszystkie aplikacje własne za pomocą uznanego w branży narzędzia do skanowania pod kątem luk w zabezpieczeniach aplikacji.
  • Zatrudnij zewnętrzną firmę zajmującą się testowaniem bezpieczeństwa aplikacji, aby oceniła wszystkie krytyczne aplikacje diagnostyczne na urządzeniu przed jakąkolwiek większą aktualizacją, zwłaszcza jeśli aplikacja została opracowana przez stronę trzecią.
  • Upewnij się, że tylko użytkownik może włączyć narzędzie ustnie lub na czacie podczas sesji pomocy technicznej. Przechowuj artefakty zgody i wyłączaj narzędzie po zebraniu niezbędnych informacji diagnostycznych.
  • Przechowuj historię użytkowania tego narzędzia w dzienniku dostępnym dla użytkownika na jego koncie operatora.
  • Upewnij się, że wszelkie informacje umożliwiające identyfikację użytkownika (PII) lub dane telemetryczne urządzenia zebrane przez narzędzie podlegają praktykom anonimizacji, przechowywania i usuwania właściwymi dla danego kraju. Należy gromadzić wyłącznie dane istotne dla wezwania wsparcia. Dane te należy usuwać po każdej rozmowie.
  • Upewnij się, że techniki, które można zastosować w przypadku oprogramowania szpiegującego, takie jak rejestrowanie naciśnięć klawiszy, użycie mikrofonu lub kamery, nie są używane bez wyraźnej zgody użytkownika. Aplikacje wykorzystujące te potencjalnie inwazyjne metody należy bardzo wyraźnie ujawnić wraz z polityką prywatności, na którą użytkownik musi wyrazić zgodę. Nie należy włączać takich aplikacji bez wyraźnej zgody użytkownika.

Oto kilka dodatkowych sugestii, do których należy się odnieść przy wdrażaniu ujawniania informacji i wyrażania zgody:

Ujawnianie informacji w aplikacji

  • Wyświetlaj normalne użytkowanie aplikacji bezpośrednio w aplikacji. Nie wymagaj od użytkownika nawigowania do menu lub ustawień.
  • Proszę opisać rodzaj gromadzonych danych i wyjaśnić, w jaki sposób dane będą wykorzystywane.
  • Najlepiej nie umieszczaj tych informacji w polityce prywatności ani warunkach świadczenia usług. Nie dołączaj go do innych ujawnień niezwiązanych z gromadzeniem danych osobowych lub wrażliwych.
  • Zgoda musi być twierdząca. Nie traktuj odchodzenia od ujawnienia informacji, w tym dotknięcia lub naciśnięcia przycisku Wstecz lub strony głównej, jako zgody.
  • Przedstaw okno dialogowe dotyczące zgody w jasny i jednoznaczny sposób.
  • Wymagaj potwierdzającej akcji użytkownika, takiej jak dotknięcie, aby zaakceptować lub wypowiedzenie polecenia, aby zaakceptować.
  • Nie zbieraj danych osobowych ani wrażliwych przed uzyskaniem pozytywnej zgody.
  • Nie używaj wiadomości automatycznie odrzucanych ani wygasających.

Wbudowana funkcjonalność w AOSP

Osadzanie dodatkowej funkcjonalności w AOSP może często mieć nieoczekiwane zachowanie i konsekwencje; postępuj ostrożnie.

  • Upewnij się, że użytkownik zostanie zapytany, czy chce korzystać z innych domyślnych aplikacji (na przykład wyszukiwarki, przeglądarki internetowej, programu uruchamiającego) i ujawnić wysyłanie danych z urządzenia.
  • Upewnij się, że pliki APK AOSP są podpisane certyfikatem AOSP.
  • Przeprowadź testy regresyjne i prowadź dziennik zmian, aby ustalić, czy do plików APK AOSP dodano kod.

Aktualizacje zabezpieczeń

Urządzenia z Androidem powinny otrzymywać stałą pomoc w zakresie bezpieczeństwa przez co najmniej dwa lata od premiery. Obejmuje to otrzymywanie regularnych aktualizacji usuwających znane luki w zabezpieczeniach.

  • Współpracuj z partnerami sprzętowymi, takimi jak dostawcy SoC, aby wprowadzić odpowiednie umowy pomocy technicznej dla wszystkich komponentów urządzenia z systemem Android.
  • Upewnij się, że aktualizacje zabezpieczeń można zainstalować przy minimalnej interakcji użytkownika, aby zwiększyć prawdopodobieństwo, że użytkownicy zaakceptują i zainstalują aktualizacje na swoim urządzeniu z Androidem. Zdecydowanie zaleca się wdrożenie bezproblemowych aktualizacji systemu lub równoważnej funkcji zabezpieczeń.
  • Upewnij się, że rozumiesz skumulowane wymagania dotyczące poziomu poprawek zabezpieczeń systemu Android (SPL) zgodnie z deklaracjami zawartymi w Biuletynie zabezpieczeń systemu Android . Na przykład urządzenia korzystające z poprawki zabezpieczeń na poziomie 2018-02-01 muszą zawierać wszystkie problemy związane z tym poziomem poprawki zabezpieczeń, a także poprawki wszystkich problemów zgłoszonych we wszystkich poprzednich biuletynach zabezpieczeń.

Dynamiczne aktualizacje jądra

Nie modyfikuj dynamicznie krytycznych komponentów systemu. Chociaż istnieją badania sugerujące, że dynamiczne aktualizacje jądra pomagają chronić przed zagrożeniami awaryjnymi, obecnie szacowany koszt przewyższa korzyści. Zamiast tego utwórz solidną metodę aktualizacji OTA, aby szybko rozpowszechnić zabezpieczenia przed lukami w zabezpieczeniach.

Zarządzanie kluczami

Utrzymuj dobre zasady i praktyki zarządzania kluczami, aby zapewnić bezpieczeństwo podpisywania kluczy.

  • Nie udostępniaj kluczy podpisujących stronom zewnętrznym.
  • Jeśli klucz podpisu zostanie naruszony, wygeneruj nowy klucz i podpisz dwukrotnie wszystkie aplikacje.
  • Przechowuj wszystkie klucze w sprzęcie modułowym o wysokim poziomie bezpieczeństwa lub w usługach wymagających dostępu z wielu czynników.

Podpisywanie obrazu systemu

Podpis obrazu systemu ma kluczowe znaczenie dla określenia integralności urządzenia.

  • Nie podpisuj urządzeń publicznie znanym kluczem.
  • Zarządzaj kluczami podpisującymi urządzenia w sposób zgodny ze standardowymi praktykami branżowymi dotyczącymi obsługi poufnych kluczy, w tym za pomocą sprzętowego modułu zabezpieczeń (HSM), który zapewnia ograniczony dostęp podlegający kontroli.

Odblokowane bootloadery

Wiele urządzeń z Androidem obsługuje odblokowywanie, umożliwiając właścicielowi urządzenia modyfikację partycji systemowej lub instalację niestandardowego systemu operacyjnego. Typowe przypadki użycia obejmują instalację obrazu systemu innej firmy i wykonywanie programowania na poziomie systemu na urządzeniu. Na przykład, aby odblokować obraz systemu na Google Nexusie lub Pixelu, użytkownik może uruchomić fastboot oem unlock , co wyświetli ten komunikat:

Zgodnie z najlepszą praktyką odblokowane urządzenia z Androidem muszą bezpiecznie usunąć wszystkie dane użytkownika przed odblokowaniem. Nieprawidłowe usunięcie wszystkich danych podczas odblokowania może pozwolić osobie atakującej znajdującej się fizycznie blisko na uzyskanie nieautoryzowanego dostępu do poufnych danych użytkownika Androida. Aby zapobiec ujawnieniu danych użytkownika, urządzenie obsługujące odblokowanie musi je odpowiednio zaimplementować.

  • Po potwierdzeniu przez użytkownika polecenia odblokowania urządzenie musi natychmiast rozpocząć czyszczenie danych. Flagi unlocked nie można ustawić przed zakończeniem bezpiecznego usuwania.
  • Jeśli nie można ukończyć bezpiecznego usuwania, urządzenie musi pozostać w stanie zablokowanym.
  • Jeśli jest obsługiwane przez podstawowe urządzenie blokowe, należy użyć ioctl(BLKSECDISCARD) lub równoważnego. W przypadku wbudowanych urządzeń MultiMediaCard (eMMC) oznacza to użycie polecenia Bezpieczne wymazywanie lub Bezpieczne przycinanie. W przypadku eMMC 4.5 i nowszych wersji oznacza to użycie normalnego usuwania lub przycinania, po którym następuje operacja odkażania.
  • Jeśli BLKSECDISCARD nie jest obsługiwany przez bazowe urządzenie blokowe, zamiast tego należy użyć ioctl(BLKDISCARD) . Na urządzeniach eMMC jest to normalna operacja przycinania.
  • Jeżeli BLKDISCARD nie jest obsługiwany, dopuszczalne jest nadpisywanie urządzeń blokowych samymi zerami.
  • Użytkownik musi mieć możliwość zażądania wyczyszczenia danych użytkownika przed flashowaniem partycji. Na przykład urządzenia Nexus używają polecenia fastboot oem lock do czyszczenia danych użytkownika.
  • Urządzenie może rejestrować, za pośrednictwem eFuse lub podobnego mechanizmu, czy urządzenie zostało odblokowane i/lub ponownie zablokowane. Jednak zdecydowanie zalecamy, aby ponowne zablokowanie programu ładującego i późniejsze przywrócenie ustawień fabrycznych przywróciło pełną funkcjonalność urządzenia.

Wymagania te zapewniają, że wszystkie dane zostaną zniszczone po zakończeniu operacji odblokowania. Niewdrożenie tych zabezpieczeń jest uważane za lukę w zabezpieczeniach umiarkowanego poziomu .

Odblokowane urządzenie można później ponownie zablokować za pomocą polecenia fastboot oem lock . Zablokowanie programu ładującego zapewnia taką samą ochronę danych użytkownika w nowym, niestandardowym systemie operacyjnym, jak była dostępna w systemie operacyjnym oryginalnego producenta urządzenia (np. dane użytkownika zostaną usunięte, jeśli urządzenie zostanie ponownie odblokowane).

Pentestowanie urządzenia

Przed wysyłką urządzenia powinny zostać sprawdzone przez kompetentnego pentestera. Pentest powinien wykazać, że urządzenie przestrzegało podanych tutaj wskazówek dotyczących bezpieczeństwa, a także wewnętrznych wskazówek dotyczących bezpieczeństwa OEM.

Testowanie bezpieczeństwa

Skorzystaj z narzędzi do testowania bezpieczeństwa dostarczonych przez AOSP. W szczególności