Sprawdzone metody zapewniania bezpieczeństwa systemu

Ta sekcja zawiera zalecenia dotyczące zapewnienia bezpieczeństwa podstawowego systemu operacyjnego Android i urządzeń.

Uwierzytelnianie biometryczne

ostrożnie pozyskiwać, przechowywać i przetwarzać dane biometryczne w celu uwierzytelniania użytkowników; Wykonaj te czynności:

  • Wymagaj stosowania podstawowej metody uwierzytelniania przed użyciem innej formy uwierzytelniania (w tym biometrycznego).
  • Wymagaj wyraźnego potwierdzenia, aby wskazać intencję podczas korzystania z biernych metod biometrycznych, takich jak rozpoznawanie twarzy, w przypadku transakcji (np. płatności), które obejmują klucze powiązane z uwierzytelnianiem.
  • Wymagaj podstawowej metody uwierzytelniania co 72 godziny.
  • Używaj w pełni bezpiecznego potoku do obsługi wszystkich danych biometrycznych.
  • Nigdy nie wysyłaj danych biometrycznych (w tym nieprzetworzonych pomiarów czujnika i wyprowadzonych funkcji) poza urządzenie. Jeśli to możliwe, przechowuj te dane w bezpiecznym, odizolowanym środowisku, takim jak zaufane środowisko wykonawcze (TEE) lub element zabezpieczeń.

Urządzenia z funkcją biometryczną powinny obsługiwać interfejs BiometricPrompt API, który zapewnia wspólny i spójny interfejs dla programistów aplikacji, aby mogli korzystać z autoryzacji biometrycznej w swoich aplikacjach. Z BiometricPrompt można korzystać tylko w przypadku silnych danych biometrycznych. Integracje muszą być zgodne z wytycznymi zawartymi w dokumentacji dotyczącej zgodności z Androidem (CDD).

Więcej wskazówek dotyczących funkcji biometrycznych znajdziesz w wytycznych dotyczących implementacji interfejsu API funkcji biometrycznych.

SELinux

SELinux definiuje i egzekwuje większość modelu zabezpieczeń Androida. Prawidłowe korzystanie z SELinux jest bardzo ważne dla bezpieczeństwa urządzeń z Androidem i może pomóc w zmniejszeniu wpływu luk w zabezpieczeniach. Z tego powodu wszystkie urządzenia z Androidem powinny stosować solidne zasady SELinux.

  • Wprowadź zasadę jak najmniejszych uprawnień.
  • Unikaj przyznawania uprawnień CAP_DAC_OVERRIDE, CAP_SYS_ADMIN i CAP_NET_ADMIN.
  • Nie rejestruj danych systemowych na karcie SD.
  • Użyj typów udostępnionych przez nas do uzyskania dostępu kierowcy, takich jak gpu_device, audio_device itp.
  • Nadawaj procesom, plikom i typom SELinux znaczące nazwy.
    • Upewnij się, że etykiety domyślne nie są używane i nie ma do nich dostępu.
  • Zasady dotyczące poszczególnych urządzeń powinny stanowić od 5% do 10% wszystkich zasad działających na urządzeniu. Dostosowania w zakresie powyżej 20%prawie na pewno zawierają domeny z nadmiernymi uprawnieniami i nieaktualne zasady. Zbyt duża zasada marnuje pamięć, zajmuje miejsce na dysku, ponieważ wymaga większego obrazu rozruchowego, i negatywne wpływa na czas wyszukiwania zasad w czasie działania.

Dynamiczne wczytywanie zasad SELinux

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

  • zapobieganie akceptacji krytycznych poprawek zabezpieczeń;
  • Udostępnianie możliwości uzyskania uprawnień root na urządzeniu przez ponowne załadowanie zasad.
  • Wystawienie wektora ataków typu „man in the middle” na updater.
  • W rezultacie urządzenia mogą się nie nadawać do użytku z powodu błędów w aktualizacjach zasad.

Backdoor

