Menerapkan Keamanan

Tim Keamanan Android secara teratur menerima permintaan informasi tentang mencegah potensi masalah keamanan pada perangkat Android. Kami juga sesekali memeriksa perangkat dan memberi tahu produsen perangkat dan mitra yang terpengaruh tentang potensi masalah.

Halaman ini memberikan praktik terbaik keamanan berdasarkan pengalaman kami, memperluas dokumentasi Merancang untuk Keamanan yang telah kami sediakan untuk pengembang dan menyertakan detail unik untuk membangun atau menginstal perangkat lunak tingkat sistem pada perangkat.

Untuk memfasilitasi penerapan praktik terbaik ini, jika memungkinkan, Tim Keamanan Android menggabungkan pengujian ke dalam Android Compatibility Test Suite (CTS) dan Android Lint . Kami mendorong pelaksana perangkat untuk memberikan kontribusi 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

Tinjauan kode sumber dapat mendeteksi berbagai masalah keamanan, termasuk yang diidentifikasi dalam dokumen ini. Android sangat menganjurkan tinjauan kode sumber manual dan otomatis. Praktik terbaik:

• Jalankan Android Lint pada semua kode aplikasi menggunakan Android SDK dan perbaiki masalah yang teridentifikasi.
• Kode asli harus dianalisis menggunakan alat otomatis yang dapat mendeteksi masalah manajemen memori seperti buffer overflows dan kesalahan satu per satu.
• Sistem build Android memiliki dukungan untuk banyak pembersih 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 ini. Praktik terbaik:

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

Gambar sistem penandatanganan

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

• Perangkat tidak boleh ditandatangani dengan kunci yang diketahui publik.
• Kunci yang digunakan untuk menandatangani perangkat harus dikelola dengan cara yang konsisten dengan praktik standar industri untuk menangani kunci sensitif, termasuk modul keamanan perangkat keras (HSM) yang menyediakan akses terbatas yang dapat diaudit.

Menandatangani aplikasi (APK)

Tanda tangan aplikasi memainkan peran penting dalam keamanan perangkat dan digunakan untuk pemeriksaan izin serta pembaruan perangkat lunak. 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 publik.
• Kunci yang digunakan untuk menandatangani aplikasi harus dikelola dengan cara yang konsisten dengan praktik standar industri untuk menangani kunci sensitif, termasuk HSM yang menyediakan akses terbatas yang dapat diaudit.
• Aplikasi tidak boleh ditandatangani dengan kunci platform.
• Aplikasi dengan nama paket yang sama tidak boleh ditandatangani dengan kunci yang berbeda. 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.

Menerbitkan aplikasi

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

• Unggah aplikasi Anda ke Google Play untuk memungkinkan pembaruan otomatis tanpa memerlukan pembaruan over-the-air (OTA) penuh. Aplikasi yang diunggah tetapi tidak dipublikasikan tidak langsung dapat diunduh oleh pengguna tetapi aplikasi tetap diperbarui. Pengguna yang sebelumnya telah menginstal aplikasi dapat menginstal ulang dan/atau menginstal di perangkat lain.
• Buat nama paket aplikasi yang jelas terkait dengan perusahaan Anda, misalnya dengan menggunakan merek dagang perusahaan.
• Aplikasi yang diterbitkan oleh produsen perangkat harus diunggah di Google Play Store untuk menghindari peniruan nama paket oleh pengguna pihak ketiga. Jika produsen perangkat memasang aplikasi di perangkat tanpa memublikasikan aplikasi di Play Store, pengembang lain dapat mengunggah aplikasi yang sama, menggunakan nama paket yang sama, dan mengubah metadata untuk aplikasi tersebut. Saat aplikasi disajikan kepada pengguna, metadata yang tidak terkait ini dapat menimbulkan kebingungan.

Menanggapi insiden

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

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

Implementasi produk

Gunakan praktik terbaik berikut saat menerapkan produk.

Mengisolasi proses root

