Pertimbangan keamanan untuk beban kerja misi penting di Azure

Keamanan adalah salah satu prinsip desain dasar dan juga area desain kunci yang harus diperlakukan sebagai perhatian kelas satu dalam proses arsitektur misi penting.

Mengingat bahwa fokus utama dari desain misi-kritis adalah memaksimalkan keandalan sehingga aplikasi tetap berkinerja dan tersedia, pertimbangan dan rekomendasi keamanan yang diterapkan dalam area desain ini akan fokus pada mitigasi ancaman dengan kapasitas untuk memengaruhi ketersediaan dan menghambat keandalan keseluruhan. Misalnya, serangan Denial-Of-Service (DDoS) yang berhasil diketahui berdampak besar pada ketersediaan dan performa. Bagaimana aplikasi mengurangi vektor serangan tersebut, seperti SlowLoris akan berdampak pada keandalan keseluruhan. Jadi, aplikasi harus sepenuhnya dilindungi dari ancaman yang dimaksudkan untuk secara langsung atau tidak langsung membahayakan keandalan aplikasi agar benar-benar misi penting di alam.

Penting juga untuk dicatat bahwa sering kali ada trade-off signifikan yang terkait dengan postur keamanan yang diperketat, terutama sehubungan dengan performa, kelincahan operasional, dan dalam beberapa kasus keandalan. Misalnya, dimasukkannya Network Virtual Appliances (NVA) sebaris untuk kemampuan Next-Generation Firewall (NGFW), seperti inspeksi paket mendalam, akan memperkenalkan penalti performa yang signifikan, kompleksitas operasional tambahan, dan risiko keandalan jika skalabilitas dan operasi pemulihan tidak selaras dengan aplikasi. Oleh karena itu penting bahwa komponen dan praktik keamanan tambahan yang dimaksudkan untuk mengurangi vektor ancaman utama juga dirancang untuk mendukung target keandalan aplikasi, yang akan membentuk aspek utama dari rekomendasi dan pertimbangan yang disajikan dalam bagian ini.

Penting

Artikel ini adalah bagian dari seri beban kerja azure Well-Architected misi penting . Jika Anda tidak terbiasa dengan seri ini, kami sarankan Anda memulai dengan apa itu beban kerja misi penting?

Mission-Critical sumber terbuka project

Implementasi referensi adalah bagian dari proyek sumber terbuka yang tersedia di GitHub. Aset kode mengadopsi model Zero Trust untuk menyusun dan memandu desain keamanan dan pendekatan implementasi.

Perataan dengan model Zero Trust

Model Microsoft Zero Trust menyediakan pendekatan proaktif dan terintegrasi untuk menerapkan keamanan di semua lapisan aplikasi. Prinsip panduan Zero Trust berusaha untuk secara eksplisit dan terus memverifikasi setiap transaksi, menegaskan hak istimewa paling sedikit, menggunakan kecerdasan, dan deteksi lanjutan untuk merespons ancaman mendekati real-time. Ini pada akhirnya berpusat pada menghilangkan kepercayaan di dalam dan di luar perimeter aplikasi, memberlakukan verifikasi untuk apa pun yang mencoba terhubung ke sistem.

Mempertimbangkan rancangan

Saat Anda menilai postur keamanan aplikasi, mulailah dengan pertanyaan-pertanyaan ini sebagai dasar untuk setiap pertimbangan.

• Pengujian keamanan berkelanjutan untuk memvalidasi mitigasi kerentanan keamanan utama.

  • Apakah pengujian keamanan dilakukan sebagai bagian dari proses CI/CD otomatis?
  • Jika tidak, seberapa sering pengujian keamanan khusus dilakukan?
  • Apakah hasil pengujian diukur terhadap postur keamanan dan model ancaman yang diinginkan?

• Tingkat keamanan di semua lingkungan yang lebih rendah.

  • Apakah semua lingkungan dalam siklus hidup pengembangan memiliki postur keamanan yang sama dengan lingkungan produksi?

• Kelangsungan autentikasi dan Otorisasi jika terjadi kegagalan.

  • Jika layanan autentikasi atau otorisasi untuk sementara tidak tersedia, apakah aplikasi dapat terus beroperasi?

• Kepatuhan dan remediasi keamanan otomatis.

  • Dapatkah perubahan pada pengaturan keamanan kunci terdeteksi?
  • Apakah respons untuk memulihkan perubahan yang tidak sesuai otomatis?

