Keamanan Java: Cara menginstal manajer keamanan dan menyesuaikan kebijakan keamanan Anda

Artikel bulan ini melanjutkan diskusi tentang model keamanan Java yang dimulai pada "Di Balik Terpal" Agustus. Dalam artikel itu, saya membuat sketsa gambaran umum tentang mekanisme keamanan yang dibangun ke dalam mesin virtual Java (JVM). Saya juga mencermati satu aspek dari mekanisme keamanan tersebut: fitur keamanan bawaan JVM. Di kolom September saya memeriksa arsitektur pemuat kelas, dan di kolom Oktober, pemverifikasi kelas. Dalam angsuran seri keamanan ini, saya menjelaskan manajer keamanan - bagian keempat dan terakhir dari arsitektur keamanan inti JVM - dan saya akhiri dengan diskusi singkat tentang cara-cara di mana strategi keamanan Java melampaui arsitektur JVM.

Manajer keamanan dan Java API

Seperti yang dijelaskan dalam "Di Balik Terpal" bulan lalu, Anda dapat mencegah kode yang dimuat oleh pemuat kelas yang berbeda agar tidak saling mengganggu di dalam JVM dengan menggunakan pemverifikasi file kelas. Namun untuk melindungi aset di luar mesin virtual Java, Anda harus menggunakan manajer keamanan. Manajer keamanan menentukan batas luar kotak pasir. (Untuk penyegar tentang kotak pasir Java, lihat bagian pertama kolom "Di Balik Terpal" bulan Agustus saya.)

Seorang manajer keamanan adalah setiap kelas yang turun dari kelas java.lang.SecurityManager. Karena dibuat dalam Java, pengelola keamanan dapat disesuaikan. Seorang manajer keamanan memungkinkan Anda untuk membuat kebijakan keamanan khusus untuk aplikasi.

Java API memberlakukan kebijakan keamanan khusus dengan meminta izin dari pengelola keamanan untuk mengambil tindakan apa pun sebelum melakukan sesuatu yang berpotensi tidak aman. Untuk setiap tindakan yang berpotensi tidak aman, terdapat metode di pengelola keamanan yang menentukan apakah tindakan tersebut diizinkan oleh kotak pasir atau tidak. Setiap nama metode diawali dengan "check", jadi, misalnya, checkRead()menentukan apakah sebuah utas diizinkan untuk membaca ke file yang ditentukan checkWrite()atau tidak , dan menentukan apakah utas diizinkan untuk menulis ke file yang ditentukan atau tidak. Implementasi metode ini adalah apa yang mendefinisikan kebijakan keamanan khusus aplikasi.

Sebagian besar aktivitas yang diatur dengan metode "periksa" tercantum di bawah ini. Kelas-kelas Java API diperiksa dengan manajer keamanan sebelum mereka:

  • Terima koneksi soket dari host dan nomor port tertentu
  • Ubah utas (ubah prioritasnya, hentikan, dan seterusnya)
  • Buka koneksi soket ke host dan nomor port tertentu
  • Buat pemuat kelas baru
  • Hapus file tertentu
  • Buat proses baru
  • Menyebabkan aplikasi keluar
  • Muat pustaka dinamis yang berisi metode asli
  • Tunggu koneksi pada nomor port lokal yang ditentukan
  • Memuat kelas dari paket tertentu (digunakan oleh pemuat kelas)
  • Tambahkan kelas baru ke paket tertentu (digunakan oleh pemuat kelas)
  • Akses atau ubah properti sistem
  • Akses properti sistem tertentu
  • Baca dari file tertentu
  • Menulis ke file tertentu

Karena Java API selalu memeriksa dengan manajer keamanan sebelum menjalankan aktivitas apa pun yang tercantum di atas, Java API tidak akan melakukan tindakan apa pun yang dilarang menurut kebijakan keamanan yang ditetapkan oleh manajer keamanan.

Area yang tidak dilindungi oleh manajer keamanan

Dua tindakan yang tidak ada dalam daftar di atas yang berpotensi tidak aman adalah alokasi memori dan pemanggilan utas. Saat ini, applet yang tidak bersahabat dapat merusak browser pengguna karena:

  • Mengalokasikan memori hingga habis
  • Menembakkan utas sampai semuanya melambat menjadi merangkak

Jenis serangan ini disebut serangan penolakan layanan , karena mereka menolak kemampuan pengguna untuk menggunakan komputer mereka sendiri. Manajer keamanan tidak mengizinkan Anda untuk menerapkan batasan apa pun pada memori yang dialokasikan atau pembuatan utas. (Tidak ada checkAllocateMemory()atau checkCreateThread()metode di kelas manajer keamanan.) Berikut ini adalah jenis lain dari applet bermusuhan yang saat ini dimungkinkan:

  • Applet yang mengirim email tidak sah dari komputer pengguna
  • Applet yang mengeluarkan suara mengganggu bahkan setelah Anda meninggalkan halaman Web
  • Applet yang menampilkan gambar atau animasi yang menyinggung

