Privasi data untuk analitik skala cloud di Azure

Artikel
10/10/2023

Analitik skala cloud membebaskan organisasi untuk menentukan pola terbaik agar sesuai dengan kebutuhan mereka sambil menjaga data pribadi di beberapa tingkat. Data pribadi adalah semua data yang dapat digunakan untuk mengidentifikasi individu, misalnya, nomor SIM, nomor jaminan sosial, nomor rekening bank, nomor paspor, alamat email, dan banyak lagi. Banyak peraturan yang ada saat ini untuk melindungi privasi pengguna.

Skema klasifikasi kerahasiaan data

Klasifikasi	Deskripsi
Publik	Siapa pun dapat mengakses data dan dapat dikirim ke siapa saja. Misalnya, buka data pemerintah.
Hanya untuk penggunaan internal	Hanya karyawan yang dapat mengakses data dan tidak dapat dikirim ke luar perusahaan.
Rahasia	Data hanya dapat dibagikan jika diperlukan untuk tugas tertentu. Data tidak dapat dikirim ke luar perusahaan tanpa perjanjian non-pengungkapan.
Sensitif (data pribadi)	Data berisi informasi privat, yang harus ditutupi dan dibagikan hanya berdasarkan kebutuhan untuk mengetahui untuk waktu yang terbatas. Data tidak dapat dikirim ke personel yang tidak berwenang atau di luar perusahaan.
Terbatas	Data hanya dapat dibagikan dengan individu bernama yang bertanggung jawab atas perlindungannya. Misalnya, dokumen hukum atau rahasia dagang.

Sebelum menyerap data, Anda harus mengategorikan data tersebut sebagai rahasia atau di bawahnya atau sensitif (data pribadi):

Data dapat diurutkan menjadi rahasia atau di bawahnya jika pengguna mendapatkan akses ke aset data yang diperkaya atau dikumpulkan. Pengguna dapat melihat semua kolom dan baris.
Data dapat diurutkan menjadi sensitif (data pribadi) jika terdapat batasan untuk kolom dan baris yang dapat dilihat oleh pengguna yang berbeda.

Penting

Himpunan data dapat berubah dari rahasia atau di bawahnya menjadi sensitif (data pribadi) ketika data digabungkan. Dalam situasi di mana data harus persisten, data tersebut harus disalin ke folder terpisah yang selaras dengan klasifikasi kerahasiaan data dan proses untuk onboarding data tersebut.

Rahasia atau di bawahnya

Untuk setiap produk data onboarding, kami membuat dua folder data lake di lapisan yang diperkaya dan dikumpulkan, rahasia atau di bawahnya dan sensitif (data pribadi), dan menggunakan daftar kontrol akses untuk mengaktifkan Autentikasi Pass-through direktori Microsoft Azure (MICROSOFT Entra ID).

Jika tim aplikasi data melakukan onboarding aset data rahasia atau di bawahnya , maka nama utama pengguna dan objek perwakilan layanan dapat ditambahkan ke dua grup Microsoft Entra (satu untuk akses baca/tulis dan yang lainnya untuk akses baca-saja). Kedua grup Microsoft Entra ini harus dibuat selama proses orientasi dan diurutkan dalam folder produk data yang sesuai dengan kontainer rahasia atau di bawahnya untuk data mentah dan diperkaya.

Pola ini memungkinkan produk komputasi apa pun yang mendukung autentikasi pass-through Microsoft Entra untuk terhubung ke data lake dan mengautentikasi pengguna yang masuk. Jika pengguna adalah bagian dari grup Microsoft Entra aset data, mereka dapat mengakses data melalui autentikasi pass-through Microsoft Entra. Hal ini memungkinkan pengguna di dalam grup untuk membaca seluruh aset data tanpa filter kebijakan. Akses kemudian dapat diaudit secara rinci dengan log dan Microsoft Graph yang sesuai.

Untuk rekomendasi tentang tata letak data lake Anda, tinjau Penyediaan tiga akun Azure Data Lake Storage Gen2 untuk setiap zona pendaratan data.

Catatan

Contoh produk komputasi adalah Azure Databricks, Azure Synapse Analytics, Apache Spark, dan kumpulan sesuai permintaan Azure Synapse SQL yang diaktifkan dengan autentikasi pass-through Microsoft Entra.

