praktik terbaik Azure Enklave

Artikel ini menjelaskan konsep utama dan praktik terbaik untuk Azure Enklave.

Azure Enklave mempercepat dan menyederhanakan penyebaran dan pengelolaan lingkungan cloud yang aman, terisolasi, dan sesuai. Lingkungan ini dirancang untuk menangani misi dan beban kerja yang paling sensitif di lingkungan komersial maupun lingkungan yang terisolasi.

Membangun dan menjalankan beban kerja dengan sukses di Azure Enclave memerlukan pemahaman dan implementasi beberapa konsep utama, termasuk:

Grup produk, tim teknik, dan tim lapangan Enclave Azure mengembangkan praktik terbaik dan artikel konseptual berikut. Artikel ini dibuat untuk membantu komunitas dan pemilik enklave dan pengembang lebih memahami konsep penting dan menerapkan fitur yang sesuai.

Pengaturan Azure

Baca langkah-langkah penyiapan ini untuk menentukan apakah langkah-langkah konfigurasi ini sesuai dengan kasus penggunaan enklave Azure Anda.

Konfigurasikan grup sumber daya Network Watcher

Untuk menghindari potensi masalah dengan pembuatan log alur jaringan virtual, siapkan NetworkWatcherRG grup sumber daya secara manual terlebih dahulu dan tetapkan peran aplikasi Mission Enclave pada grup sumber daya tersebutOwner, atau verifikasi bahwa penyiapan dan penetapan peran terjadi secara otomatis sebelum membuat enklave pertama Anda dalam langganan.

Untuk mengurangi masalah potensial ini, untuk setiap langganan, buat grup sumber daya NetworkWatcher secara manual yang disebut NetworkWatcherRG dalam langganan baru, lalu berikan Mission Enclave Aplikasi Owner Enklave Azure di NetworkWatcherRG:

  1. NetworkWatcherRG Pilih grup sumber daya, pilih Access control (IAM), lalu pilih Add dan Add role assignment.

Cuplikan layar memperlihatkan grup sumber daya tambahkan pilihan peran di portal.

  1. Pilih Privileged administrator roles, pilih owner, lalu pilih Next.

Cuplikan layar memperlihatkan tampilan tambahkan pemilihan peran pemilik di portal.

  1. Pilih Select members, ketik Mission Enclave di pencarian dan pilih aplikasi Mission Enclave, pilih Select, lalu Next.

Cuplikan layar memperlihatkan cara memilih aplikasi Mission Enclave di portal.

  1. Jika langganan Anda memerlukan kondisi, pilih Allow user to assign all roles except privileged administrator roles Owner, UAA, RBAC (Recommended), lalu pilih Review + assign.

Cuplikan layar memperlihatkan tampilan tambahkan kondisi jika langganan Anda memerlukannya.

  1. Setelah pembaruan selesai, Anda dapat mulai menyebarkan sumber daya enklave Azure.

Saat komunitas atau enklave dibuat, Azure Enklave mencoba langkah-langkah berikut:

  1. Periksa apakah NetworkWatcherRG ada. Jika tidak, coba buat grup sumber daya tersebut.
  2. Periksa apakah Mission Enclave Aplikasi memiliki penugasan permanen Owner pada NetworkWatcherRG. Jika tidak, coba tetapkan Mission Enclave Aplikasi sebagai penugasan permanen Owner pada NetworkWatcherRG. Bahkan jika ada izin yang diwariskan Owner , pembuatan penugasan permanen Owner akan dicoba.
  3. Jika ada langkah yang gagal, penyebaran enklave mungkin gagal saat mencoba membuat log alur lalu lintas jaringan virtual.

Pola desain jaringan dan organisasi untuk Azure Enclave

Sistem Multi-penyewa

Desain jaringan

Azure Enclave menyatukan kemampuan dan fleksibilitas beberapa produk jaringan Azure dalam antarmuka pengguna yang disederhanakan termasuk:

  • Azure Virtual WAN
  • Azure Firewall
  • Microsoft Azure Virtual Network
  • Kelompok Keamanan Jaringan

