JAVA SECURITY

Resume Java Security : Presentasi

M. Septian Maulana

09.41010.0170

6.1 Sejarah keamanan di Java

Java awalnya dipromosikan untuk digunakan oleh pengembang untuk membuat Java applet. Java applet memungkinkan code untuk di-download langsung ke web browse. Teknologi ini adalah salah satu yang pertama mengaktifkan web browser ke dalam framework yang dapat mendukung pelaksanaan aplikasi download  melalui Web. Frame work ini menyediakan paradigma baru untuk komputasi yang berbeda dengan komputer desktop tradisional. Dengan komputer desktop, aplikasi yang diambil dan dijalankan oleh anda pada mesin anda. Setiap kali anda membutuhkan update untuk aplikasi
perangkat lunak, anda harus mendapatkan distribusi dari sumber seperti CD dan disk, kemudian andamenjalankan proses update sendiri. Java applet memungkinkan paradigma baru di mana mobile code di-download secara dinamis ke web browser dan akan update secara otomatis setiap kali anda mengunjungi kembali situs Web dari kode yang sudah didownload.

Namun, kinerja jaringan telah membantu mengekang visi besar tersebut dengan membatasi ukuran Java applet yang user anggap layak untuk didownload dan, oleh karena itu, membatasi kompleksitas aplikasi yang didownload. Selain itu, kinerja implementasi JVM dilengkapi dengan Web browser juga menghambat proliferasi applet Java di Internet. Lagi pula, jika anda sekarang men-download mobile Java code dari beberapa remote web site ke komputer lokal anda, berapa banyak akses ke komputer lokal anda yang anda ingin berikan untuk kode tersebut? Banyak aplikasi desktop tradisional membutuhkan akses ke sistem file lokal anda. Apakah anda benar-benar menginginkan Java applet didownload dari beberapa situs Web berbahaya untuk memiliki akses ke sistem file Anda?

Dengan demikian, keamanan adalah pertimbangan utama untuk Java dari hari pertama. Aplikasi Enterprise juga dapat keuntungan dari fitur keamanan. Aplikasi Java sekarang dapat mengambil keuntungan dari model keamanan yang lebih canggih (tersedia dalam platform Java 2) untuk meningkatkan keamanan layanan perusahaan.

Evolusi dari model Java security diperkenalkan dengan setiap rilis versi utama Java yang
digambarkan pada Gambar 6.1.1 sampai 6.1.3 platform Java 1.0 yang disediakan sangat terbatas, keamanan model dikenal sebagai model sandbox, seperti yang ditunjukkan pada Gambar 6.1.1. Dalam model sandbox, hanya kode lokal memiliki akses ke semua resources yang berharga (misalnya, file dan sambungan  jaringan baru) yang terbuka dan diakses oleh Java Virtual Machine (JVM). Kode yang didownload dari remote site, seperti applet, memiliki akses hanya untuk  resources yang jumlahnya terbatas. Jadi, file-sistem akses dan kemampuan untuk membuat sambungan baru terbatas untuk remote code. Hal ini menjadi perhatian utama untuk implementasi JVM yang dilengkapi dengan web browser.

Gambar 6.1.1 Java 1.0 sandbox security model.

Model Java 1.0 security agak terlalu terbatas, namun visi memberikan aplikasi yang dapat download melalui web ditunda karena aplikasi tersebut tidak dapat melakukan operasi kunci seperti akses file atau penciptaan koneksi jaringan baru. Jika vendor web browser memperlakukan remote code seperti local code, jalan untuk malicious code yang dapat merusak local machine akan terbuka. Seperti all-or-nothing model yang diganti di Java 1.1 ketika
model keamanan terpercaya dijalankan, seperti digambarkan dalam Gambar 6.1.2.

Gambar 6.1.2 Java 1.1 trusted code security model

Dengan trusted code model, anda dapat menetapkan apakah code yang ditandatangani oleh provider tertentu akan diizinkan untuk memiliki akses penuh ke resources yang diinginkan. Dengan demikian, anda mungkin benar-benar dapat percaya bahwa beberapa Java code dari Microsoft akan dapat dijalankan dalam browser anda dengan akses penuh ke resources sistem anda, seperti anda percaya Microsoft saat anda menginstal salah satu dari banyaknya produk pada sistem anda. Code atau applet memberikan izin pada perusahaan seperti perusahaan seperti Microsoft untuk memberikan appletvya sedemikian rupa sehingga anda dapat memverifikasi bahwa code tersebut benar-benar datang dari perusahaan ini.
Dengan demikian, applet yang sah diberikan akses ke semua resources sistem anda, sedangkan untrusted code akan di taruh pada sandbox.

Java 2 platform (juga disebut Java 1.2) benar-benar telah membuka jalan bagi keamanan aplikasi dengan finer-grained security model, seperti digambarkan dalam Gambar 6.1.3. Sekarang local dan remote code dapat dibatasi hanya untuk memanfaatkan domain resource tertentu sesuai dengan kebijakan yang telah dikonfigurasi.

Gambar 6.1.3 Java 1.2/2 configurable and fine-grained access security model

6.2 Java Security Architecture

Gambar 6.2.1 menggambarkan komponen-komponen utama dari standar yang ditetapkan API dan mekanisme yang digunakan untuk menyediakan keamanan untuk aplikasi berbasis Java 2. Pada bagian bawah diagram adalah core Java 2 security architecture dan Java Cryptography Architecture (JCA), yang bersama-sama membentuk Java 2 security platform yang datang dengan Java 2 platform. Di atas atas dari diagram adalah standard Java security extensions yang diedarkan secara terpisah dari Java 2 platform tapi masih tergantung pada aspek yang berbeda dari Java 2 platform.