Proses root adalah target serangan eskalasi hak istimewa yang paling sering, sehingga mengurangi jumlah proses root mengurangi risiko eskalasi hak istimewa. CTS menyertakan tes informasi yang mencantumkan proses root. Praktik terbaik:

• Perangkat harus menjalankan kode minimum yang diperlukan sebagai root. Jika memungkinkan, gunakan proses Android biasa daripada proses root. ICS Galaxy Nexus hanya memiliki enam proses root: vold, inetd, zygote, tf_daemon, ueventd, dan init. Jika suatu proses harus dijalankan sebagai root pada perangkat, dokumentasikan proses tersebut dalam permintaan fitur AOSP sehingga dapat ditinjau secara publik.
• Jika memungkinkan, kode root harus diisolasi dari data yang tidak dipercaya dan diakses melalui IPC. Misalnya, kurangi fungsionalitas root ke Layanan kecil yang dapat diakses melalui Binder dan paparkan Layanan dengan izin tanda tangan ke aplikasi dengan hak istimewa rendah atau tanpa hak istimewa untuk menangani lalu lintas jaringan.
• Proses root tidak boleh mendengarkan pada soket jaringan.
• Proses root tidak boleh menyediakan runtime tujuan umum untuk aplikasi (misalnya, Java VM).

Mengisolasi aplikasi sistem

Secara umum, aplikasi pra-instal tidak boleh berjalan dengan UID sistem bersama. Namun, jika aplikasi perlu menggunakan UID bersama dari sistem atau layanan 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 daripada menggunakan kembali UID sistem.
• Jika memungkinkan, kode sistem harus diisolasi dari data yang tidak tepercaya dan hanya memaparkan IPC ke proses tepercaya lainnya.
• Proses sistem tidak boleh mendengarkan pada soket jaringan.

Proses isolasi

Android Application Sandbox menyediakan aplikasi dengan harapan isolasi dari proses lain pada sistem, termasuk proses root dan debugger. Kecuali debugging secara khusus diaktifkan oleh aplikasi dan pengguna, tidak ada aplikasi yang boleh melanggar harapan itu. Praktik terbaik:

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

Mengamankan file SUID

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

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

Pemverifikasi CTS menyertakan daftar uji informasi file SUID; beberapa file setuid tidak diizinkan per tes CTS.

Mengamankan soket pendengaran

Tes CTS gagal saat perangkat mendengarkan pada port apa pun, pada antarmuka apa pun. Jika terjadi kegagalan, Android memverifikasi bahwa praktik terbaik berikut sedang digunakan:

• Seharusnya tidak ada port mendengarkan pada perangkat.
• Port mendengarkan harus dapat dinonaktifkan tanpa OTA. Ini dapat berupa perubahan konfigurasi server atau perangkat pengguna.
• Proses root tidak boleh mendengarkan di port mana pun.
• Proses yang dimiliki oleh sistem UID tidak boleh mendengarkan di port mana pun.
• Untuk IPC lokal yang menggunakan soket, aplikasi harus menggunakan Soket Domain UNIX dengan akses terbatas pada grup. Buat deskriptor 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 terpisah dari prosesor aplikasi) menggunakan soket jaringan untuk berkomunikasi antar prosesor. Dalam kasus seperti itu, soket jaringan yang digunakan untuk komunikasi antar-prosesor harus menggunakan antarmuka jaringan yang terisolasi untuk mencegah akses oleh aplikasi yang tidak sah pada perangkat (yaitu, gunakan iptables untuk mencegah akses oleh aplikasi lain pada perangkat).
• Daemon yang menangani port mendengarkan harus kuat terhadap data yang cacat. Google dapat melakukan pengujian kabur terhadap port menggunakan klien yang tidak sah, dan, jika mungkin, klien resmi. Setiap crash akan diajukan sebagai bug dengan tingkat keparahan yang sesuai.

Mencatat data

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

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

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

Membatasi akses direktori