• Pemindaian rahasia untuk mendeteksi rahasia sebelum kode diterapkan untuk mencegah kebocoran rahasia melalui repositori kode sumber.

  • Apakah autentikasi ke layanan dimungkinkan tanpa memiliki kredensial sebagai bagian dari kode?

• Amankan rantai pasokan perangkat lunak.

  • Apakah mungkin untuk melacak Kerentanan dan Paparan Umum (CVE) dalam dependensi paket yang digunakan?
  • Apakah ada proses otomatis untuk memperbarui dependensi paket?

• Siklus hidup kunci perlindungan data.

  • Dapatkah kunci yang dikelola layanan digunakan untuk perlindungan integritas data?
  • Jika kunci yang dikelola pelanggan diperlukan, bagaimana siklus hidup kunci yang aman dan andal?

• Alat CI/CD harus memerlukan perwakilan layanan Microsoft Entra dengan akses tingkat langganan yang memadai untuk memfasilitasi akses sarana kontrol untuk penyebaran sumber daya Azure ke semua langganan lingkungan yang dipertimbangkan.

  • Ketika sumber daya aplikasi dikunci dalam jaringan privat, apakah ada jalur konektivitas sarana data pribadi sehingga alat CI/CD dapat melakukan penyebaran dan pemeliharaan tingkat aplikasi.
    • Ini memperkenalkan kompleksitas tambahan dan memerlukan urutan dalam proses penyebaran melalui agen build privat yang diperlukan.

Rekomendasi desain

• Gunakan Azure Policy untuk menerapkan konfigurasi keamanan dan keandalan untuk semua layanan, memastikan bahwa setiap penyimpangan diremediasi atau dilarang oleh sarana kontrol pada waktu konfigurasi, membantu mengurangi ancaman yang terkait dengan skenario 'admin berbahaya'.

• Gunakan Microsoft Entra Privileged Identity Management (PIM) dalam langganan produksi untuk mencabut akses sarana kontrol berkelanjutan ke lingkungan produksi. Ini akan secara signifikan mengurangi risiko yang ditimbulkan dari skenario 'admin berbahaya' melalui 'cek dan saldo' tambahan.

• Gunakan Azure Managed Identities untuk semua layanan yang mendukung kemampuan, karena memfasilitasi penghapusan kredensial dari kode aplikasi dan menghapus beban operasional manajemen identitas untuk komunikasi layanan ke layanan.

• Gunakan Microsoft Entra kontrol akses berbasis peran (RBAC) untuk otorisasi sarana data dengan semua layanan yang mendukung kemampuan.

• Gunakan pustaka autentikasi platform identitas Microsoft pihak pertama dalam kode aplikasi untuk berintegrasi dengan Microsoft Entra ID.

• Pertimbangkan penembolokan token aman untuk memungkinkan pengalaman yang terdegradasi tetapi tersedia jika platform identitas yang dipilih, tidak tersedia atau hanya tersedia sebagian untuk otorisasi aplikasi.

  • Jika penyedia tidak dapat mengeluarkan token akses baru, tetapi masih memvalidasi yang ada, aplikasi dan layanan dependen dapat beroperasi tanpa masalah sampai token mereka kedaluwarsa.
  • Penembolokan token biasanya ditangani secara otomatis oleh pustaka autentikasi (seperti MSAL).

• Gunakan Infrastructure-as-Code (IaC) dan alur CI/CD otomatis untuk mendorong pembaruan ke semua komponen aplikasi, termasuk dalam keadaan kegagalan.

  • Pastikan koneksi layanan perkakas CI/CD dijaga sebagai informasi sensitif penting, dan tidak boleh tersedia secara langsung untuk tim layanan apa pun.
  • Terapkan RBAC terperinci ke alur CD produksi untuk mengurangi risiko 'admin berbahaya'.
  • Pertimbangkan penggunaan gerbang persetujuan manual dalam alur penyebaran produksi untuk mengurangi risiko 'admin berbahaya' lebih lanjut dan memberikan jaminan teknis tambahan untuk semua perubahan produksi.
    • Gerbang keamanan tambahan mungkin datang pada trade-off dalam hal kelincahan dan harus dievaluasi dengan hati-hati, dengan pertimbangan yang diberikan tentang bagaimana kelincahan dapat dipertahankan bahkan dengan gerbang manual.

