Latest Articles

Services of Cryptography System

Cryptography is more than encryption. The services provided by cryptography system may include the following:
Confidentiality: renders the information unintelligible except by authorised entities.
Integrity: data has not been altered in an unauthorised manner since it was created, transmitted, or stored.
Authentication: verifies the identity of the user of system that created the information.
Authorisation: upon proving identity, the individual is then provided with the key or password that will allow access to some resource.
Nonrepudiation: ensures that the sender cannot deny sending the message.

Encryption

RSA, AES and SHA can all provide encryption but for different purpose.

RSA

RSA fits in in PKI asymmetric key structure. It provides message encryption and supports authentication and nonrepudiation services.
However, the downside is the encryption process is much slower than symmetric key, such as AES and DES. Therefore, it is often used to encrypt and distribute symmetric key.

AES

AES fits in symmetric key structure and provides longer key (safer) than DES. It provides message encryption, much faster than asymmetric key such as RSA. Therefore, it is used to encrypt file content and communication.
Online AES encryption: http://aes.online-domain-tools.com/

SHA

SHA and MD5 hashing are used to generate message digest to verify message integrity – message is not altered during transition. Hasing is one-way function and cannot be reversed. Same content always generates the same hash value. Therefore, hashing is often used to ensure message integrity; or when no decryption is required, such as Cisco enable password.
However, if simple text is used, the hash value may be reversible and the plaintext password is revealed. It can be done by hashing dictionaries to achieve a hash value library and then matching the hash value of the password to the library to figure out the original password. Therefore, complicated password should always be required for security reason.
Cisco password reverser: http://packetlife.net/toolbox/type7/
The following table summarises the pros, cons and usage of different cryptographies.
CryptographyProsConsUsage
Symmetric
(e.g. DES, 3DES, AES)
·      Fast
·      Hard to break if using large key size
·      How to securely deliver keys?
·      Scalability – too many unique keys
·      authenticity or nonrepudiation not provided
·      Encrypt files and communication paths
Asymmetric Cryptography – PKI
(e.g. RSA, DH, DSA, ECC)
·      Better key distribution than symmetric
·      Better scalability
·      Provide authentication and nonrepudiation
·      1000+ times slower than symmetric·      Distribute symmetric key (except DSA)
·      Digital signature (except DH)
Hashing
(e.g. MD5, SHA)
·      One-way function, fast
·      Provide message digest – easy file comparison
·      Safety – same content always generates same hash value
·      Decryption is not supported, due to one-way function
·      Check message integrity – no alteration

Summary of Cryptography Mechanism

Following diagram is a summary of cryptography mechanism, including i) key distribution process, enabled by RSA or DH; ii) content and communication encryption process, enabled by AES, 3DES or DES; iii) hashing process, enabled by SHA or MD5; iv) digital signature process; enabled by RSA or DSA etc.


Jalur adopsi DevOps merupakan praktik yang berfokus pada tujuan bisnis dan menyesuaikannya berdasarkan umpan balik (feedback) dari pelanggan atau disebut perencanaan bisnis yang berkelanjutan (continuous business planning).

Bisnis saat ini harus tangkas dan mampu bereaksi dengan cepat terhadap umpan balik pelanggan. Dalam mencapai tujuan ini akan berpusat pada kemampuan organisasi untuk melakukan segala sesuatu dengan tepat.

Sayangnya pendekatan tradisional dalam penyajian produk terlalu lambat untuk mengimbangi kecepatan dalam bisnis, karena pendekatan ini pengembangan dilakukan secara manual dan tim operasional terpisah di silo tersendiri. Informasi yang diperlukan untuk perencanaan menjadi lambat dalam memberikan sebuah nilai bisnis karena terfragmentasi dan tidak konsisten.




Dalam perencanaan tradisional seringkali feedback yang tepat sasaran tidak diterima lebih awal sehingga tidak mencapai tingkat kualitas yang dapat benar-benar memberikan nilai bisnis.

Tim pengembangan juga tidak dapat memahami feedback dari prioritas kebuthan bisnis, bahkan untuk beberapa tim perencanaan dipandang sebagai kerumitan tata kelola yang mengganggu dan memperlambat suatu kegiatan yang memungkinkan mereka untuk memberikan nilai bisnis dengan lebih cepat.