Azure Enclave membuat rekomendasi keseluruhan berikut:

  • Komunitas harus disebarkan ketika Anda memiliki persyaratan jaringan untuk menyediakan Azure Firewall, yang merupakan platform keamanan firewall cerdas Azure Platform-as-a-Service.
  • Komunitas harus diterapkan ketika Anda memiliki persyaratan terkait sensitivitas organisasi atau data untuk memisahkan satu Virtual WAN hub-and-spoke dari Virtual WAN hub-and-spoke lainnya.
  • Komunitas harus disebarkan ketika Anda memiliki persyaratan jaringan untuk mendukung sistem yang mencakup beberapa wilayah Azure, di mana setiap wilayah memerlukan Azure Firewall sendiri. Pelajari selengkapnya tentang kasus penggunaan multi-hub Azure Firewall.
  • Communities harus diterapkan saat Anda memiliki kebutuhan jaringan untuk mendukung sejumlah besar sistem pada jaringan area luas terdistribusi dengan topologi hub-and-spoke. Pelajari selengkapnya tentang Azure Virtual WAN.
  • Enklave harus disebarkan ketika Anda memiliki persyaratan jaringan untuk menyebarkan beban kerja serupa sebagai bagian dari jaringan privat yang sama.
  • Enklave harus disebarkan ketika Anda memiliki persyaratan beban kerja yang membutuhkan jaringan virtual dan berada dalam Virtual WAN yang sama dengan komunitas yang ada.

Pertimbangan desain jaringan komunitas

Anda harus mengikuti, sedapat mungkin, dokumentasi praktik terbaik layanan Azure yang mendasar saat merencanakan jaringan komunitas Anda. Termasuk praktik terbaik ini:

Pertimbangan desain jaringan Enklave

Anda harus mengikuti, sedapat mungkin, dokumentasi praktik terbaik layanan Azure yang mendasar saat merencanakan jaringan enklave Anda. Termasuk praktik terbaik ini:

Pelajari selengkapnya tentang praktik terbaik jaringan Azure secara keseluruhan.

Penyebaran beban kerja

  • Beban kerja terhubung ke grup sumber daya terkelola di mana kontributor enklave dapat menerapkan sumber daya Azure.
  • Secara default, semua beban kerja enklave Azure diatur melalui inisiatif Azure Policy bawaan
  • Beban kerja yang terkait dengan komunitas yang memiliki penyiapan tata kelola kustom, gunakan konfigurasi unik ini alih-alih konfigurasi tata kelola Azure Enklave default.
  • Pertimbangan untuk penamaan sumber daya Azure

Pola desain keamanan untuk enklave Azure

Pertimbangkan pola desain keamanan ini saat merancang lingkungan Enklave Azure Anda.

Batas keamanan

Azure Enclave menggunakan pendekatan pertahanan mendalam dalam hal keamanan cyber. Saat Anda menyebarkan komunitas dan enklave, Azure Enclave menetapkan beberapa lapisan isolasi jaringan, keamanan, kontrol akses, dan pengelogan dan pemantauan.

Tanggung jawab keamanan bersama

Sebagai layanan di Azure, Azure Enclave juga berkomitmen untuk menjunjung tinggi model tanggung jawab bersama di cloud. Untuk Azure Enklave secara khusus, beban kerja adalah tanggung jawab Anda. Tanggung jawab bersama Azure berlaku pada beban kerja Anda jika Anda menerapkan layanan PaaS pada beban kerja tersebut.

Komunitas dan enklave Anda mewakili tanggung jawab bersama. Komunitas dan enklave menggunakan model tanggung jawab bersama di mana Penyedia Sumber Daya enklave Azure membuat lingkungan jaringan hub-and-spoke yang aman dan telah dikonfigurasi sebelumnya. Anda mengelola lingkungan jaringan ini dengan membuat titik akhir enklave, titik akhir komunitas, hub transit, atau koneksi enklave. Versi pratinjau tertentu dari Azure Enclave juga memungkinkan Anda membuat perubahan secara manual pada jaringan melalui kontrol mendasar yang disediakan oleh Azure Virtual WAN, Microsoft Azure Virtual Network, dan layanan jaringan Azure yang mendasar lainnya.

Tata kelola Azure Enclave juga merupakan tanggung jawab bersama. Penyedia Sumber Daya enklave Azure membuat daftar inisiatif Azure Policy yang aman dan telah dikonfigurasi sebelumnya per penyebaran beban kerja. Namun, komunitas kini dapat menyesuaikan Inisiatif Azure Policy komunitas, yang menggantikan daftar prakonfigurasi untuk beban kerja. Terlepas dari persyaratan kebijakan, Anda tetap dapat membuat pengecualian secara manual untuk penetapan Azure Policy Initiative ini, bergantung pada persyaratan kepatuhan atau tata kelola.