• Tentukan postur keamanan yang sesuai untuk semua lingkungan yang lebih rendah untuk memastikan kerentanan kunci dimitigasi.

  • Jangan menerapkan postur keamanan yang sama dengan produksi, terutama sehubungan dengan penyelundupan data, kecuali persyaratan peraturan menetapkan kebutuhan untuk melakukannya, karena ini akan secara signifikan membahayakan kelincahan pengembang.

• Aktifkan Microsoft Defender untuk Cloud (sebelumnya dikenal sebagai Azure Security Center) untuk semua langganan yang berisi sumber daya untuk beban kerja misi penting.

  • Gunakan Azure Policy untuk menegakkan kepatuhan.
  • Aktifkan Azure Defender untuk semua layanan yang mendukung kemampuan.

• Rangkul DevSecOps dan terapkan pengujian keamanan dalam alur CI/CD.

  • Hasil pengujian harus diukur terhadap postur keamanan yang sesuai untuk menginformasikan persetujuan rilis, baik itu otomatis atau manual.
  • Terapkan pengujian keamanan sebagai bagian dari proses produksi CD untuk setiap rilis.
    • Jika pengujian keamanan setiap rilis membahgi kelincahan operasional, pastikan irama pengujian keamanan yang sesuai diterapkan.

• Aktifkan pemindaian rahasia dan pemindaian dependensi dalam repositori kode sumber.

Pemodelan ancaman

Pemodelan ancaman memberikan pendekatan berbasis risiko untuk desain keamanan, menggunakan potensi ancaman yang diidentifikasi untuk mengembangkan mitigasi keamanan yang sesuai. Ada banyak kemungkinan ancaman dengan berbagai probabilitas kejadian, dan dalam banyak kasus ancaman dapat dirantai dengan cara yang tidak terduga, tidak dapat diprediksi, dan bahkan kacau. Kompleksitas dan ketidakpastian inilah sebabnya mengapa pendekatan keamanan berbasis persyaratan teknologi tradisional sebagian besar tidak cocok untuk aplikasi cloud misi penting. Mengharapkan proses pemodelan ancaman untuk aplikasi misi-kritis menjadi rumit dan pantang menenangkan.

Untuk membantu menavigasi tantangan ini, pendekatan pertahanan mendalam berlapis harus diterapkan untuk menentukan dan menerapkan mitigasi kompensasi untuk ancaman yang dimodelkan, dengan mempertimbangkan lapisan defensif berikut.

1. Platform Azure dengan kemampuan dan kontrol keamanan dasar.
2. Arsitektur aplikasi dan desain keamanan.
3. Fitur keamanan bawaan, diaktifkan, dan dapat disebarkan diterapkan untuk mengamankan sumber daya Azure.
4. Kode aplikasi dan logika keamanan.
5. Proses operasional dan DevSecOps.

Catatan

Saat menyebarkan dalam zona pendaratan Azure, ketahuilah bahwa lapisan mitigasi ancaman tambahan melalui penyediaan kemampuan keamanan terpusat disediakan oleh implementasi zona pendaratan.

Mempertimbangkan rancangan

STRIDE menyediakan kerangka kerja risiko yang ringan untuk mengevaluasi ancaman keamanan di seluruh vektor ancaman utama.

• Identitas Spoofed: Peniruan identitas individu dengan otoritas. Misalnya, penyerang meniru pengguna lain dengan menggunakan -
  • Identitas
  • Autentikasi
• Mengubah Input: Modifikasi input yang dikirim ke aplikasi, atau pelanggaran batas kepercayaan untuk memodifikasi kode aplikasi. Misalnya, penyerang yang menggunakan SQL Injection untuk menghapus data dalam tabel database.
  • Integritas data
  • Validasi
  • Daftar blokir/daftar izin
• Penolakan Tindakan: Kemampuan untuk membantah tindakan yang sudah diambil, dan kemampuan aplikasi untuk mengumpulkan bukti dan mendorong akuntabilitas. Misalnya, penghapusan data penting tanpa kemampuan untuk melacak ke admin berbahaya.
  • Audit/pengelogan
  • Penandatanganan
• Pengungkapan Informasi: Mendapatkan akses ke informasi terbatas. Contohnya adalah penyerang yang mendapatkan akses ke file terbatas.
  • Enkripsi
  • Eksfiltrasi data
  • Serangan man-in-the-middle
