Edit

Koneksi internet masuk dan keluar untuk SAP di Azure

Azure Virtual Machines
Azure Virtual Network
Azure Application Gateway
Azure Load Balancer

Artikel ini menyediakan serangkaian praktik yang terbukti untuk meningkatkan keamanan koneksi internet masuk dan keluar untuk infrastruktur SAP di Azure Anda.

Sistem

Diagram yang menunjukkan solusi untuk komunikasi yang terhubung ke internet untuk SAP di Azure.

Unduh file Visio arsitektur dalam artikel ini.

Solusi ini menggambarkan lingkungan produksi umum. Anda dapat mengurangi ukuran dan cakupan konfigurasi agar sesuai dengan kebutuhan Anda. Pengurangan ini mungkin berlaku untuk lanskap SAP: lebih sedikit komputer virtual (VM), tidak ada ketersediaan tinggi, atau SAP Web Dispatchers yang disematkan alih-alih VM diskrit. Ini juga dapat berlaku untuk alternatif untuk desain jaringan, seperti yang dijelaskan nanti dalam artikel ini.

Persyaratan pelanggan, yang didorong oleh kebijakan bisnis, akan memerlukan adaptasi terhadap arsitektur, terutama untuk desain jaringan. Jika memungkinkan, kami telah menyertakan alternatif. Banyak solusi yang layak. Pilih pendekatan yang tepat untuk bisnis Anda. Ini perlu membantu Anda mengamankan sumber daya Azure Anda tetapi masih menyediakan solusi yang berkinerja.

Pemulihan bencana (DR) tidak tercakup dalam arsitektur ini. Untuk desain jaringan, prinsip dan desain yang sama yang berlaku untuk wilayah produksi utama berlaku. Dalam desain jaringan Anda, tergantung pada aplikasi yang dilindungi oleh DR, pertimbangkan untuk mengaktifkan DR di wilayah Azure lain. Untuk informasi selengkapnya, lihat artikel Gambaran umum pemulihan bencana dan panduan infrastruktur untuk beban kerja SAP

Alur kerja

  • Jaringan lokal terhubung ke hub pusat melalui Azure ExpressRoute. Jaringan virtual hub berisi subnet gateway, subnet Azure Firewall, subnet layanan bersama, dan subnet Azure Application Gateway.
  • Hub terhubung ke langganan produksi SAP melalui peering jaringan virtual. Langganan ini berisi dua jaringan virtual spoke:
    • Jaringan virtual perimeter SAP berisi subnet aplikasi perimeter SAP.
    • Jaringan virtual produksi SAP berisi subnet aplikasi dan subnet database.
  • Langganan hub dan langganan produksi SAP terhubung ke internet melalui alamat IP publik.

Komponen

Langganan. Arsitektur ini mengimplementasikan pendekatan zona pendaratan Azure. Satu langganan Azure digunakan untuk setiap beban kerja. Satu atau beberapa langganan digunakan untuk layanan IT pusat yang berisi hub jaringan dan pusat, layanan bersama seperti firewall atau Direktori Aktif dan DNS. Langganan lain digunakan untuk beban kerja produksi SAP. Gunakan panduan keputusan dalam Cloud Adoption Framework for Azure untuk menentukan strategi langganan terbaik untuk skenario Anda.

Jaringan virtual.Azure Virtual Network menghubungkan sumber daya Azure satu sama lain dengan keamanan yang ditingkatkan. Dalam arsitektur ini, jaringan virtual terhubung ke lingkungan lokal melalui gateway ExpressRoute atau jaringan privat virtual (VPN) yang disebarkan di hub topologi hub-spoke. Lanskap produksi SAP menggunakan jaringan virtual spoke-nya sendiri. Dua jaringan virtual spoke yang berbeda melakukan tugas yang berbeda, dan subnet menyediakan pemisahan jaringan.

Pemisahan ke dalam subnet berdasarkan beban kerja memudahkan penggunaan kelompok keamanan jaringan (NSG) untuk mengatur aturan keamanan untuk VM aplikasi atau layanan Azure yang disebarkan.

Gateway zona redundan. Gateway menghubungkan jaringan yang berbeda, memperluas jaringan lokal Anda ke jaringan virtual Azure. Kami menyarankan agar Anda menggunakan ExpressRoute untuk membuat koneksi privat yang tidak menggunakan internet publik. Anda juga dapat menggunakan koneksi situs-ke-situs . Anda dapat menyebarkan gateway ExpressRoute atau VPN di seluruh zona untuk membantu menghindari kegagalan zona. Lihat Gateway jaringan virtual zona-redundan untuk penjelasan tentang perbedaan antara penyebaran zona dan penyebaran zona-redundan. Untuk penyebaran zona gateway, Anda perlu menggunakan alamat IP SKU Standar.

