Keamanan integrasi data untuk SAP di Azure

Artikel
07/21/2023

Artikel ini adalah bagian dari seri artikel "SAP extend and innovate data: Best practices".

Artikel ini menjelaskan lapisan keamanan untuk skenario perluasan SAP, memberikan perincian setiap komponen, dan menawarkan pertimbangan dan rekomendasi. Sumber daya manajemen Azure Data Factory dibangun di atas infrastruktur keamanan Azure, dan mereka menggunakan langkah-langkah keamanan Azure.

Lapisan penyerapan data terdiri dari:

SAP S/4HANA, SAP BW/4HANA, atau SAP Hana edisi perusahaan
Azure Data Lake Storage Gen2
Data Factory
Komputer virtual (VM) runtime integrasi yang dihost sendiri (SHIR)

Diagram berikut adalah contoh arsitektur keamanan integrasi data SAP di Azure. Gunakan contoh arsitektur sebagai titik awal.

Unduh file Visio arsitektur ini.

Pertimbangan dan rekomendasi

Bagian berikut menjelaskan pertimbangan dan rekomendasi keamanan integrasi data untuk SAP di Azure.

Keamanan SAP

Panduan keamanan SAP memiliki panduan terperinci untuk produk SAP.

Keamanan Data Lake Storage Gen2

Lihat pertimbangan berikut untuk keamanan Data Lake Storage Gen2.

Otorisasi akses ke data di Azure Storage

Saat Anda mengakses data di akun Penyimpanan, aplikasi klien Anda membuat permintaan melalui HTTP/HTTPS ke Penyimpanan. Secara default, setiap sumber daya di Penyimpanan aman, dan setiap permintaan ke sumber daya yang aman harus diotorisasi. Penyimpanan menawarkan banyak opsi untuk mengotorisasi akses ke data. Sebaiknya gunakan kredensial Microsoft Entra untuk mengotorisasi permintaan ke data untuk keamanan dan kesederhanaan yang optimal. Untuk informasi selengkapnya, lihat Melindungi kunci akses Anda.

Kontrol akses berbasis peran Azure (RBAC)

Gunakan RBAC untuk mengelola izin prinsip keamanan untuk sumber daya blob, antrean, dan tabel di akun Penyimpanan. Anda juga dapat menggunakan kontrol akses berbasis atribut Azure (ABAC) untuk menambahkan kondisi ke penetapan peran Azure untuk sumber daya blob. Untuk informasi selengkapnya, lihat Mengotorisasi akses ke Azure Blob Storage dengan menggunakan kondisi penetapan peran Azure.

Keamanan penyimpanan blob

Pertimbangkan rekomendasi keamanan untuk penyimpanan blob, seperti perlindungan data, manajemen identitas dan akses, jaringan, pengelogan, dan pemantauan. Untuk informasi selengkapnya, lihat Rekomendasi keamanan untuk penyimpanan blob.

Kontrol akses Data Lake Storage Gen2

Data Lake Storage Gen2 mendukung strategi otorisasi berikut:

RBAC
Daftar kontrol akses (ACL)
Kelompok keamanan
Otorisasi kunci bersama dan tanda tangan akses bersama (SAS)

Ada dua jenis ACL di Data Lake Storage Gen2:

Akses ACL mengontrol akses ke objek. File dan direktori memiliki ACL akses.
ACL default adalah templat ACL yang terkait dengan direktori. Mereka menentukan ACL akses untuk item turunan apa pun yang dibuat di bawah direktori tersebut. File tidak memiliki ACL default.

Dalam entri ACL, jangan langsung menetapkan pengguna individu atau perwakilan layanan. Selalu gunakan grup keamanan Microsoft Entra sebagai prinsipal yang ditetapkan. Praktik ini memungkinkan Anda menambahkan dan menghapus pengguna atau perwakilan layanan tanpa menerapkan kembali ACL ke seluruh struktur direktori. Sebagai gantinya, Anda dapat menambahkan atau menghapus pengguna dan perwakilan layanan dari grup keamanan Microsoft Entra yang sesuai. Untuk informasi selengkapnya, lihat Daftar kontrol akses.

Keamanan Data Factory

Lihat pertimbangan berikut untuk keamanan Data Factory.

Pergerakan data

Ada dua skenario pergerakan data: skenario cloud dan skenario hibrid. Untuk informasi tentang keamanan pergerakan data, lihat Pertimbangan keamanan untuk pergerakan data di Data Factory.