Data sensitif (data pribadi)

Untuk sensitif (data pribadi), perusahaan perlu membatasi apa yang dapat dilihat pengguna melalui kebijakan, salinan data, atau komputasi. Dalam hal ini, organisasi perlu mempertimbangkan untuk memindahkan atau menyuntikkan kontrol akses ke dalam lapisan komputasi. Ada empat opsi untuk mendekati pengamanan data dalam analitik skala cloud.

Contoh skenario

Contoh berikut menjelaskan opsi untuk mengamankan sensitif (data pribadi):

Aplikasi data menyerap produk data personel sumber daya manusia (SDM) untuk Amerika Utara dan Eropa. Kasus penggunaan meminta pengguna Eropa untuk hanya melihat catatan personel Eropa dan pengguna Amerika Utara untuk hanya melihat catatan personel Amerika Utara. Ini dibatasi lebih lanjut sehingga hanya manajer SDM yang melihat kolom yang berisi data gaji.

Opsi 1: Mesin kebijakan (disarankan)

Dua opsi pertama menyediakan cara untuk menangani sensitif (data pribadi), dan mereka juga memberikan kontrol untuk operasi integrasi dan tim produk data untuk mengidentifikasi dan membatasi akses. Ini mungkin cukup untuk platform analitik skala kecil, tetapi mesin kebijakan harus ditempatkan di zona pendaratan manajemen data untuk perusahaan besar dengan ratusan produk data. Mesin kebijakan mendukung cara utama mengelola, mengamankan, dan mengendalikan:

Akses ke data
Mengelola siklus hidup data
Kebijakan dan peraturan internal dan eksternal
Kebijakan berbagi data
Mengidentifikasi sensitif (data pribadi)
Wawasan mengenai perlindungan dan kepatuhan
Kebijakan untuk pelaporan perlindungan data

Umumnya, mesin kebijakan akan terintegrasi dengan katalog data seperti Azure Purview. Azure Marketplace menghadirkan solusi vendor pihak ketiga, dan beberapa vendor bekerja dengan Azure Synapse dan Azure Databricks untuk mengenkripsi dan mendekripsi informasi selagi menyediakan keamanan tingkat baris dan tingkat kolom. Pada Jan 2022, Azure Purview telah meluncurkan pratinjau publik untuk kebijakan akses guna mengontrol akses ke data yang disimpan di Blob dan Azure Data Lake Storage (ADLS) Gen2. Lihat Provisi himpunan data oleh pemilik data untuk Azure Storage (pratinjau).

Mesin kebijakan harus menggunakan grup Microsoft Entra untuk menerapkan kebijakan ke produk data. Harapan untuk setiap solusi kebijakan yang menyediakan privasi data adalah untuk membuat token sensitif (data pribadi) dan untuk selalu memeriksa melalui kontrol akses atribut sehingga pengguna dapat membatalkan token kolom yang perlu mereka akses.

Seperti yang telah disebutkan, agar mesin kebijakan berhasil, penting bagi mesin kebijakan tersebut untuk berintegrasi ke dalam katalog data dan bagi DevOps untuk menggunakan REST API untuk melakukan onboard pada himpunan data baru. Saat tim aplikasi data membuat sumber data baca, mereka akan terdaftar di katalog data dan membantu mengidentifikasi sensitif (data pribadi). Mesin kebijakan harus mengimpor definisi dan menolak semua akses ke data hingga tim telah menyiapkan kebijakan aksesnya. Semua ini harus dilakukan melalui alur kerja REST API dari solusi manajemen layanan TI.

Opsi 2: Versi rahasia atau di bawah dan sensitif (data pribadi)

Untuk setiap produk data yang diklasifikasikan sebagai sensitif (data pribadi) dua salinan dibuat oleh alurnya. Salah satu yang diklasifikasikan sebagai rahasia atau di bawah ini yang memiliki semua kolom sensitif (data pribadi) dihapus dan dibuat di bawah folder rahasia atau di bawah ini untuk produk data. Salinan lain dibuat di folder sensitif (data pribadi), untuk produk data, yang memiliki semua data sensitif yang disertakan. Setiap folder akan diberi grup keamanan pembaca Microsoft Entra dan grup keamanan penulis Microsoft Entra. Menggunakan Manajemen Akses Data, pengguna dapat meminta akses ke produk data.