NSG. Untuk membatasi lalu lintas jaringan ke dan dari jaringan virtual, buat NSG dan tetapkan ke subnet tertentu. Berikan keamanan untuk subnet individual dengan menggunakan NSG khusus beban kerja.

Kelompok keamanan aplikasi. Untuk menentukan kebijakan keamanan jaringan yang mendefinisikan halus di NSG Anda berdasarkan beban kerja yang berpusat pada aplikasi, gunakan grup keamanan aplikasi alih-alih alamat IP eksplisit. Dengan menggunakan grup keamanan aplikasi, Anda dapat mengelompokkan VM dengan tujuan, misalnya, SAP SID. Kelompok keamanan aplikasi membantu mengamankan aplikasi dengan memfilter lalu lintas dari segmen tepercaya jaringan Anda.

Titik akhir privat. Banyak layanan Azure beroperasi sebagai layanan publik, berdasarkan desain yang dapat diakses melalui internet. Untuk mengizinkan akses privat melalui rentang jaringan privat, Anda dapat menggunakan titik akhir privat untuk beberapa layanan. Titik akhir privat adalah antarmuka jaringan di jaringan virtual Anda. Mereka secara efektif membawa layanan ke ruang jaringan privat Anda.

Azure Application Gateway.Application Gateway adalah penyeimbang beban lalu lintas web. Dengan fungsionalitas Web Application Firewall-nya, ini adalah layanan yang ideal untuk mengekspos aplikasi web ke internet dengan keamanan yang ditingkatkan. Application Gateway dapat melayani klien publik (internet) atau privat, atau keduanya, tergantung pada konfigurasinya.

Dalam arsitektur, Application Gateway, menggunakan alamat IP publik, memungkinkan koneksi masuk ke lanskap SAP melalui HTTPS. Kumpulan back-end-nya adalah dua atau lebih VM SAP Web Dispatcher, diakses round-robin dan memberikan ketersediaan tinggi. Gateway aplikasi adalah proksi terbalik dan penyeimbang beban lalu lintas web, tetapi tidak menggantikan SAP Web Dispatcher. SAP Web Dispatcher menyediakan integrasi aplikasi dengan sistem SAP Anda dan menyertakan fitur yang tidak disediakan Application Gateway dengan sendirinya. Autentikasi klien, ketika mencapai sistem SAP, dilakukan oleh lapisan aplikasi SAP secara asli atau melalui akses menyeluruh. Saat Anda mengaktifkan perlindungan Azure DDoS, pertimbangkan untuk menggunakan SKU perlindungan jaringan DDoS karena Anda akan melihat diskon untuk Application Gateway Web Application Firewall.

Untuk performa optimal, aktifkan dukungan HTTP/2 untuk Application Gateway, SAP Web Dispatcher, dan SAP NetWeaver.

Azure Load Balancer. Azure Standard Load Balancer menyediakan elemen jaringan untuk desain ketersediaan tinggi sistem SAP Anda. Untuk sistem berkluster, Standard Load Balancer menyediakan alamat IP virtual untuk layanan kluster, seperti instans ASCS/SCS dan database yang berjalan di VM. Anda juga dapat menggunakan Load Balancer Standar untuk menyediakan alamat IP untuk nama host SAP virtual dari sistem non-kluster saat IP sekunder pada kartu jaringan Azure bukan pilihan. Penggunaan Load Balancer Standar alih-alih Application Gateway untuk mengatasi akses internet keluar dibahas nanti dalam artikel ini.

Desain jaringan

Arsitektur ini menggunakan dua jaringan virtual diskrit, kedua jaringan virtual spoke yang di-peering ke jaringan virtual hub pusat. Tidak ada peering spoke-to-spoke. Topologi bintang digunakan, di mana komunikasi melewati hub. Pemisahan jaringan membantu melindungi aplikasi dari pelanggaran.

Jaringan perimeter khusus aplikasi (juga dikenal sebagai DMZ) berisi aplikasi yang terhubung ke internet, seperti SAProuter, SAP Cloud Koneksi or, SAP Analytics Cloud Agent, dan lainnya. Dalam diagram arsitektur, jaringan perimeter diberi nama perimeter SAP - jaringan virtual spoke. Karena dependensi pada sistem SAP, tim SAP biasanya melakukan penyebaran, konfigurasi, dan manajemen layanan ini. Itulah sebabnya layanan perimeter SAP ini sering tidak terletak di langganan dan jaringan hub pusat. Seringkali tantangan organisasi disebabkan oleh penempatan hub pusat aplikasi atau layanan tertentu beban kerja tersebut.