Penyajian layanan suatu produk dengan cepat akan memberikan kelincahan dalam bisnis, tetapi tetap harus mengatur kecepatan tersebut agar produk yang disajikan memiliki kualitas baik dan sesuai dengan kebutuhan bisnis.



DevOps membantu merekonsiliasi perspektif antara keduanya yaitu kelincahan bisnis dan kualitas dari produk yang dihasilkan berdasarkan umpan balik pelanggan.

Bisnis tidak lepas dari mengelola biaya, dengan mengidentifikasi dan menghilangkan sesuatu yang tidak diperlukan dalam proses pengembangan maka tim menjadi lebih efisien tetapi tetap fokus pada pengelolaan biaya.

Perencanaan melalui DevOps akan membantu tim mencapai keseimbangan secara optimal di antara semua permasalahan diatas melalui phase didalam siklus hidup (life cycle) DevOps sehingga dalam penyajian produk akan berubah ke sebuah aristektur model penyajian produk secara berkelanjutan (continuous delivery model).

Kemampuan yang membentuk sebuah DevOps adalah perluasan dari software delivery life cycle (SDLC). Di mana organisasi menggunakan DevOps disesuaikan dengan tujuan, sasaran, dan tantangan bisnisnya yang akan di hadapi

Tantangan terbesarnya adalah menjalan kan sebuah arsitektur DevOps untuk mengatasi gap diantara aspek bisnis dengan kemampuan penyajian sebuah layanan perangkat lunak.

Sebuah referensi arsitektur yang terdiri dari serangkian metodologi yang sudah terbukti dalam menyediakan template solusi.



Arsitektur referensi DevOps akan membantu praktisi mengakses dan menggunakannya sebagai pedoman, arahan, dan materi yang mereka butuhkan untuk mengakomodasi orang, proses, dan teknologi dalam sebuah DevOps platform.

Arsitektur referensi DevOps seperti terlihat pada gambar terdiri atas empat set jalur adopsi sebagai berikut:

  •  Plan
  •  Develop/Test
  •  Deploy
  •  Operate

Arsitektur referensi menyediakan kapabilitas melalui berbagai komponen yang dapat disediakan oleh satu komponen atau sekelompok komponen yang saling bekerja bersama. 
Adopsi DevOps pada organisasi telah menghasilkan beberapa prinsip yang terus berkembang dari waktu ke waktu dan masih terus berkembang. Beberapa solusi penyedia layanan telah mengembangkan varian mereka sendiri.

Semua prinsip yang berkembang dan digunakan harus disesuikan dengan prinsip utama dari DevOps sehingga DevOps dapat diterapkan secara menyeluruh dan dapat di adopsi oleh berbagai jenis ukuran organisasi.



Berikut beberapa hal yang menyangkut prinsip kerja utama dari DevOps:

Pengembangan

Pengembangan dan pengujian dilakukan pada sistem yang menyerupai lingkungan yang sebenarnya. Paparan prinsip ini berasal dari konsep "shift left", dimana fokus operasional lebih awal dalam siklus hidup pengembangan perangkat lunak.



Tujuannya adalah untuk memungkinkan tim pengembang dan tim quality assurance (QA) untuk dapat mengembangkan dan menguji pada sistem menyerupai sistem sebenarnya, sehingga mereka dapat melihat bagaimana aplikasi dapat berperilaku dan berkinerja dengan baik sebelum siap di rilis.

Dari perspektif operasional, prinsip ini juga memiliki nilai yang luar biasa. Ini memungkinkan tim operasional untuk melihat lebih awal bagaimana perilaku lingkungan opersional mereka dalam mendukung aplikasi, sehingga memungkinkan mereka untuk membuat fine-tuned, lingkungan yang sadar aplikasi.

Rilis

DevOps melakukan rilis dengan proses berulang dan dapat diandalkan, prinsip ini memungkinkan tim pengembang dan tim operasional untuk dapat terus menerus mendukung pengembangan perangkat lunak secara tangkas (atau setidaknya iteratif) selama proses pengembangan hingga produk rilis.

Otomasi sangat penting untuk dapat menciptakan proses yang berulang, sering, dan dapat diandalkan. Untuk itu organisasi harus membuat jalur pengembangan (delivery pipeline) yang memungkinkan untuk dapat dilakukan penerapan dan pengujian secara berkelanjutan dan otomatis.

Pengawasan

Organisasi biasanya pandai memonitor aplikasi dan sistem pada saat operasional tetapi kebanyakan mereka memantau secara terpisah dan tidak berkelanjutan.

Dalam DevOps prinsip ini akan berbeda karena dalam pengawasan dilakukan lebih awal dengan mewajibkan pengujian secara otomatis lebih awal dan sesering mungkin dalam sebuah siklus hidup pengembangan.

Dalam prinsip DevOps dilakukan pemantauan karakteristik fungsional dan non-fungsional dari aplikasi, setiap kali iterasi pengembangan aplikasi akan diuji dan metrik kualitas harus ditangkap dan dianalisis.

Dalam proses pengawasan ini akan memberikan peringatan dini tentang operasional dan masalah kualitas yang mungkin terjadi pada saat produksi nanti.

Metrik ini harus ditangkap dalam format yang dapat dipahami dan digunakan semua pemangku kepentingan bisnis

Umpan Balik

Fokus pada umpan balik (feedback) yang berkelanjutan adalah salah satu tujuan DevOps yang memungkinkan organisasi untuk bereaksi dan membuat perubahan lebih cepat.

Dalam pengembangan perangkat lunak, tujuan ini membutuhkan organisasi yang dapat melakukan umpan balik cepat dan kemudian belajar dengan cepat dari setiap tindakan yang dilakukan.

Prinsip ini juga membutuhkan organisasi yang memiliki saluran komunikasi yang memungkinkan semua pemangku kepentingan untuk mengakses dan bertindak berdasarkan umpan balik.

Adanya prinsip ini akan dapat bermanfaat untuk :
  • Tim Pengembang dapat bertindak dengan menyesuaikan rencana proyeknya atau prioritas.
  • Tim Operasional dapat bertindak dengan meningkatkan produksi lingkungan.
  • Bisnis dapat bertindak dengan memodifikasi rencana rilisnya.

DevOps menerapkan prinsip agile dan ramping di seluruh proses pembuatan perangkat lunak. Dengan ini memungkinkan bisnis untuk memaksimalkan kecepatan dalam penyajian suatu produk atau layanan perangkat lunak, mulai dari ide awal untuk rilis produk sampai pengembangan berikutnya melalui umpan balik dari pelanggan.

Karena DevOps meningkatkan cara kerja proses bisnis yang penting seperti peningkatan nilai tambah bagi pelanggan, pemasok, dan mitra, bukan hanya dari peningkatana dari sisi teknologi informasinya saja.



DevOps memberikan nilai tambah penting dan signifikan dalam sebuah investasi bisnis, terutama untuk bagian :
  • Peningkatan customer experience
  • Peningkatan kapasitas untuk berinovasi
  • Mempercepat nilai bisnis baru

Peningkatan Customer Experience

Pengalaman pengguna atau pelanggan adalah bagaimana cara seseorang merasakan ketika menggunakan sebuah produk, sistem, atau jasa. Pengalaman pengguna menyoroti aspek-aspek pengalaman, pengaruh, arti dan nilai dari interaksi manusia-komputer dan kepemilikan sebuah produk, juga termasuk persepsi seseorang mengenai aspek-aspek praktis seperti kegunaan, kemudahan penggunaan, dan efisiensi dari sebuah sistem.

Saat ini perangkat lunak di tuntut untuk dapat berinterkasi dengan pelanggan. Keterlibatan ini mnyebabkan kemampuan untuk bereaksi dan beradaptasi secara tangkas mengarah pada peningkatan pengalaman dan loyalitas pelanggan.

Peningkatan Kapasitas Untuk Berinovasi

Organisasi modern menggunakan pendekatan lean thinking untuk meningkatkan kapasitas mereka untuk berinovasi. Tujuan mereka adalah mengurangi limbah dan pengerjaan ulang dan untuk mengalihkan sumber daya ke nilai yang lebih tinggi.

Dasar pemikiran dari lean thinking adalah berusaha menghilangkan waste (pemborosan) di dalam proses, atau dapat juga dikatakan sebagai suatu konsep perampingan atau efisiensi.

Lean thinking merupakan suatu konsep untuk melakukan lebih dan lebih dengan sedikit human effort, sedikit peralatan, sedikit waktu, sedikit ruang, dalam memenuhi apa yang diinginkan konsumen.



Contoh praktik umum dalam lean thinking adalah pengujian A-B, di mana organisasi meminta sekelompok kecil pengguna untuk menguji dan memberi peringkat dua atau lebih perangkat lunak yang memiliki kemampuan berbeda.

Kemudian perangkat lunak yang memiliki kemampuan lebih akan di rilis ke semua pengguna sedangkan yang lainnya di batalkan dan dianggap gagal.

Pengujian perangkat lunak dengan A-B seperti itu hanya memungkinkan dengan mekanisme yang efisien dan otomatis seperti metodologi DevOps.

Mempercepat Nilai Bisnis Baru

Definisi dari nilai akan bervariasi pada setiap organisasi dan bahkan dari proyek ke proyek, tetapi tujuan DevOps adalah untuk memberikan nilai ini lebih cepat dan lebih efisien. Dengan melibatkan budaya kerja, praktik, dan otomatisasi sehingga memungkinkan me-rilis perangkat lunak dengan cepat, efisien, dan handal.

Ketika DevOps diadopsi sebagai peningkatan kemampuan bisnis maka akan membantu dalam menyediakan alat dan budaya yang diperlukan untuk memfasilitasi perencanaan rilis yang efisien, prediktabilitas, dan peningkatan keberhasilan.

Melakukan perubahan kebiasan dalam proses bisnis selalu sulit dan biasanya membutuhkan sebuah investasi. Setiap kali organisasi mengadopsi teknologi, metodologi, atau pendekatan, adopsi itu harus didorong oleh kebutuhan bisnis.

Demikan halnya dalam mengadopsi DevOps pada bisnis yang ada, kita harus benar-benar memahami kebutuhan bisnis termasuk tantangan yang akan di hadapinya.

Tujuan sebuah organisasi kebanyakan ingin membuat aplikasi atau layanan inovatif untuk menyelesaikan masalah bisnis. Mereka mungkin ingin menyelesaikan masalah bisnis di internal organisasi (seperti menciptakan sistem manajemen untuk hubungan dengan pelanggan yang lebih baik) atau untuk memberikan layanan baru kepada pelanggan atau pengguna akhir mereka (seperti dengan menyediakan aplikasi seluler baru).

Pada kenyataannya banyak organisasi gagal dengan proyek perangkat lunak, kegagalan mereka sering terkait dengan tantangan di pengembangan dan pembuatan perangkat lunak. Meskipun sebagian besar perusahaan merasa bahwa pengembangan dan pembuatan perangkat lunak sangat penting, survei industri menunjukkan hanya 25 persen setiap organisiasi percaya bahwa tim mereka efektif.



Masalah ini semakin diperkuat oleh pergeseran besar dalam jenis aplikasi yang diminta oleh bisnis, dari hanya aplikasi sistem catatan berubah menjadi sistem keterlibatan (engagement).

Aplikasi sistem catatan termasuk jenis Aplikasi perangkat lunak tradisional dimana hanya berisi data transaksi sehingga dapat dirancang handal dan stabil. Karena aplikasi jenis ini tidak perlu sering diubah, organisasi dapat memuaskan pengguna dan bisnis mereka sendiri dengan hanya memberikan satu atau dua update rilis baru setiap tahunnya.

Berbeda halnya dengan aplikasi sistem keterlibatan, dengan munculnya komunikasi seluler dan stabilnya aplikasi web via browser, aplikasi sistem catatan semakin dilengkapi oleh sistem keterlibatan, yang dapat diakses langsung oleh pelanggan dan di gunakan untuk berinteraksi. Aplikasi dengan kebutuhan seperti itu harus mudah digunakan, berkinerja tinggi, dan mampu untuk dilakukan perubahan dengan cepat karena diperlukan untuk mengakomodasi perubahan kebutuhan pelanggan dan kekuatan pasar yang berkembang.

Karena sistem keterlibatan digunakan langsung oleh pelanggan, mereka membutuhkan fokus intens pada pengalaman pengguna, kecepatan dalam pengembangan, dan fleksibel. Maka dengan kata lain sangat dibutuhkan pendekatan lain dalam pengembangan perangkat lunak dengan tujuan yang sama mengeluarkan produk akhir secepat dan seefisien mungkin seperti halnya metodologi DevOps.