Praktik terbaik keamanan Azure

Azure Enclave merekomendasikan mengikuti praktik dan pola terbaik keamanan Microsoft Azure untuk menyebarkan sumber daya Azure dan menerapkan beban kerja.

Anda harus mengikuti praktik terbaik keamanan Azure - Cloud Adoption Framework untuk mengatur sistem Anda, infrastruktur cloud, personel IT dan struktur tim, dan pelatihan kesadaran keamanan cyber perusahaan.

Penyelundupan data melalui Sistem Nama Domain

Penyelundupan data melalui Sistem Nama Domain (DNS) mewakili masalah keamanan yang signifikan bagi organisasi, karena menggunakan protokol yang biasanya diizinkan melalui firewall dan jarang dipantau untuk aktivitas berbahaya. Penyerang dapat mengeksploitasi kueri DNS untuk mengekstrak data sensitif secara rahasia dari sistem yang disusupi dengan mengodekan informasi dalam nama domain atau menggunakan teknik penerowongan DNS. Metode ini berbahaya karena lalu lintas DNS tampak sah dan sering melewati alat pemantauan keamanan tradisional.

Dalam serangan penyelundupan data berbasis DNS, aktor jahat mengodekan data yang dicuri ke dalam kueri DNS, sering menggunakan teknik seperti pelabelan subdomain atau kueri rekaman TXT. Misalnya, penyerang dapat memecah data sensitif menjadi potongan dan menyematkan setiap gugus sebagai subdomain dalam kueri DNS ke domain yang dikontrol penyerang. Data dapat diekstrak dari log DNS di server DNS penyerang. Pendekatan ini memungkinkan eksfiltrasi bertahap himpunan data besar sambil mempertahankan profil rendah, karena kueri DNS muncul sebagai permintaan resolusi nama normal.

Mengatasi eksfiltrasi data dengan Kebijakan Keamanan Azure DNS

Azure DNS Kebijakan Keamanan memberikan perlindungan komprehensif terhadap serangan penyelundupan data berbasis DNS dengan menawarkan kontrol terperinci atas lalu lintas DNS dalam Azure Virtual Networks. Layanan ini memungkinkan organisasi untuk menerapkan langkah-langkah keamanan proaktif yang dapat mendeteksi, memperingatkan, dan memblokir aktivitas DNS yang mencurigakan sebelum data dapat berhasil dieksfiltrasi.

Azure DNS Kebijakan Keamanan mengatasi penyelundupan data DNS melalui beberapa mekanisme utama. Pertama, ini menyediakan kemampuan untuk membuat aturan lalu lintas DNS yang dapat memblokir kueri ke domain berbahaya yang diketahui atau pola domain mencurigakan yang umumnya digunakan dalam upaya penyelundupan. Organisasi dapat mempertahankan daftar blok domain yang terkait dengan infrastruktur perintah dan kontrol atau layanan eksfiltrasi data. Kedua, layanan ini menawarkan kemampuan pengelogan DNS komprehensif yang menangkap semua kueri dan respons DNS dalam jaringan virtual yang dilindungi. Pengelogan ini memungkinkan tim keamanan menganalisis pola lalu lintas DNS dan mengidentifikasi potensi upaya eksfiltrasi. Ketiga, mesin kebijakan mendukung pemfilteran domain wildcard, memungkinkan organisasi memblokir seluruh kategori domain yang mencurigakan atau menerapkan daftar izinkan untuk tujuan DNS yang disetujui.

Implementasi Kebijakan Keamanan Azure DNS menciptakan beberapa lapisan pertahanan terhadap eksfiltrasi data DNS. Aturan lalu lintas dapat dikonfigurasi dengan tingkat prioritas yang berbeda, memungkinkan kebijakan keamanan kompleks yang menyeimbangkan keamanan dengan persyaratan operasional. Layanan ini mendukung pemblokiran kueri berbahaya secara real time sambil menyediakan log terperinci untuk analisis forensik dan perburuan ancaman. Selain itu, tautan jaringan virtual memastikan bahwa kebijakan keamanan DNS diterapkan secara konsisten di semua sumber daya dalam segmen jaringan yang dilindungi, menciptakan perimeter keamanan komprehensif yang sulit dilewati oleh penyerang.