Jadi, pengelola keamanan tidak cukup untuk mencegah setiap kemungkinan tindakan yang dapat menyinggung atau merepotkan pengguna. Selain serangan yang tercantum di sini, pengelola keamanan mencoba memberikan metode pemeriksaan yang memungkinkan Anda mengontrol akses ke tindakan yang berpotensi tidak aman.

Menginstal manajer keamanan

Saat aplikasi Java dijalankan, ia tidak memiliki manajer keamanan. Atas opsinya, aplikasi dapat menginstalnya. Jika tidak menginstal manajer keamanan, tidak ada batasan yang ditempatkan pada aktivitas apa pun yang diminta dari Java API; API Java akan melakukan apa pun yang diminta. (Inilah sebabnya mengapa aplikasi Java, secara default, tidak memiliki pembatasan keamanan seperti yang membatasi kegiatan applet tidak dipercaya.) Jika aplikasi tidak menginstal manajer keamanan, kemudian bahwa manajer keamanan akan bertanggung jawab untuk seluruh seumur hidup aplikasi itu. Itu tidak dapat diganti, diperpanjang, atau diubah. Sejak saat itu, Java API hanya akan memenuhi permintaan yang disetujui oleh manajer keamanan.

Secara umum, metode "check" dari manajer keamanan melontarkan pengecualian keamanan jika aktivitas yang diperiksa dilarang, dan hanya ditampilkan jika aktivitas diizinkan. Oleh karena itu, prosedur yang umumnya diikuti oleh metode Java API ketika akan melakukan aktivitas yang berpotensi tidak aman melibatkan dua langkah. Pertama, kode Java API memeriksa apakah manajer keamanan telah diinstal. Jika tidak, itu tidak pindah ke langkah kedua tetapi melanjutkan dengan tindakan yang berpotensi tidak aman. Jika seorang manajer keamanan memilikitelah diinstal, kode API memberlakukan langkah kedua, yaitu memanggil metode "periksa" yang sesuai di manajer keamanan. Jika tindakan tersebut dilarang, metode "check" akan memunculkan pengecualian keamanan, yang akan menyebabkan metode API Java segera dibatalkan. Tindakan yang berpotensi tidak aman tidak akan pernah diambil. Sebaliknya, jika tindakan diizinkan, metode "periksa" akan kembali. Dalam kasus ini, metode Java API menjalankan dan melakukan tindakan yang berpotensi tidak aman.

Meskipun Anda hanya dapat menginstal satu manajer keamanan, Anda dapat menulis manajer keamanan sehingga ia menetapkan beberapa kebijakan keamanan. Selain metode "check", pengelola keamanan juga memiliki metode yang memungkinkan Anda menentukan apakah permintaan dibuat baik secara langsung atau tidak langsung dari kelas yang dimuat oleh objek loader kelas, dan jika demikian, yang digunakan oleh objek loader kelas. Ini memungkinkan Anda untuk mengimplementasikan kebijakan keamanan yang bervariasi bergantung pada class loader mana yang memuat class yang membuat permintaan. Anda juga dapat mengubah kebijakan keamanan berdasarkan informasi tentang file kelas yang dimuat oleh pemuat kelas, seperti apakah file kelas diunduh melalui jaringan atau diimpor dari disk lokal. Jadi meskipun sebuah aplikasi hanya dapat memiliki satu pengelola keamanan,bahwa manajer keamanan dapat menetapkan kebijakan keamanan fleksibel yang bervariasi berdasarkan kepercayaan kode yang meminta tindakan yang berpotensi tidak aman.

Autentikasi

Dukungan untuk otentikasi yang diperkenalkan di Java 1.1 dalam java.securitypaket memperluas kemampuan Anda untuk menetapkan beberapa kebijakan keamanan dengan memungkinkan Anda menerapkan kotak pasir yang bervariasi bergantung pada siapa yang sebenarnya membuat kode. Otentikasi memungkinkan Anda untuk memverifikasi bahwa sekumpulan file kelas diberkati sebagai dapat dipercaya oleh beberapa vendor, dan bahwa file kelas tidak diubah dalam perjalanan ke mesin virtual Anda. Jadi, sejauh Anda mempercayai vendor, Anda dapat mengurangi pembatasan yang ditempatkan pada kode oleh kotak pasir. Anda dapat membuat kebijakan keamanan berbeda untuk kode yang berasal dari vendor berbeda.

Untuk link ke informasi selengkapnya tentang otentikasi dan java.security, lihat Sumber daya di bagian bawah artikel ini.

Keamanan di luar arsitektur

