Keamanan Azure untuk aplikasi asli awan

Petunjuk / Saran

Konten ini adalah kutipan dari eBook, Merancang Aplikasi .NET Cloud Native untuk Azure, tersedia di .NET Docs atau sebagai PDF gratis yang dapat diunduh yang dapat dibaca secara offline.

Unduh PDF

Aplikasi cloud-native dapat lebih mudah dan lebih sulit diamankan daripada aplikasi tradisional. Kelemahannya, Anda perlu mengamankan aplikasi yang lebih kecil dan mendedikasikan lebih banyak energi untuk membangun infrastruktur keamanan. Sifat heterogen dari bahasa dan gaya pemrograman di sebagian besar penyebaran layanan juga berarti Anda perlu lebih memperhatikan buletin keamanan dari berbagai penyedia.

Di sisi lain, layanan yang lebih kecil, masing-masing dengan penyimpanan data mereka sendiri, membatasi cakupan serangan. Jika penyerang mengorbankan satu sistem, mungkin lebih sulit bagi penyerang untuk melakukan lompatan ke sistem lain daripada dalam aplikasi monolitik. Batas proses adalah batas yang kuat. Selain itu, jika cadangan database terekspos, maka kerusakannya lebih terbatas, karena database tersebut hanya berisi subset data dan tidak mungkin berisi data pribadi.

Pemodelan ancaman

Tidak peduli apakah keuntungannya melebihi kekurangan aplikasi cloud-native, pola pikir keamanan holistik yang sama harus diikuti. Pemikiran keamanan dan keamanan harus menjadi bagian dari setiap langkah cerita pengembangan dan operasi. Saat merencanakan aplikasi, ajukan pertanyaan seperti:

• Apa dampak data ini hilang?
• Bagaimana kita dapat membatasi kerusakan dari data buruk yang disuntikkan ke dalam layanan ini?
• Siapa yang harus memiliki akses ke data ini?
• Apakah ada kebijakan audit yang mengatur proses pengembangan dan rilis?

Semua pertanyaan ini adalah bagian dari proses yang disebut pemodelan ancaman. Proses ini mencoba menjawab pertanyaan tentang ancaman apa yang ada pada sistem, seberapa besar kemungkinan ancamannya, dan potensi kerusakan dari mereka.

Setelah daftar ancaman ditetapkan, Anda perlu memutuskan apakah ancaman tersebut layak dimitigasi. Terkadang ancaman sangat tidak mungkin terjadi dan terlalu mahal untuk dipersiapkan sehingga tidak layak menghabiskan energi untuk itu. Misalnya, beberapa aktor tingkat status dapat menyuntikkan perubahan ke dalam desain proses yang digunakan oleh jutaan perangkat. Sekarang, alih-alih menjalankan sepotong kode tertentu di Ring 3, kode itu dijalankan di Ring 0. Proses ini memungkinkan eksploitasi yang dapat melewati hypervisor dan menjalankan kode serangan pada mesin bare metal, memungkinkan serangan pada semua komputer virtual yang berjalan pada perangkat keras tersebut.

Prosesor yang diubah sulit dideteksi tanpa mikroskop dan pengetahuan tingkat lanjut tentang desain silikon prosesor tersebut. Skenario ini tidak mungkin terjadi dan mahal untuk dimitigasi, jadi mungkin tidak ada model ancaman yang merekomendasikan membangun perlindungan eksploitasi untuk itu.

Ancaman yang lebih mungkin, seperti kontrol akses yang rusak yang memungkinkan serangan penambahan (mengganti Id dengan Id=2 di URL) atau injeksi SQL, lebih penting untuk membangun perlindungan. Mitigasi untuk ancaman ini cukup masuk akal untuk membangun dan mencegah lubang keamanan memalukan yang mencemari reputasi perusahaan.

Prinsip hak istimewa paling sedikit

Salah satu ide pendiri dalam keamanan komputer adalah Prinsip Hak Istimewa Paling Rendah (POLP). Ini sebenarnya ide dasar dalam sebagian besar bentuk keamanan baik itu digital maupun fisik. Singkatnya, prinsipnya adalah bahwa setiap pengguna atau proses harus memiliki sejumlah kecil hak yang mungkin untuk menjalankan tugasnya.

Sebagai contoh, anggaplah teller di bank: mengakses brankas adalah aktivitas yang tidak biasa. Jadi, teller rata-rata tidak dapat membuka brankas itu sendiri. Untuk mendapatkan akses, mereka perlu meningkatkan permintaan mereka melalui manajer bank, yang melakukan pemeriksaan keamanan tambahan.