• Penolakan Layanan: Gangguan aplikasi berbahaya untuk menurunkan pengalaman pengguna. Misalnya, serangan botnet DDoS seperti Slowloris.
  • DDoS
  • Botnets
  • Kemampuan CDN dan WAF
• Elevasi: Mendapatkan akses aplikasi istimewa melalui eksploitasi otorisasi. Misalnya, penyerang yang memanipulasi string URL untuk mendapatkan akses ke informasi sensitif.
  • Eksekusi kode jarak jauh
  • Authorization
  • Isolasi

Rekomendasi desain

• Alokasikan anggaran teknik dalam setiap sprint untuk mengevaluasi potensi ancaman baru dan menerapkan mitigasi.

• Upaya sadar harus diterapkan untuk memastikan mitigasi keamanan ditangkap dalam kriteria rekayasa umum untuk mendorong konsistensi di semua tim layanan aplikasi.

• Mulailah dengan pemodelan ancaman tingkat layanan dan satukan model dengan mengonsolidasikan model utas pada tingkat aplikasi.

Perlindungan intrusi jaringan

Mencegah akses tidak sah ke aplikasi misi penting dan data yang mencakup sangat penting untuk menjaga ketersediaan dan melindungi integritas data.

Mempertimbangkan rancangan

• Zero Trust mengasumsikan status dilanggar dan memverifikasi setiap permintaan seolah-olah berasal dari jaringan yang tidak terkontrol.

  • Implementasi jaringan zero-trust canggih menggunakan segmentasi mikro dan perimeter mikro masuk/keluar terdistribusi.

• Layanan Azure PaaS biasanya diakses melalui titik akhir publik. Azure menyediakan kemampuan untuk mengamankan titik akhir publik atau bahkan membuatnya sepenuhnya privat.

  • Azure Private Link/Titik Akhir Privat menyediakan akses khusus ke sumber daya Azure PaaS menggunakan alamat IP privat dan konektivitas jaringan privat.
  • Virtual Network Titik Akhir Layanan menyediakan akses tingkat layanan dari subnet yang dipilih ke layanan PaaS yang dipilih.
  • Virtual Network Injection menyediakan penyebaran privat khusus untuk layanan yang didukung, seperti App Service melalui Lingkungan App Service.
    • Lalu lintas bidang manajemen masih mengalir melalui alamat IP publik.

• Untuk layanan yang didukung, Azure Private Link menggunakan Azure Private Endpoints mengatasi risiko penyelundupan data yang terkait dengan Titik Akhir Layanan, seperti admin berbahaya yang menulis data ke sumber daya eksternal.

• Saat membatasi akses jaringan ke layanan Azure PaaS menggunakan Titik Akhir Privat atau Titik Akhir Layanan, saluran jaringan aman akan diperlukan untuk alur penyebaran untuk mengakses sarana kontrol Azure dan bidang data sumber daya Azure untuk menyebarkan dan mengelola aplikasi.

  • Agen build privat yang dihost sendiri yang disebarkan ke jaringan privat karena sumber daya Azure dapat digunakan sebagai proksi untuk menjalankan fungsi CI/CD melalui koneksi privat. Jaringan virtual terpisah harus digunakan untuk agen build.
    • Konektivitas ke agen build privat dari alat CI/CD diperlukan.
  • Pendekatan alternatif adalah memodifikasi aturan firewall untuk sumber daya dengan cepat dalam alur untuk memungkinkan koneksi dari alamat IP publik agen Azure DevOps, dengan firewall kemudian dihapus setelah tugas selesai.
    • Namun, pendekatan ini hanya berlaku untuk subset layanan Azure. Misalnya, ini tidak layak untuk kluster AKS privat.
  • Untuk melakukan tugas pengembang dan administratif pada jump box layanan aplikasi dapat digunakan.

• Penyelesaian tugas administrasi dan pemeliharaan adalah skenario lebih lanjut yang memerlukan konektivitas ke bidang data sumber daya Azure.

• Connections layanan dengan perwakilan layanan Microsoft Entra terkait dapat digunakan dalam Azure DevOps untuk menerapkan RBAC melalui Microsoft Entra ID.

• Tag Layanan dapat diterapkan ke Kelompok Keamanan Jaringan untuk memfasilitasi konektivitas dengan layanan Azure PaaS.