Aplikacje na Androida nie powinny zawierać żadnych backdoorów ani sposobów na uzyskanie dostępu do systemu lub danych, które omijają normalne mechanizmy zabezpieczeń. Obejmuje to diagnostykę, debugowanie, rozwój lub naprawę gwarancyjną, które są dostępne tylko dla dewelopera. Aby zapobiec backdoorom:

  • Skanowanie wszystkich aplikacji innych firm za pomocą uznanego w branży narzędzia do skanowania aplikacji pod kątem luk w zabezpieczeniach.
  • Sprawdzanie kodu wszystkich plików kodu z dostępem do danych wrażliwych, w tym bibliotek zewnętrznych.
  • Korzystaj z Google Play Protect, przesyłając aplikacje do Google Play w celu skanowania. Aplikacje możesz przesyłać do skanowania bez publikowania ich w Google Play.
  • Nie przeładowuj narzędzi diagnostycznych ani narzędzi do naprawy w ramach wersji wydania. Instaluj te narzędzia tylko wtedy, gdy chcesz rozwiązać konkretne problemy. Ponadto narzędzia te nie mogą działać na podstawie żadnych danych dotyczących konta ani przesyłać żadnych takich danych.

Narzędzia dla programistów

Narzędzia programistyczne, takie jak narzędzia do debugowania, testowania i diagnostyki, często powodują niezamierzone luki w zabezpieczeniach na urządzeniu, ponieważ ujawniają sposób ich działania oraz dane, które zbierają. Aby mieć pewność, że narzędzia programistyczne nie dostaną się do wersji produkcyjnych:

  • Przed użyciem obrazu systemu utwórz czarną listę haszy narzędzi do debugowania i testowania oraz skanowania kompilacji tych plików APK.
  • Skanuj wszystkie aplikacje własne za pomocą narzędzia do skanowania pod kątem luk w zabezpieczeniach, które jest uznawane w branży.
  • Zatrudnij zewnętrzną firmę zajmującą się testowaniem aplikacji, aby zweryfikować wszystkie ważne aplikacje diagnostyczne na urządzeniu przed każdą dużą aktualizacją, zwłaszcza jeśli aplikacja została opracowana przez zewnętrzną firmę.
  • Upewnij się, że podczas sesji pomocy tylko użytkownik może włączyć narzędzie, mówiąc lub pisząc na czacie. przechowywać artefakty dotyczące zgody i wyłączyć narzędzie po zebraniu niezbędnych informacji diagnostycznych;
  • przechowywać w logach dostępnych dla użytkownika na jego koncie operatora zapisy dotyczące korzystania z tego narzędzia;
  • Upewnij się, że wszelkie informacje umożliwiające identyfikację oraz dane telemetryczne dotyczące urządzeń zbierane przez narzędzie są poddawane anonimizacji, przechowywane i usuwane zgodnie z obowiązującymi w danym kraju zasadami. Należy zbierać tylko dane istotne dla rozmowy z zespołem pomocy. Te dane powinny zostać usunięte po każdym wywołaniu.
  • Upewnij się, że techniki, które mogą być wykorzystywane przez programy szpiegowskie, takie jak rejestrowanie naciśnięć klawiszy, używanie mikrofonu lub kamery, nie są używane bez wyraźnej zgody użytkownika. Aplikacje korzystające z tych potencjalnie inwazyjnych metod powinny być wyraźnie opisane wraz z polityką prywatności, na którą użytkownik musi wyrazić zgodę. Aplikacje tego typu nie powinny być włączone bez wyraźnej zgody użytkownika.

Oto kilka dodatkowych sugestii dotyczących wdrażania informacji o zbieraniu danych i uzyskiwania zgody:

Powiadomienie o zbieraniu danych w aplikacji

  • Wyświetlaj normalne korzystanie z aplikacji bezpośrednio w aplikacji. Nie wymagaj od użytkownika otwierania menu ani ustawień.
  • Opisz typ zbieranych danych i wyjaśnij, jak są one wykorzystywane.
  • Najlepiej nie umieszczać tych informacji w polityce prywatności ani warunkach korzystania z usługi. nie może być częścią innych informacji, które nie dotyczą zbierania danych osobowych lub poufnych;
  • Zgoda musi być wyrażona w postaci twierdzącej. nie może traktować jako zgody opuszczenia przez użytkownika ekranu z tymi informacjami (również przez kliknięcie w innym miejscu aplikacji albo naciśnięcie przycisku Wstecz lub przycisku ekranu głównego);
  • Okno z prośbą o zgodę na przetwarzanie danych osobowych musi być prezentowane w jasny i jednoznaczny sposób.
  • Wyrażenie zgody musi wymagać działania użytkownika, takiego jak kliknięcie przycisku lub wypowiedzenie polecenia.
  • Nie zbieraj danych osobowych ani danych wrażliwych bez wyraźnej zgody.
  • Nie używaj komunikatów automatycznie zamykanych ani wygasających.