Dalam sistem komputer, contoh yang fantastis adalah hak pengguna yang terhubung ke database. Dalam banyak kasus, ada satu akun pengguna yang digunakan untuk membangun struktur database dan menjalankan aplikasi. Kecuali dalam kasus ekstrem, akun yang menjalankan aplikasi tidak memerlukan kemampuan untuk memperbarui informasi skema. Harus ada beberapa akun yang memberikan tingkat hak istimewa yang berbeda. Aplikasi hanya boleh menggunakan tingkat izin yang memberikan akses baca dan tulis ke data dalam tabel. Perlindungan semacam ini akan menghilangkan serangan yang bertujuan untuk menghilangkan tabel database atau memperkenalkan pemicu berbahaya.

Hampir setiap bagian dari membangun aplikasi cloud-native dapat mendapat manfaat dari mengingat prinsip hak akses minimal. Anda dapat menemukannya saat menyiapkan firewall, grup keamanan jaringan, peran, dan cakupan dalam kontrol akses berbasis Peran (RBAC).

Uji penetrasi

Ketika aplikasi menjadi lebih rumit jumlah vektor serangan meningkat pada tingkat yang mengkhawatirkan. Pemodelan ancaman cacat karena cenderung dijalankan oleh orang yang sama yang membangun sistem. Dengan cara yang sama seperti banyak pengembang mengalami kesulitan membayangkan interaksi pengguna dan kemudian membangun antarmuka pengguna yang tidak dapat digunakan, sebagian besar pengembang mengalami kesulitan melihat setiap vektor serangan. Ada kemungkinan juga bahwa pengembang yang membangun sistem tidak berpengalaman dalam metodologi serangan dan melewatkan sesuatu yang penting.

Pengujian penetrasi atau "pen testing" melibatkan pihak eksternal untuk mencoba menyerang sistem. Penyerang ini mungkin merupakan perusahaan konsultasi eksternal atau pengembang lain dengan pengetahuan keamanan yang baik dari bagian lain dari bisnis. Mereka diberi carte blanche untuk mencoba menumbangkan sistem. Sering kali, mereka akan menemukan lubang keamanan ekstensif yang perlu di-patch. Terkadang vektor serangan akan menjadi sesuatu yang sama sekali tidak terduga seperti mengeksploitasi serangan phishing terhadap CEO.

Azure sendiri terus-menerus mengalami serangan dari tim peretas di dalam Microsoft. Selama bertahun-tahun, mereka telah menjadi yang pertama menemukan lusinan vektor serangan yang berpotensi bencana, menutupnya sebelum mereka dapat dieksploitasi secara eksternal. Semakin menggoda target, semakin besar kemungkinan aktor eksternal akan mencoba mengeksploitasinya, dan ada beberapa target di dunia yang lebih menggoda daripada Azure.

Pemantauan

Jika penyerang mencoba menembus aplikasi, harus ada beberapa peringatan tentang hal itu. Sering kali, serangan dapat dilihat dengan memeriksa log dari layanan. Serangan meninggalkan tanda khas yang dapat dilihat sebelum serangan berhasil. Misalnya, penyerang yang mencoba menebak kata sandi akan membuat banyak permintaan ke sistem login. Pemantauan di sekitar sistem masuk dapat mendeteksi pola aneh yang tidak sejalan dengan pola akses umum. Pemantauan ini dapat diubah menjadi pemberitahuan yang dapat, pada gilirannya, memperingatkan orang operasi untuk mengaktifkan semacam penanggulangan. Sistem pemantauan yang sangat matang bahkan dapat mengambil tindakan berdasarkan penyimpangan ini secara proaktif menambahkan aturan untuk memblokir permintaan atau membatasi respons.

Mengamankan build

Satu tempat di mana keamanan sering diabaikan adalah sekitar proses build. Tidak hanya harus menjalankan pemeriksaan keamanan pada build, seperti memindai kode yang tidak aman atau kredensial yang sudah dicommit, tetapi build tersebut juga harus aman. Jika server build disusupi, maka ia menyediakan jalur yang fantastis untuk memperkenalkan kode sembarang ke dalam produk.

Bayangkan bahwa penyerang ingin mencuri kata sandi orang yang masuk ke aplikasi web. Mereka dapat memperkenalkan langkah build yang memodifikasi kode yang dicek keluar untuk mencerminkan permintaan masuk apa pun ke server lain. Lain kali kode melalui proses build, kode diperbarui tanpa disadari. Pemindaian kerentanan kode sumber tidak akan menangkap kerentanan ini karena berjalan sebelum build. Sama halnya, tidak ada yang akan menemukannya dalam tinjauan kode karena langkah-langkah dalam proses build berada di server build. Kode yang dieksploitasi akan pergi ke produksi di mana ia dapat memanen kata sandi. Mungkin tidak ada log audit dari perubahan proses build, atau setidaknya tidak ada yang memantau audit.