Sementara ini memenuhi pemisahan sensitif (data pribadi) dan rahasia atau di bawahnya, pengguna yang diberikan akses melalui autentikasi passthrough Direktori Aktif ke sensitif (data pribadi) akan dapat mengkueri semua baris. Jika Anda memerlukan keamanan tingkat baris, Anda harus menggunakan Opsi 1: Mesin kebijakan (disarankan ) atau Opsi 3: Azure SQL Database, SQL Managed Instance, atau kumpulan Azure Synapse Analytics SQL.

Opsi 3: Kumpulan Azure SQL Database, SQL Managed Instance, atau Azure Synapse Analytics SQL

Aplikasi data menggunakan kumpulan SQL Database, SQL Managed Instance, atau Azure Synapse Analytics SQL untuk memuat produk data ke dalam database yang mendukung keamanan tingkat baris, keamanan tingkat kolom, dan masking data dinamis. Tim aplikasi data membuat grup Microsoft Entra yang berbeda dan menetapkan izin yang mendukung sensitivitas data.

Untuk kasus penggunaan skenario ini, tim aplikasi data harus membuat empat grup Microsoft Entra berikut dengan akses baca-saja:

Grupkan	Izin
`DA-AMERICA-HRMANAGER-R`	Lihat aset data personel SDM Amerika Utara dengan informasi gaji.
`DA-AMERICA-HRGENERAL-R`	Lihat aset data personel SDM Amerika Utara tanpa informasi gaji.
`DA-EUROPE-HRMANAGER-R`	Lihat aset data personel SDM Eropa dengan informasi gaji.
`DA-EUROPE-HRGENERAL-R`	Lihat aset data personel SDM Eropa tanpa informasi gaji.

Tingkat pembatasan pertama akan mendukung masking data dinamis, yang menyembunyikan data sensitif dari pengguna tanpa hak istimewa. Salah satu keuntungan dari pendekatan ini adalah pendekatan ini dapat diintegrasikan ke dalam onboarding himpunan data dengan REST API.

Tingkat kedua adalah menambahkan keamanan tingkat kolom untuk membatasi manajer non-SDM melihat gaji dan keamanan tingkat baris untuk membatasi baris mana yang dapat dilihat anggota tim Eropa dan Amerika Utara.

Selain enkripsi data transparan, lapisan keamanan dimaksudkan untuk mengenkripsi kolom data dan mendekripsi saat dibaca.

Tabel dapat dibuat agar tersedia untuk Azure Databricks dengan konektor Apache Spark: SQL Server dan Azure SQL Database.

Opsi 4: Azure Databricks

Opsi empat adalah menggunakan Azure Databricks untuk menjelajahi sensitif (data pribadi). Menggunakan kombinasi pustaka enkripsi Fernet, fungsi yang ditentukan pengguna (UDF), rahasia Databricks, kontrol akses tabel, dan fungsi tampilan dinamis membantu mengenkripsi dan mendekripsi kolom.

Sesuai dengan postingan blog, memberlakukan enkripsi tingkat Kolom dan menghindari duplikasi data, yang menjelaskan:

Langkah pertama dalam proses ini adalah melindungi data dengan mengenkripsinya selama penyerapan dan satu solusi yang memungkinkan adalah pustaka Python Fernet. Fernet menggunakan enkripsi simetris, yang dibangun dengan beberapa kriptografi standar primitif. Pustaka ini digunakan dalam UDF enkripsi yang akan memungkinkan kami untuk mengenkripsi kolom tertentu dalam bingkai data. Untuk menyimpan kunci enkripsi, kami menggunakan rahasia Databricks dengan kontrol akses yang terpasang untuk hanya memungkinkan proses penyerapan data kami untuk mengaksesnya. Setelah data ditulis ke tabel Delta Lake kami, kolom data pribadi yang menyimpan nilai-nilai seperti nomor jaminan sosial, nomor telepon, nomor kartu kredit, dan pengidentifikasi lainnya tidak mungkin dibaca oleh pengguna yang tidak berwenang.

Setelah data sensitif ditulis dan dilindungi, Anda memerlukan cara bagi pengguna dengan hak istimewa untuk membaca data sensitif tersebut. Hal pertama yang perlu dilakukan adalah membuat UDF permanen untuk ditambahkan ke instans Apache Hive yang berjalan di Databricks. Agar UDF menjadi permanen, UDF tersebut harus ditulis dalam Scala. Untungnya, Fernet juga memiliki implementasi Scala yang dapat Anda gunakan untuk bacaan dekripsi Anda. UDF ini juga mengakses rahasia yang sama dengan yang digunakan dalam penulisan terenkripsi untuk melakukan dekripsi, dan, dalam hal ini, ditambahkan ke konfigurasi Spark dari kluster. Ini mengharuskan kami untuk menambahkan kontrol akses kluster bagi pengguna dengan hak istimewa dan non-istimewa untuk mengontrol akses mereka ke kunci. Setelah UDF dibuat, kita dapat menggunakannya dalam definisi tampilan kami untuk pengguna dengan hak istimewa untuk melihat data yang didekripsi.

Dengan fungsi tampilan dinamis, Anda hanya dapat membuat satu tampilan dan mengembalikan nilai yang dienkripsi atau didekripsi berdasarkan grup Databricks tempat mereka berada.

Dalam contoh sebelumnya, Anda akan membuat dua fungsi tampilan dinamis, satu untuk Amerika Utara dan satu lagi untuk Eropa, dan menerapkan teknik enkripsi dalam buku catatan ini.

Tampilan Amerika Utara:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_us AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-AMERICA-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='US'

Tampilan Eropa:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_eu AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-EUROPE-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='EU'

Agar ini berfungsi, Anda harus mengaktifkan kontrol akses tabel Azure Databricks di ruang kerja dan menerapkan izin berikut:

Memberikan DA-AMERICA-HRMANAGER-R akses DA-AMERICA-HRGENERAL-R grup Microsoft Entra ke vhr_us tampilan.
Memberikan DA-EUROPE-HRMANAGER-R akses DA-EUROPE-HRGENERAL-R grup Microsoft Entra ke vhr_eu tampilan.

Karena kolom dienkripsi dan tidak dapat didekripsi di ruang kerja rahasia atau di bawah ini , ruang kerja rahasia atau di bawah ini masih dapat menggunakan autentikasi pass-through Microsoft Entra dan memungkinkan pengguna menjelajahi danau, berdasarkan izin mereka.

Di tempat akses tabel digunakan, tim yang memerlukan akses ditambahkan ke ruang kerja Azure Databricks. Azure Databricks akan menggunakan perwakilan layanan untuk memetakan ke Azure Data Lake Storage, tetapi data akan diamankan dengan kontrol akses tabel Azure Databricks.

Saat produk data baru disebarkan, bagian dari proses DevOps perlu menjalankan skrip untuk menyiapkan izin tabel di ruang kerja Azure Databricks dan menambahkan grup Microsoft Entra yang benar ke izin tersebut.

Catatan

Kontrol akses tabel Azure Databricks tidak dapat digabungkan dengan autentikasi pass-through Microsoft Entra. Oleh karena itu, Anda hanya dapat menggunakan satu ruang kerja Azure Databricks dan menggunakan kontrol akses tabel sebagai gantinya.

Data terbatas

Bersama dengan menerapkan opsi untuk data rahasia atau terbatas, kami juga menyarankan Anda menghosting data yang sangat rahasia di zona pendaratan data khusus dan zona pendaratan manajemen data.

Ini memungkinkan persyaratan khusus seperti akses just-in-time, kunci yang dikelola pelanggan untuk enkripsi, dan pembatasan masuk atau keluar yang diterapkan ke zona pendaratan. Panduan telah mengevaluasi penempatan data jenis ini ke zona pendaratan data yang sama tetapi dengan akun penyimpanan yang berbeda. Namun, hal ini dapat membuat solusi menjadi rumit pada lapisan jaringan, misalnya, dengan kelompok keamanan jaringan dan lain-lain.

Zona pendaratan manajemen data 'terbatas' khusus harus terhubung ke katalog data di zona pendaratan data 'terbatas'. Zona pendaratan ini harus membatasi siapa yang dapat mencari data ini di katalog.

Langkah berikutnya

Manajemen Akses Data