Arsitektur referensi Azure Spring Apps
Catatan
Azure Spring Apps adalah nama baru untuk layanan Azure Spring Cloud. Meskipun layanan memiliki nama baru, Anda akan melihat nama lama di beberapa tempat untuk sementara saat kami berupaya memperbarui aset seperti cuplikan layar, video, dan diagram.
Artikel ini berlaku untuk: ✔️ Standard ✔️ Enterprise
Arsitektur referensi ini adalah fondasi yang menggunakan hub perusahaan dan desain spoke untuk penggunaan Azure Spring Apps. Dalam desainnya, Azure Spring Apps disebarkan dalam satu spoke yang bergantung pada layanan bersama yang dihosting di hub. Arsitektur ini dibangun dengan komponen untuk mencapai prinsip di Microsoft Azure Well-Architected Framework.
Ada dua rasa Azure Spring Apps: Paket standar dan paket Enterprise.
Paket Standar Azure Spring Apps terdiri dari Spring Cloud Config Server, Spring Cloud Service Registry, dan layanan build kpack.
Paket Azure Spring Apps Enterprise terdiri dari VMware Tanzu® Build Service™, Application Configuration Service untuk VMware Tanzu®, VMware Tanzu® Service Registry, Spring Cloud Gateway untuk VMware Tanzu®, dan portal API untuk VMware Tanzu®.
Untuk implementasi arsitektur ini, lihat Arsitektur Referensi Azure Spring Apps di GitHub.
Opsi penyebaran untuk arsitektur ini termasuk Azure Resource Manager (ARM), Terraform, Azure CLI, dan Bicep. Artefak di repositori ini menyediakan fondasi yang dapat Anda sesuaikan untuk lingkungan Anda. Anda bisa mengelompokkan sumber daya seperti Azure Firewall atau Application Gateway ke dalam grup sumber daya atau langganan yang berbeda. Pengelompokan ini membantu menjaga fungsi yang berbeda tetap terpisah, seperti infrastruktur TI, keamanan, tim aplikasi bisnis, dan sebagainya.
Merencanakan ruang alamat
Azure Spring Apps memerlukan dua subnet khusus:
- Waktu proses layanan
- Aplikasi Spring Boot
Masing-masing subnet ini memerlukan kluster Azure Spring Apps khusus. Beberapa kluster tidak dapat berbagi subnet yang sama. Ukuran minimum setiap subnet adalah /28. Jumlah instans aplikasi yang dapat didukung oleh Azure Spring Apps bervariasi berdasarkan ukuran subnet. Anda dapat menemukan persyaratan jaringan virtual terperinci di bagian Persyaratan jaringan virtual dari Sebarkan Azure Spring Apps di jaringan virtual.
Peringatan
Ukuran subnet yang dipilih tidak dapat tumpang tindih dengan ruang alamat jaringan virtual yang ada, dan tidak boleh tumpang tindih dengan rentang alamat subnet yang di-peering atau lokal.
Kasus penggunaan
Penggunaan umum untuk arsitektur ini meliputi:
- Aplikasi internal yang diterapkan di lingkungan cloud hibrid
- Aplikasi publik: Aplikasi yang menghadap ke eksternal
Kasus penggunaan ini serupa kecuali untuk keamanan dan aturan lalu lintas jaringannya. Arsitektur ini dirancang untuk mendukung nuansa masing-masing.
Aplikasi privat
Daftar berikut ini menjelaskan persyaratan infrastruktur untuk aplikasi privat. Persyaratan ini umumnya untuk lingkungan dengan tingkat regulasi yang tinggi.
- Subnet hanya boleh memiliki satu instans Azure Spring Apps.
- Kepatuhan terhadap setidaknya satu Tolok Ukur Keamanan harus ditegakkan.
- Rekaman Domain Name Service (DNS) host aplikasi harus disimpan di Azure Private DNS.
- Dependensi layanan Azure harus berkomunikasi melalui Titik Akhir Layanan atau Private Link.
- Data tidak aktif harus dienkripsi.
- Data saat transit harus dienkripsi.
- Alur penyebaran DevOps dapat digunakan (misalnya, Azure DevOps) dan memerlukan konektivitas jaringan ke Azure Spring Apps.
- Lalu lintas keluar harus melalui pusat Network Virtual Appliance (NVA) (misalnya, Azure Firewall).
- Jika Azure Spring Apps Config Server digunakan untuk memuat properti konfigurasi dari repositori, repositori harus bersifat privat.
- Pendekatan keamanan Zero Trust Microsoft mewajibkan agar rahasia, sertifikat, dan kredensial disimpan dalam brankas aman. Layanan yang direkomendasikan adalah Azure Key Vault.
- Resolusi nama di host lokal dan di Cloud harus bersifat dua arah.
- Tidak ada akses keluar langsung ke Internet publik kecuali untuk mengontrol lalu lintas pesawat.
- Grup Sumber Daya yang dikelola oleh penyebaran Azure Spring Apps tidak boleh diubah.
- Subnet yang dikelola oleh penyebaran Azure Spring Apps tidak boleh diubah.
Daftar berikut ini memperlihatkan komponen yang membentuk desain:
- Jaringan lokal
- Layanan Nama Domain (DNS)
- Gateway
- Langganan hub
- Subnet Application Gateway
- Subnet Azure Firewall
- Subnet Layanan Bersama
- Langganan tersambung
- Subnet Azure Bastion
- Rekan Virtual Network
Daftar berikut ini menguraikan layanan Azure dalam arsitektur referensi ini:
Azure Key Vault: layanan pengelolaan kredensial didukung perangkat keras yang memiliki integrasi ketat dengan layanan identitas Microsoft dan sumber daya komputasi.
Azure Monitor: rangkaian layanan pemantauan yang mencakup semua aplikasi yang disebarkan baik di Azure maupun secara lokal.
Azure Pipelines: layanan Integrasi Berkelanjutan / Pengembangan Berkelanjutan (CI/CD) unggulan lengkap yang dapat secara otomatis menyebarkan aplikasi Spring Boot yang diperbarui ke Azure Spring Apps.
Microsoft Defender for Cloud: sistem pengelolaan keamanan dan perlindungan ancaman terpadu untuk beban kerja di seluruh lokal, multi-cloud, dan Azure.
Azure Spring Apps: layanan terkelola yang dirancang dan dioptimalkan secara khusus untuk aplikasi Spring Boot berbasis Java dan aplikasi Steeltoe berbasis .NET.
Diagram berikut mewakili hub yang dirancang dengan baik dan desain spoke yang membahas persyaratan di atas:
Aplikasi publik
Daftar berikut ini menjelaskan persyaratan infrastruktur untuk aplikasi publik. Persyaratan ini umumnya untuk lingkungan dengan tingkat regulasi yang tinggi.
- Subnet hanya boleh memiliki satu instans Azure Spring Apps.
- Kepatuhan terhadap setidaknya satu Tolok Ukur Keamanan harus ditegakkan.
- Rekaman Domain Name Service (DNS) host aplikasi harus disimpan di Azure Private DNS.
- Azure DDoS Protection harus diaktifkan.
- Dependensi layanan Azure harus berkomunikasi melalui Titik Akhir Layanan atau Private Link.
- Data tidak aktif harus dienkripsi.
- Data saat transit harus dienkripsi.
- Alur penyebaran DevOps dapat digunakan (misalnya, Azure DevOps) dan memerlukan konektivitas jaringan ke Azure Spring Apps.
- Lalu lintas keluar harus melalui pusat Network Virtual Appliance (NVA) (misalnya, Azure Firewall).
- Lalu lintas masuk harus dikelola setidaknya oleh Application Gateway atau Azure Front Door.
- Alamat yang dapat dirutekan internet harus disimpan di Azure Public DNS.
- Pendekatan keamanan Zero Trust Microsoft mewajibkan agar rahasia, sertifikat, dan kredensial disimpan dalam brankas aman. Layanan yang direkomendasikan adalah Azure Key Vault.
- Resolusi nama di host lokal dan di Cloud harus bersifat dua arah.
- Tidak ada akses keluar langsung ke Internet publik kecuali untuk mengontrol lalu lintas pesawat.
- Grup Sumber Daya yang dikelola oleh penyebaran Azure Spring Apps tidak boleh diubah.
- Subnet yang dikelola oleh penyebaran Azure Spring Apps tidak boleh diubah.
Daftar berikut ini memperlihatkan komponen yang membentuk desain:
- Jaringan lokal
- Layanan Nama Domain (DNS)
- Gateway
- Langganan hub
- Subnet Application Gateway
- Subnet Azure Firewall
- Subnet Layanan Bersama
- Langganan tersambung
- Subnet Azure Bastion
- Rekan Virtual Network
Daftar berikut ini menguraikan layanan Azure dalam arsitektur referensi ini:
Azure Application Firewall: fitur Azure Application Gateway yang memberikan perlindungan terpusat pada aplikasi dari eksploitasi dan kerentanan umum.
Azure Application Gateway: penyeimbang muatan yang bertanggung jawab atas lalu lintas aplikasi dengan offload Keamanan Lapisan Transportasi (TLS) yang beroperasi pada lapisan 7.
Azure Key Vault: layanan pengelolaan kredensial didukung perangkat keras yang memiliki integrasi ketat dengan layanan identitas Microsoft dan sumber daya komputasi.
Azure Monitor: rangkaian layanan pemantauan yang mencakup semua aplikasi yang disebarkan baik di Azure maupun secara lokal.
Azure Pipelines: layanan Integrasi Berkelanjutan / Pengembangan Berkelanjutan (CI/CD) unggulan lengkap yang dapat secara otomatis menyebarkan aplikasi Spring Boot yang diperbarui ke Azure Spring Apps.
Microsoft Defender for Cloud: sistem pengelolaan keamanan dan perlindungan ancaman terpadu untuk beban kerja di seluruh lokal, multi-cloud, dan Azure.
Azure Spring Apps: layanan terkelola yang dirancang dan dioptimalkan secara khusus untuk aplikasi Spring Boot berbasis Java dan aplikasi Steeltoe berbasis .NET.
Diagram berikut mewakili hub yang dirancang dengan baik dan desain spoke yang memenuhi persyaratan di atas. Hanya hub-virtual-network yang berkomunikasi dengan internet:
Konektivitas lokal Azure Spring Apps
Aplikasi di Azure Spring Apps dapat berkomunikasi dengan berbagai sumber daya Azure, lokal, dan eksternal. Dengan menggunakan hub dan desain spoke, aplikasi dapat merutekan lalu lintas secara eksternal atau ke jaringan lokal menggunakan Rute Ekspres atau Jaringan Privat Maya (VPN) Situs ke Situs.
Pertimbangan Azure Well-Architected Framework
Azure Well-Architected Framework adalah seperangkat tenet panduan untuk diikuti dalam membangun fondasi infrastruktur yang kuat. Kerangka kerja ini berisi kategori berikut: pengoptimalan biaya, keunggulan operasional, efisiensi kinerja, keandalan, dan keamanan.
Pengoptimalan biaya
Karena sifat desain sistem yang terdistribusi, terbentangnya infrastruktur dapat diwujudkan. Kenyataan ini menghasilkan biaya yang tidak terduga dan tidak terkendali. Azure Spring Apps dibangun menggunakan komponen yang dapat diskalakan sehingga dapat memenuhi permintaan dan mengoptimalkan biaya. Inti dari arsitektur ini adalah Azure Kubernetes Service (AKS). Layanan ini dirancang untuk mengurangi kompleksitas dan overhead operasional saat mengelola Kubernetes, yang mencakup efisiensi dalam biaya operasional kluster.
Anda dapat menyebarkan berbagai aplikasi dan jenis aplikasi ke satu instans Azure Spring Apps. Layanan ini mendukung autoscaling aplikasi yang dipicu oleh metrik atau jadwal yang dapat meningkatkan pemanfaatan dan efisiensi biaya.
Anda juga dapat menggunakan Application Insights dan Azure Monitor untuk menurunkan biaya operasional. Dengan visibilitas yang disediakan oleh solusi pencatatan komprehensif, Anda dapat menerapkan otomatisasi untuk menskalakan komponen sistem secara real time. Anda juga dapat menganalisis data log untuk mengungkapkan inefisiensi dalam kode aplikasi yang dapat Anda atasi untuk meningkatkan biaya dan performa sistem secara keseluruhan.
Keunggulan operasional
Azure Spring Apps membahas berbagai aspek keunggulan operasional. Anda dapat menggabungkan aspek-aspek ini untuk memastikan bahwa layanan berjalan secara efisien di lingkungan produksi, seperti yang dijelaskan dalam daftar berikut:
- Anda dapat menggunakan Azure Pipelines untuk memastikan bahwa penyebaran dapat diandalkan dan konsisten sekaligus membantu Anda menghindari kesalahan manusia.
- Anda dapat menggunakan Azure Monitor dan Application Insights untuk menyimpan data log dan telemetri. Anda dapat menilai data log dan metrik yang dikumpulkan untuk memastikan kesehatan dan performa aplikasi Anda. Application Performance Monitoring (APM) terintegrasi penuh ke dalam layanan melalui agen Java. Agen ini memberikan visibilitas ke semua aplikasi dan dependensi yang diterapkan tanpa memerlukan kode tambahan. Untuk informasi selengkapnya, lihat posting blog Memantau aplikasi dan dependensi di Azure Spring Apps dengan mudah.
- Anda dapat menggunakan Microsoft Defender for Cloud untuk memastikan bahwa aplikasi menjaga keamanan dengan menyediakan platform untuk menganalisis dan menilai data yang disediakan.
- Layanan ini mendukung berbagai pola penyebaran. Untuk informasi selengkapnya, lihat Menyiapkan staging environment di Azure Spring Apps.
Keandalan
Azure Spring Apps dibangun di atas AKS. Sementara AKS memberikan tingkat ketahanan melalui pengklusteran, arsitektur referensi ini menggabungkan layanan dan pertimbangan arsitektur untuk meningkatkan ketersediaan aplikasi jika ada kegagalan komponen.
Dengan membangun di atas hub yang terdefinisi dengan baik dan desain spoke, fondasi arsitektur ini memastikan bahwa Anda dapat menyebarkannya ke beberapa wilayah. Untuk kasus penggunaan aplikasi privat, arsitektur menggunakan Azure Private DNS untuk memastikan ketersediaan yang berkelanjutan selama kegagalan geografis. Untuk kasus penggunaan aplikasi publik, Azure Front Door dan Azure Application Gateway memastikan ketersediaan.
Keamanan
Keamanan arsitektur ini diatasi oleh kepatuhannya terhadap kontrol dan tolok ukur yang ditentukan industri. Dalam konteks ini, "kontrol" berarti praktik terbaik yang ringkas dan terdefinisi dengan baik, seperti "Gunakan prinsip hak istimewa paling sedikit saat menerapkan akses sistem informasi. Kontrol IAM-05” dalam arsitektur ini berasal dari Cloud Control Matrix (CCM) oleh Cloud Security Alliance (CSA) dan Microsoft Azure Foundations Benchmark (MAFB) oleh Center untuk Internet Security (CIS). Dalam kontrol yang diterapkan, fokusnya adalah pada prinsip-prinsip desain keamanan utama terkait tata kelola, jaringan, dan keamanan aplikasi. Anda bertanggung jawab untuk menangani prinsip desain Identitas, Manajemen Akses, dan Penyimpanan karena berkaitan dengan infrastruktur target Anda.
Pemerintahan
Aspek utama tata kelola yang diatasi oleh arsitektur ini adalah pemisahan melalui isolasi sumber daya jaringan. Dalam CCM, DCS-08 merekomendasikan kontrol masuk dan keluar untuk pusat data. Untuk memenuhi kontrol, arsitektur menggunakan hub dan desain spoke menggunakan Network Security Groups (NSGs) untuk memfilter lalu lintas timur-barat antara sumber daya. Arsitektur ini juga memfilter lalu lintas antara layanan pusat di hub dan sumber daya dalam spoke. Arsitektur menggunakan instans Azure Firewall untuk mengelola lalu lintas antara Internet dan sumber daya di dalam arsitektur.
Daftar berikut ini memperlihatkan kontrol yang membahas keamanan pusat data dalam referensi ini:
| ID Kontrol CSA CCM | Domain Kontrol CSA CCM |
|---|---|
| DCS-08 | Entri Orang Tidak Berwenang Keamanan Pusat Data |
Jaringan
Desain jaringan yang mendukung arsitektur ini berasal dari hub tradisional dan model spoke. Keputusan ini memastikan bahwa isolasi jaringan adalah konstruksi dasar. Kontrol CCM IVS-06 merekomendasikan agar lalu lintas antara jaringan dan komputer virtual dibatasi serta dipantau antara lingkungan tepercaya dan tidak tepercaya. Arsitektur ini mengadopsi kontrol dengan implementasi NSGs untuk lalu lintas timur-barat, dan Azure Firewall untuk lalu lintas utara-selatan (di luar "pusat data"). Kontrol CCM IPY-04 merekomendasikan bahwa infrastruktur harus menggunakan protokol jaringan yang aman untuk pertukaran data antar layanan. Layanan Azure yang mendukung arsitektur ini semuanya menggunakan protokol aman standar seperti TLS untuk HTTP dan SQL.
Daftar berikut ini memperlihatkan kontrol CCM yang menangani keamanan jaringan dalam referensi berikut:
| ID Kontrol CSA CCM | Domain Kontrol CSA CCM |
|---|---|
| IPY-04 | Protokol Jaringan |
| IVS-06 | Keamanan Jaringan |
Implementasi jaringan selanjutnya diamankan dengan mendefinisikan kontrol dari MAFB. Kontrol memastikan bahwa lalu lintas ke lingkungan dibatasi dari Internet publik.
Daftar berikut ini memperlihatkan kontrol CIS yang menangani keamanan jaringan dalam referensi ini:
| ID Kontrol CIS | Deskripsi Kontrol CIS |
|---|---|
| 6.2 | Pastikan akses SSH dibatasi dari internet |
| 6.3 | Pastikan tidak ada SQL Database yang mengizinkan jalur masuk 0.0.0.0/0 (IP APA PUN). |
| 6.5 | Pastikan Network Watcher diatur ke ‘Aktif’ |
| 6.6 | Pastikan jalur masuk yang menggunakan UDP dibatasi dari internet. |
Azure Spring Apps memerlukan lalu lintas manajemen untuk keluar dari Azure saat disebarkan di lingkungan yang aman. Anda harus mengizinkan aturan jaringan dan aplikasi yang tercantum dalam Tanggung jawab pelanggan untuk menjalankan Azure Spring Apps di jaringan virtual.
Keamanan aplikasi
Prinsip desain ini mencakup komponen mendasar identitas, perlindungan data, manajemen kunci, dan konfigurasi aplikasi. Secara desain, aplikasi yang disebarkan di Azure Spring Apps berjalan dengan hak istimewa paling sedikit yang diperlukan agar berfungsi. Rangkaian kontrol otorisasi terkait langsung dengan perlindungan data saat menggunakan layanan. Pengelolaan kunci memperkuat pendekatan keamanan aplikasi berlapis ini.
Daftar berikut ini memperlihatkan kontrol CCM yang menangani pengelolaan kunci dalam referensi ini:
| ID Kontrol CSA CCM | Domain Kontrol CSA CCM |
|---|---|
| EKM-01 | Hak Enkripsi dan Pengelolaan Kunci |
| EKM-02 | Pembuatan Kunci Enkripsi dan Pengelolaan Kunci |
| EKM-03 | Perlindungan Data Sensitif Enkripsi dan Pengelolaan Kunci |
| EKM-04 | Akses serta Penyimpanan Enkripsi dan Pengelolaan Kunci |
Dari CCM, EKM-02, dan EKM-03 merekomendasikan kebijakan dan prosedur untuk mengelola kunci dan menggunakan protokol enkripsi untuk melindungi data sensitif. EKM-01 merekomendasikan agar semua kunci kriptografi memiliki pemilik yang dapat diidentifikasi sehingga dapat dikelola. EKM-04 merekomendasikan penggunaan algoritma standar.
Daftar berikut ini memperlihatkan kontrol CIS yang menangani pengelolaan kunci dalam referensi ini:
| ID Kontrol CIS | Deskripsi Kontrol CIS |
|---|---|
| 8.1 | Pastikan tanggal kedaluwarsa telah diatur pada semua kunci. |
| 8.2 | Pastikan tanggal kedaluwarsa telah diatur pada semua rahasia. |
| 8.4 | Pastikan brankas kunci dapat dipulihkan. |
Kontrol CIS 8.1 dan 8.2 merekomendasikan bahwa tanggal kedaluwarsa ditetapkan untuk kredensial untuk memastikan bahwa rotasi diberlakukan. CIS control 8.4 memastikan konten brankas kunci dapat dipulihkan untuk menjaga kelangsungan bisnis.
Aspek keamanan aplikasi menetapkan fondasi untuk penggunaan arsitektur referensi ini untuk mendukung beban kerja Spring di Azure.
Langkah berikutnya
Jelajahi arsitektur referensi ini melalui penyebaran ARM, Terraform, dan Azure CLI yang tersedia di repositori Arsitektur Referensi Azure Spring Apps.