Untuk penyebaran Enklave Azure, Kebijakan Keamanan Azure DNS harus diintegrasikan sebagai bagian dari arsitektur keamanan keseluruhan. Organisasi harus mengonfigurasi kebijakan keamanan DNS untuk memantau dan mengontrol lalu lintas DNS dari beban kerja enklave, memastikan bahwa data sensitif tetap dilindungi bahkan jika beban kerja individual disusupi. Tinjauan rutin dan pembaruan daftar domain DNS, dikombinasikan dengan pemantauan berkelanjutan log DNS, memberikan perlindungan berkelanjutan terhadap ancaman berbasis DNS yang berkembang dan membantu menjaga integritas keamanan lingkungan enklave Azure.

Informasi selengkapnya tersedia di dokumentasi Kebijakan Keamanan DNS.

Menerapkan kebijakan keamanan DNS yang secara default menolak semua permintaan

Untuk keamanan maksimum di lingkungan Azure Enclave, organisasi harus menerapkan pendekatan "tolak secara default, izinkan dengan pengecualian" untuk pemfilteran DNS. Model keamanan ini memastikan bahwa semua kueri DNS diblokir kecuali diizinkan secara eksplisit, memberikan perlindungan terkuat terhadap eksfiltrasi data berbasis DNS dan komunikasi perintah dan kontrol.

Pendekatan tolak secara default diimplementasikan menggunakan struktur aturan DNS dua tingkat dalam Kebijakan Keamanan Azure DNS:

Langkah 1: Buat aturan tolak default Buat Daftar Domain DNS yang hanya berisi domain . akar (titik). Domain wildcard ini cocok dengan semua kemungkinan kueri DNS. Kaitkan daftar domain ini ke aturan lalu lintas DNS yang dikonfigurasi dengan:

  • Prioritas: 65000 (prioritas terendah)
  • Tindakan: Blokir
  • Daftar Domain: domain root (.)

Aturan ini berfungsi sebagai catch-all yang memblokir kueri DNS apa pun yang tidak diizinkan secara eksplisit oleh aturan prioritas yang lebih tinggi.

Langkah 2: Membuat aturan daftar izin Buat Daftar Domain DNS terpisah yang berisi domain tertentu yang diperlukan untuk operasi bisnis yang sah. Ini mungkin termasuk:

  • Layanan Azure penting (misalnya, *.azure.com, *.microsoft.com)
  • Domain perusahaan dan layanan non-Microsoft tepercaya
  • Layanan pembaruan sistem operasi
  • Domain otoritas sertifikat

Asosiasikan daftar izin ke aturan lalu lintas DNS yang dikonfigurasi dengan:

  • Prioritas: 500-1000 (prioritas lebih tinggi daripada tolak default)
  • Tindakan: Izinkan
  • Daftar Domain: Domain tertentu yang disetujui

Pemrosesan aturan berbasis prioritas Azure DNS Kebijakan Keamanan memproses aturan dalam urutan prioritas (angka yang lebih rendah = prioritas yang lebih tinggi). Saat kueri DNS dibuat:

  1. Sistem pertama-tama mengevaluasi aturan yang mengizinkan berprioritas tinggi (prioritas 500-1000)
  2. Jika domain sesuai dengan daftar yang diizinkan, kueri tersebut diizinkan
  3. Jika tidak ada allow aturan yang cocok, kueri masuk ke aturan tolak default (prioritas 65000) dan lalu lintas diblokir

Pendekatan ini memberikan beberapa keuntungan keamanan:

  • Model kepercayaan nol: Tidak ada kueri DNS yang diizinkan kecuali secara eksplisit diotorisasi
  • Kontrol terperinci: Organisasi dapat mengontrol domain mana yang dapat diakses dengan tepat
  • Jejak audit: Semua kueri yang diblokir dicatat, memberikan visibilitas ke potensi ancaman
  • Pembaruan tambahan: Domain baru yang disetujui dapat ditambahkan untuk mengizinkan daftar tanpa mengubah aturan tolak default

Contoh implementasi:

Priority 500: Allow rule for Azure services
- Domain List: azure-services (contains azure.com., microsoft.com.)
- Action: Allow

Priority 600: Allow rule for business applications
- Domain List: business-domains (contains company.com., partner1.com., partner2.com.)
- Action: Allow