Ini adalah beberapa manfaat menggunakan jaringan virtual perimeter SAP terpisah:

  • Isolasi cepat dan segera dari layanan yang disusupi jika pelanggaran terdeteksi. Menghapus peering jaringan virtual dari perimeter SAP ke hub segera mengisolasi beban kerja perimeter SAP dan aplikasi jaringan virtual aplikasi SAP dari internet. Mengubah atau menghapus aturan NSG yang mengizinkan akses hanya memengaruhi koneksi baru dan tidak memotong koneksi yang ada.
  • Kontrol yang lebih ketat pada jaringan virtual dan subnet, dengan penguncian ketat pada mitra komunikasi masuk dan keluar dari jaringan perimeter SAP dan jaringan aplikasi SAP. Anda dapat memperluas kontrol yang ditingkatkan ke pengguna yang berwenang dan metode akses pada aplikasi perimeter SAP, dengan ujung belakang otorisasi yang berbeda, akses istimewa, atau kredensial masuk untuk aplikasi perimeter SAP.

Kelemahannya adalah peningkatan kompleksitas dan biaya peering jaringan virtual ekstra untuk lalu lintas SAP yang terikat internet (karena komunikasi perlu melewati peering jaringan virtual dua kali). Dampak latensi pada lalu lintas peering spoke-hub-spoke tergantung pada firewall apa pun yang ada di tempat dan perlu diukur.

Arsitektur yang disederhanakan

Untuk mengatasi rekomendasi dalam artikel ini tetapi membatasi kelemahannya, Anda dapat menggunakan satu jaringan virtual spoke untuk perimeter dan aplikasi SAP. Arsitektur berikut berisi semua subnet dalam satu jaringan virtual produksi SAP. Manfaat isolasi segera dengan penghentian peering jaringan virtual ke perimeter SAP jika disusupi tidak tersedia. Dalam skenario ini, perubahan pada NSG hanya memengaruhi koneksi baru.

Diagram yang menunjukkan arsitektur yang disederhanakan untuk komunikasi yang terhubung ke internet untuk SAP di Azure.

Unduh file Visio arsitektur dalam artikel ini.

Untuk penyebaran yang ukuran dan cakupannya lebih kecil, arsitektur yang disederhanakan mungkin lebih cocok, dan masih mematuhi prinsip-prinsip arsitektur yang lebih kompleks. Artikel ini, kecuali dinyatakan lain, mengacu pada arsitektur yang lebih kompleks.

Arsitektur yang disederhanakan menggunakan gateway NAT di subnet perimeter SAP. Gateway ini menyediakan konektivitas keluar untuk SAP Cloud Koneksi or dan SAP Analytics Cloud Agent dan pembaruan OS untuk VM yang disebarkan. Karena SAProuter memerlukan koneksi masuk dan keluar, jalur komunikasi SAProuter melewati firewall alih-alih menggunakan gateway NAT. Arsitektur yang disederhanakan juga menempatkan Application Gateway dengan subnet yang ditunjuk sendiri di jaringan virtual perimeter SAP, sebagai pendekatan alternatif untuk jaringan virtual hub.

Gateway NAT adalah layanan yang menyediakan alamat IP publik statis untuk konektivitas keluar. Gateway NAT ditetapkan ke subnet. Semua komunikasi keluar menggunakan alamat IP gateway NAT untuk akses internet. Koneksi masuk tidak menggunakan gateway NAT. Aplikasi seperti SAP Cloud Koneksi or, atau layanan pembaruan OS VM yang mengakses repositori di internet, dapat menggunakan gateway NAT alih-alih merutekan semua lalu lintas keluar melalui firewall pusat. Sering kali, aturan yang ditentukan pengguna diterapkan pada semua subnet untuk memaksa lalu lintas yang terikat internet dari semua jaringan virtual melalui firewall pusat.

Bergantung pada kebutuhan Anda, Anda mungkin dapat menggunakan gateway NAT sebagai alternatif untuk firewall pusat, hanya pada koneksi keluar. Dengan demikian, Anda dapat mengurangi beban pada firewall pusat saat berkomunikasi dengan titik akhir publik yang diizinkan NSG. Anda juga mendapatkan kontrol IP keluar, karena Anda dapat mengonfigurasi aturan firewall tujuan pada daftar IP yang ditetapkan gateway NAT. Contohnya termasuk menjangkau titik akhir publik Azure yang digunakan oleh layanan publik, repositori patch OS, atau antarmuka pihak ketiga.