Skenario ini adalah contoh sempurna dari target yang tampaknya bernilai rendah yang dapat digunakan untuk masuk ke dalam sistem. Setelah penyerang melanggar perimeter sistem, mereka dapat mulai bekerja menemukan cara untuk meningkatkan izin mereka ke titik bahwa mereka dapat menyebabkan bahaya nyata di mana saja mereka suka.

Membangun kode aman

.NET Framework sudah menjadi kerangka kerja yang cukup aman. Ini menghindari beberapa jebakan kode yang tidak terkelola, seperti melampaui batas array. Pekerjaan dilakukan secara aktif untuk memperbaiki lubang keamanan saat ditemukan. Bahkan ada program bug bounty yang membayar peneliti untuk menemukan masalah dalam kerangka kerja dan melaporkannya alih-alih mengeksploitasinya.

Ada banyak cara untuk membuat kode .NET lebih aman. Panduan berikut seperti artikel Panduan pengodean aman untuk .NET adalah langkah yang wajar untuk memastikan bahwa kode aman dari bawah ke atas. 10 teratas OWASP adalah panduan tak ternilai lainnya untuk membangun kode aman.

Proses penyusunan adalah tempat yang baik untuk menempatkan alat pemindaian guna mendeteksi masalah dalam kode sumber sebelum mereka masuk ke lingkungan produksi. Sebagian besar setiap proyek memiliki dependensi pada beberapa paket lain. Alat yang dapat memindai paket yang sudah ketinggalan lama akan menangkap masalah dalam build malam hari. Bahkan saat membangun gambar Docker, berguna untuk memeriksa dan memastikan bahwa gambar dasar tidak memiliki kerentanan yang diketahui. Hal lain yang perlu diperiksa adalah bahwa tidak ada yang secara tidak sengaja memeriksa kredensial.

Keamanan bawaan

Azure dirancang untuk menyeimbangkan kegunaan dan keamanan bagi sebagian besar pengguna. Pengguna yang berbeda akan memiliki persyaratan keamanan yang berbeda, sehingga mereka perlu menyempurnakan pendekatan mereka terhadap keamanan cloud. Microsoft menerbitkan banyak informasi keamanan di Pusat Kepercayaan. Sumber daya ini harus menjadi pemberhentian pertama bagi para profesional yang tertarik untuk memahami cara kerja teknologi mitigasi serangan bawaan.

Dalam portal Microsoft Azure, Azure Advisor adalah sistem yang terus memindai lingkungan dan membuat rekomendasi. Beberapa rekomendasi ini dirancang untuk menghemat uang pengguna, tetapi yang lain dirancang untuk mengidentifikasi konfigurasi yang berpotensi tidak aman, seperti memiliki kontainer penyimpanan yang terbuka untuk dunia dan tidak dilindungi oleh Virtual Network.

Infrastruktur jaringan Azure

Di lingkungan penyebaran lokal, banyak energi didedikasikan untuk menyiapkan jaringan. Menyiapkan router, sakelar, dan perangkat sejenisnya adalah pekerjaan yang rumit. Jaringan memungkinkan sumber daya tertentu untuk berbicara dengan sumber daya lain dan mencegah akses dalam beberapa kasus. Aturan jaringan yang sering diterapkan adalah membatasi akses ke lingkungan produksi dari lingkungan pengembangan untuk mencegah kemungkinan terjadinya masalah di mana bagian kode yang setengah dikembangkan berjalan tidak semestinya dan menghapus sejumlah besar data.

Di luar kotak, sebagian besar sumber daya PaaS Azure hanya memiliki penyiapan jaringan yang paling dasar dan permisif. Misalnya, siapa pun di Internet dapat mengakses layanan aplikasi. Instans SQL Server baru biasanya dibatasi, sehingga pihak eksternal tidak dapat mengaksesnya, tetapi rentang alamat IP yang digunakan oleh Azure itu sendiri diizinkan. Jadi, sementara server SQL dilindungi dari ancaman eksternal, penyerang hanya perlu menyiapkan bridgehead Azure dari mana mereka dapat meluncurkan serangan terhadap semua instans SQL di Azure.

Untungnya, sebagian besar sumber daya Azure dapat ditempatkan ke dalam Azure Virtual Network yang memungkinkan kontrol akses halus. Mirip dengan cara jaringan lokal membangun jaringan privat yang dilindungi dari dunia yang lebih luas, jaringan virtual adalah pulau alamat IP privat yang terletak di dalam jaringan Azure.

Gambar 9-1. Jaringan virtual di Azure.

