Menambahkan keamanan ke solusi pada akhir siklus hidup desain dan pengembangan sering kali mengakibatkan pengerjaan ulang yang mahal serta pengorbanan pada kegunaan yang dapat mengurangi kemampuan solusi dan pengalaman pengguna. Merancang solusi agar aman sejak awal membantu memastikan keseimbangan yang tepat antara kegunaan, interoperabilitas, ketahanan, dan keamanan pada solusi akhir.

Secure by design adalah prinsip bahwa praktik desain, pengembangan, dan pengiriman proyek harus mencakup praktik keamanan dan kepatuhan yang dilaksanakan oleh tim yang terampil dan berpengalaman. Prinsip-prinsip desain keamanan, seperti yang berikut ini, memandu praktik pemikiran arsitektur.

Proses desain perlu dimulai dengan penggunaan pemikiran desain perusahaan untuk berfokus pada hasil pengguna yang diperlukan bagi para pemangku kepentingan risiko, kepatuhan, dan keamanan, baik internal maupun eksternal organisasi. Pemangku kepentingan eksternal mencakup pelanggan, pemerintah, dan regulator. Pemangku kepentingan internal mencakup pihak-pihak yang mengelola risiko, kepatuhan, dan keamanan.

Jika pengguna atau perangkat lunak dalam suatu sistem memiliki hak istimewa yang berlebihan, terdapat risiko penyalahgunaan, baik secara tidak sengaja maupun sengaja. Definisi karakteristik, seperti ketahanan, kinerja, dan skalabilitas, kemudian ditetapkan untuk layanan keamanan.

Setelah definisi persyaratan dan arsitektur ditetapkan, rekayasa fungsionalitas keamanan dan infrastruktur dapat dilakukan, termasuk dengan mengikuti prinsip Secure by default.

IBM® memiliki pendekatan jangka panjang terhadap keamanan dan privasi berbasis security and privacy by design yang digunakan dalam pengembangan produk. Redpaper dari IBM® yang diterbitkan tentang Keamanan dalam Pengembangan: Kerangka Kerja Rekayasa Aman dari IBM® bermanfaat untuk ditinjau.

Jika pengguna atau perangkat lunak dalam suatu sistem memiliki hak istimewa yang berlebihan, terdapat risiko penyalahgunaan, baik secara tidak sengaja maupun sengaja. Aktor ancaman dapat membahayakan akun istimewa pengguna internal dan menggunakan hak tersebut untuk bergerak melintasi jaringan serta sistem.

Hak istimewa terkecil adalah prinsip yang menyatakan bahwa sistem harus memberikan kepada pengguna atau perangkat lunak kemampuan minimum yang diperlukan untuk melaksanakan tugas yang dimaksudkan. Sistem harus menerapkan prinsip ini mulai dari tingkat tertinggi dalam aplikasi hingga koneksi individual antara dua komponen perangkat lunak.

Untuk menerapkan prinsip hak istimewa paling sedikit, Anda harus memahami aset di lingkungan TI yang dinamis. Akses istimewa bukan hanya berkaitan dengan manusia; Anda juga perlu mengetahui aplikasi apa yang memiliki akses ke data tertentu. Proses penemuan, klasifikasi, dan penilaian risiko harus dilakukan secara berkelanjutan. Kumpulkan data risiko dari aset digital Anda untuk mengungkap insight risiko tingkat bisnis yang baru, sehingga membantu Anda menetapkan kebijakan yang tepat.

Pengguna atau perangkat lunak mungkin memiliki konteks yang aman pada titik identifikasi awal dan autentikasi untuk suatu sesi, tetapi aktor jahat dapat membahayakan sesi yang aktif dan memanfaatkannya untuk membahayakan sistem lebih lanjut.

Verifikasi berkelanjutan adalah prinsip bahwa pengguna atau perangkat lunak harus terus-menerus melakukan verifikasi untuk mengevaluasi apakah mereka masih berada dalam konteks yang aman. Tujuan dari verifikasi berkelanjutan adalah menemukan masalah keamanan dan kerentanan sedini mungkin idealnya sebelum aktor ancaman menemukannya.