Untuk konfigurasi ketersediaan tinggi, perlu diingat bahwa gateway NAT disebarkan di zona tertentu saja dan saat ini tidak berlebihan lintas zona. Dengan gateway NAT tunggal, tidak ideal untuk penyebaran SAP yang menggunakan penyebaran zona redundan (lintas zona) untuk komputer virtual.

Penggunaan komponen jaringan di seluruh lanskap SAP

Dokumen arsitektur biasanya hanya menggambarkan satu sistem atau lanskap SAP. Ini membuat mereka lebih mudah dipahami. Hasilnya adalah bahwa sering gambaran yang lebih besar, bagaimana arsitektur cocok dengan lanskap SAP yang lebih besar yang mencakup beberapa trek dan tingkat sistem, tidak ditangani.

Layanan jaringan pusat, seperti firewall, gateway NAT, dan server proksi jika disebarkan, paling baik digunakan di seluruh lanskap SAP dari semua tingkatan: produksi, pra-produksi, pengembangan, dan kotak pasir. Bergantung pada kebutuhan Anda, ukuran organisasi Anda, dan kebijakan bisnis, Anda mungkin ingin mempertimbangkan implementasi terpisah per tingkat, atau satu produksi dan satu lingkungan kotak pasir/pengujian.

Layanan yang biasanya melayani sistem SAP paling baik dipisahkan seperti yang dijelaskan di sini:

  • Load balancer harus didedikasikan untuk layanan individual. Kebijakan perusahaan menentukan penamaan dan pengelompokan sumber daya. Kami merekomendasikan satu load balancer untuk ASCS/SCS dan ERS dan satu lagi untuk database, dipisahkan untuk setiap SAP SID. Atau, penyeimbang beban tunggal untuk kluster (A)SCS, ERS, dan DB dari satu sistem SAP juga merupakan desain yang baik. Konfigurasi ini membantu memastikan bahwa pemecahan masalah tidak menjadi kompleks, dengan banyak kumpulan front-end dan back-end dan aturan penyeimbangan beban semuanya pada satu load balancer. Penyeimbang beban tunggal per SAP SID juga memastikan bahwa penempatan dalam grup sumber daya cocok dengan komponen infrastruktur lainnya.
  • Application Gateway, seperti load balancer, memungkinkan beberapa ujung belakang, ujung depan, pengaturan HTTP, dan aturan. Keputusan untuk menggunakan satu gateway aplikasi untuk beberapa penggunaan lebih umum di sini karena tidak semua sistem SAP di lingkungan memerlukan akses publik. Beberapa penggunaan dalam konteks ini mencakup port dispatcher web yang berbeda untuk sistem SAP S/4HANA yang sama atau lingkungan SAP yang berbeda. Kami merekomendasikan setidaknya satu gateway aplikasi per tingkat (produksi, non-produksi, dan kotak pasir) kecuali kompleksitas dan jumlah sistem yang terhubung menjadi terlalu tinggi.
  • Layanan SAP, seperti SAProuter, Cloud Koneksi or, dan Analytics Cloud Agent, disebarkan berdasarkan persyaratan aplikasi, baik secara terpusat atau terpisah. Pemisahan produksi dan non-produksi sering kali diinginkan.

Ukuran dan desain subnet

Saat Anda merancang subnet untuk lanskap SAP Anda, pastikan untuk mengikuti prinsip ukuran dan desain:

  • Beberapa layanan platform as a service (PaaS) Azure memerlukan subnet yang ditunjuk sendiri.
  • Application Gateway merekomendasikan subnet /24 untuk penskalaan. Jika memilih untuk membatasi skala Application Gateway, subnet yang lebih kecil dapat digunakan, minimal /26 atau lebih besar. Anda tidak dapat menggunakan kedua versi Application Gateway (1 dan 2) di subnet yang sama.
  • Jika Anda menggunakan Azure NetApp Files untuk berbagi NFS/SMB atau penyimpanan database, subnet yang ditunjuk diperlukan. Subnet /24 adalah default. Gunakan persyaratan Anda untuk menentukan ukuran yang tepat.
  • Jika Anda menggunakan nama host virtual SAP, Anda memerlukan lebih banyak ruang alamat di subnet SAP Anda, termasuk perimeter SAP.
  • Layanan pusat seperti Azure Bastion atau Azure Firewall, biasanya dikelola oleh tim IT pusat, memerlukan subnet khusus mereka sendiri dengan ukuran yang memadai.

Dengan menggunakan subnet khusus untuk database dan aplikasi SAP, Anda dapat mengatur NSG agar lebih ketat, yang membantu melindungi kedua jenis aplikasi dengan seperangkat aturan mereka sendiri. Anda kemudian dapat membatasi akses database ke aplikasi SAP dengan lebih mudah, tanpa perlu menggunakan kelompok keamanan aplikasi untuk kontrol terperinci. Memisahkan aplikasi SAP dan subnet database Anda juga memudahkan pengelolaan aturan keamanan Anda di NSG.