Dengan cara yang sama seperti jaringan lokal memiliki firewall yang mengatur akses ke jaringan, Anda dapat membuat firewall serupa di batas jaringan virtual. Secara default, semua sumber daya pada jaringan virtual masih dapat berbicara dengan Internet. Hanya koneksi masuk saja yang memerlukan beberapa bentuk pengecualian firewall eksplisit.

Dengan jaringan yang ditetapkan, sumber daya internal seperti akun penyimpanan dapat disiapkan untuk hanya memungkinkan akses oleh sumber daya yang juga ada di Virtual Network. Firewall ini memberikan tingkat keamanan ekstra, jika kunci untuk akun penyimpanan tersebut bocor, penyerang tidak akan dapat terhubung ke dalamnya untuk mengeksploitasi kunci yang bocor. Skenario ini adalah contoh lain dari prinsip hak istimewa paling sedikit.

Node dalam kluster Azure Kubernetes dapat berpartisipasi dalam jaringan virtual, mengikuti cara sumber daya yang secara lebih native terintegrasi dengan Azure. Fungsionalitas ini disebut Antarmuka Jaringan Kontainer Azure. Akibatnya, ia mengalokasikan subnet dalam jaringan virtual tempat komputer virtual dan citra kontainer ditempatkan.

Melanjutkan penjelajahan menggambarkan prinsip hak istimewa minimal, tidak setiap sumber daya dalam jaringan virtual perlu berkomunikasi dengan sumber daya lain. Misalnya, dalam aplikasi yang menyediakan API web melalui akun penyimpanan dan database SQL, tidak mungkin database dan akun penyimpanan perlu berbicara satu sama lain. Setiap berbagi data di antara mereka akan melalui aplikasi web. Jadi, kelompok keamanan jaringan (NSG) dapat digunakan untuk menolak lalu lintas antara kedua layanan.

Kebijakan menolak komunikasi antar sumber daya dapat mengganggu untuk diterapkan, terutama berasal dari latar belakang menggunakan Azure tanpa batasan lalu lintas. Di beberapa cloud lain, konsep kelompok keamanan jaringan jauh lebih umum. Misalnya, kebijakan default di AWS adalah bahwa sumber daya tidak dapat berkomunikasi di antara mereka sendiri sampai diaktifkan oleh aturan dalam NSG. Meskipun lebih lambat untuk mengembangkan ini, lingkungan yang lebih ketat menyediakan default yang lebih aman. Memanfaatkan praktik DevOps yang tepat, terutama menggunakan Azure Resource Manager atau Terraform untuk mengelola izin dapat membuat kontrol aturan lebih mudah.

Virtual Network juga dapat berguna saat menyiapkan komunikasi antara sumber daya lokal dan cloud. Jaringan privat virtual dapat digunakan untuk menghubungkan dua jaringan dengan lancar. Pendekatan ini memungkinkan menjalankan jaringan virtual tanpa gateway apa pun untuk skenario di mana semua pengguna berada di situs. Ada sejumlah teknologi yang dapat digunakan untuk membangun jaringan ini. Yang paling sederhana adalah menggunakan VPN situs-ke-situs yang dapat dibuat antara banyak router dan Azure. Lalu lintas dienkripsi dan dikirim melalui terowongan di Internet dengan biaya yang sama per byte seperti lalu lintas lainnya. Untuk skenario di mana lebih banyak bandwidth atau lebih keamanan diinginkan, Azure menawarkan layanan yang disebut Rute Ekspres yang menggunakan sirkuit privat antara jaringan lokal dan Azure. Lebih mahal dan sulit untuk dibentuk tetapi juga lebih aman.

Kontrol akses berbasis peran untuk membatasi akses ke sumber daya Azure

RBAC adalah sistem yang menyediakan identitas untuk aplikasi yang berjalan di Azure. Aplikasi dapat mengakses sumber daya menggunakan identitas ini alih-alih atau selain menggunakan kunci atau kata sandi.

Prinsip Keamanan

Komponen pertama dalam RBAC adalah prinsip keamanan. Perwakilan keamanan dapat berupa pengguna, grup, perwakilan layanan, atau identitas terkelola.

Gambar 9-2. Berbagai jenis prinsip keamanan.

• Pengguna - Setiap pengguna yang memiliki akun di Azure Active Directory adalah pengguna.
• Grup - Kumpulan pengguna dari Azure Active Directory. Sebagai anggota grup, pengguna mengambil peran grup tersebut selain mereka sendiri.
• Perwakilan layanan - Identitas keamanan tempat layanan atau aplikasi berjalan.
• Identitas terkelola - Identitas Azure Active Directory yang dikelola oleh Azure. Identitas terkelola biasanya digunakan saat mengembangkan aplikasi cloud yang mengelola kredensial untuk mengautentikasi ke layanan Azure.