• Kelompok Keamanan Aplikasi tidak mencakup beberapa jaringan virtual.

• Pengambilan paket di Azure Network Watcher dibatasi hingga periode maksimum lima jam.

Rekomendasi desain

• Batasi akses jaringan publik ke minimum mutlak yang diperlukan aplikasi untuk memenuhi tujuan bisnisnya untuk mengurangi permukaan serangan eksternal.

  • Gunakan Azure Private Link untuk membuat titik akhir privat untuk sumber daya Azure yang memerlukan integrasi jaringan yang aman.
  • Gunakan agen build privat yang dihosting untuk alat CI/CD untuk menyebarkan dan mengonfigurasi sumber daya Azure yang dilindungi oleh Azure Private Link.
    • Agen yang dihosting Microsoft tidak akan dapat langsung terhubung ke sumber daya terintegrasi jaringan.

• Saat berhadapan dengan agen build privat, jangan pernah membuka port RDP atau SSH langsung ke internet.

  • Gunakan Azure Bastion untuk menyediakan akses aman ke Azure Virtual Machines dan untuk melakukan tugas administratif di Azure PaaS melalui Internet.

• Gunakan paket perlindungan standar DDoS untuk mengamankan semua alamat IP publik dalam aplikasi.

• Gunakan Azure Front Door dengan kebijakan firewall aplikasi web untuk memberikan dan membantu melindungi aplikasi HTTP/S global yang mencakup beberapa wilayah Azure.

  • Gunakan validasi ID Header untuk mengunci titik akhir aplikasi publik sehingga mereka hanya menerima lalu lintas yang berasal dari instans Azure Front Door.

• Jika persyaratan keamanan jaringan in-line tambahan, seperti inspeksi paket mendalam atau inspeksi TLS, mandat penggunaan Azure Firewall Premium atau Network Virtual Appliance (NVA), pastikan dikonfigurasi untuk ketersediaan tinggi maksimum dan redundansi.

• Jika ada persyaratan penangkapan paket, gunakan paket Network Watcher untuk mengambil meskipun jendela pengambilan terbatas.

• Gunakan Kelompok Keamanan Jaringan dan Kelompok Keamanan Aplikasi untuk lalu lintas aplikasi segmen mikro.

  • Hindari menggunakan appliance keamanan untuk memfilter arus lalu lintas intra-aplikasi.
  • Pertimbangkan penggunaan Azure Policy untuk menerapkan aturan NSG tertentu selalu dikaitkan dengan subnet aplikasi.

• Aktifkan log aliran NSG dan masukkan ke dalam Analisis Lalu Lintas untuk mendapatkan wawasan tentang arus lalu lintas internal dan eksternal.

• Gunakan Azure Private Link/Titik Akhir Privat, jika tersedia, untuk mengamankan akses ke layanan Azure PaaS dalam desain aplikasi. Untuk informasi tentang layanan Azure yang mendukung Private Link, lihat Ketersediaan Azure Private Link.

• Jika Titik Akhir Privat tidak tersedia dan risiko penyelundupan data dapat diterima, gunakan titik akhir layanan Virtual Network untuk mengamankan akses ke layanan Azure PaaS dari dalam jaringan virtual.

  • Jangan aktifkan titik akhir layanan jaringan virtual secara default di semua subnet karena ini akan memperkenalkan saluran penyelundupan data yang signifikan.

• Untuk skenario aplikasi hibrid, akses layanan Azure PaaS dari lokal melalui ExpressRoute dengan peering privat.

Catatan

Saat menyebarkan dalam zona pendaratan Azure, ketahuilah bahwa konektivitas jaringan ke pusat data lokal disediakan oleh implementasi zona pendaratan. Salah satu pendekatannya adalah dengan menggunakan ExpressRoute yang dikonfigurasi dengan peering privat.

Perlindungan integritas data

Enkripsi adalah langkah penting untuk memastikan integritas data dan pada akhirnya merupakan salah satu kemampuan keamanan terpenting yang dapat diterapkan untuk mengurangi berbagai ancaman. Oleh karena itu, bagian ini akan memberikan pertimbangan dan rekomendasi utama yang terkait dengan enkripsi dan manajemen kunci untuk melindungi data tanpa mengorbankan keandalan aplikasi.

Mempertimbangkan rancangan

• Azure Key Vault memiliki batas transaksi untuk kunci dan rahasia, dengan pembatasan diterapkan per vault dalam periode tertentu.

• Azure Key Vault menyediakan batas keamanan karena izin akses untuk kunci, rahasia, dan sertifikat diterapkan pada tingkat brankas.

  • Penetapan kebijakan akses Key Vault memberikan izin secara terpisah untuk kunci, rahasia, atau sertifikat.
    • Izin tingkat objek terperinci ke kunci, rahasia, atau sertifikat tertentu sekarang dimungkinkan.

• Setelah penetapan peran diubah, ada latensi hingga 10 menit (600 detik) agar peran diterapkan.

  • Ada batas 2.000 penetapan peran Azure per langganan.

• Azure Key Vault modul keamanan perangkat keras (HSM) yang mendasar memiliki validasi FIPS 140.

  • Azure Key Vault managed HSM khusus tersedia untuk skenario yang memerlukan kepatuhan FIPS 140-2 Level 3.

• Azure Key Vault menyediakan ketersediaan dan redundansi tinggi untuk membantu menjaga ketersediaan dan mencegah kehilangan data.

• Selama failover wilayah, mungkin perlu beberapa menit agar layanan Key Vault gagal.

  • Selama failover Key Vault akan berada dalam mode baca-saja, sehingga tidak akan mungkin untuk mengubah properti brankas kunci seperti konfigurasi dan pengaturan firewall.

• Jika tautan privat digunakan untuk menyambungkan ke Azure Key Vault, mungkin perlu waktu hingga 20 menit agar koneksi dibuat kembali selama failover regional.

• Cadangan membuat rekam jepret point-in-time dari rahasia, kunci, atau sertifikat, sebagai blob terenkripsi yang tidak dapat didekripsi di luar Azure. Untuk mendapatkan data yang dapat digunakan dari blob, data tersebut harus dipulihkan ke dalam Key Vault dalam langganan Azure dan geografi Azure yang sama.

  • Rahasia dapat diperpanjang selama pencadangan, menyebabkan ketidakcocokan.

• Dengan kunci yang dikelola layanan, Azure akan melakukan fungsi manajemen kunci, seperti rotasi, sehingga mengurangi cakupan operasi aplikasi.

• Kontrol peraturan dapat menetapkan penggunaan kunci yang dikelola pelanggan untuk fungsionalitas enkripsi layanan.

• Saat lalu lintas berpindah antar pusat data Azure, enkripsi lapisan tautan data MACsec digunakan pada perangkat keras jaringan yang mendasar untuk mengamankan data dalam transit di luar batas fisik yang tidak dikendalikan oleh Microsoft atau atas nama Microsoft.

Rekomendasi desain

• Gunakan kunci yang dikelola layanan untuk perlindungan data jika memungkinkan, menghapus kebutuhan untuk mengelola kunci enkripsi dan menangani tugas operasional seperti rotasi kunci.

  • Hanya gunakan kunci yang dikelola pelanggan ketika ada persyaratan peraturan yang jelas untuk melakukannya.

• Gunakan Azure Key Vault sebagai repositori aman untuk semua rahasia, sertifikat, dan kunci jika mekanisme enkripsi tambahan atau kunci yang dikelola pelanggan perlu dipertimbangkan.

  • Sediakan Azure Key Vault dengan kebijakan penghapusan sementara dan penghapusan menyeluruh yang diaktifkan untuk memungkinkan perlindungan penyimpanan untuk objek yang dihapus.
  • Gunakan Azure Key Vault SKU yang didukung HSM untuk lingkungan produksi aplikasi.

• Sebarkan instans Azure Key Vault terpisah dalam setiap stempel penyebaran regional, memberikan isolasi kesalahan dan manfaat performa melalui pelokalan, serta menavigasi batas skala yang diberlakukan oleh satu instans Key Vault.

  • Gunakan instans azure Key Vault khusus untuk sumber daya global aplikasi.

• Ikuti model hak istimewa paling sedikit dengan membatasi otorisasi untuk menghapus rahasia, kunci, dan sertifikat secara permanen ke peran Microsoft Entra kustom khusus.

• Pastikan kunci enkripsi, dan sertifikat yang disimpan dalam Key Vault dicadangkan, menyediakan salinan offline dalam peristiwa yang tidak mungkin Key Vault menjadi tidak tersedia.

• Gunakan sertifikat Key Vault untuk mengelola pengadaan dan penandatanganan sertifikat.

• Buat proses otomatis untuk rotasi kunci dan sertifikat.

  • Mengotomatiskan manajemen sertifikat dan proses pembaruan dengan otoritas sertifikat publik untuk memudahkan administrasi.
    • Atur pemberitahuan dan pemberitahuan, untuk melengkapi perpanjangan sertifikat otomatis.

• Pantau penggunaan kunci, sertifikat, dan rahasia.

  • Tentukan pemberitahuan untuk penggunaan tak terduga dalam Azure Monitor.

Tata kelola yang didorong kebijakan

Konvensi keamanan pada akhirnya hanya efektif jika secara konsisten dan holistik diberlakukan di semua layanan dan tim aplikasi. Azure Policy menyediakan kerangka kerja untuk menegakkan garis besar keamanan dan keandalan, memastikan kepatuhan berkelanjutan dengan kriteria rekayasa umum untuk aplikasi yang sangat penting. Lebih khusus lagi, Azure Policy membentuk bagian penting dari sarana kontrol Azure Resource Manager (ARM), melengkapi RBAC dengan membatasi tindakan apa yang dapat dilakukan pengguna yang berwenang, dan dapat digunakan untuk menegakkan konvensi keamanan dan keandalan penting di seluruh layanan platform yang digunakan.

Oleh karena itu, bagian ini akan mengeksplorasi pertimbangan dan rekomendasi utama seputar penggunaan tata kelola yang didorong Azure Policy untuk aplikasi misi penting, memastikan konvensi keamanan dan keandalan terus diberlakukan.

Mempertimbangkan rancangan

• Azure Policy menyediakan mekanisme untuk mendorong kepatuhan dengan memberlakukan konvensi keamanan dan keandalan, seperti penggunaan Titik Akhir Privat atau penggunaan Zona Ketersediaan.

Catatan

Saat menyebarkan dalam zona pendaratan Azure, ketahuilah bahwa penegakan penetapan kebijakan garis besar terpusat kemungkinan akan diterapkan dalam implementasi untuk grup manajemen zona pendaratan dan langganan.

• Azure Policy dapat digunakan untuk mendorong aktivitas manajemen otomatis, seperti provisi dan konfigurasi.

  • Pendaftaran Penyedia Sumber Daya.
  • Validasi dan persetujuan konfigurasi sumber daya Azure individual.

• Azure Policy cakupan penugasan menentukan cakupan dan lokasi definisi Azure Policy menginformasikan penggunaan kembali kebijakan kustom.

• Azure Policy memiliki beberapa batasan, seperti jumlah definisi pada cakupan tertentu.

• Diperlukan waktu beberapa menit agar eksekusi kebijakan Deploy If Not Exist (DINE) terjadi.

• Azure Policy memberikan input penting untuk pelaporan kepatuhan dan audit keamanan.

Rekomendasi desain

• Memetakan persyaratan peraturan dan kepatuhan untuk Azure Policy definisi.

  • Misalnya, jika ada persyaratan residensi data, kebijakan harus diterapkan untuk membatasi wilayah penyebaran yang tersedia.

• Tentukan kriteria rekayasa umum untuk menangkap definisi konfigurasi yang aman dan andal untuk semua layanan Azure yang digunakan, memastikan kriteria ini dipetakan ke Azure Policy penugasan untuk menegakkan kepatuhan.

  • Misalnya, terapkan Azure Policy untuk memberlakukan penggunaan Zona Ketersediaan untuk semua layanan yang relevan, memastikan konfigurasi penyebaran intra-wilayah yang andal.

Implementasi referensi Mission Critical berisi berbagai kebijakan sentris keamanan dan keandalan untuk menentukan dan menerapkan kriteria rekayasa umum sampel.

• Pantau penyimpangan konfigurasi layanan, relatif terhadap kriteria rekayasa umum, menggunakan Azure Policy.

Untuk skenario misi penting dengan beberapa langganan produksi di bawah grup manajemen khusus, prioritaskan penugasan di cakupan grup manajemen.

• Gunakan kebijakan bawaan jika memungkinkan untuk meminimalkan overhead operasional untuk mempertahankan definisi kebijakan kustom.

• Jika definisi kebijakan kustom diperlukan, pastikan definisi disebarkan pada cakupan grup manajemen yang sesuai untuk memungkinkan penggunaan kembali di seluruh langganan lingkungan yang dicakup untuk ini memungkinkan penggunaan kembali kebijakan di seluruh lingkungan produksi dan yang lebih rendah.

  • Saat menyelaraskan peta strategi aplikasi dengan peta strategi Azure, gunakan sumber daya Microsoft yang tersedia untuk mengeksplorasi apakah definisi kustom penting dapat dimasukkan sebagai definisi bawaan.

Catatan

Saat menyebarkan dalam zona pendaratan Azure, pertimbangkan untuk menyebarkan Definisi Azure Policy kustom dalam cakupan grup manajemen akar perusahaan perantara untuk memungkinkan penggunaan kembali di semua aplikasi dalam estate Azure yang lebih luas. Dalam lingkungan zona pendaratan, kebijakan keamanan terpusat tertentu akan diterapkan secara default dalam cakupan grup manajemen yang lebih tinggi untuk menegakkan kepatuhan keamanan di seluruh kawasan Azure. Misalnya, kebijakan Azure harus diterapkan untuk menyebarkan konfigurasi perangkat lunak secara otomatis melalui ekstensi VM dan menerapkan konfigurasi VM garis besar yang sesuai.

• Gunakan Azure Policy untuk menerapkan skema pemberian tag yang konsisten di seluruh aplikasi.
  • Identifikasi tag Azure yang diperlukan dan gunakan mode kebijakan tambahan untuk menerapkan penggunaan.

Jika aplikasi berlangganan Dukungan microsoft Mission-Critical, pastikan bahwa skema pemberian tag yang diterapkan memberikan konteks yang bermakna untuk memperkaya pengalaman dukungan dengan pemahaman aplikasi yang mendalam.

• Ekspor log aktivitas Microsoft Entra ke Ruang Kerja Analitik Log global yang digunakan oleh aplikasi.
  • Pastikan log aktivitas Azure diarsipkan dalam Akun Penyimpanan global bersama dengan data operasional untuk retensi jangka panjang.

Di zona pendaratan Azure, log aktivitas Microsoft Entra juga akan diserap ke ruang kerja Analitik Log platform terpusat. Ini perlu dievaluasi dalam hal ini jika Microsoft Entra ID masih diperlukan di ruang kerja Analitik Log global.

• Integrasikan informasi keamanan dan manajemen peristiwa dengan Microsoft Defender for Cloud (sebelumnya dikenal sebagai Azure Security Center).

Pertimbangan spesifik IaaS saat menggunakan Virtual Machines

Dalam skenario di mana penggunaan iaaS Virtual Machines diperlukan, beberapa spesifik harus dipertimbangkan.

Mempertimbangkan rancangan

• Gambar tidak diperbarui secara otomatis setelah disebarkan.
• Updates tidak diinstal secara otomatis untuk menjalankan VM.
• Gambar dan VM individual biasanya tidak diperkeras secara langsung.

Rekomendasi desain

• Jangan izinkan akses langsung melalui Internet publik Virtual Machines dengan menyediakan akses ke SSH, RDP, atau protokol lainnya. Selalu gunakan Azure Bastion dan jumpbox dengan akses terbatas ke sekelompok kecil pengguna.
• Batasi konektivitas internet langsung dengan menggunakan Kelompok Keamanan Jaringan, (Azure) Firewall atau Application Gateway (Tingkat 7) untuk memfilter dan membatasi lalu lintas keluar.
• Untuk aplikasi multi-tingkat, pertimbangkan untuk menggunakan subnet yang berbeda dan gunakan Kelompok Keamanan Jaringan untuk membatasi akses di antaranya.
• Prioritaskan penggunaan autentikasi Kunci Umum, jika memungkinkan. Simpan rahasia di tempat yang aman seperti Azure Key Vault.
• Lindungi VM dengan menggunakan autentikasi dan kontrol akses.
• Terapkan praktik keamanan yang sama seperti yang dijelaskan untuk skenario aplikasi yang sangat penting.

Ikuti dan terapkan praktik keamanan untuk skenario aplikasi misi penting seperti yang dijelaskan di atas, jika berlaku, serta praktik terbaik Keamanan untuk beban kerja IaaS di Azure.

Langkah selanjutnya

Tinjau praktik terbaik untuk prosedur operasional untuk skenario aplikasi yang sangat penting.

Prosedur operasional