Verifikasi berkelanjutan menegaskan bahwa suatu entitas adalah siapa, atau apa, yang mereka klaim melalui tantangan seperti permintaan autentikasi faktor kedua. Beban kerja mungkin memerlukan pembaruan untuk mendukung verifikasi berkelanjutan bagi pengguna dan perangkat lunak dengan menggunakan solusi seperti Zero Trust Network Architecture (ZTNA). Organisasi yang berfokus pada pemberian pengalaman pengguna terbaik di kelasnya sering ragu untuk mengganggu pengguna dengan permintaan yang tidak perlu; namun, tingkat jaminan identitas ini merupakan bagian penting dari pendekatan zero-trust untuk pengalaman pengguna yang aman.

Seorang aktor ancaman mungkin sudah melanggar organisasi. Jika organisasi hanya mencari ancaman di boundary eksternal dan bukan ancaman yang telah menggunakan mekanisme yang valid untuk melewati kontrol boundary, mereka mungkin tidak menemukan pelanggaran untuk waktu yang lama. Asumsikan pelanggaran adalah prinsip bahwa organisasi mengasumsikan pelanggaran telah terjadi oleh aktor ancaman.

Pendekatan ini mengharuskan manajemen ancaman menambahkan deteksi internal yang proaktif, mencari tanda-tanda peringatan dini, melakukan perburuan ancaman, serta menggunakan runbook yang telah terbukti. Deteksi dan respons harus terintegrasi secara erat dengan lapisan insight dan penegakan, berbagi konteks, serta menyesuaikan kebijakan kontrol akses secara dinamis sebagai respons terhadap ancaman yang teridentifikasi.

Sistem informasi akan memiliki kerentanan pada perangkat lunak, firmware, dan perangkat keras. Konfigurasi dan perangkat lunak akan berubah, dan kerentanan baru akan muncul. Jika satu lapisan pertahanan menjadi rentan, sistem tetap harus mampu mempertahankan keamanannya.

Pertahanan secara mendalam adalah prinsip bahwa suatu sistem memiliki beberapa lapisan pertahanan sehingga jika satu lapisan gagal, lapisan lain tetap tersedia untuk melindungi data sensitif dalam sistem. Menggunakan pendekatan berlapis dalam strategi keamanan memastikan bahwa organisasi dapat menghentikan penyerang pada lapisan berikutnya ketika satu lapisan pertahanan dilanggar.

Strategi keamanan tingkat perusahaan dan arsitektur harus mencakup langkah-langkah yang memberikan perlindungan pada berbagai lapisan di luar model komputasi jaringan tradisional. Secara umum, organisasi perlu merencanakan keamanan mulai dari tingkat yang paling dasar (keamanan tingkat sistem) hingga tingkat yang paling kompleks (keamanan tingkat transmisi).

Permukaan serangan organisasi adalah jumlah kerentanan, jalur, atau metode—kadang-kadang disebut vektor serangan—yang dapat digunakan aktor ancaman untuk memperoleh akses tidak sah ke jaringan atau data sensitif, atau untuk melancarkan serangan siber. Seiring dengan semakin banyaknya organisasi yang mengadopsi layanan cloud dan model kerja hibrida (on premises/kerja dari rumah), jaringan mereka dan permukaan serangan yang terkait menjadi semakin besar dan kompleks dari hari ke hari.

Minimalkan permukaan serangan adalah prinsip bahwa sistem harus mengurangi ruang lingkup vektor serangan sehingga mengurangi kemungkinan cara bagi aktor ancaman untuk memperoleh akses. Pakar keamanan membagi permukaan serangan menjadi tiga sub-permukaan: permukaan serangan digital, permukaan serangan fisik, dan permukaan serangan rekayasa sosial.

1. Setiap permukaan serangan berpotensi mengekspos infrastruktur cloud dan on-premises organisasi kepada aktor ancaman mana pun yang memiliki koneksi internet. Vektor serangan yang umum meliputi akses jaringan, kerentanan perangkat lunak, penyediaan sumber daya yang tidak digunakan, TI bayangan, serta perangkat lunak yang tidak lagi didukung.

2. Permukaan serangan fisik mengekspos aset dan informasi yang biasanya hanya dapat diakses oleh pengguna dengan akses resmi ke kantor fisik organisasi atau perangkat titik akhir. Hal ini mencakup serangan oleh orang dalam yang berniat jahat, pencurian perangkat, serta serangan “baiting” - yaitu ketika aktor ancaman meninggalkan drive USB yang terinfeksi malware di tempat umum dengan harapan menipu pengguna agar mencolokkan perangkat tersebut ke komputer mereka dan secara tidak sengaja mengunduh malware.

3.  Permukaan serangan rekayasa sosial memanipulasi orang untuk membagikan informasi yang seharusnya tidak mereka bagikan, mengunduh perangkat lunak yang seharusnya tidak mereka unduh, mengunjungi situs web yang seharusnya tidak mereka kunjungi, mengirimkan uang kepada penjahat, atau melakukan kesalahan lain yang membahayakan aset maupun keamanan pribadi atau organisasi mereka.

Suatu organisasi harus menilai risiko terhadap data sensitif yang sedang diproses oleh sistem dengan memeriksa setiap permukaan serangan tersebut.

Pengguna dapat memiliki akses ke data yang sangat sensitif yang memungkinkan bypass terhadap kontrol, seperti kunci enkripsi, atau memiliki hak untuk melakukan tindakan yang sangat istimewa, seperti mentransfer sejumlah besar uang. Bahkan ketika sistem memantau pengguna, mereka masih dapat menyalahgunakan hak tersebut yang dapat mengakibatkan konsekuensi bisnis yang serius.

Pemisahan tugas adalah prinsip bahwa pengguna dengan akses kuat terhadap data atau tindakan memerlukan lebih dari satu pengguna untuk menyelesaikan suatu tindakan. Prinsip ini memberikan organisasi kemampuan untuk membagi fungsi administratif di antara individu tanpa tanggung jawab yang saling tumpang tindih, sehingga tidak ada satu pengguna pun yang memiliki otoritas tanpa batas.

Untuk aktivitas seperti pengelolaan kunci enkripsi, organisasi memerlukan administrator kunci enkripsi untuk mengelola berbagai bagian kunci sehingga tidak ada satu administrator pun yang memiliki pengetahuan tentang keseluruhan kunci. Dalam transaksi bisnis, aplikasi mungkin juga mengharuskan seseorang yang mengajukan transaksi memperoleh persetujuan dari satu atau lebih pihak untuk menyelesaikannya.

Untuk beberapa industri, regulator mungkin mensyaratkan pemisahan tugas yang kuat sebagai bagian dari panduan regulasi. Pemisahan tugas membantu bisnis mematuhi peraturan pemerintah serta menyederhanakan pengelolaan otoritas.

Produk atau layanan memiliki banyak titik konfigurasi yang berbeda dan ada keinginan untuk membuatnya semudah mungkin digunakan. Akibatnya, produk dapat memiliki konfigurasi keamanan yang tidak aman, seperti port jaringan yang terbuka atau memungkinkan penggunaan kata sandi yang mudah ditebak.

Aman secara default adalah prinsip bahwa organisasi menerima produk atau layanan yang dikonfigurasi dalam keadaan aman sejak awal. Produk disiapkan untuk melindungi dari ancaman dan kerentanan yang paling umum tanpa pengguna akhir perlu mengambil langkah tambahan untuk mengamankannya.

Suatu sistem dapat dikonfigurasi dengan aman pada awalnya, tetapi pengembang selanjutnya dapat melakukan perubahan yang memodifikasi konfigurasi, atau aktor ancaman dapat membuat perubahan melalui kerentanan yang membahayakan sistem.

Kepatuhan berkelanjutan adalah prinsip bahwa konfigurasi keamanan sistem terus diperiksa, mulai dari tahap pengembangan hingga sistem yang sedang berjalan. Tujuan dari kepatuhan berkelanjutan adalah untuk menemukan masalah dan kerentanan keamanan sebelum aktor ancaman menemukannya.

Idealnya, pemeriksaan kepatuhan dilakukan secara otomatis dan mencakup semua konfigurasi keamanan, termasuk platform cloud, platform kontainer, middleware, serta image komputasi seperti virtual servers dan kontainer. Untuk image komputasi, pendekatan yang lebih baik mungkin menggunakan Infrastructure as Code (IaC) untuk mengganti seluruh image secara berkala.

