Penting Adanya !! Arsitek TI..

Adalah memang bisa dipahami ketika seseorang ingin membangun gedung maka dipanggilah seorang Arsitek Gedung dan sang ahli bisa memperlihatkan wujud nyata dalam gambar 2 atau 3 dimensi yang dengan jelas dimengerti oleh pemilik rumah gambaran kelak rumah mereka. Hal ini karena pembangunan yang dilakukan berupa fisik.

Lain halnya dengan pengembangan sistem informasi dimana sifatnya yang tidak bisa dikatakan fisik maka barang tentu apa yang diinginkan oleh pemilik tidak mudah untuk divisualisasikan oleh pembuat. Apalagi kalau sang pemilik juga tidak bisa mendeskripsikan kebutuhannya dengan jelas, maka pasti apa yang tidak bisa digambarkan akan sulit untuk direalisasikan.

Analogi di atas sangat bisa jadi merupakan akar masalah dari kegagalan pengembangan sistem yang terjadi pada proyek di atas. Sehingga sedari awal saat analisa sistem berlangsung hingga akhirnya user menandatangani To-be Documentation, saat itu sebenarnya user belum bisa menjelaskan seperti apa kebutuhan ia sebenarnya. Sama halnya analis juga tidak bisa menyampaikan sebenarnya apa yang ia tangkap dan apa yang ia usulkan. Sehingga pada akhirnya implementasi berjalan, aplikasi tidak sesuai dengan apa yang dibayangkan. Bahkan belum sampai implementasi pun sering proyek TI menampakkan kegagalannya.

Lantas SIAPA dia manusia yang bisa menyebut dirinya Arsitek TI?
Bukan Super Developer
Bukan Super DB Administrator
Bukan IT/Development Manager
So SIAPA DIA??
Bisa Developer yang berkompetensi BISNIS atau
Bisa Pelaku Bisnis yang menguasai Teknis atau
Bisa Network/System Specialist yang berkompetensi BISNIS atau
Bisa IT Pro yang bisa menjadi jembatan BISNIS dan Teknologi.

Yang PASTI dia generalis IT yang mengenal betul Bisnis, yang mampu meluruskan langkah tujuan TI sejurus dengan Strategi Bisnis. Bisa satu dari beberapa ahli di atas. Dia mampu mengurai BLACK BOX IT menjadi untaian visualisasi terindra oleh pebisnis, yang menawarkan PROFIT kepada bisnis dengan menjadikan ceruk keuntungan menjadi mungkin untuk diraih.

So pahami ITABOK guys !

Apa itu Google + ?

Hari ini baca di detik.com kalau kang mark zuckerberg diundang dan menjadi member di Projek Google+, jadi penasaran apaan sih nih projek? So coba ane cari-cari and berbagi ke pembaca blog aku. Google+ adalah proyek yang bertujuan untuk membuat aktivitas berbagi di web mirip dengan apa yang terjadi di dunia nyata. Ya kalau merujuk dari perkembangannya arahnya ke web 3.0, naik kelas kan.. Nah, apa saja fitur menarik yang bisa dilakukan dengan Google+?

Seperti dikutip detikINET dari Techradar, Kamis (30/6/2011), berikut adalah beberapa elemen yang bisa dilakukan dengan Google+. Sebelumnya dikabarkan, layanan jejaring sosial dari Google yang bertajuk Google+ mulai diujicoba untuk umum. Undangan terbatas diluncurkan Google pada beberapa usernya untuk mencoba Google+, sebelum nantinya dirilis secara luas. Iseng coba login.. teteup.. ditolak secara halus,, katanya “Mas,, ntar kalau udah ready.. kita undang deh ..”

Google+ adalah jawaban sang raksasa internet terhadap dominasi Facebook, situs jejaring terpopuler di dunia. Google+ adalah upaya untuk menyegarkan jejaring sosial di perangkat mobile maupun web. Berikut fitur yang nampak :