Dalam skenario cloud, sumber dan tujuan Anda dapat diakses secara publik melalui internet. Sumber atau tujuan Anda mungkin merupakan layanan penyimpanan cloud terkelola, seperti Azure Storage, Azure Synapse Analytics, Azure SQL Database, Data Lake Storage Gen2, Amazon S3, Amazon Redshift, layanan software-as-a-service (SaaS), seperti Salesforce, atau protokol web, seperti protokol transfer file (FTP) dan protokol data terbuka (OData). Temukan daftar lengkap sumber data yang didukung di penyimpanan dan format data yang didukung.
Dalam skenario hibrid, sumber atau tujuan Anda berada di belakang firewall atau di dalam jaringan perusahaan lokal. Atau penyimpanan data berada di jaringan privat atau jaringan virtual dan tidak dapat diakses secara publik. Dalam hal ini, penyimpanan data biasanya menjadi sumbernya. Skenario hibrid juga mencakup server database yang dihosting di komputer virtual.

Strategi akses data

Organisasi Anda ingin melindungi penyimpanan data mereka, seperti penyimpanan data lokal atau cloud/SaaS, dari akses yang tidak sah melalui internet. Anda dapat mengontrol akses di penyimpanan data cloud anda dengan menggunakan:

Tautan privat dari jaringan virtual ke sumber data yang mendukung titik akhir privat.
Aturan firewall yang membatasi konektivitas dengan menggunakan alamat IP.
Strategi autentikasi yang mengharuskan pengguna membuktikan identitas mereka.
Strategi otorisasi yang membatasi pengguna ke tindakan dan data tertentu.

Untuk informasi selengkapnya, lihat Strategi akses data.

Simpan info masuk di Azure Key Vault

Anda dapat menyimpan kredensial untuk penyimpanan data dan komputasi di Key Vault. Data Factory mengambil kredensial saat aktivitas berjalan yang menggunakan penyimpanan data atau komputasi. Untuk informasi selengkapnya, lihat Menyimpan kredensial di Key Vault dan Menggunakan rahasia Key Vault dalam aktivitas alur.

Enkripsi info masuk

Di Data Factory, pertimbangkan untuk mengenkripsi kredensial untuk penyimpanan data lokal. Pada komputer dengan SHIR, Anda dapat mengenkripsi dan menyimpan kredensial untuk salah satu penyimpanan data lokal Anda, seperti layanan tertaut dengan informasi sensitif. Untuk informasi selengkapnya, lihat Mengenkripsi kredensial untuk penyimpanan data lokal di Data Factory.

Menggunakan identitas terkelola

Saat menggunakan identitas terkelola, Anda tidak perlu mengelola kredensial. Identitas terkelola menyediakan identitas untuk instans layanan saat terhubung ke sumber daya yang mendukung autentikasi Microsoft Entra. Ada dua jenis identitas terkelola yang didukung: Identitas terkelola yang ditetapkan sistem dan identitas terkelola yang ditetapkan pengguna. Untuk informasi selengkapnya, lihat Identitas terkelola untuk Data Factory.

Mengenkripsi dengan kunci yang dikelola pelanggan

Bergantung pada kebijakan keamanan Anda, pertimbangkan untuk mengenkripsi Data Factory dengan kunci yang dikelola pelanggan. Untuk informasi selengkapnya, lihat Mengenkripsi Data Factory dengan kunci yang dikelola pelanggan.

Menggunakan jaringan virtual terkelola

Saat Anda membuat runtime integrasi Azure dalam jaringan virtual yang dikelola Data Factory, runtime integrasi disediakan dengan jaringan virtual terkelola. Ini menggunakan titik akhir privat untuk terhubung dengan aman ke penyimpanan data yang didukung. Titik akhir pribadi adalah alamat IP pribadi di dalam jaringan virtual tertentu dan subnet. Jaringan virtual terkelola hanya didukung di wilayah yang sama dengan wilayah Data Factory. Untuk informasi selengkapnya, lihat Jaringan virtual terkelola Data Factory.

Gunakan Azure Private Link

Saat menggunakan Private Link, Anda dapat terhubung ke penyebaran platform-as-a-service (PaaS) di Azure melalui titik akhir privat. Untuk daftar penyebaran PaaS yang mendukung Private Link, lihat Private Link untuk Data Factory.

Koneksi dan keamanan komputer virtual SHIR

Lihat pertimbangan berikut untuk koneksi dan keamanan komputer virtual SHIR.

Kredensial penyimpanan data di tempat

Anda dapat menyimpan kredensial penyimpanan data lokal di Data Factory, atau mereferensikan kredensial dengan menggunakan Data Factory selama runtime dari Key Vault. Jika Anda menyimpan kredensial di Data Factory, selalu enkripsi kredensial tersebut pada SHIR. Untuk informasi selengkapnya, lihat Kredensial penyimpanan data lokal.

Menyiapkan SHIR berdasarkan konfigurasi jaringan Anda

Untuk pergerakan data hibrid, tabel berikut ini meringkas rekomendasi konfigurasi jaringan dan SHIR berdasarkan kombinasi lokasi sumber dan tujuan yang berbeda.

Sumber	Tujuan	Konfigurasi jaringan	Penyiapan runtime integrasi
Lokal	Jaringan virtual, termasuk semua komputer virtual dan layanan cloud	IPSec VPN (point-to-site atau situs-ke-situs)	Menginstal SHIR pada komputer virtual Azure di jaringan virtual
Lokal	Jaringan virtual, termasuk semua komputer virtual dan layanan cloud	Azure ExpressRoute (peering privat)	Menginstal SHIR pada komputer virtual Azure di jaringan virtual
Lokal	Layanan berbasis Azure yang memiliki titik akhir publik	ExpressRoute (peering Microsoft)	Menginstal SHIR lokal atau di komputer virtual Azure

ExpressRoute atau IPSec VPN

Gambar berikut menunjukkan cara menggunakan SHIR untuk memindahkan data antara database lokal dan layanan Azure dengan menggunakan Azure Virtual Network dan ExpressRoute atau IPSec VPN.

Untuk konfigurasi firewall dan penyiapan daftar yang diizinkan untuk alamat IP, lihat Pertimbangan keamanan untuk pergerakan data di Data Factory.

Diagram ini memperlihatkan cara memindahkan data dengan menggunakan peering privat ExpressRoute:

Diagram ini memperlihatkan cara memindahkan data dengan menggunakan IPSec VPN:

Di firewall, pastikan bahwa alamat IP komputer SHIR diizinkan dan dikonfigurasi dengan tepat. Penyimpanan data cloud berikut mengharuskan Anda mengizinkan alamat IP komputer SHIR. Secara default, beberapa penyimpanan data ini mungkin tidak memerlukan daftar yang diizinkan.

Microsoft Azure SQL Database
Azure Synapse Analytics
Data Lake Storage Gen2
Azure Cosmos DB
Amazon Redshift

Untuk informasi selengkapnya, lihat Pertimbangan keamanan untuk pergerakan data di Data Factory dan Membuat dan mengonfigurasi SHIR.

Keamanan Azure Databricks

Lihat pertimbangan berikut untuk keamanan Azure Databricks.

Garis besar keamanan Azure untuk Azure Databricks

Pertimbangkan garis besar keamanan Azure untuk Azure Databricks. Garis besar keamanan ini menerapkan panduan dari tolok ukur keamanan cloud Microsoft versi 1.0 ke Azure Databricks. Tolok ukur keamanan cloud Microsoft memberikan rekomendasi tentang cara mengamankan solusi cloud Anda di Azure.

Keamanan Azure Synapse Analytics

Azure Synapse Analytics menerapkan arsitektur keamanan berlapis untuk perlindungan menyeluruh data Anda. Ada lima lapisan:

Perlindungan data mengidentifikasi dan mengklasifikasikan data sensitif dan mengenkripsi data tidak aktif dan bergerak. Untuk rekomendasi penemuan dan klasifikasi, tata kelola, dan enkripsi data, lihat Perlindungan data.
Kontrol akses menentukan hak pengguna untuk berinteraksi dengan data. Azure Synapse Analytics mendukung berbagai kemampuan untuk mengontrol siapa yang dapat mengakses data apa. Untuk informasi selengkapnya, lihat Kontrol akses.
Autentikasi membuktikan identitas pengguna dan aplikasi. Audit Azure SQL dapat mencatat aktivitas autentikasi, dan administrator TI dapat mengonfigurasi laporan dan pemberitahuan setiap kali ada upaya masuk dari lokasi yang mencurigakan. Untuk informasi lebih lanjut, lihat Autentikasi.
Keamanan jaringan mengisolasi lalu lintas jaringan dengan titik akhir privat dan jaringan privat virtual. Ada banyak opsi keamanan jaringan untuk mengamankan Azure Synapse Analytics. Untuk informasi selengkapnya, lihat Keamanan jaringan.
Deteksi ancaman mengidentifikasi potensi ancaman keamanan, seperti lokasi akses yang tidak biasa, serangan injeksi SQL, dan serangan autentikasi. Untuk informasi selengkapnya, lihat Deteksi ancaman.

Lapisan presentasi data

Pertimbangkan bagaimana Anda dapat menggunakan kemampuan keamanan untuk mempertahankan lapisan presentasi, termasuk Power BI. Untuk informasi selengkapnya, lihat Keamanan Power BI dan perencanaan implementasi Power BI: Keamanan.