Funkcje osadzone w AOSP

Umieszczanie dodatkowych funkcji w AOSP może często powodować nieoczekiwane zachowania i skutki. Należy zachować ostrożność.

  • Upewnij się, że użytkownik otrzyma odpowiedni komunikat, jeśli chce używać innych domyślnych aplikacji (np. wyszukiwarki, przeglądarki internetowej, programu uruchamiającego) i poinformuj go o wysyłaniu danych poza urządzenie.
  • Upewnij się, że pliki APK AOSP są podpisane certyfikatem AOSP.
  • Przeprowadź testy regresji i zachowaj dziennik zmian, aby sprawdzić, czy do plików APK AOSP został dodany kod.

Aktualizacje zabezpieczeń

Urządzenia z Androidem powinny otrzymywać ciągłe wsparcie zabezpieczeń przez co najmniej 2 lata od premiery. Obejmuje to regularne otrzymywanie aktualizacji, które eliminują znane luki w zabezpieczeniach.

  • Współpracuj z partnerami sprzętowymi, takimi jak dostawcy układów SoC, aby wdrożyć odpowiednie umowy dotyczące obsługi wszystkich komponentów na urządzeniu z Androidem.
  • Zadbaj o to, aby aktualizacje zabezpieczeń można było instalować z minimalną interakcją użytkownika, aby zwiększyć prawdopodobieństwo zaakceptowania i zainstalowania aktualizacji na urządzeniu z Androidem. Zdecydowanie zalecamy wdrożenie bezproblemowych aktualizacji systemu lub równoważnych funkcji zabezpieczeń.
  • Zapoznaj się z wymaganiami dotyczącymi łącznego poziomu poprawek zabezpieczeń Androida (SPL) określonymi w komunikatach o błędach zabezpieczeń Androida. Na przykład urządzenia, które korzystają z poziomu poprawki zabezpieczeń z 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 biuletynów bezpieczeństwa.

Dynamiczne aktualizacje jądra

Nie modyfikuj dynamicznie kluczowych komponentów systemu. Chociaż niektóre badania sugerują, że dynamiczne aktualizacje jądra pomagają chronić przed zagrożeniami w nagłych przypadkach, ocenione koszty obecnie przewyższają korzyści. Zamiast tego utwórz solidną metodę aktualizacji OTA, aby szybko rozpowszechniać zabezpieczenia przed lukami w zabezpieczeniach.

Zarządzanie kluczami

Stosuj dobre zasady i sprawdzone metody zarządzania kluczami, aby zapewnić bezpieczeństwo kluczy podpisywania.

  • Nie udostępniaj kluczy podpisywania stronom zewnętrznym.
  • Jeśli klucz podpisywania zostanie złamany, wygeneruj nowy klucz i podpisz ponownie wszystkie aplikacje.
  • przechowywać wszystkie klucze w wysokiej klasy modułach sprzętowych lub usługach wymagających dostępu za pomocą wielu czynników;

Podpisywanie obrazu systemu

Sygnatura obrazu systemu ma kluczowe znaczenie dla integralności urządzenia.

  • Nie podpisuj urządzeń kluczem publicznym.
  • zarządzać kluczami do podpisywania urządzeń w sposób zgodny ze standardowymi metodami branżowymi dotyczącymi obsługi kluczy poufnych, w tym sprzętowego modułu zabezpieczeń (HSM), który zapewnia ograniczony, możliwy do zweryfikowania dostęp;

odblokowane programy rozruchowe,