Agile dan DevOps adalah dua metodologi pengembangan perangkat lunak dengan tujuan yang sama yaitu mengeluarkan produk akhir secepat dan seefisien mungkin. Sementara banyak organisasi ingin menggunakan kedua metode ini, tapi dalam prakteknya sering terjadi kebingungan di antara keduanya.

Apa sebenarnya yang dicakup oleh masing-masing metodologi tersebut dan apakah terjadi tumpang tindih dalam penggunaannya. Atau mungkin keduanya dapat bekerja bersama, atau haruskah kita memilih hanya satu saja.



DevOps 

DevOps adalah metodologi pengembangan perangkat lunak yang bertujuan untuk menyatukan tim pengembangan perangkat lunak dan tim teknologi informasi. Ini adalah konsep yang menumbuhkan budaya kolaborasi antara kedua tim yang sebelumnya bekerja di silo yang terpisah , dari tahap desain awal hingga rilis sebuah produk.

DevOps adalah metodologi yang menggabungkan pengembangan perangkat lunak (Dev) dengan operasional (Ops). Tujuannya adalah untuk memungkinkan komunikasi antara tim sehingga mereka dapat membangun, menguji, dan merilis perangkat lunak lebih cepat dan dengan efisiensi dan kecepatan yang lebih besar.

Dalam menggabungkan dua tim dengan proses yang berbeda ini diharapkan memberikan produk dan layanan yang berkualitas tinggi secara berkesinambungan melalui integrasi berkelanjutan, distribusi berkelanjutan, pengujian seacara otomatis, dan transparansi dalam repositori kode.



Agile

Metodologi tangkas yang juga merupakan metodologi pengembangan perangkat lunak yang diperkenalkan sekitar tahun 2001.

Secara umum metode agile mendorong adopsi dan perubahan pola pikir seorang leadership yang dapat meningkatkan kerja tim, pengorganisasian diri, dan akuntabilitas.

Lebih penting lagi, pendekatan agile lebih berfokus secara terus menerus menyelaraskan pengembangan dengan tren dari kebutuhan konsumen.

Agile mewujudkan serangkaian prinsip yang dapat membantu individu, tim, dan unit untuk dapat bekerja bersama. Sehingga agile lebih berfokus pada orang, bukan pada proses dan alat.

Sebuah organisasi yang tangkas beradaptasi dan belajar tentang perubahan terus-menerus yang memungkinkan mereka mengidentifikasi peluang baru dan menambahkan nilai bagi konsumen.



Agile dan DevOps

Pada dasarnya, DevOps menyatukan dua tim besar untuk dapat merilis perangkat lunak yang lebih cepat sementara Agile fokus untuk membuat tim yang lebih kecil agar dapat berkolaborasi satu sama lain sehingga dapat bereaksi dengan cepat dan tangkas terhadap kebutuhan konsumen yang terus berubah.

Agile menggunakan sprint, yang berkisar dari satu minggu hingga bulan sebagai cara untuk mengatur jadwal pengembangan sementara DevOps fokus pada rilis cepat yang dimulai dengan beberapa hari.

Baik DevOps dan Agile dapat bekerja bersama karena mereka dapat saling melengkapi. DevOps mempromosikan integrasi terus menerus yang sepenuhnya otomatis dalam pipa penyebaran untuk memungkinkan rilis yang lebih sering, sementara Agile menyediakan kemampuan untuk dengan cepat beradaptasi dengan perubahan melalui kolaborasi yang lebih baik antara berbagai tim kecil.

Ketika diterapkan bersama-sama, Agile dan DevOps dapat memungkinkan organisasi untuk mengembangkan dan mengimplementasikan teknologi dengan kecepatan yang jauh lebih besar. Ada penekanan pada menempatkan kebutuhan pelanggan berada di garis depan diatas teknologi apa pun yang akan kembangkan.

Penerapan Agile maupun DevOps dalam sebuah organisasi, terutama organisasi yang lebih besar, tim yang berbeda cenderung memiliki kebiasaan mereka untuk hanya berfokus pada tujuan departemen yang tertanam dalam cara berpikir mereka. Maka sangat penting untuk mencari sumber daya yang sesuai dengan kultur baru dengan mendapat dukungan stakeholder.

Agile dan DevOps masing-masing merujuk pada dua hal berbeda, terkadang beberapa organisasi menggunakan satu untuk mengaktifkan yang lain misalnya menggunakan metodologi agile sebagai motivator untuk mengembangkan budaya DevOps.