Priority 65000: Default deny rule
- Domain List: deny-all (contains .)
- Action: Block

Organisasi yang menerapkan pendekatan ini harus dimulai dengan inventarisasi komprehensif domain yang diperlukan dan secara bertahap menyempurnakan daftar domain yang diizinkan berdasarkan kebutuhan operasional dan log keamanan. Tinjauan rutin kueri yang diblokir membantu mengidentifikasi domain sah yang mungkin perlu ditambahkan ke daftar yang diizinkan sambil mempertahankan postur keamanan yang kuat.

Menerapkan kebijakan DNS tolak secara default dengan server DNS Windows

Untuk lingkungan yang tidak dapat menggunakan Kebijakan Keamanan Azure DNS atau memerlukan kontrol DNS lokal, keamanan tolak secara default serupa dapat diimplementasikan menggunakan server DNS Windows dengan fitur Kebijakan DNS. Pendekatan ini memberikan perlindungan yang sebanding terhadap eksfiltrasi data berbasis DNS sambil mempertahankan kompatibilitas dengan infrastruktur Windows yang ada.

Windows DNS Server (Server Windows 2016 dan yang lebih baru) mendukung fungsionalitas Kebijakan DNS yang memungkinkan organisasi menerapkan aturan pemfilteran DNS canggih. Model tolak secara default dapat dicapai melalui kombinasi aturan Kebijakan DNS dan konfigurasi zona.

Grup sumber daya terkelola di enklave Azure

Grup sumber daya yang berisi sumber daya yang dikelola oleh Azure Enclave.

Grup sumber daya terkelola komunitas

Grup sumber daya yang dikelola Komunitas berisi sumber daya infrastruktur yang dijelaskan dalam Apa itu komunitas?.

Nama grup sumber daya yang dikelola komunitas mengikuti konvensi penamaan ini: myCommunityName-HostedResources-<GUID>. Setiap penyebaran komunitas membuat grup sumber daya ini dan menempatkan infrastruktur komunitas di dalamnya. Saat Anda menghapus komunitas, penyedia sumber daya Azure Enclave secara otomatis menghapus grup sumber daya terkelola komunitas.

Cuplikan layar memperlihatkan contoh sumber daya komunitas yang dikelola oleh Azure Enklave.

Grup sumber daya yang dikelola komunitas memiliki batasan berikut:

  • Anda tidak dapat menentukan grup sumber daya yang ada untuk grup sumber daya terkelola komunitas.
  • Anda tidak dapat menentukan langganan yang berbeda untuk grup sumber daya terkelola komunitas.
  • Anda tidak dapat mengubah nama grup sumber daya terkelola komunitas setelah komunitas dibuat.
  • Anda tidak dapat menentukan nama untuk sumber daya terkelola dalam grup sumber daya yang dikelola komunitas.
  • Anda tidak dapat mengubah atau menghapus tag sumber daya terkelola yang dibuat Azure dalam grup sumber daya yang dikelola komunitas.

Jika Anda mengubah atau menghapus tag, sumber daya, dan properti sumber daya yang dibuat Azure di grup sumber daya terkelola komunitas, Anda dapat melihat hasil yang tidak terduga. Karena Azure Enclave mengelola siklus hidup infrastruktur di grup sumber daya yang dikelola komunitas, setiap perubahan berpotensi memindahkan enklave Anda ke status yang tidak didukung.

Skenario umum di mana Anda ingin memodifikasi sumber daya adalah melalui tag. Azure Enclave memungkinkan Anda membuat dan memodifikasi tag yang disebarkan ke sumber daya di grup sumber daya yang dikelola komunitas. Anda mungkin ingin membuat atau memodifikasi tag kustom, misalnya, untuk menetapkan unit bisnis atau pusat biaya. Hal ini juga dapat dicapai dengan membuat Kebijakan Azure dengan cakupan pada grup sumber daya yang dikelola komunitas.

Note

Jika Anda tidak mengaktifkan penguncian grup sumber daya terkelola komunitas, Anda dapat langsung memodifikasi sumber daya apa pun di grup sumber daya yang dikelola komunitas. Memodifikasi sumber daya secara langsung di grup sumber daya yang dikelola komunitas dapat menyebabkan enklave Anda menjadi tidak stabil atau tidak responsif.

Grup sumber daya terkelola Enclave