Prinsip keamanan dapat diterapkan ke sebagian besar sumber daya apa pun. Aspek ini berarti bahwa dimungkinkan untuk menetapkan prinsip keamanan ke kontainer yang berjalan dalam Azure Kubernetes, memungkinkannya untuk mengakses rahasia yang disimpan di Key Vault. Azure Function dapat mengambil izin yang memungkinkannya berbicara dengan instans Direktori Aktif untuk memvalidasi JWT untuk pengguna panggilan. Setelah layanan diaktifkan dengan perwakilan layanan, izin mereka dapat dikelola secara terperinci menggunakan peran dan cakupan.

Peranan

Perwakilan keamanan dapat mengambil banyak peran atau, menggunakan analogi yang lebih sartorial, mengenakan banyak topi. Setiap peran menentukan serangkaian izin seperti "Membaca pesan dari titik akhir Azure Service Bus". Set izin efektif dari entitas keamanan adalah kombinasi dari semua izin yang diberikan kepada semua peran yang dimiliki oleh entitas keamanan. Azure memiliki sejumlah besar peran bawaan dan pengguna dapat menentukan peran mereka sendiri.

Gambar 9-3. Definisi peran RBAC.

Bawaan Azure juga merupakan sejumlah peran tingkat tinggi seperti Pemilik, Kontributor, Pembaca, dan Administrator Akun Pengguna. Dengan peran Pemilik, prinsip keamanan dapat mengakses semua sumber daya dan menetapkan izin kepada orang lain. Kontributor memiliki tingkat akses yang sama ke semua sumber daya tetapi tidak dapat menetapkan izin. Pembaca hanya dapat melihat sumber daya Azure yang ada dan Administrator Akun Pengguna dapat mengelola akses ke sumber daya Azure.

Peran bawaan yang lebih terperinci seperti Kontributor Zona DNS memiliki hak terbatas pada satu layanan. Perwakilan keamanan dapat mengambil sejumlah peran.

Ruang Lingkup

Peran dapat diterapkan ke sekumpulan sumber daya terbatas dalam Azure. Misalnya, dengan menerapkan cakupan pada contoh sebelumnya tentang membaca dari antrean Azure Service Bus, Anda dapat mempersempit izin ke satu antrean: "Membaca pesan dari titik akhir Azure Service Bus blah.servicebus.windows.net/queue1"

Cakupannya bisa sesempit sumber daya tunggal atau dapat diterapkan ke seluruh grup sumber daya, langganan, atau bahkan grup manajemen.

Saat menguji apakah perwakilan keamanan memiliki izin tertentu, kombinasi peran dan cakupan diperhitungkan. Kombinasi ini menyediakan mekanisme otorisasi yang kuat.

Menyangkal

Sebelumnya, hanya aturan "izinkan" yang diizinkan untuk RBAC. Perilaku ini membuat beberapa cakupan rumit untuk dibangun. Misalnya, mengizinkan prinsipal keamanan untuk mengakses semua akun penyimpanan kecuali satu, membutuhkan pemberian izin eksplisit ke daftar akun penyimpanan yang berpotensi tak berujung. Setiap kali akun penyimpanan baru dibuat, akun tersebut harus ditambahkan ke daftar akun ini. Ini menambahkan overhead manajemen yang tentu saja tidak diinginkan.

Aturan penolakan lebih diutamakan daripada aturan izinkan. Sekarang, untuk mewakili cakupan "izinkan semua kecuali satu yang spesifik" yang sama, dapat diuraikan sebagai dua aturan: "izinkan semua" dan "tolak satu yang khusus ini". Tolak aturan tidak hanya memudahkan manajemen tetapi memungkinkan sumber daya yang ekstra aman dengan menolak akses ke semua orang.

Memeriksa akses

Seperti yang dapat Anda bayangkan, memiliki sejumlah besar peran dan lingkup dapat membuat penentuan izin efektif dari perwakilan layanan menjadi cukup sulit. Menumpuk aturan penolakan di atas itu hanya berfungsi untuk meningkatkan kompleksitas. Untungnya, ada kalkulator izin yang dapat menunjukkan izin efektif untuk setiap entitas layanan. Biasanya ditemukan di bawah tab IAM di portal, seperti yang ditunjukkan pada Gambar 9-3.

Gambar 9-4. Kalkulator izin untuk layanan aplikasi.

Mengamankan rahasia