Layanan SAP

SAProuter

Anda dapat menggunakan SAProuter untuk memungkinkan pihak ketiga seperti dukungan SAP atau mitra Anda untuk mengakses sistem SAP Anda. SAProuter berjalan pada satu VM di Azure. Izin rute untuk menggunakan SAProuter disimpan dalam file datar yang disebut saprouttab. Entri saprouttab memungkinkan koneksi dari port TCP/IP apa pun ke tujuan jaringan di belakang SAProuter, biasanya VM sistem SAP Anda. Akses jarak jauh oleh dukungan SAP bergantung pada SAProuter. Arsitektur utama menggunakan desain yang dijelaskan sebelumnya, dengan SAProuter VM yang berjalan dalam jaringan virtual perimeter SAP yang ditunjuk. Melalui peering jaringan virtual, SAProuter kemudian berkomunikasi dengan server SAP Anda yang berjalan di jaringan virtual spoke dan subnet mereka sendiri.

SAProuter adalah terowongan ke SAP atau mitra Anda. Arsitektur ini menjelaskan penggunaan SAProuter dengan penggunaan SNC untuk membuat terowongan aplikasi terenkripsi (lapisan jaringan 7) ke SAP/mitra. Penggunaan terowongan berbasis IPSEC tidak tercakup dalam arsitektur ini saat ini.

Fitur berikut membantu melindungi jalur komunikasi melalui internet:

  • Azure Firewall atau NVA pihak ketiga menyediakan titik masuk IP publik ke jaringan Azure Anda. Aturan firewall membatasi komunikasi hanya untuk alamat IP yang diotorisasi. Untuk koneksi Anda ke dukungan SAP, catatan SAP 48243 - Mengintegrasikan perangkat lunak SAProuter ke dalam lingkungan firewall mendokumentasikan alamat IP router SAP.
  • Seperti aturan firewall, aturan keamanan jaringan memungkinkan komunikasi pada port SAProuter, biasanya 3299 dengan tujuan yang ditunjuk.
  • Anda mempertahankan aturan SAProuter allow/deny dalam file saprouttab , menentukan siapa yang dapat menghubungi SAProuter dan sistem SAP mana yang dapat diakses.
  • Aturan NSG lebih lanjut berlaku pada subnet masing-masing dalam subnet produksi SAP yang berisi sistem SAP.

Untuk langkah-langkah mengonfigurasi SAProuter dengan Azure Firewall, lihat Konfigurasi SAProuter dengan Azure Firewall.

Pertimbangan keamanan SAProuter

Karena SAProuter tidak beroperasi di subnet aplikasi yang sama dengan sistem SAP Anda, mekanisme masuk untuk OS mungkin berbeda. Bergantung pada kebijakan Anda, Anda dapat menggunakan domain masuk terpisah atau kredensial pengguna khusus host untuk SAProuter. Jika ada pelanggaran keamanan, akses berkala ke sistem SAP internal tidak dimungkinkan karena basis kredensial yang berbeda. Pemisahan jaringan dalam kasus seperti itu, seperti yang dijelaskan sebelumnya, dapat memisahkan akses lebih lanjut dari SAProuter yang disusupi ke dalam subnet aplikasi Anda. Anda dapat menyelesaikan isolasi ini dengan memutuskan sambungan peering jaringan virtual perimeter SAP.

Pertimbangan ketersediaan tinggi SAProuter

Karena SAProuter adalah file yang dapat dieksekusi sederhana dengan tabel izin rute berbasis file, saProuter dapat dengan mudah dimulai. Aplikasi ini tidak memiliki ketersediaan tinggi bawaan. Jika ada kegagalan VM atau aplikasi, layanan perlu dimulai pada VM lain. Menggunakan nama host virtual untuk layanan SAProuter sangat ideal. Nama host virtual terikat ke IP, yang ditetapkan sebagai konfigurasi IP sekunder dengan NIC VM atau ke load balancer internal yang terhubung ke VM. Dalam konfigurasi ini, jika layanan SAProuter perlu dipindahkan ke VM lain, konfigurasi IP nama host virtual layanan dapat dihapus. Anda kemudian menambahkan nama host virtual pada VM lain tanpa perlu mengubah tabel rute atau konfigurasi firewall. Semuanya dikonfigurasi untuk menggunakan alamat IP virtual. Untuk informasi selengkapnya, lihat Menggunakan Nama Host Virtual SAP dengan Linux di Azure.

SaProuters berskala

Untuk menerapkan SAProuters bertahap, Anda dapat menentukan sebanyak dua SAProuters untuk koneksi dukungan SAP. SAProuter pertama, yang berjalan di subnet aplikasi perimeter SAP, menyediakan akses dari firewall pusat dan dari SAP atau SAProuters mitra. Satu-satunya tujuan yang diizinkan adalah SAProuters lain, berjalan dengan beban kerja tertentu. SAProuters berjenjang dapat menggunakan pemisahan per tingkat, per wilayah, atau per SID, tergantung pada arsitektur Anda. SAProuter kedua hanya menerima koneksi internal dari SAProuter pertama dan menyediakan akses ke sistem dan VM SAP individual. Desain ini memungkinkan Anda untuk memisahkan akses dan manajemen antara tim yang berbeda jika perlu. Untuk contoh SAProuters berskala, lihat konfigurasi SAProuter dengan Azure Firewall.

SAP Fiori dan WebGui

SAP Fiori dan ujung depan HTTPS lainnya untuk aplikasi SAP sering dikonsumsi dari luar jaringan perusahaan internal. Kebutuhan untuk tersedia di internet memerlukan solusi keamanan tinggi untuk membantu melindungi aplikasi SAP. Application Gateway dengan Web Application Firewall adalah layanan yang ideal untuk tujuan ini.

Untuk pengguna yang mengakses nama host publik IP publik yang terkait dengan Application Gateway, sesi HTTPS dihentikan di Application Gateway. Kumpulan back-end dari dua atau beberapa VM SAP Web Dispatcher mendapatkan sesi round-robin dari Application Gateway. Gateway aplikasi lalu lintas internal ke Web Dispatcher ini dapat berupa HTTP atau HTTPS, tergantung pada persyaratan. Firewall aplikasi web membantu melindungi SAP Web Dispatcher dari serangan yang datang melalui internet dengan seperangkat aturan inti OWASP. SAP NetWeaver, sering terikat dengan MICROSOFT Entra ID melalui akses menyeluruh (SSO), melakukan autentikasi pengguna. Untuk langkah-langkah yang diperlukan untuk mengonfigurasi SSO untuk Fiori dengan menggunakan Application Gateway, lihat Konfigurasi Akses Menyeluruh menggunakan SAML dan ID Microsoft Entra untuk URL Publik dan Internal.

Perlu diingat bahwa Anda perlu mengamankan SAP Web Dispatcher dalam situasi apa pun. Bahkan jika hanya terbuka secara internal, buka ke Arah Application Gateway melalui IP publik, atau dapat diakses melalui jaringan lain. Untuk informasi selengkapnya, lihat Informasi Keamanan untuk SAP Web Dispatcher.

Azure Firewall dan Application Gateway

Semua lalu lintas web yang disediakan oleh Application Gateway berbasis HTTPS dan dienkripsi dengan sertifikat TLS yang disediakan. Anda dapat menggunakan Azure Firewall sebagai titik masuk ke jaringan perusahaan, melalui IP publiknya, lalu merutekan lalu lintas SAP Fiori dari firewall ke Application Gateway melalui alamat IP internal. Untuk informasi selengkapnya, lihat Application Gateway setelah firewall. Karena enkripsi lapisan-7 TCP/IP sudah diberlakukan melalui TLS, ada manfaat terbatas untuk menggunakan firewall dalam skenario ini, dan Anda tidak dapat melakukan pemeriksaan paket. Fiori berkomunikasi melalui alamat IP eksternal yang sama untuk lalu lintas masuk dan keluar, yang biasanya tidak diperlukan untuk penyebaran SAP Fiori.

Ada beberapa manfaat dari application gateway tandem dan penyebaran firewall lapisan-4:

  • Kemungkinan integrasi dengan manajemen kebijakan keamanan di seluruh perusahaan.
  • Lalu lintas jaringan yang melanggar aturan keamanan sudah dibuang, sehingga tidak memerlukan pemeriksaan.

Penyebaran gabungan ini adalah arsitektur yang baik. Metode untuk menangani lalu lintas internet masuk tergantung pada arsitektur perusahaan Anda secara keseluruhan. Anda juga perlu mempertimbangkan bagaimana arsitektur jaringan keseluruhan cocok dengan metode akses dari ruang alamat IP internal, seperti klien lokal. Pertimbangan ini tercakup di bagian berikutnya.

Application Gateway untuk alamat IP internal (opsional)