Tanggung jawab bersama dalam penyampaian keamanan dan kepatuhan pada lingkungan hybrid cloud bergantung pada model layanan, platform komputasi, serta penyedia layanan cloud yang digunakan oleh beban kerja atau aplikasi. Seorang arsitek keamanan harus mendokumentasikan dan mengomunikasikan tanggung jawab yang mencakup desain, pembangunan, dan pengoperasian layanan keamanan. Tanpa kejelasan ini, celah dalam keamanan solusi dapat muncul.

Setiap dimensi memiliki dampak yang berbeda pada tanggung jawab bersama:

• Model layanan cloud -  Definisi NIST tentang komputasi awan memiliki cakupan tanggung jawab yang berbeda bergantung pada model layanan cloud, seperti IaaS, PaaS, SaaS, atau cloud terdistribusi. Layanan keamanan merupakan bagian dari tanggung jawab bersama. Misalnya, tanggung jawab bersama pada IBM® Cloud mencakup manajemen identitas dan akses, serta kepatuhan terhadap keamanan dan regulasi. Tanggung jawab bersama untuk berbagai kategori ini bervariasi tergantung pada model layanan cloud.
   

• Platform komputasi - Hosting beban kerja dapat berupa satu atau lebih platform komputasi, seperti Bare Metal Server, virtual servers, kontainer, dan nirserver. Setiap platform komputasi memiliki serangkaian tanggung jawab bersama yang berbeda. Misalnya, Bare Metal Server mengharuskan pemilik beban kerja bertanggung jawab atas semua kontrol keamanan pada platform tersebut, kecuali untuk perangkat keras fisik dan integrasinya.
   

• Penyedia layanan cloud - Tanggung jawab juga berubah tergantung pada penyedia layanan cloud. Misalnya, platform Kubernetes dari setiap penyedia layanan cloud berbeda (kecuali Anda menggunakan Red Hat OpenShift) karena masing-masing terdiri dari kumpulan paket sumber terbuka yang dikurasi.

Jadi, mengapa seorang arsitek keamanan harus peduli terhadap perbedaan dalam kepemilikan layanan? Tim yang menyediakan operasi keamanan mungkin telah memiliki layanan keamanan yang ditentukan untuk mendukung pengoperasian layanan. Layanan keamanan tersebut dapat menjadi bagian dari platform cloud atau mungkin berada di lingkungan on-premises yang memerlukan integrasi.

Misalnya, tim operasi keamanan internal dapat menggunakan teknologi yang berbeda dari integrator sistem global (GSI) seperti IBM® Consulting. Bagi tim keamanan internal, pesawat kontrol keamanan yang meng-host layanan keamanan mungkin berada di lingkungan on-premises, sedangkan GSI mungkin menggunakan layanan keamanan cloud yang disediakan oleh penyedia layanan cloud lainnya.

Untuk model layanan cloud Software-as-a-Service (SaaS), hanya administrasi keamanan aplikasi yang tersedia bagi konsumen layanan cloud. Keamanan biasanya sudah terpasang pada aplikasi sebagai bagian dari layanan, dengan ruang lingkup terbatas untuk mengontrol konfigurasi keamanan. Dalam hal ini, penyedia SaaS memegang sebagian besar tanggung jawab operasi keamanan.

Tanpa tanggung jawab yang terdokumentasi, mungkin tidak ada pemilik yang ditugaskan untuk merancang, membangun, dan menjalankan komponen keamanan yang menjadi ketergantungan dalam menjalankan beban kerja. Memahami tanggung jawab bersama untuk layanan keamanan memungkinkan arsitektur solusi memenuhi kebutuhan operasional serta menghindari pengerjaan ulang solusi pada tahap selanjutnya dalam proyek.

Layanan keamanan dalam arsitektur hybrid cloud menggunakan berbagai model layanan cloud, platform komputasi, serta penyedia layanan cloud. Layanan ini memerlukan arsitektur pesawat kontrol yang disepakati untuk memberikan manajemen serta pengawasan keamanan dan kepatuhan yang konsisten.

Dengan perusahaan yang memiliki beban kerja pusat data on-premises, pesawat kontrol dapat ditempatkan di pusat data on-premises agar tetap tangguh terhadap kegagalan penyedia layanan cloud. Namun, layanan keamanan on-premises tidak selalu memiliki kemampuan untuk sepenuhnya mengelola platform cloud. Oleh karena itu, rancang arsitektur pesawat kontrol untuk melaporkan status keamanan serta mengidentifikasi risiko di berbagai penyedia layanan cloud yang berbeda.