Circles:
Fitur ini memungkinkan pengguna jejaring sosial membagikan hal-hal yang mereka suka, terhadap lingkaran pertemanan tertentu. Jadi pengguna bisa mengelompokan kontak mereka ke dalam grup-grup sesuai kebutuhan. Hal ini sedikit mirip fitur ‘list’ di Facebook. Jadi berbagi hal yang benar dengan orang yang tepat membuat segala sesuatunya tidak merepotkan.

Hangouts:
Sesuai namanya, ini merupakan fitur grup video yang diambil dari Circles secara kolektif. Di dalamnya, pengguna bisa melakukan video conference layaknya Skype atau Windows Live.

Sparks:
Sparks adalah tempat di mana kita bisa mengelompokan konten-konten yang ada di internet, untuk kemudian dibagikan ke teman-teman kita. Misalnya bahasan-bahasan fotografi, media sosial, atau apapun yang akan muncul di timeline. Kita pun bisa memberi +1 ke konten tersebut. Fitur ini semacam news-feed yang bisa dikustomisasi.

Mobile – Instant Upload:
Akses Google+ bisa dilakukan dari mana saja via ponsel kita. Di dalamnya ada fitur-fitur seperti instant upload, membuat rencana grup, multiple conversation, dan sebagainya.

Hmm.. tak tunggu om fiturmu.. juga nunggu orang-orang kreatif dari indonesia yang bisa menggali emas di bisnis internet. Mendulang uang yang ramah lingkungan yang tak pernah habis.

Cheers..

Failed to mount database ‘Mailbox Database’ hr=0×80004005, ec=-528

Sekian lama waktu terlewati, penuh dengan kesibukkan membuat blog ini ga keurus. Sore ini base on rasa terima kasih aku ke NerdNero dan jader3rd, aku tulis ulang perbaikan Exchange Server 2007 step by step beserta kronologi masalahnya.

1. Ga niat masuk kerja lagi sakit.. maksain kerja abis malu kalah ama sakit.. kepala pening plus meriang “gembira”.
2. Boss Go telpon, mas agung.. iki piye emailku kok lambreta.. J peace Boss. Ga lama yg lain nimbrung waduh, kirim dari tadi kok masih ngendon di outbox. Akhirnya gw cek server via mstsc.exe.
3. Cek error log.. kagak ada yg aneh… lagi.. Cuma antivirus ngadat..
4. Cek Direktori Database Exchange.. what a hell !!! Lognya bejibun ampek beranak pinak.. weleh..welehh
5. Hapus Log.. ga mungkin pake explore.. lambat dan ga bakal nongol, pake dos,, karena pusing dir sekali langsung del E0000F*.exe biasanya aman2 ajah.. dan langsung sembuh. Walah email masih lambat,, wal hasil reset dah.
6. Kagak mau shutdow dah hampir sejam.. jadinya dirty shotdown dah.
7. Server hidup lagi tp Exchangenya tambah parah.. kali ini DB ga bisa dimount, alamak kunaon ieuk mah… tanya si Om G, keyword :

(hr=0×80004005, ec=-528)

1. Ikutin langkah ini :

-          Matikan exchange transport service.

-          Masuk ke direktori bin dari instalasi program, biasanya di sub exchange yg ada di Program Files.

-          Jalankan eseutil /p [database] contoh

Eseutil /p “d:/exchange db/first group/exchange db.edb”

Tungguin dah .. besar file db /8 [jam]. Trus yang paling lama nungguin proses “deleting unicode fixup table” Sabar.. sabar.. aku tunggu sambil ketar-ketir ampek 5 jam.

-          Setelah selesai.. jangan buru-buru mount DB, tapi apus tus di direktori log dengan perintah “del E00*.log” klau ga yakin ya remove dululah di dir lain.

-          Mount DB setelah exchange transport dinaikin dulu yah..

1. Exchange kembali normal… puihh ngelap keringet.

 

Message of Story : “KALAU SAKIT JANGAN MAKSAIN KERJA !!!”

Semoga berguna

Lowongan Marketing

Sahabat sekalian,

Kami dari Lembaga Komputer yang sedang berkembang, membuka kesempatan untuk bergabung dengan tim profesional kami sebagai “Marketing Leader”

kualifikasi :

- punya motor & SIM

- good communication skill

- mau belajar

- laki-laki

- usia dibawah 25

- memiliki motivasi kerja yang kuat

- dinamis dan berorientasi pada target

- Mampu mengoperasikan computer

- Bisa mengajar komputer

Lokasi kantor di sekitar Karawaci/Perum I Tangerang. Apabila tertarik silakan email cv anda ke: agung1978@gmail.com dengan Subject Marketing Star Komputer

Salam

Sekilas Keamanan Sebuah Website

Berbicara keamanan sebuah website tentu akan membutuhkan berlembar-lembar halaman untuk menulisnya, tentu tinjauannya akan sangat luas. Tulisan kali ini akan mencoba membicarakan hal ini tentu dalam tinjauan yang terbatas.

10 Celah keamanan pada aplikasi web

Upaya untuk mengetahui apakah website kita aman atau tidak adalah langkah yang dianjurkan dengan tujuan mengetahui kelemahan atau lubang dari web service kita. Open Web Application Security Project (OWASP) adalah project open source yang dibangun untuk menemukan penyebab dari tidak amannya sebuah software dan menemukan cara menanganinya. Ada 10 celah kemanan aplikasi web yang ditemukan dan rekomendasi mereka tentang menanganinya sebagai sebuah standard keamanan minimal dari aplikasi web.

Berikut ini adalah 10 celah tersebut dan cara agar kita dapat mengatasi masalah tersebut.

I. Unvalidated input

Semua aplikasi web menampilkan data dari HTTP request yang dibuat oleh user dan menggunakan data tersebut untuk melakukan operasinya. Hacker dapat memanipulasi bagian-bagian pada request (query string, cookie information, header) untuk membypass mekanisme keamanan.

Berikut ini tiga jenis penyerangan yang berhubungan dengan masalah ini:

• Cross site scripting

• Buffer overflows

• Injection flaws

Ada beberapa hal yang dapat dicatat ketika menangani validasi pada aplikasi kita. Pertama, adalah tidak baik pada aplikasi web untuk percaya pada client side scripting. Script tersebut biasanya menghentikan form submission apabila terdapat sebuah input yang salah. Akan tetapi, script tersebut tidak dapat mencegah hacker untuk membuat HTTP requestnya sendiri yang terbebas dari form. Menggunakan client side validation masih bisa membuat aplikasi web yang mudah diserang.

Kedua, beberapa aplikasi menggunakan pendekatan “negative” (negative approach) pada validasinya : Aplikasi mencoba mendeteksi jika terdapat elemen yang berbahaya pada request parameter. Masalah dari jenis pendekatan ini adalah hanya bisa melindungi dari beberapa serangan yaitu : hanya serangan yang dikenali oleh validation code yang dicegah. Ada banyak cara dimana hacker dapat membypass keamanan dari unvalidated input; Masih ada kemungkinan dimana cara yang baru tidak dikenali oleh aplikasi dapat membypass validasi dan melakukan perusakan. Adalah cara yang lebih baik untuk menggunakan pendekatan “positive” (positive approach) yaitu : membatasi sebuah format atau pola untuk nilai yang diijinkan dan memastikan input tersebut sesuai dengan format tersebut.

 

II. Broken Access Control

Banyak aplikasi yang mengkategorikan user-usernya ke dalam role yang berbeda dan level yang berbeda untuk berinteraksi dengan content yang dibedakan dari kategori-kategori tersebut. Salah satu contohnya, banyak aplikasi yang terdapat user role dan admin role : hanya admin role yang diijinkan untuk mengakses halaman khusus atau melakukan action administration.