Gambar 6.2.1 Java security architecture standard components

6.3 Core Java 2 Security Architecture

Gambar 6.3.1 menunjukkan  Core Java 2 Security Architecture dalam konteks seluruh Java 2
platform, sistem operasi, resources, dan Java code yang running pada Java 2 platform.

Byte code verifier memverifikasi bahwa byte code yang diambil dari kode Java application code external  ke Java platform  telah sesuai sintaks dari spesifikasi bahasa Java. Class loader kemudian bertanggung jawab untuk penerjemahan dari byte code ke dalam Java class constructs yang dapat dimanipulasi oleh Java runtime environment (JRE). Dalam proses loading classes,  class loader  yang berbeda dapat menerapkan kebijakan yang berbeda untuk menentukan apakah kelas-kelas tertentu harus
dimuat ke dalam Java runtime environment. Class loader dan Java 2 platform classes sendiri
membantu membatasi akses ke resources penting dengan cara mencegat panggilan yang digunakan untuk platform Java API dan mendelegasikan keputusan, apakah panggilan tersebut dapat digunakan untuk security manajer. Java 1.0 and 1.1 memanfaatkan security manager secara eksklusif dalam membuat keputusan, sedangkan aplikasi Java 2 dapat menggunakan access controller dengan lebih fleksibel dan access-control decision making yang dapat dikonfigurasi. Akhirnya, code tidak dapat dieksekusi tanpa runtime execution engine.

Akses kontrol adalah penambahan paling signifikan terhadap Java 2 platform security, membantu memperluas model security untuk mengaktifkan konfigurasi dan fine-grained access control.

Gambar 6.3.1 core Java security architecture

6.4 Class Loader

Class loader merupakan salah satu komponen kunci dari Java virtual machine yang bertanggung jawab untuk mengelola pemuatan Java class byte codes ke lingkungan Java runtime. Class loader bertanggung jawab untuk :

• Meng-load Java class byte codes dari input stream (misalnya, file atau jaringan).
• Mendorong byte code verifier untuk memverifikasi byte code.
• Mendorong security manager dan access controller untuk memverifikasi akses ke resources.
• Menyerahkan classes ke Java runtime execution engine.

Komponen class loader sebenarnya terdiri dari satu atau lebih class loader individu. Primordial class loader diproses ke dalam Java virtual machine dan bertanggung jawab untuk meng-load core Java platform classes. Class loaders yang lain dapat diimplementasikan dengan mengikuti standar class loader interface. Namun, class loader seperti itu tunduk pada verifikasi keamanan yang lebih ketat daripada primordial class loader.  Implementasi class loader yang berbeda disediakan untuk menawarkan cara yang berbeda untuk meng-load classes dari input stream dengan menggunakan kebijakan yang berbeda.

6.5 Security Manager

Komponen security manager dari core Java security architecture bertanggung jawab untuk menentukan apakah permintaan tertentu untuk mengakses resources penting tertentu  harus diperbolehkan. Untuk membuat keputusan ini, security manager menganggap sumber (yaitu, Java class) yang membuat request. Karena akses ke banyak resources harus terlebih dahulu melewati core Java classes dari Java class yang membuat request, core Java classes mengambil kesempatan untuk bertany pertama kepada security manager apakah permintaannya diperbolehkan. Jika akses ditolak, sebuah
java.lang.SecurityException dilemparkan. Jika akses diizinkan, panggilan tersebut akan lanjutkan seperti biasa.

Setiap proses instance Java virtual machine hanya mengijinkan ada satu security manager instance (yaitu, singleton). Setelah security manager diinstantiated, JVM dapat dikonfigurasi sehingga membuat security manager tidak dapat diganti. Dengan demikian  akan selalu ada selama Java virtual machine process juga ada. Banyak Java virtual machines yang ada dalam web browser akan instantiate security manager instance sebelum Java applet pertama yang pernah dimuat dan tidak akan mengizinkan security manager direplace. Dengan demikian, security manager di web browser tidak dapat digantikan dengan malicious Java applet. Malicious Java applet mungkin dapat mengganti security manager
dengan security manager instance-nya sendiri yang dapat melonggarkan restrictions pada resources penting sehingga resoureces tersebut dapat diakses oleh siapapun dengan mudah.

Meskipun Java applet bekerja di proses  Java virtual machine  yang memiliki security manager yang sudah diinstantiated, aplikasi Java biasa anda buat tidak memiliki keunggulan ini. Di Java 1.1, menciptakan security manager anda sendiri merupakan hal yang merepotkan. Java 2 mempermudah anda membuat security manager untuk anda sendiri untuk aplikasi Java  dan membuatnya mudah dikonfigurasi. Hal ini karena
default dan  konfigurasi security manager  dapat digunakan dengan Java 2 applications; manajer ini
cukup lengkap dalam fitur pendukungnya untuk berbagai aplikasi. Dengan demikian, seperti yang akan anda lihat, penggunaan security manager untuk melindungi akses ke resources juga dapat disediakan untuk aplikasi Java.

Penggunaan default security manager dapat ditentukan dari command line ketika startup dari
aplikasi Java. Properti java.security.manager dapat dikirimkan ke Java virtual
machine sebagai properti sistem, spesifikasikan penggunaan dari default security manager seperti dibawah ini:

java –Djava.security.manager MyApplication

java –Djava.security.manager=default MyApplication