Dengan organisasi yang terlahir di awan, hosting pesawat kontrol bisa menjadi cloud yang lain, dihosting di point-of-present (POP), atau dihosting di pusat data co-lo. Pesawat kontrol keamanan mungkin perlu tersedia, bahkan jika kegagalan dalam penyedia layanan cloud telah terjadi.

Sebagai arsitek keamanan, penting untuk mendokumentasikan dan menyepakati keputusan arsitektur guna memastikan keselarasan pada arsitektur pesawat kontrol keamanan di seluruh organisasi. Buat keputusan ini sejak awal proyek untuk memastikan solusi selaras dengan strategi organisasi.

Keamanan bukan semata-mata tentang menerapkan kemampuan keamanan, melainkan tentang melindungi data bisnis dan proses dari ancaman. Gunakan pendekatan sistematis untuk melacak aliran data melalui sistem guna mengidentifikasi kontrol keamanan yang melindungi data saat transit, saat tersimpan (at rest), dan saat digunakan.

Arsitek harus mengidentifikasi data sensitif untuk perlindungan dengan memulai dari diagram konteks sistem guna menentukan boundary dan interaksi eksternal yang memulai aliran data melalui sistem. Aliran data internal aplikasi kemudian dianalisis menggunakan diagram untuk memvisualisasikan komponen fungsional, misalnya melalui diagram komponen.

Saat arsitek beralih ke tahap implementasi, mereka memeriksa aliran data antar komponen yang diterapkan pada infrastruktur cloud menggunakan diagram arsitektur cloud. IBM® telah mengembangkan bahasa desain diagram teknis yang memungkinkan desain yang independen dari penyedia layanan cloud.

Untuk mengidentifikasi ancaman terhadap aliran data ini, gunakan pemodelan ancaman baik pada komponen fungsional beban kerja maupun pada infrastruktur yang mendukung beban kerja.

Bersama-sama, teknik dan artefak ini menawarkan pendekatan yang berulang dan konsisten untuk pemikiran arsitektur terkait keamanan dan kepatuhan.

Saat memproses data yang paling sensitif, pertimbangkan lapisan perlindungan tambahan dengan menggunakan komputasi rahasia dan enkripsi homomorfik.

Suatu sistem perlu memenuhi banyak persyaratan kontrol yang berbeda, dan daftarnya bisa menjadi panjang serta sulit untuk dikelola. Alih-alih menangani banyak persyaratan secara individual, fokuslah pada proses, layanan, atau kemampuan yang mengelompokkan persyaratan ke dalam kemampuan pengiriman. Misalnya, manajemen siklus hidup identitas atau deteksi komponen yang tidak sah merupakan contoh kemampuan pengiriman potensial.

Ikuti langkah-langkah berikut untuk mengelola kepatuhan secara lebih efektif:

1. Buat kerangka kerja kepatuhan tunggal dengan ketertelusuran kembali ke sumber asli.
2. Memetakan persyaratan dalam kerangka kerja kepatuhan ke serangkaian kemampuan penyampaian
3. Pastikan kemampuan yang sesuai di semua tahap desain, pembangunan, pengujian, dan operasi.
4. Lanjutkan untuk mematuhi persyaratan dalam produksi.

Arsitek keamanan harus memastikan bahwa kemampuan keamanan terkait dengan Service Level Objectives (SLOs), perjanjian tanggung jawab, dan aspek terkait lainnya.

Sering kali terdapat kebutuhan untuk memastikan bahwa data dari satu klien, lini bisnis, atau lingkungan tidak bocor ke yang lain. Pemisahan perlu dilakukan untuk menjalankan beban kerja dan penyimpanan data. Hal ini dapat sesederhana menggunakan tabel yang berbeda dalam satu basis data atau server fisik yang terpisah.

Hybrid cloud menawarkan berbagai opsi untuk menegakkan pemisahan pemrosesan data. Pemisahan harus dilakukan antara:

1. Beban kerja atau aplikasi - misalnya akuntansi vs sumber daya manusia
2. Lingkungan - misalnya, pengembangan, pengujian dan produksi
3. Klien - misalnya, pelanggan A vs Pelanggan B
4. Lokasi - misalnya, Inggris vs Amerika Serikat

