Menerapkan keamanan

Tim Keamanan Android secara rutin menerima permintaan informasi tentang cara mencegah potensi masalah keamanan di perangkat Android. Kami juga sesekali melakukan pemeriksaan mendadak pada perangkat dan memberi tahu produsen perangkat serta partner yang terpengaruh tentang potensi masalah.

Halaman ini memberikan praktik terbaik keamanan berdasarkan pengalaman kami, yang memperluas dokumentasi Mendesain untuk Keamanan yang telah kami berikan kepada developer dan menyertakan detail unik untuk mem-build atau menginstal software tingkat sistem di perangkat.

Untuk memfasilitasi penerapan praktik terbaik ini, jika memungkinkan, Tim Keamanan Android akan menggabungkan pengujian ke dalam Android Compatibility Test Suite (CTS) dan Android Lint. Sebaiknya penerapkan perangkat berkontribusi pada pengujian yang dapat membantu pengguna Android lainnya (lihat pengujian terkait keamanan di root/cts/tests/tests/security/src/android/security/cts).

Proses pengembangan

Gunakan praktik terbaik berikut dalam proses dan lingkungan pengembangan Anda.

Meninjau kode sumber

Peninjauan kode sumber dapat mendeteksi berbagai masalah keamanan, termasuk masalah yang diidentifikasi dalam dokumen ini. Android sangat mendorong peninjauan kode sumber manual dan otomatis. Praktik terbaik:

• Jalankan Android Lint di semua kode aplikasi menggunakan Android SDK dan perbaiki masalah yang teridentifikasi.
• Kode native harus dianalisis menggunakan alat otomatis yang dapat mendeteksi masalah pengelolaan memori seperti buffer overflow dan error off-by-one.
• Sistem build Android memiliki dukungan untuk banyak sanitizer LLVM, seperti AddressSanitizer dan UndefinedBehaviorSanitizer yang dapat digunakan untuk tujuan ini.

Menggunakan pengujian otomatis

Pengujian otomatis dapat mendeteksi berbagai masalah keamanan, termasuk beberapa masalah yang dibahas di bawah. Praktik terbaik:

• CTS diperbarui secara rutin dengan pengujian keamanan; jalankan CTS versi terbaru untuk memverifikasi kompatibilitas.
• Jalankan CTS secara rutin selama proses pengembangan untuk mendeteksi masalah lebih awal dan mengurangi waktu untuk koreksi. Android menggunakan CTS sebagai bagian dari continuous integration dalam proses build otomatis kami, yang melakukan build beberapa kali per hari.
• Produsen perangkat harus mengotomatiskan pengujian keamanan antarmuka, termasuk pengujian dengan input yang salah format (pengujian fuzz).

Gambar sistem tanda tangan

Tanda tangan image sistem sangat penting untuk menentukan integritas perangkat. Praktik terbaik:

• Perangkat tidak boleh ditandatangani dengan kunci yang diketahui secara publik.
• Kunci yang digunakan untuk menandatangani perangkat harus dikelola dengan cara yang konsisten dengan praktik standar industri untuk menangani kunci sensitif, termasuk hardware security module (HSM) yang memberikan akses terbatas dan dapat diaudit.

Menandatangani aplikasi (APK)

Tanda tangan aplikasi berperan penting dalam keamanan perangkat dan digunakan untuk pemeriksaan izin serta update software. Saat memilih kunci yang akan digunakan untuk menandatangani aplikasi, penting untuk mempertimbangkan apakah aplikasi hanya akan tersedia di satu perangkat atau umum di beberapa perangkat. Praktik terbaik:

• Aplikasi tidak boleh ditandatangani dengan kunci yang diketahui secara publik.
• Kunci yang digunakan untuk menandatangani aplikasi harus dikelola dengan cara yang konsisten dengan praktik standar industri untuk menangani kunci sensitif, termasuk HSM yang memberikan akses terbatas dan dapat diaudit.
• Aplikasi tidak boleh ditandatangani dengan kunci platform.
• Aplikasi dengan nama paket yang sama tidak boleh ditandatangani dengan kunci yang berbeda. Hal ini sering terjadi saat membuat aplikasi untuk perangkat yang berbeda, terutama saat menggunakan kunci platform. Jika aplikasi tidak bergantung pada perangkat, gunakan kunci yang sama di seluruh perangkat. Jika aplikasi khusus perangkat, buat nama paket unik per perangkat dan kunci.

Memublikasikan aplikasi

Google Play memberi produsen perangkat kemampuan untuk mengupdate aplikasi tanpa melakukan update sistem lengkap. Hal ini dapat mempercepat respons terhadap masalah keamanan dan pengiriman fitur baru, serta memberikan cara untuk memastikan aplikasi Anda memiliki nama paket yang unik. Praktik terbaik:

• Upload aplikasi Anda ke Google Play untuk mengizinkan update otomatis tanpa memerlukan update over the air (OTA) penuh. Aplikasi yang diupload tetapi tidak dipublikasikan tidak dapat didownload langsung oleh pengguna, tetapi aplikasi tetap diupdate. Pengguna yang sebelumnya telah menginstal aplikasi dapat menginstal ulang dan/atau menginstal di perangkat lain.
• Buat nama paket aplikasi yang secara jelas dikaitkan dengan perusahaan Anda, seperti dengan menggunakan merek dagang perusahaan.
• Aplikasi yang dipublikasikan oleh produsen perangkat harus diupload di Google Play Store untuk menghindari peniruan identitas nama paket oleh pengguna pihak ketiga. Jika produsen perangkat menginstal aplikasi di perangkat tanpa memublikasikan aplikasi di Play Store, developer lain dapat mengupload aplikasi yang sama, menggunakan nama paket yang sama, dan mengubah metadata untuk aplikasi. Saat aplikasi ditampilkan kepada pengguna, metadata yang tidak terkait ini dapat menimbulkan kebingungan.

Merespons insiden

Pihak eksternal harus memiliki kemampuan untuk menghubungi produsen perangkat terkait masalah keamanan khusus perangkat. Sebaiknya buat alamat email yang dapat diakses secara publik untuk mengelola insiden keamanan. Praktik terbaik:

• Buat alamat security@perusahaan-anda.com atau alamat serupa dan publikasikan.
• Jika mengetahui masalah keamanan yang memengaruhi Android OS atau perangkat Android dari beberapa produsen perangkat, Anda harus menghubungi Tim Android Security dengan mengajukan Laporan bug keamanan.

Menerapkan produk

Gunakan praktik terbaik berikut saat menerapkan produk.

Mengisolasi proses root

Proses root adalah target serangan eskalasi akses yang paling sering terjadi, sehingga mengurangi jumlah proses root akan mengurangi risiko eskalasi akses. CTS menyertakan pengujian informasi yang mencantumkan proses root. Praktik terbaik:

• Perangkat harus menjalankan kode minimum yang diperlukan sebagai root. Jika memungkinkan, gunakan proses Android reguler, bukan proses root. ICS Galaxy Nexus hanya memiliki enam proses root: vold, inetd, zygote, tf_daemon, ueventd, dan init. Jika proses harus berjalan sebagai root di perangkat, dokumentasikan proses tersebut dalam permintaan fitur AOSP agar dapat ditinjau secara publik.
• Jika memungkinkan, kode root harus diisolasi dari data yang tidak tepercaya dan diakses melalui IPC. Misalnya, kurangi fungsi root ke Layanan kecil yang dapat diakses melalui Binder dan tampilkan Layanan dengan izin tanda tangan ke aplikasi dengan hak istimewa rendah atau tidak ada untuk menangani traffic jaringan.
• Proses root tidak boleh memproses soket jaringan.
• Proses root tidak boleh menyediakan runtime tujuan umum untuk aplikasi (misalnya, VM Java).

Mengisolasi aplikasi sistem

Secara umum, aplikasi bawaan tidak boleh berjalan dengan UID sistem bersama. Namun, jika perlu, agar aplikasi dapat menggunakan UID bersama sistem atau layanan dengan hak istimewa lainnya, aplikasi tidak boleh mengekspor layanan, penerima siaran, atau penyedia konten apa pun yang dapat diakses oleh aplikasi pihak ketiga yang diinstal oleh pengguna. Praktik terbaik:

• Perangkat harus menjalankan kode minimum yang diperlukan sebagai sistem. Jika memungkinkan, gunakan proses Android dengan UID-nya sendiri, bukan menggunakan kembali UID sistem.
• Jika memungkinkan, kode sistem harus diisolasi dari data yang tidak tepercaya dan mengekspos IPC hanya ke proses tepercaya lainnya.
• Proses sistem tidak boleh memproses soket jaringan.

Mengisolasi proses

Sandbox Aplikasi Android memberi aplikasi ekspektasi isolasi dari proses lain di sistem, termasuk proses root dan debugger. Kecuali jika proses debug diaktifkan secara khusus oleh aplikasi dan pengguna, tidak ada aplikasi yang boleh melanggar ekspektasi tersebut. Praktik terbaik:

• Proses root tidak boleh mengakses data dalam setiap folder data aplikasi, kecuali jika menggunakan metode proses debug Android yang didokumentasikan.
• Proses root tidak boleh mengakses memori aplikasi, kecuali jika menggunakan metode proses debug Android yang didokumentasikan.
• Perangkat tidak boleh menyertakan aplikasi apa pun yang mengakses data atau memori aplikasi atau proses lainnya.

Mengamankan file SUID

Program setuid baru tidak boleh diakses oleh program yang tidak tepercaya. Program setuid sering kali menjadi lokasi kerentanan yang dapat digunakan untuk mendapatkan akses root, jadi usahakan untuk meminimalkan ketersediaan program setuid ke aplikasi yang tidak tepercaya. Praktik terbaik:

• Proses SUID tidak boleh menyediakan shell atau backdoor yang dapat digunakan untuk mengakali model keamanan Android.
• Program SUID tidak boleh ditulis oleh pengguna mana pun.
• Program SUID tidak boleh dapat dibaca atau dieksekusi oleh semua orang. Buat grup, batasi akses ke biner SUID untuk anggota grup tersebut, dan tempatkan aplikasi apa pun yang seharusnya dapat menjalankan program SUID ke dalam grup tersebut.
• Program SUID adalah sumber umum dari rooting perangkat oleh pengguna. Untuk mengurangi risiko ini, program SUID tidak boleh dieksekusi oleh pengguna shell.

Pengverifikasi CTS menyertakan pengujian informasi yang mencantumkan file SUID; beberapa file setuid tidak diizinkan per pengujian CTS.

Soket pemrosesan permintaan aman

Pengujian CTS gagal saat perangkat memproses di port mana pun, di antarmuka mana pun. Jika terjadi kegagalan, Android akan memverifikasi bahwa praktik terbaik berikut sedang digunakan:

• Tidak boleh ada port pemrosesan di perangkat.
• Port yang sedang dalam proses harus dapat dinonaktifkan tanpa OTA. Hal ini dapat berupa perubahan konfigurasi server atau perangkat pengguna.
• Proses root tidak boleh memproses port apa pun.
• Proses yang dimiliki oleh UID sistem tidak boleh memproses port apa pun.
• Untuk IPC lokal yang menggunakan soket, aplikasi harus menggunakan Soket Domain UNIX dengan akses yang dibatasi untuk grup. Buat deskripsi file untuk IPC dan buat +RW untuk grup UNIX tertentu. Setiap aplikasi klien harus berada dalam grup UNIX tersebut.
• Beberapa perangkat dengan beberapa prosesor (misalnya, radio/modem yang terpisah dari prosesor aplikasi) menggunakan soket jaringan untuk berkomunikasi antar prosesor. Dalam kasus tersebut, soket jaringan yang digunakan untuk komunikasi antar-prosesor harus menggunakan antarmuka jaringan terisolasi untuk mencegah akses oleh aplikasi yang tidak sah di perangkat (yaitu, gunakan iptables untuk mencegah akses oleh aplikasi lain di perangkat).
• Daemon yang menangani port pemrosesan harus tahan terhadap data yang salah format. Google dapat melakukan pengujian fuzz terhadap port menggunakan klien yang tidak sah, dan, jika memungkinkan, klien yang sah. Setiap error akan diajukan sebagai bug dengan tingkat keparahan yang sesuai.

Mencatat data ke dalam log

Mencatat data meningkatkan risiko eksposur data tersebut dan mengurangi performa sistem. Beberapa insiden keamanan publik telah terjadi sebagai akibat dari pencatatan data pengguna sensitif oleh aplikasi yang diinstal secara default di perangkat Android. Praktik terbaik:

• Aplikasi atau layanan sistem tidak boleh mencatat data yang diberikan dari aplikasi pihak ketiga yang mungkin menyertakan informasi sensitif.
• Aplikasi tidak boleh mencatat informasi identitas pribadi (PII) apa pun sebagai bagian dari operasi normal.

CTS menyertakan pengujian yang memeriksa keberadaan informasi sensitif yang berpotensi dalam log sistem.

Membatasi akses direktori

Direktori yang dapat ditulis publik dapat menyebabkan kelemahan keamanan dan memungkinkan aplikasi mengganti nama file tepercaya, mengganti file, atau melakukan serangan berbasis symlink (penyerang dapat menggunakan symlink ke file untuk mengelabui program tepercaya agar melakukan tindakan yang tidak seharusnya). Direktori yang dapat ditulis juga dapat mencegah penguninstalan aplikasi untuk membersihkan semua file yang terkait dengan aplikasi dengan benar.

Sebagai praktik terbaik, direktori yang dibuat oleh sistem atau pengguna root tidak boleh dapat ditulis oleh semua orang. Pengujian CTS membantu menerapkan praktik terbaik ini dengan menguji direktori yang diketahui.

File konfigurasi aman

Banyak driver dan layanan mengandalkan file konfigurasi dan data yang disimpan di direktori seperti /system/etc dan /data. Jika file ini diproses oleh proses dengan hak istimewa dan dapat ditulis oleh semua orang, aplikasi dapat mengeksploitasi kerentanan dalam proses tersebut dengan membuat konten berbahaya dalam file yang dapat ditulis oleh semua orang. Praktik terbaik:

• File konfigurasi yang digunakan oleh proses dengan hak istimewa tidak boleh dibaca oleh semua orang.
• File konfigurasi yang digunakan oleh proses dengan hak istimewa tidak boleh dapat ditulis oleh semua orang.

Menyimpan library kode native

Setiap kode yang digunakan oleh proses produsen perangkat dengan hak istimewa harus berada di /vendor atau /system; sistem file ini dipasang hanya baca saat booting. Sebagai praktik terbaik, library yang digunakan oleh sistem atau aplikasi lain dengan hak istimewa tinggi yang diinstal di perangkat juga harus berada dalam sistem file ini. Hal ini dapat mencegah kerentanan keamanan yang dapat memungkinkan penyerang mengontrol kode yang dieksekusi oleh proses dengan hak istimewa.

Membatasi akses driver perangkat

Hanya kode tepercaya yang boleh memiliki akses langsung ke driver. Jika memungkinkan, arsitektur yang lebih disukai adalah menyediakan daemon tujuan tunggal yang melakukan proxy panggilan ke driver dan membatasi akses driver ke daemon tersebut. Sebagai praktik terbaik, node perangkat driver tidak boleh dapat dibaca atau ditulis oleh semua orang. Pengujian CTS membantu menerapkan praktik terbaik ini dengan memeriksa instance driver yang terekspos yang diketahui.

Menonaktifkan ADB

Android Debug Bridge (adb) adalah alat pengembangan dan proses debug yang berharga, tetapi dirancang untuk digunakan di lingkungan yang terkontrol dan aman serta tidak boleh diaktifkan untuk penggunaan umum. Praktik terbaik:

• ADB harus dinonaktifkan secara default.
• ADB harus mewajibkan pengguna untuk mengaktifkannya sebelum menerima koneksi.

Membuka kunci bootloader

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

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 tidak sah ke data pengguna Android yang bersifat rahasia. Untuk mencegah pengungkapan data pengguna, perangkat yang mendukung fitur buka kunci harus menerapkannya dengan benar (kami telah melihat banyak kasus saat produsen perangkat menerapkan fitur buka kunci dengan tidak benar). Proses pembukaan kunci yang diterapkan dengan benar memiliki properti berikut:

• Saat perintah membuka kunci dikonfirmasi oleh pengguna, perangkat harus memulai pembersihan total data secara langsung. Flag unlocked tidak boleh ditetapkan hingga 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 eMMC, 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 akhir harus memiliki opsi untuk mewajibkan data pengguna dihapus sebelum mem-flash partisi. Misalnya, di perangkat Nexus, hal ini dilakukan melalui perintah fastboot oem lock.
• Perangkat dapat merekam, melalui efuse atau mekanisme serupa, apakah perangkat telah dibuka kuncinya dan/atau dikunci kembali.

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

Perangkat yang dibuka kuncinya 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).