Grup sumber daya terkelola Enclave berisi sumber daya infrastruktur yang dijelaskan dalam Apa itu enklave?.

Nama grup sumber daya terkelola enklave mengikuti konvensi penamaan ini: myEnclaveName-HostedResources-<GUID>. Setiap penyebaran enklave membuat grup sumber daya ini dan menempatkan infrastruktur enklave di dalamnya. Saat Anda menghapus enklave, penyedia sumber daya Azure Enclave secara otomatis menghapus grup sumber daya terkelola enklave.

Cuplikan layar memperlihatkan contoh sumber daya enklave yang dikelola oleh Azure Enklave.

Grup sumber daya terkelola enklave memiliki batasan berikut:

  • Anda tidak dapat menentukan grup sumber daya yang sudah ada untuk grup sumber daya terkelola enklave.
  • Anda tidak dapat menentukan langganan lain untuk grup sumber daya terkelola enklave.
  • Anda tidak dapat mengubah nama grup sumber daya terkelola enklave setelah enklave dibuat.
  • Anda tidak dapat menetapkan nama untuk sumber daya terkelola di dalam grup sumber daya terkelola enklave.
  • Anda tidak dapat mengubah atau menghapus tag yang dibuat oleh Azure pada sumber daya terkelola di dalam grup sumber daya terkelola enklave.

Jika Anda mengubah atau menghapus tag, sumber daya, dan properti sumber daya lainnya yang dibuat oleh Azure dalam grup sumber daya terkelola enklave, Anda dapat mengalami dampak yang tidak terduga, seperti kesalahan jaringan, akses, dan pemantauan. Karena Azure Enclave mengelola siklus hidup infrastruktur di grup sumber daya terkelola enklave, setiap perubahan berpotensi memindahkan enklave Anda ke status yang tidak didukung.

Skenario umum di mana Anda ingin memodifikasi sumber daya adalah melalui tag. Azure Enclave memungkinkan Anda membuat dan memodifikasi tag yang diterapkan ke sumber daya dalam grup sumber daya terkelola Enclave. Anda mungkin ingin membuat atau memodifikasi tag kustom, misalnya, untuk menetapkan unit bisnis atau pusat biaya. Pemberian tag pada sumber daya juga dapat dilakukan dengan membuat Kebijakan Azure dengan cakupan di grup sumber daya terkelola enklave.

Warning

Memodifikasi sumber daya dalam grup sumber daya terkelola enklave dapat menyebabkan enklave Anda menjadi tidak stabil atau tidak responsif.

Grup sumber daya beban kerja

Beban kerja ditautkan ke satu atau beberapa grup sumber daya tempat Anda dapat membuat dan mengatur sumber daya Azure Anda.

Menambahkan grup sumber daya ke beban kerja

Menambahkan grup sumber daya baru biasanya mengharuskan pengguna memiliki izin untuk membuat grup sumber daya baru. Langganan Owner atau Contributor peran memiliki izin ini tetapi orang yang membuat grup sumber daya beban kerja mungkin tidak memiliki atau memerlukan izin istimewa ini. Azure Enclave mencoba tiga cara untuk membuat grup sumber daya baru mulai dari persyaratan izin pengguna tertinggi hingga terendah, menawarkan fleksibilitas bagi pengguna:

  • Opsi 1: Memerlukan izin yang paling istimewa untuk individu yang membuat atau memperbarui beban kerja, memberikan kontrol penuh tetapi memerlukan akses yang ditinggikan.
  • Opsi 2: Melibatkan penyiapan manual oleh pengguna untuk memberikan kepemilikan aplikasi kami Mission Enclave di tingkat langganan, yang mungkin tidak selaras dengan preferensi Anda.
  • Opsi 3: Tidak memerlukan izin untuk pengguna atau Mission Enclave aplikasi, menjadikannya metode paling mudah tetapi memberlakukan hubungan 1:1 yang ketat antara grup sumber daya dan beban kerja.

Setiap opsi memiliki manfaat dan batasan, kontrol keseimbangan, kenyamanan, dan fleksibilitas agar sesuai dengan berbagai kebutuhan. Opsi ini masing-masing dievaluasi dimulai dengan opsi 1 dan opsi pertama untuk berhasil digunakan untuk membuat grup sumber daya baru.

