Praktik Terbaik Keamanan Sistem

Bagian ini berisi rekomendasi untuk memastikan keamanan sistem operasi dan perangkat inti Android.

Otentikasi biometrik

Dapatkan, simpan, dan proses data biometrik untuk otentikasi pengguna dengan hati-hati. Anda harus:

  • Mandatkan metode autentikasi utama sebelum menggunakan bentuk autentikasi lainnya (termasuk biometrik).
  • Memerlukan konfirmasi eksplisit untuk menunjukkan niat saat menggunakan modalitas biometrik pasif, seperti pengenalan wajah, untuk transaksi (misalnya, pembayaran) yang melibatkan kunci terikat autentikasi.
  • Wajibkan metode autentikasi utama setiap 72 jam.
  • Gunakan saluran yang sepenuhnya aman untuk semua data dan penanganan biometrik.
  • Jangan pernah mengirimkan data biometrik (termasuk pengukuran sensor mentah dan fitur turunannya) ke luar perangkat. Jika memungkinkan, simpan data ini di lingkungan terisolasi yang aman, seperti Trusted Execution Environment (TEE) atau Elemen Aman.

Perangkat dengan biometrik harus mendukung BiometricPrompt API , yang menawarkan antarmuka umum dan konsisten bagi pengembang aplikasi untuk memanfaatkan autentikasi berbasis biometrik di aplikasi mereka. Hanya biometrik yang kuat yang dapat berintegrasi dengan BiometricPrompt dan integrasi harus mengikuti pedoman Dokumen Definisi Kompatibilitas (CDD) Android .

Untuk pedoman biometrik lebih lanjut, lihat Pedoman penerapan HAL Biometrik .

SELinux

SELinux memberikan definisi dan penerapan sebagian besar model keamanan Android. Penggunaan SELinux dengan benar sangat penting untuk keamanan perangkat Android dan dapat membantu mengurangi dampak kerentanan keamanan. Semua perangkat Android harus menerapkan kebijakan SELinux yang kuat karena alasan ini.

  • Terapkan kebijakan hak istimewa paling rendah.
  • Hindari memberikan izin CAP_DAC_OVERRIDE , CAP_SYS_ADMIN , dan CAP_NET_ADMIN .
  • Jangan mencatat data sistem ke kartu SD.
  • Gunakan tipe yang disediakan untuk akses driver, seperti gpu_device , audio_device , dll.
  • Gunakan nama yang bermakna untuk proses, file, dan tipe SELinux.
    • Pastikan label default tidak digunakan dan akses tidak diberikan kepada label tersebut.
  • Kebijakan khusus perangkat harus mencakup 5–10% dari keseluruhan kebijakan yang berjalan pada perangkat. Penyesuaian dalam kisaran 20%+ hampir pasti berisi domain dengan hak istimewa berlebih dan kebijakan mati. Kebijakan besar yang tidak perlu akan membuang-buang memori, membuang-buang ruang disk karena memerlukan image booting yang lebih besar, dan berdampak negatif terhadap waktu pencarian kebijakan runtime.

Pemuatan dinamis kebijakan SELinux

Jangan memuat kebijakan SELinux secara dinamis pada perangkat Android. Melakukan hal ini dapat mengakibatkan masalah, seperti:

  • Mencegah penerimaan patch keamanan penting.
  • Mengekspos kemampuan untuk melakukan root pada perangkat melalui pemuatan ulang kebijakan.
  • Mengekspos vektor serangan man-in-the-middle terhadap pembaru kebijakan.
  • Mengakibatkan perangkat mengalami brick karena kesalahan pada pembaruan kebijakan.

Pintu belakang

Aplikasi Android tidak boleh memiliki pintu belakang atau cara apa pun untuk mengakses sistem atau data yang melewati mekanisme keamanan normal. Ini termasuk diagnostik, debugging, pengembangan, atau perbaikan garansi akses khusus yang dilindungi oleh rahasia yang diketahui pengembang. Untuk mencegah pintu belakang:

  • Pindai semua aplikasi pihak ketiga menggunakan alat pemindaian kerentanan aplikasi yang diakui industri.
  • Lakukan peninjauan kode terhadap semua kode dengan akses sensitif, termasuk perpustakaan pihak ketiga.
  • Manfaatkan Google Play Protect dengan mengunggah aplikasi ke Google Play untuk dipindai. Anda dapat mengunggah aplikasi untuk dipindai tanpa dipublikasikan ke Google Play.
  • Jangan melakukan pramuat alat yang berfokus pada diagnostik atau perbaikan pada versi rilis. Instal alat ini hanya sesuai permintaan untuk menyelesaikan masalah tertentu. Selain itu, alat ini tidak boleh mengoperasikan atau mengunggah data khusus akun apa pun.

Alat pengembangan

Alat pengembangan, seperti alat debugging, pengujian, dan diagnostik, sering kali dapat menciptakan celah keamanan yang tidak diinginkan pada perangkat Anda dengan mengungkapkan cara pengoperasiannya dan data yang dikumpulkannya. Untuk memastikan alat pengembangan tidak masuk ke dalam build produksi:

  • Kembangkan daftar hitam hash alat debug dan pengujian internal serta build pemindaian untuk APK ini sebelum menggunakan image sistem.
  • Pindai semua aplikasi pihak pertama menggunakan alat pemindaian kerentanan aplikasi yang diakui industri.
  • Sewa perusahaan pengujian keamanan aplikasi pihak ketiga untuk mengevaluasi semua aplikasi diagnostik penting pada perangkat sebelum melakukan pembaruan besar apa pun, terutama jika aplikasi tersebut dikembangkan oleh pihak ketiga.
  • Pastikan hanya pengguna yang dapat mengaktifkan alat tersebut, baik secara lisan atau melalui chat, selama sesi dukungan. Simpan artefak persetujuan dan nonaktifkan alat setelah mengumpulkan informasi diagnostik yang diperlukan.
  • Simpan catatan penggunaan alat ini dalam log yang dapat diakses oleh pengguna di akun operator mereka.
  • Pastikan bahwa setiap informasi identitas pribadi (PII) atau data telemetri perangkat yang dikumpulkan oleh alat ini tunduk pada praktik anonimisasi, penyimpanan, dan penghapusan yang relevan dengan negara tersebut. Hanya data yang relevan untuk panggilan dukungan yang harus dikumpulkan. Data ini harus dihapus setelah setiap panggilan.
  • Pastikan bahwa teknik yang dapat digunakan untuk spyware, seperti pencatatan keystroke, penggunaan mikrofon, atau penggunaan kamera, tidak digunakan tanpa izin pengguna yang jelas. Aplikasi yang menggunakan metode yang berpotensi melanggar privasi ini harus diungkapkan dengan jelas bersama dengan kebijakan privasi yang harus disetujui oleh pengguna. Aplikasi seperti ini tidak boleh diaktifkan tanpa izin eksplisit dari pengguna.

Berikut adalah beberapa saran tambahan untuk dijadikan referensi ketika menerapkan pengungkapan dan persetujuan:

Pengungkapan dalam aplikasi

  • Tampilkan penggunaan normal aplikasi langsung di dalam aplikasi. Tidak mengharuskan pengguna untuk menavigasi ke menu atau pengaturan.
  • Jelaskan jenis data yang dikumpulkan dan jelaskan bagaimana data tersebut akan digunakan.
  • Idealnya, jangan memasukkan informasi ini ke dalam kebijakan privasi atau persyaratan layanan. Jangan sertakan hal ini dengan pengungkapan lain yang tidak terkait dengan pengumpulan data pribadi atau sensitif.
  • Persetujuan harus bersifat afirmatif. Jangan menganggap navigasi keluar dari pengungkapan, termasuk mengetuk atau menekan tombol kembali atau beranda, sebagai persetujuan.
  • Sajikan dialog persetujuan dengan cara yang jelas dan tidak ambigu.
  • Memerlukan tindakan afirmatif dari pengguna, seperti mengetuk untuk menerima atau mengucapkan perintah, untuk menerima.
  • Jangan mengumpulkan data pribadi atau sensitif sebelum mendapatkan persetujuan afirmatif.
  • Jangan gunakan pesan yang dapat ditutup secara otomatis atau pesan yang masa berlakunya akan habis.

Fungsionalitas tertanam di AOSP

Menanamkan fungsionalitas tambahan di AOSP sering kali menimbulkan perilaku dan konsekuensi yang tidak terduga; lanjutkan dengan hati hati.

  • Pastikan pengguna ditanya apakah mereka ingin menggunakan aplikasi default yang berbeda (misalnya, mesin telusur, browser web, peluncur) dan mengungkapkan pengiriman data keluar perangkat.
  • Pastikan APK AOSP ditandatangani dengan sertifikat AOSP.
  • Jalankan uji regresi dan simpan log perubahan untuk menentukan apakah APK AOSP telah menambahkan kode.

Pembaruan keamanan

Perangkat Android harus menerima dukungan keamanan berkelanjutan setidaknya selama dua tahun sejak diluncurkan. Hal ini termasuk menerima pembaruan rutin yang mengatasi kerentanan keamanan yang diketahui.

  • Bekerja samalah dengan partner perangkat keras, seperti vendor SoC Anda, untuk menerapkan perjanjian dukungan yang sesuai untuk semua komponen di perangkat Android Anda.
  • Pastikan pembaruan keamanan dapat diinstal dengan interaksi pengguna minimal untuk meningkatkan kemungkinan pengguna menerima dan menginstal pembaruan di perangkat Android mereka. Sangat disarankan untuk menerapkan Pembaruan Sistem yang Mulus atau fitur keamanan serupa.
  • Pastikan Anda memahami persyaratan kumulatif Level Patch Keamanan Android (SPL) sebagaimana dinyatakan dalam Buletin Keamanan Android . Misalnya, perangkat yang menggunakan tingkat patch keamanan 01-02-2018 harus mencakup semua masalah yang terkait dengan tingkat patch keamanan tersebut, serta perbaikan untuk semua masalah yang dilaporkan di semua buletin keamanan sebelumnya.

Pembaruan kernel dinamis

Jangan memodifikasi komponen sistem penting secara dinamis. Meskipun ada beberapa penelitian yang menunjukkan bahwa pembaruan kernel dinamis membantu melindungi terhadap ancaman darurat, biaya yang diperkirakan saat ini lebih besar daripada manfaatnya. Sebaliknya, buatlah metode pembaruan OTA yang kuat untuk mendistribusikan perlindungan kerentanan dengan cepat.

Manajemen kunci

Pertahankan kebijakan dan praktik manajemen kunci yang baik untuk memastikan keamanan kunci penandatanganan.

  • Jangan membagikan kunci penandatanganan dengan pihak eksternal.
  • Jika kunci penandatanganan disusupi, buat kunci baru dan tandatangani dua kali semua aplikasi selanjutnya.
  • Simpan semua kunci dalam perangkat keras atau layanan modul keamanan tinggi yang memerlukan banyak faktor untuk diakses.

Penandatanganan gambar sistem

Tanda tangan dari citra sistem sangat penting untuk menentukan integritas perangkat.

  • Jangan menandatangani perangkat dengan kunci yang diketahui publik.
  • Kelola kunci penandatanganan perangkat dengan cara yang konsisten dengan praktik standar industri untuk menangani kunci sensitif, termasuk modul keamanan perangkat keras (HSM) yang menyediakan akses terbatas dan dapat diaudit.

Bootloader yang tidak dapat dibuka kuncinya

