Thursday, November 4, 2010

S.M.A.R.T policy dan procedure

Wihartoyo     Thursday, November 04, 2010    
Jika kita terbiasa dalam pembentukan kebijakan terkait pengamanan informasi itu harus mengikuti pola S.M.A.R.T yang boleh di panjangin jadi Specifics untuk S, Measureable untuk M, Achievable untuk A, Realistic untuk R, dan Time Based untuk T.

Namun sebelum tahu banyak tentang SMART ada baiknya mengenal 5Ws.
  1. What, apa, prosedurnya sendiri itu prosedur apa?
  2. Who, siapa, siapa yang menjalankan prosedur?
  3. When, kapan, kapan suatu prosedure harus dijalankan?
  4. Where, dimana, dimana suatu prosedure harus dijalankan?
  5. Why, mengapa, mengapa suatu prosedure harus dijalankan?
Ya, 5Ws yang selalu diawali dengan 'Wh' sama dengan 5Ws dari dunia jurnalistik.  Lalu, kenapa kita menggunakan ini untuk membangun suatu prosedure? Karena dengan mejawab pertanyaan-pertanyaan di atas maka kita akan bisa mendapat gambaran secara utuh tentang suatu prosedur, baik tentang prosedur apa yang akan dijalankan, siapa yang harus menjalankannya, kapan harus dijalankan, dimana harus dijalankan, dan yang pasti adalah mengapa suatu prosedur harus dijalankan. Yang pasti dalam menilai SMART atau membentuk kebijakan secara SMART maka kira harus menggunakan kaidah jurnalistik di atas.

Kembali ke SMART.
S, Specifics. Sespesifik apakah kebijakan tentang pengamanan informasi yang akan kita buat? Pada dasarnya suatu kebijakan pengamanan  bisa dibuat sangat spesifik atau sangat umum bergantung pada kemampuan organisasi itu mengadaptasi perubahan dan tentunya bergantung pula pada kebijakan dari organisasi itu sendiri untuk melakukan review terhadap seluruh kebijakan yang berlaku di dalam organisasi itu sendiri.
Pada suatu organisasi, oleh karena sifatnya yang sangat fleksible untuk mengantisipasi ancaman-ancaman, sangat mungkin untuk membuat suatu policy sedetail mungkin. Dalam organisasi seperti ini, mungkin perubahan policy hanya membutuhkan waktu dalam hitungan hari.  Bisa 3 hari, bisa 4 hari atau mungkin kurang dari itu.  Namun, pada organisasi lain, yang karena ukurannya dan jenjang birokrasi, atau karena kebutuhan akan kepastian kebijakan; perubahan suatu kebijakan bisa membutuhkan waktu lebih lama dan siklus perubahannya bisa mencapai 1 tahun ata bergantung pada kebijakan dari oragnisasi itu sendiri. Pada organisasi ini, mungkin kebijakan pengamanan informasi  tidak dibuat dengan sangat detail karena luasnya cakupan yang memang tidak bisa dihindari oleh karena sifat dan ukuran organisasi. Namun, kenyataan bahwa tidak pernah ada satu jawaban untuk menjawab semua pertanyaan, maka penting bagi organisasi untuk melakukan review untuk melakukan perubahan-perubahan yang dirasa perlu.

M, Measurable. Pernyataan-pernyataan di dalam membentuk suatu kebijakan pengamanan informasi harus bisa terukur dalam arti jelas dan tidak bersayap. Sebagai contoh point-point pengamanan informasi mengenai password berikut
  • Tidak diperkenankan menggunakan singkatan-singkatan yang umum sebagai bagian dari password
  • Tidak diperkenankan menggunakan kata-kata umum atau kebalikan dari kata-kata umum sebagai bagian dari password
  • Tidak diperkenankan menggunakan nama orang atau nama tempat sebagai bagian dari password
  • Tidak diperkenankan menggunakan seluruh atau sebagian dari login name (user name) sebagai bagian dari password
  • Tidak diperkenankan menggunakan angka-angka yang mudah ditebak seperti tanggal lahir, nomor telepon, nomor NPWP dan nomor-nomor sejenis lainnya sebagai bagian dari password.
Perhatikan penggunaan kata-kata "tidak diperkenankan".  Penggunaan kata-kata ini bisa masuk dalam katagori measurable.  Di sini, user atau object dari kebijakan bisa menerima dengan jelas maksud dari kebijakan.

Bandingkan dengan contoh berikut:
  • Pada kondisi dimana password dibutuhkan, setiap user harus mempunyai passwordnya sendiri yang hanya diketahui oleh yang bersangkutan.  Masing-masing user bertanggung-jawab terhadap kerahasiaan dari passwordnya masing-masing dan untuk setiap penyalahgunaan passwordnya oleh pihak lain.
Pada contoh kedua ini, kebijakan tidak menyebutkan dengan jelas tentang bagaimana password yang rahasia dan tidak mudah ditebak tetapi menyerahkan tanggung-jawab kerahasiannya kepada user.

A, Achievable. Suatu kebijakan seharusnya bisa dijalankan. Sebagai contoh bisa dilihat pada frasa kebijakan berikut;

"Apabila suatu data dan sistem baru telah terpasang, maka personel dari application security bisa melakukan evaluasi dan menentukan metode, proses, kelengkapan, dan prosedur untuk meminimalkan resiko."

Frasa di atas kelihatan sangat ideal, sangat mudah bagi seorang Application Security untuk menuliskan frasa seperti itu. Akan tetapi, pada kondisi yang sebenarnya, akan sangat sulit bagi seorang Application Security untuk menentukan point-point kebijakan yang akan dituliskan agar memenuhi persayaratan spesifik dan measurable.  Bila seorang Application Security bisa dengan mudah menuliskan point kebijakannya, sangat boleh jadi itu akan menjadi tidak achievable.  Contoh di atas adalah point kebijakan yang tidak spesifik, measurable, dan acievable. Contoh di atas terlalu mengambang dan tidak spesifik, tidak secara jelas menyebutkan tindakan yang harus dilakukan oleh seorang Application Security dan tentunya tidak akan achievable karena tolok ukurnya yang tidak jelas.

R, Realistic.  Suatu kebijakan seharusnya mempunyai pandangan yang realistik terhadap setiap point yang diuraikan. Contoh berikut adalah contoh point yang kurang realistik.

"Seluruh karyawan yang memperoleh sambungan internet hanya boleh menggunakannya hanya untuk kepentingan bisnis perusahaan."

Frasa di atas kelihatannya memang indah, namun kurang realistik. Kenapa tidak realistik? Karena user akan berpikir, bagaimana dengan karyawan yang bepergian dengan laptop perusahaan? Bisa jadi mereka mempunyai account facebook, dan menggunakan laptop perusahaan plus sambungan internetnya untuk ber-facebook-ria.

T, Time Based.  Harus jelas waktunya, dan karena harus memperhatikan faktor achievable maka untuk mendukung kebijakan terkait Time Based harus juga dilengkapi dengan prosedur. Perhatikan contoh berikut:

"Terminasi Account: Setiap supervisor dari karyawan yang mengundurkan diri harus melaporkan pengunduran diri karyawan bersangkutan kepada Security Admin sebelum atau pada hari pengunduran diri karyawan yang bersangkutan, sehingga semua account milik karyawan bisa di-inaktifkan dengan baik"

Paragraf kebijakan di atas bagus namun frasa "sebelum atau pada hari" atau "secepatnya" hanya akan bisa berjalan bila dilengkapi dengan prosedure yang bisa menjelaskan dengan pasti mengenai apa yang harus dilakukan oleh seorang supervisor terkait pengunduran diri staff-nya.

Wednesday, November 3, 2010

Replikasi PostgreSQL 9.0

Wihartoyo     Wednesday, November 03, 2010    
PostgreSQL 9.0.x mungkin merupakan satu lompatan yang mampu menyejukkan 'kekeringan' para penggemar PostgreSQL akan satu fitur yang paling sangat dinantikan. Replikasi. Semenjak saya mulai keranjingan PostgreSQL pada tahun 2006, hal yang paling sering mengganggu adalah masalah replikasi data. Tak usahlah sampai ke active-active, active-passive pun terasa amat sulit mendapatkan pemecahannya. Memang teramat banyak pilihan replikasi untuk postgres, namun, ataghfirullah, reliability nya sangat-sangat rentan. Terutama bila dipegang oleh orang yang tidak terlalu menguasai. Sebut saja pgCluster, pgPool, sequoia, atau Slony. Hampir semua nyaris bikin frustasi, kecuali Slony. Hanya proses inisiasi Slony teramat-amat sangat ribet dan menghasilkan rieut yang sangat. Nah ribet, rieut inilah kemudian yang dicoba untuk dipangkas oleh Replikasi PostgreSQL 9.0.

Streaming Replication
Streaming Replication? Kenapa streaming? PostgresSQl 9.0.x memanfaatkan XLOG (pg_xlog) untuk melakukan replikasi. Rekaman XLOG ini secara terus-menerus perbagian dikirimkan ke standby site dengan mengimplementasikan record-based log-shipping. Ini akan menjamin semakin kecilnya data-loss. Isi dari XLOG akan dituliskan di standby dan secara tepat akan sama dengan primary. Dengan menggunakan streaming replication ini kita bisa membuat suatu konfigurasi redundant untuk standby site, dimana dengan satu primary kita bisa setup lebih dari satu standby. Jumlah maksimum dari standby bisa ditentukan melalui variable GUC. Oleh karena standby site akan selalu mereplay seluruh log yang dikirim oleh primary maka bisa dharapkan setiap perubahan di sisi primary akan segera direplay di sisi standby atau posisi standby akan selalu (hampir) sama dengan primary, tentunya oleh karena adanya antrian dan pengiriman melalui jaringan akan menimbulkan latensi.

Installasi PostgreSQL 9.0
Untuk mendapatkan keuntungan replikasi PostgreSQL 9.0.x mau gak mau kita harus menginstall PostgreSQL 9.0. Source PostgreSQL 9.0.x bisa didapat di sini. Download source,extract, configure, make all, dan make install dengan perintah.

postgres@firsthost:~/postgresql-9.0.1$cd $HOME
postgres@firsthost:~$echo "export PATH=$HOME/pgsql/bin:$PATH" >>.profile [atau file profile lainnya]


Logout dan Login lagi dan jalankan initdb untuk mengisiasi database.


postgres@firsthost:~$nano ~/data1/postgresql.conf

cari bagian listen_addresses, edit dan sesuaikan dengan kondisi. Untuk kasus kita kali ini listen_address akan kita isi dengan '*', dan port = 5432


#untuk mengaktifkan konfigurasi "hot standby" dan meng-enable-kan read-only query pada standby
#server maka parameter "wal_level" kita beri nilai "hot_standby".

wal_level = hot_standby

#kemudian untuk memberikan nilai concurrent connection dari standby server kita beri nilai integer
#sejumlah standby server yang akan terkoneksi ke primary. dalam konfigurasi ini karena hanya
#mempunyai satu standby server maka kita masukan integer "1"

max_wal_sender = 1

#Untuk mencegah primary server membuang WAL segment yang dibutuhkan untuk standby server
#maka nilai minimum segment yang dipegang dalam direktori "pg_xlog" harus ditentukan
#pada parameter "wal_keep_segments". Dalam hal ini setidaknya nilai dari wal_keep_segments
#lebih besar dari segment yang dibentuk antara online backup dan permulaan (startup) dari
#streaming replication. Bila anda meng-enable-kan WAL archiving pada suatu direktory yang bisa
#diakses dari standby site, parameter ini bisa diabaikan.

wal_keep_segments = 32

#Enable-kan WAL archiving pada primary pada suatu direktory yang bisa diakses dari standby.
#Jika wal_keep_segments cukup besar untuk menjaga WAL segment yang dibutuhkan oleh standby server,
#maka parameter ini bisa diabaikan

archive_mode = on
archive_command = 'cp -i %p $HOME/archive/%f'


Catatan :
Perhatikan bagian yang dicetak tebal. Kita harus menyiapkan direktori $HOME/archive untuk menghindari kesalahan.

Setelah kita lakukan editing terhadap file postgresql.conf, kemudian kita jalankan server dengan perintah:


postgres@firsthost:~$psql -c "SELECT pg_start_backup('label',true)"
postgres@firsthost:~$rsync -a $HOME/data1/ secondhost:$HOME/data1/ --exclude postmaster.pid
postgres@firsthost:~$psql -c "SELECT pg_stop_backup()"


Note:
Perhatikan bagian yang dicetak tebal. Untuk menjalankan perintah ini, $HOME directory antara primary (firsthost) dan standby (secondhost) harus menunjuk ke direktori yang sama. Atau bisa diganti dengan menggunakan absolute path.

Selanjutnya kita pindah ke secondhost (standby). Edit file postgresql.conf, cari parameter "hot_standby" dan berikan nilai "on" padanya.


postgres@secondhost:~$nano ~/data1/recovery.conf
--
#Karena server akan berjalan sebagai standby maka tentukan standby_mode = on

standby_mode = on

#Tentukan parameter koneksi ke primary server

primary_conninfo = 'host=firsthost port=5432 user=postgres'

#tentukan suatu trigger file yang keberadaannya akan menyebabkan streaming replication akan
#terhenti (contohnya pada failover).

trigger_file = '$HOME/trigger'

#Tentukan perintah untuk me-load segment-segment archives dari WAL archive. Bila nilai dari
#wal_keep_segments cukup besar untuk menampung segment WAL yang dibutuhkan oleh standby server,
#parameter ini mungkin tidak dibutuhkan. Namun workload yang cukup tinggi bisa menyebabkan
#segment akan diresaikel sebelum standby tersinkronisasi secara penuh dan menyebabkan kita harus
#mulai dari basec backup.

restore_command = 'cp $HOME/archives/%f %p'


Catatan
Perhatikan bahwa kita harus membuatkan direktori $HOME/trigger. Sebaiknya direktori kita buat pada dua sisi baik di primary maupun standby

Terakhir, untuk memberikan informasi koneksi antara primary dan standby, maka kita harus merubah file pg_hba.conf baik di primary maupun di standby. Kenapa kedua-duanya? Karena pada beberapa kondisi mungkin perlu dilakukan switch dari primary menjadi standby atau sebaliknya.

Pada primary:
Tambahkan baris ini:

#bila IP second host adalah 10.10.10.2 maka:

host replication postgres 10.10.10.2/32 trust


Untuk memastikan kita restart primary dan jalankan standby. Pada log di standby harus bisa dilihat kepastian terkoneksi ke primary dengan munculnya message berikut:

Pada log standby:

..
..
LOG: replication connection authorized: user=postgres host=10.10.10.3 port=XXXX


Bila kedua server sudah memberikan message seperti di atas maka replikasi sudah bisa dijalankan.

Test Replikasi
Secara gampangnya untuk meyakini bahwa replikasi telah terinstall kita bisa menjalankan perintah berikut di sisi primary. Ingat hanya primary yang bisa melakukan transaksi!!!!!


postgres@fisthost:~$psql -c "select datname from pg_stat_database where datname='testdb'" -h firsthost
datname
---------
testdb
(1 row)


Test di secondhost seharusnya akan memberikan hasil yang sama.
postgres@fisthost:~$psql -c "select datname from pg_stat_database where datname='testdb'" -h secondhost

datname
---------
testdb
(1 row)


Test create table dan insert data
postgres@fisthost:~$psql -c "create testtable(no integer, nama character varying(76))" -h firsthost
postgres@fisthost:~$psql -c "insert into testtable(no, nama) values (1,'nama saya')" -h firsthost
postgres@fisthost:~$psql -c "insert into testtable(no, nama) values (2,'nama kamu')" -h firsthost


Test hasilnya di primary

postgres@fisthost:~$psql -c "select * from testtable" -h firsthost
no | nama
----+-----------
1 | nama saya
2 | nama kamu
(2 rows)


Lakukan yang sama terhadap secondhost dan seharusnya bisa memberikan hasil yang sama.

postgres@fisthost:~$psql -c "select * from testtable" -h secondhost no | nama
----+-----------
1 | nama saya
2 | nama kamu
(2 rows)


Jika telah benar telah memberikan hasil yang sama maka bisa dikatakan bahwa installasi replikasi kita telah berhasil.

Tambahan
Dari ujicoba, untuk merubah standby menjadi primary maka langkah-langkah yang harus dilakukan:
  1. Rubah parameter hot_standby menjadi off pada sisi standby sehingga standy akan bertindak menjadi primary dan menjadi on pada primary sehingga primary akan mejadi secondary.
  2. Pindahkan recovery.conf dari secondary ke primary, atau copy ke primary sementara di secondary direname menjadi bukan recovery.conf

Beberapa Catatan Penting
  1. Untuk melakukan materialisasi pada sisi standby tidak bisa dilakukan dengan menggunakan pg_dump/pg_restore harus dengan menggunakan base backup seperti dilakukan di atas.
  2. Pemindahan material dari primary ke standby tidak harus dengan menggunakan rsync.
  3. Penggunaan rsync pada beberapa kondisi harus menggunakan akses passwordless.

Monday, November 1, 2010

Berpikir Ulang Tentang Java

Wihartoyo     Monday, November 01, 2010    
Mungkin sedikit agak telat kalo aku nulis ini. Ini terkait akuisisi Sun Microsystem oleh Oracle kemudian diikuti oleh keluarnya Jonathan Schwartz serta keluarnya James Gosling salah satu co-creator Java dari Oracle April 2010 dan jika kita mengikuti blognya, maka kita sungguh akan sangat berpikir bahwa ada yang "kurang baik" yang mengikuti akuisisi SUN Microsystem oleh Oracle. Yang paling hangat saat ini adalah mengenai pertengaran Oracle dan Google khususnya pada Android sebuah opensource project dengan bahasa pemrograman Dalvix yang notabene opensource turunan java. Kenapa Google dikejar sementara baik Android dan Dalvix adalah opensources? Karena Google menyatakan bahwa mereke berdiri di belakang Android. Dor! Plak ada sasaran! Dan jadilah ada "pertengkaran rumit" antara Oracle adn Google.
Sejauh ini, "pertengkaran" antara Oracle Google memang belum memberikan imbas negatif terhadap perkembangan java. Namun saya yakin dari kondisi seperti ini, lama-kelamaan akan terpengaruh juga. Dan dari berita-berita terakhir ternyata peperangan Oracle dan Google masih berlangsung.
"Konfrontasi ini, bukan tentang perusahaan yang baik atau perusahaan yang jahat adlam situasi ini." Kata Douglas Lea, seorang ilmuwan dari State University of New York. "Tetapi ini tentang perusahaan-perusahaan yang bersaing secara jahat (viciously) dan mempunyai tujuan yang berbeda. Dan dalam kasus ini, anda bisa melihat 2 perusahaan/korporasi yang mengkampanyekan 2 bentuk yang berbeda dari open-sources"
Yang menjadi terombang-ambing dalam kasus ini adalah orang yang tidak terlibat dalam peperangan ini, c.q. para pengembang open-sources. Mereka tentunya sangat berharap agar segera terwujud gencatan senjata antara kedua-belah pihak, atau setidaknya kedua-belah pihak menhindari hal-hal yang tidak perlu. Dan kata Lea, "Akan sangat sulit untuk memprediksikan konsekuensi dari dua perusahaan yang saling bentrok satu sama lain". Dan bagi saya sendiri, saya yang bukan programmer java tetapi banyak bergantung sama java, sangat berharap untuk tidak perlu berpikir ulang tentang Java.

Recommended