Arsitektur ini berfokus pada aplikasi yang terhubung ke internet. Ada berbagai opsi yang tersedia untuk klien yang mengakses SAP Fiori, UI web sistem SAP NetWeaver, atau antarmuka HTTPS SAP lainnya melalui alamat IP internal privat. Salah satu skenarionya adalah memperlakukan semua akses ke Fiori sebagai akses publik, melalui IP publik. Opsi lain adalah menggunakan akses jaringan langsung melalui jaringan privat ke SAP Web Dispatchers, melewati Application Gateway sepenuhnya. Opsi ketiga adalah menggunakan alamat IP privat dan publik di Application Gateway, menyediakan akses ke internet dan jaringan privat.

Anda dapat menggunakan konfigurasi serupa dengan alamat IP privat di Application Gateway untuk akses jaringan khusus privat ke lanskap SAP. Alamat IP publik dalam kasus ini hanya digunakan untuk tujuan manajemen dan tidak memiliki pendengar yang terkait dengannya.

Sebagai alternatif untuk menggunakan Application Gateway, Anda dapat menggunakan load balancer secara internal. Anda dapat menggunakan load balancer internal standar dengan VM Web Dispatcher yang dikonfigurasi sebagai back end round-robin. Dalam skenario ini, load balancer standar ditempatkan dengan VM Web Dispatcher di subnet aplikasi produksi SAP dan menyediakan penyeimbangan beban aktif/aktif antara VM Web Dispatcher.

Untuk penyebaran yang menghadap internet, kami merekomendasikan Application Gateway dengan Web Application Firewall alih-alih load balancer dengan IP publik.

Platform Teknologi Bisnis SAP (BTP)

SAP BTP adalah sekumpulan besar aplikasi SAP, SaaS atau PaaS, biasanya diakses melalui titik akhir publik melalui internet. SAP Cloud Koneksi or sering digunakan untuk menyediakan komunikasi untuk aplikasi yang berjalan di jaringan privat, seperti sistem SAP S/4HANA yang berjalan di Azure. SAP Cloud Koneksi or berjalan sebagai aplikasi di VM. Ini membutuhkan akses internet keluar untuk membuat terowongan HTTPS terenkripsi TLS dengan SAP BTP. Ini bertindak sebagai proksi pemanggilan balik antara rentang IP privat di jaringan virtual Anda dan aplikasi SAP BTP. Karena dukungan pemanggilan terbalik ini, tidak perlu membuka port firewall atau akses lain untuk koneksi masuk, karena koneksi dari jaringan virtual Anda keluar.

Secara default, VM memiliki akses internet keluar secara asli di Azure. Alamat IP publik yang digunakan untuk lalu lintas keluar, ketika tidak ada alamat IP publik khusus yang terkait dengan komputer virtual, dipilih secara acak dari kumpulan IP publik di wilayah Azure tertentu. Anda tidak dapat mengontrolnya. Untuk memastikan koneksi keluar dibuat melalui layanan dan alamat IP yang terkontrol dan dapat diidentifikasi, Anda dapat menggunakan salah satu metode berikut:

  • Gateway NAT yang terkait dengan subnet atau load balancer dan alamat IP publiknya.
  • Server proksi HTTP yang Anda operasikan.
  • Rute yang ditentukan pengguna yang memaksa lalu lintas jaringan mengalir ke appliance jaringan seperti firewall.

Diagram arsitektur menunjukkan skenario paling umum: merutekan lalu lintas yang terikat internet ke jaringan virtual hub dan melalui firewall pusat. Anda perlu mengonfigurasi pengaturan lebih lanjut di SAP Cloud Koneksi or untuk terhubung ke akun SAP BTP Anda.

Ketersediaan tinggi untuk SAP Cloud Koneksi or

Ketersediaan tinggi dibangun ke dalam SAP Cloud Koneksi or. Cloud Koneksi or diinstal pada dua VM. Instans utama aktif, dan instans bayangan terhubung ke instans tersebut. Mereka berbagi konfigurasi dan tetap sinkron secara asli. Jika instans utama tidak tersedia, VM sekunder mencoba mengambil alih peran utama dan membangun kembali terowongan TLS ke SAP BTP. Lingkungan Cloud Koneksi or dengan ketersediaan tinggi ditampilkan dalam arsitektur. Anda tidak memerlukan teknologi Azure lainnya, seperti load balancer atau perangkat lunak kluster, untuk konfigurasi. Untuk detail tentang konfigurasi dan operasi, lihat dokumentasi SAP.

Agen Cloud Analitik SAP

Untuk beberapa skenario aplikasi, SAP Analytics Cloud Agent adalah aplikasi yang diinstal di VM. Ini menggunakan SAP Cloud Koneksi or untuk konektivitas SAP BTP. Dalam arsitektur ini, VM SAP Analytics Cloud Agent berjalan di subnet aplikasi perimeter SAP, bersama dengan VM SAP Cloud Koneksi or. Untuk arus lalu lintas dari jaringan privat seperti jaringan virtual Azure ke SAP BTP melalui SAP Analytics Cloud Agent, lihat dokumentasi SAP.

SAP menyediakan layanan Private Link untuk SAP BTP. Ini memungkinkan koneksi privat antara layanan SAP BTP yang dipilih dan layanan yang dipilih di langganan Azure dan jaringan virtual Anda. Saat Anda menggunakan layanan Private Link, komunikasi tidak dirutekan melalui internet publik. Tetap berada di backbone jaringan global Azure keamanan tinggi. Komunikasi ke layanan Azure terjadi melalui ruang alamat privat. Perlindungan penyelundupan data yang ditingkatkan dibangun saat Anda menggunakan layanan Private Link, karena titik akhir privat memetakan layanan Azure tertentu ke alamat IP. Akses terbatas pada layanan Azure yang dipetakan.

Untuk beberapa skenario integrasi SAP BTP, pendekatan layanan Private Link lebih disukai. Untuk yang lain, SAP Cloud Koneksi or lebih baik. Untuk informasi guna membantu Anda memutuskan mana yang akan digunakan, lihat Menjalankan Cloud Koneksi or dan SAP Private Link secara berdampingan.

SAP RISE/ECS

Jika SAP mengoperasikan sistem SAP Anda berdasarkan kontrak SAP RISE/ECS, SAP adalah mitra layanan terkelola. Lingkungan SAP disebarkan oleh SAP. Pada arsitektur SAP, arsitektur yang ditampilkan di sini tidak berlaku untuk sistem Anda yang berjalan di RISE dengan SAP/ECS. Untuk informasi tentang mengintegrasikan jenis lanskap SAP ini dengan layanan Azure dan jaringan Anda, lihat dokumentasi Azure.

Persyaratan komunikasi SAP lainnya

Pertimbangan tambahan mengenai komunikasi yang terikat internet mungkin berlaku untuk lanskap SAP yang beroperasi di Azure. Arus lalu lintas dalam arsitektur ini menggunakan firewall Azure pusat untuk lalu lintas keluar ini. Aturan yang ditentukan pengguna di jaringan virtual spoke merutekan permintaan lalu lintas yang terikat internet ke firewall. Atau, Anda dapat menggunakan gateway NAT pada subnet tertentu, komunikasi keluar Azure default, alamat IP publik pada VM (tidak disarankan), atau load balancer publik dengan aturan keluar.

Untuk VM yang berada di belakang load balancer internal standar, seperti yang ada di lingkungan berkluster, perlu diingat bahwa Standard Load Balancer memodifikasi perilaku untuk konektivitas publik. Untuk informasi selengkapnya, lihat artikel Konektivitas titik akhir publik untuk VM menggunakan Azure Standard Load Balancer dalam skenario ketersediaan tinggi SAP.

Pembaruan sistem operasi

Pembaruan sistem operasi sering kali terletak di belakang titik akhir publik dan diakses melalui internet. Jika tidak ada repositori perusahaan dan manajemen pembaruan yang ada, mencerminkan pembaruan OS dari vendor pada alamat IP / VM privat, beban kerja SAP Anda perlu mengakses repositori pembaruan vendor.

Untuk sistem operasi Linux, Anda dapat mengakses repositori berikut jika Anda mendapatkan lisensi OS dari Azure. Jika Anda membeli lisensi secara langsung dan membawanya ke Azure (BYOS), hubungi vendor OS tentang cara menyambungkan ke repositori OS dan rentang alamat IP masing-masing.

Manajemen kluster ketersediaan tinggi

Sistem yang sangat tersedia seperti SAP ASCS/SCS terkluster atau database mungkin menggunakan manajer kluster dengan agen pagar Azure sebagai perangkat STONITH. Sistem ini bergantung pada menjangkau Azure Resource Manager. Resource Manager digunakan untuk kueri status tentang sumber daya Azure dan agar operasi menghentikan dan memulai VM. Karena Resource Manager adalah titik akhir publik, tersedia di bawah management.azure.com, komunikasi keluar VM harus dapat menjangkaunya. Arsitektur ini bergantung pada firewall pusat dengan aturan yang ditentukan pengguna merutekan lalu lintas dari jaringan virtual SAP. Untuk alternatif, lihat bagian sebelumnya.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Kontributor lainnya:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Komunitas

Pertimbangkan untuk menggunakan komunitas ini untuk mendapatkan jawaban atas pertanyaan dan untuk bantuan dalam menyiapkan penyebaran:

Langkah berikutnya