Praktik terbaik keamanan sistem

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

Autentikasi biometrik

Dapatkan, simpan, dan proses data biometrik untuk autentikasi pengguna dengan cermat. Anda harus:

  • Wajibkan metode autentikasi utama sebelum menggunakan bentuk autentikasi lainnya (termasuk biometrik).
  • Wajibkan konfirmasi eksplisit untuk menunjukkan intent 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 pipeline yang sepenuhnya aman untuk semua data dan penanganan biometrik.
  • Jangan pernah mengirim data biometrik (termasuk pengukuran sensor mentah dan fitur turunan) ke luar perangkat. Jika memungkinkan, simpan data ini di lingkungan terisolasi yang aman, seperti Trusted Execution Environment (TEE) atau Elemen Pengaman.

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

Untuk panduan biometrik lainnya, lihat Panduan penerapan HAL biometrik.

SELinux

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

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

Pemuatan kebijakan SELinux secara dinamis

Jangan memuat kebijakan SELinux secara dinamis di perangkat Android. Tindakan tersebut dapat menyebabkan masalah, seperti:

  • Mencegah penerimaan patch keamanan penting.
  • Mengekspos kemampuan untuk melakukan root pada perangkat melalui pemuatan ulang kebijakan.
  • Mengekspos vektor untuk serangan man-in-the-middle terhadap pembaru kebijakan.
  • Akibatnya, perangkat menjadi tidak berfungsi karena error pada update kebijakan.

Backdoor (Pintu belakang)

Aplikasi Android tidak boleh memiliki backdoor atau cara untuk mengakses sistem atau data yang mengabaikan mekanisme keamanan normal. Hal ini mencakup akses khusus diagnostik, proses debug, pengembangan, atau perbaikan garansi yang dibatasi oleh secret yang diketahui developer. Untuk mencegah backdoor:

  • Pindai semua aplikasi pihak ketiga menggunakan alat pemindaian kerentanan aplikasi yang diakui industri.
  • Lakukan peninjauan kode untuk semua kode dengan akses sensitif, termasuk library pihak ketiga.
  • Manfaatkan Google Play Protect dengan mengupload aplikasi ke Google Play untuk pemindaian. Anda dapat mengupload aplikasi untuk dipindai tanpa memublikasikannya ke Google Play.
  • Jangan pramuat alat yang berfokus pada diagnostik atau perbaikan pada build rilis. Hanya instal alat ini sesuai kebutuhan untuk menyelesaikan masalah tertentu. Selain itu, alat ini tidak boleh beroperasi berdasarkan atau mengupload data khusus akun.

Alat pengembangan

Alat pengembangan, seperti alat proses debug, pengujian, dan diagnostik, sering kali dapat menciptakan celah keamanan yang tidak disengaja di perangkat Anda dengan mengungkapkan cara alat tersebut beroperasi dan data yang dikumpulkannya. Untuk memastikan alat pengembangan tidak masuk ke build produksi:

  • Buat daftar hitam hash alat pengujian dan debug internal, lalu pindai build 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 di atas perangkat yang penting sebelum update besar, terutama jika aplikasi dikembangkan oleh pihak ketiga.
  • Pastikan hanya pengguna yang dapat mengaktifkan alat ini, baik secara lisan maupun melalui chat, selama sesi dukungan. Simpan artefak izin 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 informasi identitas pribadi (PII) atau data telemetri perangkat yang dikumpulkan oleh alat tersebut tunduk pada praktik anonimisasi, retensi, dan penghapusan yang relevan dengan negara tersebut. Hanya data yang relevan untuk panggilan dukungan yang boleh dikumpulkan. Data ini harus dihapus setelah setiap panggilan.
  • Pastikan teknik yang dapat digunakan untuk spyware, seperti logging ketukan tombol, penggunaan mikrofon, atau penggunaan kamera, tidak digunakan tanpa izin eksplisit pengguna. Aplikasi yang menggunakan metode yang berpotensi melanggar privasi ini harus diungkapkan dengan sangat jelas beserta kebijakan privasi yang harus disetujui pengguna. Aplikasi seperti ini tidak boleh diaktifkan tanpa izin eksplisit dari pengguna.

Berikut beberapa saran tambahan yang dapat Anda rujuk saat menerapkan pengungkapan dan izin:

Pengungkapan dalam aplikasi

  • Tampilkan penggunaan normal aplikasi langsung dalam aplikasi. Jangan mengharuskan pengguna membuka menu atau setelan.
  • Jelaskan jenis data yang dikumpulkan dan jelaskan cara data tersebut digunakan.
  • Sebaiknya jangan sematkan informasi ini dalam kebijakan privasi atau persyaratan layanan. Jangan sertakan dengan pengungkapan lain yang tidak terkait dengan pengumpulan data pribadi atau sensitif.
  • Izin harus bersifat afirmatif. Jangan anggap tindakan menutup pengungkapan, termasuk mengetuk untuk menutup atau menekan tombol kembali atau tombol layar utama, sebagai pemberian izin.
  • Tampilkan dialog izin dengan cara yang jelas dan tidak ambigu.
  • Wajibkan tindakan afirmatif dari pengguna, seperti mengetuk untuk menyetujui atau mengucapkan perintah, untuk menyetujui.
  • Jangan mengumpulkan data pribadi atau sensitif sebelum mendapatkan izin afirmatif.
  • Jangan gunakan pesan yang ditutup atau berakhir secara otomatis.

Fungsi tersemat di AOSP

Menyematkan fungsi tambahan di AOSP sering kali dapat memiliki perilaku dan konsekuensi yang tidak terduga; lanjutkan dengan hati-hati.

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

Update keamanan

Perangkat Android harus menerima dukungan keamanan berkelanjutan selama minimal dua tahun sejak peluncuran. Hal ini mencakup menerima update rutin yang mengatasi kerentanan keamanan umum.

  • Bekerja sama dengan partner hardware, seperti vendor SoC, untuk menerapkan perjanjian dukungan yang sesuai untuk semua komponen di perangkat Android Anda.
  • Pastikan update keamanan dapat diinstal dengan interaksi pengguna minimal untuk meningkatkan kemungkinan pengguna menerima dan menginstal update di perangkat Android mereka. Sebaiknya terapkan Update Sistem yang Lancar atau fitur keamanan yang setara.
  • Pastikan Anda memahami persyaratan kumulatif Level Patch Keamanan Android (SPL) seperti yang dinyatakan dalam Android Security Bulletin. Misalnya, perangkat yang menggunakan level patch keamanan 01-02-2018 harus menyertakan semua masalah yang terkait dengan level patch keamanan tersebut, serta perbaikan untuk semua masalah yang dilaporkan dalam semua buletin keamanan sebelumnya.

Update kernel dinamis

Jangan ubah komponen sistem penting secara dinamis. Meskipun ada beberapa riset yang menunjukkan bahwa update kernel dinamis membantu melindungi dari ancaman darurat, biaya yang dinilai saat ini lebih besar daripada manfaatnya. Sebagai gantinya, buat metode update OTA yang andal untuk mendistribusikan perlindungan kerentanan dengan cepat.

Pengelolaan kunci

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

  • Jangan bagikan kunci penandatanganan kepada pihak eksternal.
  • Jika kunci penandatanganan disusupi, buat kunci baru dan tanda tangani ulang semua aplikasi ke depannya.
  • Simpan semua kunci di hardware atau layanan modul keamanan tinggi yang memerlukan beberapa faktor untuk diakses.

Penandatanganan image sistem

Tanda tangan image sistem sangat penting untuk menentukan integritas perangkat.

  • Jangan tanda tangani perangkat dengan kunci yang diketahui publik.
  • Mengelola kunci penandatanganan perangkat dengan cara yang konsisten dengan praktik standar industri untuk menangani kunci sensitif, termasuk modul keamanan hardware (HSM) yang memberikan akses terbatas dan dapat diaudit.

Bootloader yang dapat dibuka kuncinya

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

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

  • Setelah pengguna mengonfirmasi perintah pembukaan kunci, perangkat harus memulai pembersihan data langsung. Flag unlocked tidak boleh ditetapkan hingga setelah 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) tersemat, hal ini berarti menggunakan perintah Secure Erase atau Secure Trim. Untuk eMMC 4.5 dan yang lebih baru, ini berarti menggunakan Penghapusan atau Pemangkasan normal, diikuti dengan operasi Pembersihan.
  • Jika BLKSECDISCARD tidak didukung oleh perangkat blok pokok, ioctl(BLKDISCARD) harus digunakan sebagai gantinya. Pada perangkat eMMC, ini adalah operasi Trim normal.
  • Jika BLKDISCARD tidak didukung, menimpa perangkat blok dengan semua nol dapat diterima.
  • Pengguna harus memiliki opsi untuk mewajibkan data pengguna dihapus sebelum mem-flash partisi. Misalnya, perangkat Nexus menggunakan perintah fastboot oem lock untuk menghapus total data pengguna.
  • Perangkat dapat merekam, melalui eFuses atau mekanisme serupa, apakah perangkat telah dibuka kuncinya dan/atau dikunci kembali. Namun, sebaiknya mengunci ulang bootloader dengan reset pabrik berikutnya akan memulihkan fungsi perangkat sepenuhnya.

Persyaratan ini memastikan bahwa semua data dihancurkan setelah selesainya operasi buka kunci. Kegagalan dalam menerapkan perlindungan ini dianggap sebagai kerentanan keamanan tingkat sedang.

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

Pentesting perangkat

Perangkat harus ditinjau oleh pentester yang kompeten sebelum dikirim. Pentesting harus memastikan 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 yang lebih baru), dan HWASan jika tidak didukung. Jalankan sebanyak mungkin pengujian dengan mengaktifkan alat ini.
  • Gunakan GWP-ASan dan KFENCE dalam produksi, untuk deteksi probabilistik masalah keamanan memori.