Masalahnya adalah beberapa aplikasi tidak efektif untuk memaksa agar otorisasi ini bekerja. Contohnya, beberapa program hanya menggunakan sebuah checkpoint dimana hanya user yang terpilih yang dapat mengakses : untuk proses lebih lanjut, user harus membuktikan dirinya terotorisasi dengan menggunakan user name dan password. Akan tetapi, Mereka tidak menjalankan pengecekan dari checkpoint sebelumnya : dimana apabila user berhasil melewati halaman login, mereka dapat bebas menjalankan operasi.

Masalah lain yang berhubungan dengan access control adalah:

• Insecure Ids – Beberapa site menggunakan id atau kunci yang menunjuk kepada user atau fungsi. ID dapat juga ditebak, dan jika hacker dapat mudah menebak ID dari user yang terautorisasi, maka site akan mudah diserang.

• File permissions – Kebanyakan web dan aplikasi server percaya kepada external file yang menyimpan daftar dari user yang terotorisasi dan resources mana saja yang dapat dan/atau tidak dapat diakses. Apabila file ini dapat dibaca dari luar, maka hacker dapat memodifikasi dengan mudah untuk menambahkan dirinya pada daftar user yang diijinkan.

Langkah-langkah apa saja yang dapat dilakukan untuk mengatasinya? Pada contoh-contoh tadi, kita dapat mengembangkan filter atau komponen yang dapat dijalankan pada sensitive resources. Filter atau komponen tadi dapat menjamin hanya user yang terotorisasi dapat mengakases. Untuk melindungi dari insecure Ids, kita harus mengembangkan aplikasi kita agar tidak percaya pada kerahasiaan dari Ids yang dapat memberi access control. Pada masalah file permission, file-file tersebut harus berada pada lokasi yang tidak dapat diakses oleh web browser dan hanya role tertentu saja yang dapat mengaksesnya.

 

III. Broken Authentication dan Session Management

Authentication dan session management menunjuk kepada semua aspek dari pengaturan user authentikasi dan management of active session. Berikut ini beberapa hal yang perlu diperhatikan :

• Password strength – Aplikasi kita harus memberikan level minimal dari keamanan sebuah password, dimana dapat dilihat dengan cara melihat panjang dari password dan kompleksitasnya. Contohnya sebuah aplikasi dimana terdapat user baru yang akan mendaftar : aplikasi tidak mengijinkan password dengan panjang 3-4 karakter atau kata-kata simpel yang dapat mudah ditebak oleh hacker.

• Password use – Aplikasi kita harus membatasi user yang mengakses aplikasi melakukan login kembali ke sistem pada tenggang waktu tertentu. Dengan cara ini aplikasi dapat dilindungi dari serangan brute force dimana hacker bisa menyerang berulang kali untuk berhasil login ke sistem. Selain itu, log in yang gagal sebaiknya dicatat sebagai informasi kepada administrator untuk mengindikasikan kemungkinan serangan yang terjadi.

• Password storage – password tidak boleh disimpan di dalam aplikasi. Password harus disimpan dalam format terenkripsi dan disimpan di file lain seperti file database atau file password. Hal ini dapat memastikan bahwa informasi yang sensitif seperti password tidak disebarkan ke dalam aplikasi.

Issue lain yang berhubungan : password tidak boleh dalam bentuk hardcoded di dalam source code.

• Session ID Protection – server biasanya menggunakan session Id untuk mengidentifikasi user yang masuk ke dalam session. Akan tetapi jika session ID ini dapat dilihat oleh seseorang pada jaringan yang sama, orang tersebut dapat menjadi seorang client.

Salah satu cara yang dapat digunakan untuk mencegah terlihatnya session ID oleh seseorang pada suatu jaringan yang sama adalah menghubungkan komunikasi antara sever dan client pada sebuah SSL-protected channel.

IV.Cross site scripting

Cross site scripting terjadi ketika seseorang membuat aplikasi web melalui script ke user lain. Hal ini dilakukan oleh penyerang dengan menambahkan content (seperti JavaScript, ActiveX, Flash) pada request yang dapat membuat HTML output yang dapat dilihat oleh user lain. Apabila ada user lain yang mengakses content tersebut, browser tidak m

Halaman Berikutnya »