Agar efektif, strategi keamanan komputer atau jaringan harus komprehensif. Ini tidak dapat secara eksklusif terdiri dari kotak pasir untuk menjalankan kode Java yang diunduh. Misalnya, mungkin tidak terlalu menjadi masalah bahwa applet Java yang Anda unduh dari Internet dan dijalankan di komputer Anda tidak dapat membaca file pengolah kata dari rencana bisnis rahasia Anda jika Anda:

  • Unduh secara rutin executable asli yang tidak tepercaya dari Internet dan jalankan
  • Buang salinan cetak rencana bisnis Anda tanpa mencabik-cabiknya
  • Biarkan pintu Anda tidak terkunci saat Anda pergi
  • Pekerjakan seseorang untuk membantu Anda yang sebenarnya adalah mata-mata musuh bebuyutan Anda

Namun, dalam konteks strategi keamanan yang komprehensif, model keamanan Java dapat memainkan peran yang berguna.

Keamanan adalah pertukaran antara biaya dan risiko: Semakin rendah risiko pelanggaran keamanan, semakin tinggi biaya keamanan. Biaya yang terkait dengan komputer atau strategi keamanan jaringan harus dibandingkan dengan biaya yang terkait dengan pencurian atau penghancuran informasi atau sumber daya komputasi yang dilindungi. Sifat komputer atau strategi keamanan jaringan harus dibentuk oleh nilai aset yang dilindungi.

Hal yang menyenangkan tentang model keamanan Java adalah setelah Anda mengaturnya, ia melakukan sebagian besar pekerjaan untuk Anda. Anda tidak perlu khawatir tentang apakah program tertentu dipercaya atau tidak - runtime Java akan menentukannya untuk Anda. Jika program tidak tepercaya, runtime Java akan melindungi aset Anda dengan membungkus kode tidak tepercaya di kotak pasir.

Strategi keamanan keseluruhan Java

Sebagaimana pengguna perangkat lunak Java harus memiliki kebijakan keamanan komprehensif yang sesuai dengan kebutuhan mereka, strategi keamanan teknologi Java itu sendiri tidak bergantung secara eksklusif pada arsitektur mekanisme keamanan yang dijelaskan di bagian ini. Misalnya, salah satu aspek dari strategi keamanan Java adalah setiap orang dapat menandatangani perjanjian lisensi dan mendapatkan salinan kode sumber implementasi Platform Java Sun. Alih-alih menyimpan implementasi internal arsitektur keamanan Java sebagai "kotak hitam" rahasia, program ini terbuka bagi siapa saja yang ingin melihatnya. Hal ini mendorong ahli keamanan mencari tantangan teknis yang baik untuk mencari celah keamanan dalam implementasinya. Ketika lubang keamanan ditemukan, mereka dapat ditambal. Dengan demikian, keterbukaan implementasi internal Java merupakan bagian dari Java 'strategi keamanan keseluruhan.

Selain keterbukaan, ada beberapa aspek lain dari keseluruhan strategi keamanan Java yang tidak secara langsung melibatkan arsitekturnya. Anda dapat menemukan tautan ke informasi lebih lanjut tentang ini di bagian Sumber di bagian bawah artikel ini.

Kesimpulan

Manajer keamanan berkontribusi pada model keamanan JVM dengan menetapkan kebijakan keamanan kustom untuk aplikasi Java. Agar kebijakan keamanan menjadi "anti peluru", Java API dan manajer keamanan itu sendiri harus diterapkan dengan benar. Bug di salah satu dari ini dapat mengakibatkan lubang keamanan yang dapat dieksploitasi oleh pemrogram jahat.

Sifat pengelola keamanan yang dapat disesuaikan adalah salah satu kekuatan arsitektur keamanan Java. Metode "pemeriksaan" dari pengelola keamanan hanyalah kode Java, jadi Anda bebas memutuskan pada situasi yang tepat di mana aplikasi Anda akan mengizinkan tindakan yang berpotensi tidak aman. Jika Anda dapat mengekspresikan algoritme dalam kode Java sebagai metode "pemeriksaan" dari pengelola keamanan, algoritme tersebut dapat menjadi bagian dari kebijakan keamanan khusus aplikasi Anda.

Bill Venners telah menulis perangkat lunak secara profesional selama 12 tahun. Berbasis di Silicon Valley, dia menyediakan layanan konsultasi dan pelatihan perangkat lunak dengan nama Artima Software Company. Selama bertahun-tahun ia telah mengembangkan perangkat lunak untuk elektronik konsumen, pendidikan, semikonduktor, dan industri asuransi jiwa. Dia telah memprogram dalam banyak bahasa di banyak platform: bahasa assembly di berbagai mikroprosesor, C di Unix, C ++ di Windows, Java di Web. Dia adalah penulis buku: Inside the Java Virtual Machine, diterbitkan oleh McGraw-Hill.