Wiele urządzeń z Androidem obsługuje odblokowywanie, co umożliwia właścicielowi urządzenia modyfikowanie partycji systemowej lub instalowanie niestandardowego systemu operacyjnego. Typowe przypadki użycia to instalowanie obrazu systemu innej firmy i wdrażanie na urządzeniu funkcji na poziomie systemu. Aby na przykład odblokować obraz systemu na Nexusie lub Pixelu, użytkownik może uruchomić fastboot oem unlock, co spowoduje wyświetlenie tego komunikatu:

Zalecamy, aby przed odblokowaniem urządzenia z Androidem wszystkie dane użytkownika były bezpiecznie usuwane. Nieusunięcie wszystkich danych podczas odblokowywania może umożliwić osobie atakującej znajdującej się w pobliżu nieautoryzowany dostęp do poufnych danych użytkownika Androida. Aby zapobiec ujawnieniu danych użytkownika, urządzenie obsługujące odblokowywanie musi prawidłowo stosować tę funkcję.

  • Gdy użytkownik potwierdzi polecenie odblokowania, urządzenie musi natychmiast rozpocząć kasowanie danych. Flaga unlocked musi być ustawiona dopiero po zakończeniu bezpiecznego usunięcia.
  • Jeśli nie można bezpiecznie usunąć danych, urządzenie musi pozostać w zamkniętym stanie.
  • Jeśli jest to obsługiwane przez urządzenie blokujące, należy użyć ioctl(BLKSECDISCARD) lub jego odpowiednika. W przypadku urządzeń z wbudowaną kartą MultiMediaCard (eMMC) należy użyć polecenia Secure Erase lub Secure Trim. W przypadku eMMC 4.5 i nowszych należy użyć zwykłego polecenia Erase lub Trim, a następnie operacji Sanitize.
  • Jeśli BLKSECDISCARD nie jest obsługiwany przez urządzenie blokujące, należy użyć ioctl(BLKDISCARD). Na urządzeniach z eMMC jest to zwykła operacja Trim.
  • Jeśli BLKDISCARD nie jest obsługiwane, zaakceptuj zastąpienie blokowania urządzeń przez wpisanie wszystkich zer.
  • Użytkownik musi mieć możliwość wyczyszczenia danych przed flashowaniem partycji. Na przykład urządzenia Nexus używają polecenia fastboot oem lock do wyczyszczania danych użytkownika.
  • Urządzenie może rejestrować, za pomocą eFuses lub podobnego mechanizmu, czy zostało odblokowane lub ponownie zablokowane. Zalecamy jednak, aby przywrócić blokadę programu rozruchowego, a następnie przywrócić ustawienia fabryczne, co powinno przywrócić pełną funkcjonalność urządzenia.

Te wymagania gwarantują, że wszystkie dane zostaną zniszczone po zakończeniu operacji odblokowania. Niewdrożenie tych zabezpieczeń jest uznawane za niebezpieczeństwo o umiarkowanym poziomie zagrożeń.

Odblokowane urządzenie można ponownie zablokować za pomocą polecenia fastboot oem lock. Zablokowanie bootloadera zapewnia tę samą ochronę danych użytkownika w nowym niestandardowym systemie operacyjnym, co w systemie operacyjnym oryginalnego producenta urządzenia (np. dane użytkownika są usuwane, jeśli urządzenie zostanie ponownie odblokowane).

testowanie penetracyjne urządzeń;

Przed wysyłką urządzenia powinny zostać sprawdzone przez kompetentnego pentestera. Testy penetracyjne powinny ustalić, czy urządzenie jest zgodne z instrukcjami dotyczącymi zabezpieczeń podanymi tutaj oraz z wewnętrznych wytycznych producenta OEM.

testowanie bezpieczeństwa;

Użyj narzędzi testowania bezpieczeństwa udostępnionych przez AOSP. W szczególności

  • Korzystaj z narzędzi do zabezpieczania pamięci podczas tworzenia aplikacji: używaj MTE, jeśli jest obsługiwany (ARMv9 i nowsze), oraz HWASan, jeśli nie. Uruchom jak najwięcej testów przy włączonych tych narzędziach.
  • Używaj w produkcji GWP-ASan i KFENCE do wykrywania z zastosowaniem metody probabilistycznej problemów z bezpieczeństwem pamięci.