Kata sandi dan sertifikat adalah vektor serangan umum untuk penyerang. Perangkat keras pemecahan kata sandi dapat melakukan serangan brute-force dan mencoba menebak miliaran kata sandi per detik. Jadi penting bahwa kata sandi yang digunakan untuk mengakses sumber daya kuat, dengan berbagai karakter. Kata sandi ini adalah jenis kata sandi yang hampir tidak mungkin diingat. Untungnya, kata sandi di Azure sebenarnya tidak perlu diketahui oleh manusia mana pun.

Banyak pakar keamanan menyarankan bahwa menggunakan pengelola kata sandi untuk menyimpan kata sandi Anda sendiri adalah pendekatan terbaik. Meskipun memusatkan kata sandi Anda di satu lokasi, sistem ini juga memungkinkan penggunaan kata sandi yang sangat kompleks dan memastikan bahwa setiap kata sandi unik untuk setiap akun. Sistem yang sama ada dalam Azure: penyimpanan pusat untuk rahasia.

Azure Key Vault

Azure Key Vault menyediakan lokasi terpusat untuk menyimpan kata sandi untuk hal-hal seperti database, kunci API, dan sertifikat. Setelah rahasia dimasukkan ke dalam Vault, tidak pernah ditampilkan kembali dan perintah untuk mengeluarkan dan melihatnya sengaja dibuat rumit. Informasi dalam brankas dilindungi menggunakan enkripsi perangkat lunak atau Modul Keamanan Perangkat Keras tervalidasi FIPS 140-2 Level 2.

Akses ke brankas kunci disediakan melalui RBAC, yang berarti bahwa tidak sembarang pengguna dapat mengakses informasi di brankas. Katakanlah aplikasi web ingin mengakses string koneksi database yang disimpan di Azure Key Vault. Untuk mendapatkan akses, aplikasi perlu berjalan menggunakan prinsipal layanan. Di bawah peran yang diasumsikan ini, mereka dapat membaca rahasia dari brankas. Ada sejumlah pengaturan keamanan berbeda yang dapat membatasi akses lebih lanjut yang dimiliki aplikasi ke vault, sehingga tidak dapat memperbarui rahasia tetapi hanya membacanya.

Akses ke brankas kunci dapat dipantau untuk memastikan bahwa hanya aplikasi yang diharapkan yang mengakses vault. Log dapat diintegrasikan kembali ke Azure Monitor, membuka kunci kemampuan untuk menyiapkan pemberitahuan ketika kondisi tak terduga ditemui.

Kubernetes

Dalam Kubernetes, ada layanan serupa untuk mempertahankan bagian kecil informasi rahasia. Rahasia Kubernetes dapat diatur melalui executable yang khas kubectl .

Membuat rahasia sama sederhananya dengan menemukan versi base64 dari nilai yang akan disimpan:

echo -n 'admin' | base64
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm

Kemudian menambahkannya ke file rahasia bernama secret.yml misalnya yang terlihat mirip dengan contoh berikut:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

Terakhir, file ini dapat dimuat ke Kubernetes dengan menjalankan perintah berikut:

kubectl apply -f ./secret.yaml

Rahasia ini kemudian dapat dipasang ke dalam volume atau diekspos ke proses kontainer melalui variabel lingkungan. Pendekatan Aplikasi dua belas faktor untuk membangun aplikasi menyarankan penggunaan denominator umum terendah untuk mengirimkan pengaturan ke aplikasi. Variabel lingkungan adalah denominator umum terendah, karena didukung tidak peduli sistem operasi atau aplikasi.

Alternatif untuk menggunakan rahasia Kubernetes bawaan adalah dengan mengakses rahasia di Azure Key Vault dari dalam Kubernetes. Cara paling sederhana untuk melakukan ini adalah dengan menetapkan peran RBAC ke kontainer yang ingin memuat rahasia. Aplikasi kemudian dapat menggunakan API Azure Key Vault untuk mengakses rahasia. Namun, pendekatan ini memerlukan modifikasi pada kode dan tidak mengikuti pola penggunaan variabel lingkungan. Sebaliknya, dimungkinkan untuk memasukkan nilai ke dalam kontainer. Pendekatan ini sebenarnya lebih aman daripada menggunakan rahasia Kubernetes secara langsung, karena dapat diakses oleh pengguna pada kluster.

Enkripsi saat transit dan saat tidak aktif

Menjaga keamanan data penting baik di disk maupun transit di antara berbagai layanan yang berbeda. Cara paling efektif untuk menjaga data tidak bocor adalah dengan mengenkripsinya ke dalam format yang tidak dapat dengan mudah dibaca oleh orang lain. Azure mendukung berbagai opsi enkripsi.

Sedang dalam perjalanan