Terdapat berbagai opsi berbeda untuk segregasi dalam lingkungan hybrid cloud, yang menawarkan kemampuan dan jaminan yang berbeda:

1. Akun Enterprise
2. Akun Cloud
3. Grup Sumber Daya
4. Cloud Pribadi Virtual
5. Domain eksekusi - misalnya, kontainer atau gambar server
6. Proyek
7. Domain Manajemen Kunci
8. Perangkat fisik

Kebijakan organisasi harus menentukan jenis pemisahan yang sesuai untuk beban kerja yang memproses data. Misalnya, kebijakan dapat mengharuskan bahwa data pelanggan produksi tidak boleh dihosting di lingkungan non-produksi. Tingkat minimum pemisahan yang diperlukan adalah penggunaan akun cloud yang berbeda, karena di sanalah pengelolaan identitas dan akses dilakukan.

Terkait dengan topik pemisahan data adalah kedaulatan data. Beberapa negara memberlakukan pembatasan terkait lokasi pemrosesan dan akses data. “Posting blog Mengatasi Peraturan dan Mengemudi Inovasi dengan Sovereign Cloud“ memberikan diskusi mengenai hierarki kebutuhan kedaulatan data.

Pemodelan ancaman sering dianggap sebagai teknik untuk mengidentifikasi dan memvalidasi kontrol keamanan terhadap data yang mengalir melalui sistem.

Namun, pemodelan ancaman memiliki tujuan kedua - yaitu untuk mengidentifikasi ancaman yang akan dipantau dalam sistem pemantauan ancaman. Arsitek keamanan harus bekerja untuk menyusun daftar ancaman yang diprioritaskan. Selanjutnya, tentukan contoh penggunaan deteksi ancaman yang diperlukan untuk kemampuan deteksi tersebut. Terapkan dan uji contoh penggunaan deteksi dengan runbook respons insiden agar memungkinkan respons yang efektif terhadap ancaman.

Pastikan ketertelusuran terdokumentasi antara ancaman, contoh penggunaan deteksi ancaman, dan runbook respons insiden untuk menjamin desain dan penyampaian yang lengkap pada proyek.

Dengan pusat data lokal di masa lalu, tim operasi keamanan menyelesaikan aktivitas dalam hitungan hari atau jam dan tidak memerlukan tingkat layanan yang ketat. Dengan otomatisasi menggunakan Infrastructure as Code (IaC), hilangnya layanan keamanan terpusat seperti manajemen rahasia atau sertifikat dapat berdampak langsung pada ketersediaan aplikasi. Oleh karena itu, layanan keamanan memerlukan tingkat layanan dan arsitektur yang dirancang untuk memenuhi persyaratan ketersediaan.

Tentukan untuk setiap kemampuan keamanan atau layanan:

1. Jam layanan
2. Waktu respons insiden, masalah, dan perubahan
3. Keterampilan dan pengalaman staf operasi
4. Prosedur teruji terperinci agar sesuai dengan persyaratan layanan
5. Otomatisasi untuk mencocokkan kebutuhan layanan

Jika tim operasi keamanan internal tidak dapat memenuhi tuntutan beban kerja cloud-native, pertimbangkan apakah penyedia layanan keamanan terkelola sesuai.

Jika dipikirkan, banyak layanan keamanan saat ini membutuhkan ketahanan dan tingkat layanan yang setidaknya setara dengan beban kerja yang mereka dukung.

Cara kerja lama berarti keamanan sering kali menjadi hal yang dipikirkan belakangan, sehingga konfigurasi dan penambalan keamanan menjadi sulit dilakukan karena tidak diterapkan sejak awal siklus pengembangan. Dengan praktik kerja DevOps, standar pembangunan keamanan harus:

1. Termasuk ke dalam lingkungan pengembangan dan pengujian.
2. Konsisten dari pengembangan awal hingga produksi penuh.
3. Terus diuji untuk kepatuhan berkelanjutan.

Proses build harus mencegah penerapan beban kerja yang tidak aman di semua tahap pengembangan dan operasi, sehingga keamanan tidak menjadi hal yang terabaikan atau disengaja.