Direktori yang dapat ditulisi dunia dapat menimbulkan kelemahan keamanan dan memungkinkan aplikasi untuk 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 seharusnya tidak dilakukan). Direktori yang dapat ditulis juga dapat mencegah penghapusan instalasi aplikasi dari 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 dunia. Tes CTS membantu menegakkan praktik terbaik ini dengan menguji direktori yang dikenal.

Mengamankan file konfigurasi

Banyak driver dan layanan bergantung pada konfigurasi dan file data yang disimpan dalam direktori seperti /system/etc dan /data . Jika file-file ini diproses oleh proses yang memiliki hak istimewa dan dapat ditulis oleh dunia, aplikasi mungkin saja mengeksploitasi kerentanan dalam proses tersebut dengan membuat konten berbahaya dalam file yang dapat ditulisi dunia. Praktik terbaik:

• File konfigurasi yang digunakan oleh proses istimewa seharusnya tidak dapat dibaca dunia.
• File konfigurasi yang digunakan oleh proses istimewa tidak boleh dapat ditulis oleh dunia.

Menyimpan pustaka kode asli

Kode apa pun yang digunakan oleh proses produsen perangkat yang memiliki hak istimewa harus berada di /vendor atau /system ; sistem file ini dipasang hanya-baca saat boot. Sebagai praktik terbaik, pustaka yang digunakan oleh sistem atau aplikasi berprivilese tinggi lainnya yang diinstal pada perangkat juga harus ada di sistem file ini. Ini dapat mencegah kerentanan keamanan yang memungkinkan penyerang mengontrol kode yang dijalankan oleh proses istimewa.

Membatasi akses driver perangkat

Hanya kode tepercaya yang memiliki akses langsung ke driver. Jika memungkinkan, arsitektur yang disukai adalah menyediakan daemon tujuan tunggal yang memanggil proxy ke driver dan membatasi akses driver ke daemon itu. Sebagai praktik terbaik, node perangkat driver tidak boleh dapat dibaca atau ditulis oleh dunia. Tes CTS membantu menegakkan praktik terbaik ini dengan memeriksa contoh driver yang diketahui.

Menonaktifkan ADB

Android debug bridge (adb) adalah alat pengembangan dan debugging yang berharga, tetapi dirancang untuk digunakan di lingkungan yang terkendali dan aman dan tidak boleh diaktifkan untuk penggunaan umum. Praktik terbaik:

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

Membuka kunci bootloader

Banyak perangkat Android mendukung pembukaan kunci, memungkinkan pemilik perangkat untuk mengubah partisi sistem dan/atau menginstal sistem operasi khusus. Kasus penggunaan umum termasuk menginstal ROM pihak ketiga dan melakukan pengembangan tingkat sistem pada 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 tidak 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 terdekat secara fisik untuk mendapatkan akses tidak sah ke data rahasia pengguna Android. Untuk mencegah pengungkapan data pengguna, perangkat yang mendukung pembukaan kunci harus menerapkannya dengan benar (kami telah melihat banyak contoh di mana produsen perangkat menerapkan pembukaan kunci dengan tidak benar). Proses membuka kunci yang diterapkan dengan benar memiliki properti berikut:

• Saat perintah membuka kunci dikonfirmasi oleh pengguna, perangkat harus segera memulai penghapusan data. Bendera yang tidak unlocked tidak boleh disetel 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, ini berarti menggunakan perintah Secure Erase atau Secure Trim. Untuk eMMC 4.5 dan yang lebih baru, ini berarti menggunakan Hapus atau Pangkas normal diikuti dengan operasi Sanitasi.
• Jika BLKSECDISCARD tidak didukung oleh perangkat blok yang mendasarinya, 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 meminta agar data pengguna dihapus sebelum mem-flash partisi. Misalnya, pada perangkat Nexus, ini dilakukan melalui perintah fastboot oem lock .
• Perangkat dapat merekam, melalui efuse atau mekanisme serupa, apakah perangkat dibuka kuncinya dan/atau dikunci kembali.

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

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