Ada beberapa cara untuk mengenkripsi lalu lintas pada jaringan di Azure. Akses ke layanan Azure biasanya dilakukan melalui koneksi yang menggunakan Keamanan Lapisan Transportasi (TLS). Misalnya, semua koneksi ke API Azure memerlukan koneksi TLS. Sama halnya, koneksi ke titik akhir di penyimpanan Azure hanya dapat dibatasi untuk bekerja melalui koneksi terenkripsi TLS.

TLS adalah protokol yang rumit dan hanya mengetahui bahwa koneksi menggunakan TLS tidak cukup untuk memastikan keamanan. Misalnya, TLS 1.0 tidak aman secara kronis, dan TLS 1.1 tidak jauh lebih baik. Bahkan dalam versi TLS, ada berbagai pengaturan yang dapat membuat koneksi lebih mudah didekripsi. Tindakan terbaik adalah memeriksa dan melihat apakah koneksi server menggunakan protokol up-to-date dan dikonfigurasi dengan baik.

Pemeriksaan ini dapat dilakukan oleh layanan eksternal seperti SSL Labs' SSL Server Test. Uji coba terhadap titik akhir Azure yang khas, dalam hal ini titik akhir bus layanan, menghasilkan skor A yang hampir sempurna.

Bahkan layanan seperti database Azure SQL menggunakan enkripsi TLS untuk menjaga data tetap tersembunyi. Bagian menarik tentang mengenkripsi data saat transit menggunakan TLS adalah bahwa tidak mungkin, bahkan bagi Microsoft, untuk mendengarkan koneksi antara komputer yang menjalankan TLS. Ini harus memberikan kenyamanan untuk perusahaan yang khawatir data mereka mungkin berisiko dari Microsoft itu sendiri atau bahkan aktor dari negara yang memiliki lebih banyak sumber daya dibandingkan dengan penyerang standar.

Gambar 9-5. Laporan SSL Labs memperlihatkan skor A untuk endpoint Azure Service Bus.

Meskipun tingkat enkripsi ini tidak akan cukup untuk semua waktu, itu harus menginspirasi keyakinan bahwa koneksi Azure TLS cukup aman. Azure akan terus mengembangkan standar keamanannya saat enkripsi meningkat. Senang mengetahui bahwa ada seseorang yang mengawasi standar keamanan dan memperbarui Azure saat mereka meningkat.

Saat istirahat

Dalam aplikasi apa pun, ada sejumlah tempat data berada di disk. Kode aplikasi itu sendiri dimuat dari beberapa mekanisme penyimpanan. Sebagian besar aplikasi juga menggunakan beberapa jenis database seperti SQL Server, Cosmos DB, atau bahkan Table Storage yang sangat hemat harga. Semua database ini menggunakan penyimpanan yang sangat terenkripsi untuk memastikan bahwa tidak ada selain aplikasi dengan izin yang tepat yang dapat membaca data Anda. Bahkan operator sistem tidak dapat membaca data yang telah dienkripsi. Jadi pelanggan dapat tetap yakin informasi rahasia mereka tetap rahasia.

Penyimpanan

Yang mendasar dari sebagian besar Azure adalah mesin Azure Storage. Disk komputer virtual dipasang di atas Azure Storage. Azure Kubernetes Service berjalan pada komputer virtual yang, sendiri, dihosting di Azure Storage. Bahkan teknologi tanpa server, seperti Azure Functions Apps dan Azure Container Instances, kehabisan disk yang merupakan bagian dari Azure Storage.

Jika Azure Storage dienkripsi dengan baik, maka azure Storage menyediakan fondasi bagi sebagian besar hal lain untuk juga dienkripsi. Azure Storage dienkripsi dengan AES 256-bit yang mematuhi FIPS 140-2. Ini adalah teknologi enkripsi yang dikenal baik dan telah menjadi subjek pengamatan akademik yang luas selama sekitar 20 tahun terakhir. Saat ini, tidak ada serangan praktis yang diketahui yang akan memungkinkan seseorang tanpa pengetahuan tentang kunci untuk membaca data yang dienkripsi oleh AES.

Secara default, kunci yang digunakan untuk mengenkripsi Azure Storage dikelola oleh Microsoft. Ada perlindungan ekstensif untuk memastikan untuk mencegah akses berbahaya ke kunci ini. Namun, pengguna dengan persyaratan enkripsi tertentu juga dapat menyediakan kunci penyimpanan mereka sendiri yang dikelola di Azure Key Vault. Kunci ini dapat dicabut kapan saja, yang mengakibatkan konten akun Storage yang menggunakannya menjadi tidak dapat diakses.