Banyak perangkat Android mendukung pembukaan kunci, memungkinkan pemilik perangkat untuk mengubah partisi sistem atau menginstal sistem operasi khusus. Kasus penggunaan umum mencakup pemasangan citra sistem pihak ketiga dan melakukan pengembangan tingkat sistem pada perangkat. Misalnya, untuk membuka kunci citra sistem pada Google Nexus atau Pixel, pengguna dapat menjalankan fastboot oem unlock , yang menampilkan pesan ini:

Sebagai praktik terbaik, perangkat Android yang tidak dapat dibuka kuncinya harus menghapus semua data pengguna dengan aman sebelum dibuka kuncinya. Kegagalan menghapus semua data dengan benar saat membuka kunci dapat memungkinkan penyerang terdekat secara fisik mendapatkan akses tidak sah ke data rahasia pengguna Android. Untuk mencegah pengungkapan data pengguna, perangkat yang mendukung unlocking harus menerapkannya dengan benar.

  • Setelah pengguna mengonfirmasi perintah membuka kunci, perangkat harus segera memulai penghapusan data. Bendera unlocked tidak boleh disetel sampai penghapusan aman selesai.
  • Jika penghapusan aman tidak dapat diselesaikan, perangkat harus tetap dalam keadaan terkunci.
  • Jika didukung oleh perangkat blok yang mendasarinya, ioctl(BLKSECDISCARD) atau yang setara harus digunakan. Untuk perangkat MultiMediaCard (eMMC) tertanam, ini berarti menggunakan perintah Secure Erase atau Secure Trim. Untuk eMMC 4.5 dan yang lebih baru, ini berarti menggunakan Erase atau Trim normal yang diikuti dengan operasi Sanitize.
  • Jika BLKSECDISCARD tidak didukung oleh perangkat blok yang mendasarinya, ioctl(BLKDISCARD) harus digunakan. Pada perangkat eMMC, ini adalah operasi Trim normal.
  • Jika BLKDISCARD tidak didukung, menimpa perangkat blok dengan semua angka nol dapat diterima.
  • Pengguna harus memiliki opsi untuk meminta data pengguna dihapus sebelum mem-flash partisi. Misalnya, perangkat Nexus menggunakan perintah fastboot oem lock untuk menghapus data pengguna.
  • Perangkat dapat merekam, melalui eFuse atau mekanisme serupa, apakah perangkat dibuka kuncinya dan/atau dikunci kembali. Namun, kami sangat menyarankan agar mengunci kembali bootloader dan kemudian melakukan reset pabrik akan memulihkan fungsionalitas perangkat secara penuh.

Persyaratan ini memastikan bahwa semua data dimusnahkan setelah operasi pembukaan kunci selesai. Kegagalan untuk menerapkan perlindungan ini dianggap sebagai kerentanan keamanan tingkat sedang .

Perangkat yang tidak terkunci selanjutnya dapat dikunci kembali menggunakan perintah fastboot oem lock . Mengunci bootloader memberikan perlindungan yang sama terhadap data pengguna dengan OS kustom baru seperti yang tersedia pada OS pabrikan perangkat asli (misalnya, data pengguna akan dihapus jika perangkat dibuka kuncinya lagi).

Pengujian perangkat

Perangkat harus ditinjau oleh pentester yang kompeten sebelum dikirim. Pentesting harus menetapkan bahwa perangkat mengikuti panduan keamanan yang diberikan di sini serta panduan keamanan OEM internal.

Pengujian Keamanan

Gunakan alat Pengujian Keamanan yang disediakan oleh AOSP. Secara khusus

  • Gunakan alat keamanan memori selama pengembangan: gunakan MTE jika didukung (ARMv9 dan lebih tinggi), dan HWASan jika tidak didukung. Jalankan pengujian sebanyak mungkin dengan alat ini diaktifkan.
  • Gunakan GWP-ASan dan KFENCE dalam produksi, untuk deteksi probabilistik masalah keamanan memori.