Setelah Anda membuat satu grup sumber daya beban kerja dengan menggunakan opsi 3, Anda akan melihat peringatan bahwa opsi 3 tidak dapat digunakan untuk grup sumber daya beban kerja berikutnya pada beban kerja tersebut. Anda juga dapat membuat beban kerja baru lalu membuat grup sumber daya beban kerja baru dengan menggunakan opsi 3 lagi.

Tambahkan grup sumber daya ke enklave Anda:

  1. Buka halaman portal Azure untuk beban kerja.
  2. Pilih Manage lalu Resource Groups.
  3. Pilih Add a resource group.
  4. Di jendela samping yang terbuka, pilih Create new untuk memberikan nama grup sumber daya kosong baru, atau pilih Resource Group menu drop-down untuk memilih grup sumber daya yang sudah ada.
  5. Pilih OK lalu Save.

Apa perbedaan grup sumber daya beban kerja dengan grup sumber daya Azure lainnya?

Grup sumber daya beban kerja adalah komponen penting dari keamanan dan kepatuhan Enklave Azure karena di situlah sumber daya penting Anda dibuat. Karena grup sumber daya beban kerja ini ditautkan ke beban kerja, dan beban kerja ditautkan ke enklave, Azure Enclave mengelola penghapusan grup sumber daya terkelola beban kerja.

Selain itu, kebijakan diterapkan ke grup sumber daya beban kerja. Mirip dengan bagaimana kebijakan komunitas mengalir ke enklave, kebijakan enklave mengalir ke sumber daya beban kerja dan grup sumber daya beban kerja. Saat Anda membuat grup sumber daya beban kerja baru, peran diatur pada tingkat enklave dan diwarisi dari langganan. Beberapa kebijakan ini diwariskan dari komunitas, dan Anda juga dapat membuat kebijakan di enklave yang diterapkan ke beban kerja dan kelompok sumber daya beban kerja.

Menata sumber daya dalam grup sumber daya beban kerja

Jika Anda ingin membagi sumber daya menjadi dua grup sumber daya, Anda dapat memilih salah satu opsi berikut:

  • membagi sumber daya tersebut antara dua grup sumber daya yang ditautkan ke satu beban kerja
  • membagi sumber daya tersebut antara dua beban kerja yang masing-masing memiliki satu atau beberapa grup sumber daya

Penghapusan beban kerja

Saat penghapusan beban kerja diminta, grup sumber daya beban kerja diperiksa untuk memastikannya kosong. Jika grup sumber daya beban kerja berisi sumber daya, penghapusan beban kerja yang diminta gagal dan menunjukkan kesalahan. Untuk menghapus beban kerja dan grup sumber daya beban kerja, pertama-tama kosongkan grup sumber daya beban kerja. Grup sumber daya beban kerja kosong membantu menghindari penghapusan sumber daya penting yang tidak disengaja.

Penghapusan sumber daya yang ditautkan ke beban kerja mengikuti perilaku yang sama. Misalnya, jika penghapusan komunitas diminta tetapi semua grup sumber daya beban kerja tidak kosong, operasi menunjukkan kesalahan. Kosongkan grup sumber daya beban kerja dan coba lagi.

Grup sumber daya terkelola beban kerja memiliki batasan berikut:

  • Anda tidak dapat menentukan grup sumber daya yang ada untuk grup sumber daya terkelola beban kerja.
  • Anda tidak dapat menentukan langganan lain untuk grup sumber daya terkelola beban kerja.
  • Anda tidak dapat mengubah nama grup sumber daya terkelola beban kerja setelah beban kerja dibuat.
  • Anda tidak dapat mengubah atau menghapus tag sumber daya terkelola yang dibuat Azure dalam grup sumber daya terkelola beban kerja.

Skenario umum di mana Anda ingin memodifikasi sumber daya adalah melalui tag. Azure Enclave memungkinkan Anda membuat dan memodifikasi tag yang disebarkan ke sumber daya dalam grup sumber daya terkelola beban kerja. Anda mungkin ingin membuat atau memodifikasi tag kustom, misalnya, untuk menetapkan unit bisnis atau pusat biaya. Penandaan juga dapat dilakukan dengan membuat kebijakan Azure dengan cakupan pada grup sumber daya terkelola untuk beban kerja.

Praktik terbaik Azure lainnya

Saat Anda membangun komunitas, enklave, dan beban kerja di Azure, penting untuk diingat prinsip desain universal berikut: