Bagikan melalui


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-kritis.

Mengingat bahwa fokus utama dari desain misi-penting adalah memaksimalkan keandalan sehingga aplikasi tetap berkinerja dan tersedia, pertimbangan keamanan dan rekomendasi 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 memengaruhi keandalan keseluruhan. Jadi, aplikasi harus sepenuhnya dilindungi dari ancaman yang dimaksudkan untuk secara langsung atau tidak langsung mengkompromikan keandalan aplikasi agar benar-benar sangat krusial untuk misi.

Penting juga untuk dicatat bahwa sering ada trade-off yang signifikan yang terkait dengan postur keamanan yang diperketat, terutama sehubungan dengan performa, kelincahan operasional, dan dalam beberapa kasus keandalan. Misalnya, dimasukkannya Peralatan Virtual Jaringan sebaris (NVA) 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 Azure Well-Architected seri beban kerja misi penting. Jika Anda tidak terbiasa dengan seri ini, kami sarankan Anda memulai dengan apa itu beban kerja misi penting?

Logo GitHub Mission-Critical proyek sumber terbuka

Keselarasan 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 terus menerus dan eksplisit memverifikasi setiap transaksi, menetapkan hak akses minimum, menggunakan kecerdasan, dan deteksi lanjutan untuk merespons ancaman dalam waktu hampir real-time. Ini pada akhirnya berpusat pada menghilangkan kepercayaan di dalam dan di luar perimeter aplikasi, menegakkan verifikasi untuk apa pun yang mencoba terhubung ke sistem.

Pertimbangan desain

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 waktu tidak tersedia, apakah aplikasi akan 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 menambahkan kompleksitas tambahan dan memerlukan tahapan pada proses penyebaran melalui agen build privat yang diperlukan.

Rekomendasi desain

  • Gunakan Azure Policy untuk menerapkan konfigurasi keamanan dan keandalan untuk semua layanan, memastikan bahwa penyimpangan apa pun 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 'pemeriksaan dan penyeimbangan' tambahan.

  • Gunakan Identitas Terkelola Azure 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 kontrol akses berbasis peran Microsoft Entra (RBAC) untuk otorisasi pada ranah data dengan semua layanan yang mendukung kemampuan tersebut.

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

  • Pertimbangkan caching token yang aman untuk memungkinkan pengalaman yang menurun tetapi tetap tersedia jika platform identitas yang dipilih tidak tersedia atau hanya tersedia sebagian untuk pemberian 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 alat CI/CD dilindungi sebagai informasi sensitif penting, dan tidak boleh tersedia secara langsung untuk tim layanan apa pun.
    • Terapkan RBAC tingkat tinggi ke jalur produksi CD 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 dapat menghadirkan kompromi terkait kelincahan dan harus dievaluasi dengan hati-hati, dengan mempertimbangkan bagaimana kelincahan dapat dipertahankan bahkan dengan gerbang manual.
  • Tentukan postur keamanan yang sesuai untuk semua lingkungan yang lebih rendah untuk memastikan kerentanan utama 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 Pertahanan Microsoft 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 mengancam kelincahan operasional, pastikan pengujian keamanan dengan irama yang tepat 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 tingkat kemungkinan terjadinya, dan sering kali ancaman dapat saling berkaitan 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-kritis. Perkirakan proses pemodelan ancaman untuk aplikasi yang sangat penting akan menjadi kompleks dan ketat.

Untuk membantu menavigasi tantangan ini, pendekatan pertahanan mendalam berlapis harus diterapkan untuk menentukan dan menerapkan kompensasi mitigasi untuk ancaman yang dimodelkan, mengingat 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.

Nota

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

Pertimbangan desain

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

  • Identitas Palsu: Peniruan individu yang memiliki kewenangan. Misalnya, penyerang berpura-pura menjadi pengguna lain dengan menggunakan -
    • Identitas
    • Otentikasi
  • Input Perusakan: Modifikasi input yang dikirim ke aplikasi, atau pelanggaran batas kepercayaan untuk memodifikasi kode aplikasi. Misalnya, penyerang yang menggunakan Injeksi SQL 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
    • Penyelundupan data
    • Serangan man-in-the-middle
  • Penolakan Layanan: Gangguan aplikasi berbahaya untuk menurunkan pengalaman pengguna. Misalnya, serangan botnet DDoS seperti Slowloris.
    • DDoS
    • Botnet
    • Kemampuan CDN dan WAF
  • Elevasi Hak Istimewa: Mendapatkan akses aplikasi istimewa melalui eksploitasi otorisasi. Misalnya, penyerang yang memanipulasi string URL untuk mendapatkan akses ke informasi sensitif.
    • Eksekusi kode jarak jauh
    • Otorisasi
    • Isolasi

Rekomendasi desain

  • Alokasikan anggaran rekayasa 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 disertakan sangat penting untuk menjaga ketersediaan dan melindungi integritas data.

Pertimbangan desain

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

    • Implementasi jaringan tanpa kepercayaan lanjutan 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/Private Endpoints menyediakan akses khusus ke sumber daya Azure PaaS menggunakan alamat IP privat dan konektivitas jaringan privat.
    • Titik Akhir Layanan Virtual Network menyediakan akses tingkat layanan dari subnet yang dipilih ke layanan PaaS yang dipilih.
    • Injeksi Jaringan Virtual menyediakan penyebaran privat yang telah didedikasikan untuk layanan yang didukung, seperti App Service melalui lingkungan App Service khusus.
      • Lalu lintas lapisan manajemen terus 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 yang aman akan diperlukan agar alur penyebaran 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 penyusunan.
      • Diperlukan konektivitas dari alat CI/CD ke agen build privat.
    • Pendekatan alternatif adalah dengan memodifikasi aturan firewall untuk sumber daya secara langsung dalam alur kerja untuk memungkinkan koneksi dari alamat IP publik agen Azure DevOps, dengan firewall kemudian dihapus begitu tugas selesai.
      • Namun, pendekatan ini hanya berlaku untuk subset layanan Azure. Misalnya, ini tidak dapat dilakukan untuk kluster AKS privat.
    • Untuk melakukan tugas pengembangan dan administratif, jump box layanan aplikasi dapat digunakan.
  • Penyelesaian tugas administrasi dan pemeliharaan adalah skenario lebih lanjut yang memerlukan konektivitas ke bidang data sumber daya Azure.

  • Koneksi Layanan dengan perwakilan layanan Microsoft Entra yang sesuai dapat digunakan dalam Azure DevOps untuk menerapkan RBAC melalui ID Microsoft Entra.

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

  • Kelompok Keamanan Aplikasi tidak meluas ke berbagai jaringan virtual.

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

Rekomendasi desain

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

  • 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 pengambilan 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 perangkat keamanan untuk memfilter lalu lintas antar-aplikasi.
    • Pertimbangkan penggunaan Azure Policy untuk menerapkan aturan NSG tertentu selalu dikaitkan dengan subnet aplikasi.
  • Aktifkan log alur NSG dan masukkan ke Analitik Lalu Lintas untuk mendapatkan wawasan tentang arus lalu lintas internal dan eksternal.

  • Gunakan Azure Private Link/Private Endpoints, 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 Jaringan Virtual 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 eksfiltrasi data yang signifikan.
  • Untuk skenario aplikasi hibrid, akses layanan Azure PaaS dari lokal melalui ExpressRoute dengan peering privat.

Nota

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.

Pertimbangan desain

  • 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.

    • Penugasan kebijakan akses Key Vault memberikan izin dalam bentuk terpisah untuk kunci, rahasia, atau sertifikat.
      • Izin secara rinci di tingkat objek untuk kunci, rahasia, atau sertifikat tertentu sekarang telah tersedia.
  • Setelah penetapan peran diubah, diperlukan waktu latensi hingga 10 menit (600 detik) sebelum peran diterapkan.

    • Terdapat batas 2.000 penugasan peran Azure per langganan.
  • Modul keamanan perangkat keras (HSM) yang mendasar Azure Key Vault memiliki validasi FIPS 140.

  • 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 cuplikan titik waktu dari rahasia, kunci, atau sertifikat, sebagai blob terenkripsi yang tidak dapat didekripsi di luar Azure. Untuk mendapatkan data yang dapat digunakan dari blob, data harus dipulihkan ke Key Vault dalam langganan Azure dan geografi Azure yang sama.

    • Rahasia mungkin diperbarui 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 dikontrol 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 saat 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.

    • Provisikan Azure Key Vault dengan kebijakan penghapusan sementara dan penghapusan menyeluruh yang diaktifkan untuk memungkinkan perlindungan retensi untuk objek yang dihapus.
    • Gunakan SKU Azure Key Vault yang didukung HSM untuk lingkungan produksi aplikasi.
  • Sebarkan instans Azure Key Vault terpisah pada setiap stempel penyebaran regional, memberikan isolasi gangguan dan manfaat kinerja melalui pelokalan, serta mengatasi 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 jika terjadi kemungkinan kecil, tetapi 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 perpanjangan dengan otoritas sertifikat publik untuk memudahkan administrasi.
      • Atur peringatan dan pemberitahuan untuk melengkapi perpanjangan sertifikat otomatis.
  • Pantau kunci, sertifikat, dan penggunaan rahasia.

    • Tentukan pemberitahuan untuk penggunaan tak terduga dalam Azure Monitor.

Tata kelola berbasis kebijakan

Konvensi keamanan pada akhirnya hanya efektif jika diberlakukan secara konsisten dan holistik 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 utama 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 vital 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.

Pertimbangan desain

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

Nota

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.
  • Cakupan penetapan Azure Policy 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 menyediakan input penting untuk pelaporan kepatuhan dan audit keamanan.

Rekomendasi desain

  • Memetakan persyaratan peraturan dan kepatuhan ke definisi Azure Policy.

    • 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 penetapan Azure Policy 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 untuk Misi Kritis berisi berbagai kebijakan yang berpusat pada 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 tersebut diterapkan pada cakupan grup manajemen yang sesuai agar dapat digunakan kembali di seluruh langganan lingkungan yang dicakup, memungkinkan penggunaan kembali kebijakan di seluruh lingkungan produksi dan lingkungan dengan tingkat yang lebih rendah.

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

Nota

Saat menyebarkan dalam zona landasan Azure, pertimbangkan penerapan Definisi Kebijakan Azure kustom dalam cakupan grup manajemen perusahaan tingkat menengah untuk mengaktifkan penggunaan kembali di semua aplikasi dalam lingkungan Azure yang lebih luas. Dalam lingkungan zona pendaratan, kebijakan keamanan terpusat tertentu akan diterapkan secara default dalam cakupan grup manajemen yang lebih tinggi untuk memberlakukan 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 memberlakukan 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 Azure landing zone, log aktivitas Microsoft Entra juga akan dimasukkan ke dalam ruang kerja Log Analytics di platform terpusat. Perlu dievaluasi apakah ID Entra Microsoft masih diperlukan di ruang kerja Analitik Log global dalam kasus ini.

  • 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.

Pertimbangan desain

  • Gambar tidak diperbarui secara otomatis setelah disebarkan.
  • Pembaruan 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 ke 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 misi-kritis.