Komputer virtual menggunakan penyimpanan terenkripsi, tetapi dimungkinkan untuk menyediakan lapisan enkripsi lain dengan menggunakan teknologi seperti BitLocker di Windows atau DM-Crypt di Linux. Teknologi ini berarti bahwa bahkan jika gambar disk bocor dari penyimpanan, akan tetap hampir tidak mungkin untuk membacanya.

Azure SQL

Database yang dihosting di Azure SQL menggunakan teknologi yang disebut Transparent Data Encryption (TDE) untuk memastikan data tetap dienkripsi. Ini diaktifkan secara default pada semua database SQL yang baru dibuat, tetapi harus diaktifkan secara manual untuk database warisan. TDE menjalankan enkripsi real-time dan dekripsi tidak hanya database, tetapi juga cadangan dan log transaksi.

Parameter enkripsi disimpan dalam master database dan, saat startup, dibaca ke dalam memori untuk operasi yang tersisa. Ini berarti bahwa master database harus tetap tidak terenkripsi. Kunci aktual dikelola oleh Microsoft. Namun, pengguna dengan persyaratan keamanan yang tepat dapat memberikan kunci mereka sendiri di Key Vault dengan cara yang sama seperti yang dilakukan untuk Azure Storage. Key Vault menyediakan layanan seperti rotasi dan pencabutan kunci.

Bagian "Transparan" dari TDS berasal dari fakta bahwa tidak ada perubahan klien yang diperlukan untuk menggunakan database terenkripsi. Meskipun pendekatan ini memberikan keamanan yang baik, membocorkan kata sandi database sudah cukup bagi pengguna untuk dapat mendekripsi data. Ada pendekatan lain yang mengenkripsi kolom atau tabel individual dalam database. Always Encrypted memastikan bahwa tidak ada titik data terenkripsi yang muncul dalam teks biasa di dalam database.

Menyiapkan tingkat enkripsi ini mengharuskan menggunakan wizard di SQL Server Management Studio untuk memilih jenis enkripsi dan lokasi penyimpanan kunci terkait di Key Vault.

Gambar 9-6. Memilih kolom dalam tabel yang akan dienkripsi menggunakan Always Encrypted.

Aplikasi klien yang membaca informasi dari kolom terenkripsi ini perlu membuat tunjangan khusus untuk membaca data terenkripsi. String koneksi perlu diperbarui dengan Column Encryption Setting=Enabled dan kredensial klien harus diambil dari Key Vault. Client SQL Server kemudian harus dipersiapkan dengan kunci enkripsi kolom-kolom. Setelah selesai, tindakan yang tersisa menggunakan antarmuka standar ke Klien SQL. Artinya, alat seperti Dapper dan Entity Framework, yang dibangun di atas Klien SQL, akan terus berfungsi tanpa perubahan. Always Encrypted mungkin belum tersedia untuk setiap driver SQL Server pada setiap bahasa.

Kombinasi TDE dan Always Encrypted, yang keduanya dapat digunakan dengan kunci khusus klien, memastikan bahwa bahkan persyaratan enkripsi yang paling tepat pun didukung.

Cosmos DB (layanan basis data dari Microsoft)

Cosmos DB adalah database terbaru yang disediakan oleh Microsoft di Azure. Ini telah dibangun dari bawah ke atas dengan keamanan dan kriptografi dalam pikiran. Enkripsi AES-256bit adalah standar untuk semua database Cosmos DB dan tidak dapat dinonaktifkan. Ditambah dengan persyaratan TLS 1.2 untuk komunikasi, seluruh solusi penyimpanan dienkripsi.

Gambar 9-7. Aliran enkripsi data dalam Cosmos DB.

Meskipun Cosmos DB tidak menyediakan fasilitas untuk memberikan kunci enkripsi pelanggan, tim telah melakukan pekerjaan signifikan untuk memastikan database ini tetap mematuhi standar PCI-DSS meskipun tanpa kunci tersebut. Cosmos DB juga tidak mendukung enkripsi kolom tunggal apa pun yang mirip dengan Always Encrypted Azure SQL.

Menjaga keamanan

Azure memiliki semua alat yang diperlukan untuk merilis produk yang sangat aman. Namun, rantai hanya sekuat tautan terlemahnya. Jika aplikasi yang disebarkan di atas Azure tidak dikembangkan dengan pola pikir keamanan yang tepat dan audit keamanan yang baik, maka aplikasi tersebut menjadi tautan lemah dalam rantai. Ada banyak alat analisis statis yang hebat, pustaka enkripsi, dan praktik keamanan yang dapat digunakan untuk memastikan bahwa perangkat lunak yang diinstal di Azure seaman Azure itu sendiri. Contohnya termasuk alat analisis statis dan pustaka enkripsi.

SebelumnyaBerikutnya