Azure'da bulut ölçeğinde analiz için veri gizliliği

Bulut ölçeğinde analiz, kuruluşların kişisel verileri birden çok düzeyde korurken gereksinimlerine uygun en iyi desenleri belirlemesini sağlar. Kişisel veriler, ehliyet numaraları, sosyal güvenlik numaraları, banka hesap numaraları, pasaport numaraları, e-posta adresleri ve daha fazlası gibi kişileri tanımlamak için kullanılabilecek herhangi bir veridir. Günümüzde kullanıcı gizliliğini korumak için birçok düzenleme mevcuttur.

Veri gizliliği sınıflandırma düzeni

Sınıflandırma	Tanım
Sunulabilir	Verilere herkes erişebilir ve herkese gönderilebilir. Örneğin, kamu verilerini açın.
Yalnızca iç kullanım	Verilere yalnızca çalışanlar erişebilir ve şirket dışına gönderemez.
Gizli	Veriler yalnızca belirli bir görev için gerekliyse paylaşılabilir. Veriler gizlilik sözleşmesi olmadan şirket dışına gönderilemez.
Hassas (kişisel veriler)	Veriler, sınırlı bir süre için yalnızca bilinmesi gereken bir şekilde maskelenip paylaşılması gereken özel bilgiler içerir. Veriler yetkisiz personele veya şirket dışına gönderilemiyor.
Kısıtlı	Veriler yalnızca korunmasından sorumlu olan adlandırılmış kişilerle paylaşılabilir. Örneğin, yasal belgeler veya ticari gizli diziler.

Verileri almadan önce, verileri gizli veya daha altında veya hassas (kişisel veriler) olarak kategorilere ayırmanız gerekir:

• Bir kullanıcı zenginleştirilmiş veya seçilmiş veri varlığına erişim elde ederse veriler gizli veya aşağıda sıralanabilir. Kullanıcılar tüm sütunları ve satırları görüntüleyebilir.

• Sütunlar ve satırların farklı kullanıcılar tarafından görülebileceği kısıtlamalar varsa veriler hassas (kişisel veriler) olarak sıralanabilir.

Önemli

Veri kümesi, veriler birleştirildiğinde gizli veya aşağıdan hassas (kişisel veriler) olarak değişebilir. Verilerin kalıcı olması gereken durumlarda, veri gizliliği sınıflandırması ve ekleme işlemiyle uyumlu ayrı bir klasöre kopyalanmalıdır.

Gizli veya altı

Eklenen her veri ürünü için, zenginleştirilmiş ve seçilmiş katmanlarda gizli veya altve hassas (kişisel veriler) olmak üzere iki data lake klasörü oluştururuz ve Erişim denetim listelerini kullanarak Microsoft Azure dizini (Microsoft Entra ID) Geçiş Kimlik Doğrulaması'nı etkinleştiririz.

Veri uygulaması ekibi gizli veya daha küçük bir veri varlığı eklerse, kullanıcı asıl adları ve hizmet sorumlusu nesneleri iki Microsoft Entra grubuna eklenebilir (biri okuma/yazma erişimi, diğeri salt okunur erişim için). Bu iki Microsoft Entra grubu, ekleme işlemi sırasında oluşturulmalı ve ham ve zenginleştirilmiş veriler için gizli veya aşağıdaki kapsayıcılarla uygun veri ürün klasöründe sıralanmalıdır.

Bu düzen, Microsoft Entra geçiş kimlik doğrulamasını destekleyen tüm işlem ürünlerinin data lake'e bağlanmasını ve oturum açmış kullanıcıların kimliğini doğrulamasını sağlar. Bir kullanıcı veri varlığının Microsoft Entra grubunun bir parçasıysa, Microsoft Entra doğrudan kimlik doğrulaması aracılığıyla verilere erişebilir. Grup içindeki kullanıcıların ilke filtreleri olmadan veri varlığının tamamını okumasına olanak tanır. Erişim daha sonra uygun günlükler ve Microsoft Graph ile ayrıntılı olarak denetlenebilir.

Veri gölünüzün düzeniyle ilgili öneriler için lütfen Her veri giriş bölgesi için üç Azure Data Lake Storage 2. Nesil hesabı sağlama'ya bakın.

Dekont

İşlem ürünlerine örnek olarak Azure Databricks, Azure Synapse Analytics, Apache Spark ve Microsoft Entra doğrudan kimlik doğrulaması ile etkinleştirilen azure synapse SQL isteğe bağlı havuzları verilebilir.

Hassas veriler (kişisel veriler)

Hassas (kişisel veriler) için kuruluşun kullanıcıların ilke, veri kopyaları veya işlem yoluyla görebileceklerini kısıtlaması gerekir. Bu durumda kuruluşun erişim denetimini işlem katmanına taşımayı veya eklemeyi düşünmesi gerekir. Bulut ölçeğinde analizde verilerin güvenliğini sağlamaya yönelik dört seçenek vardır.

Örnek senaryo

Aşağıdaki örnekte hassas (kişisel verilerin) güvenliğini sağlama seçenekleri açıklanmaktadır:

Veri uygulaması, Kuzey Amerika ve Avrupa için bir insan kaynakları (İk) personel veri ürünü alır. Kullanım örneği, Avrupalı kullanıcıların yalnızca Avrupa personel kayıtlarını ve Kuzey Amerika kullanıcıların yalnızca Kuzey Amerika n personel kayıtlarını görmesi için çağrıda bulunur. Yalnızca İk yöneticilerinin maaş verilerini içeren sütunları görmesi için daha da kısıtlanmıştır.

Seçenek 1: İlke altyapısı (önerilir)

İlk iki seçenek hassas (kişisel verileri) işlemek için bir yol sağlar ve ayrıca erişimi tanımlamak ve kısıtlamak için tümleştirme işlemlerine ve veri ürün ekiplerine denetim sağlar. Küçük ölçekli bir analiz platformu için yeterli olabilir, ancak yüzlerce veri ürünü içeren büyük bir kuruluş için veri yönetimi giriş bölgesine bir ilke altyapısı yerleştirilmelidir. İlke altyapıları şunları yönetme, güvenli hale getirme ve denetlemenin merkezi bir yolunu destekler:

• Verilere erişim
• Veri yaşam döngüsünü yönetme
• İç ve dış ilkeler ve düzenlemeler
• Veri paylaşımı ilkeleri
• Hassas verileri tanımlama (kişisel veriler)
• Koruma ve uyumluluk hakkında Analizler
• Veri koruma raporlama ilkeleri

Genellikle bir ilke altyapısı Azure Purview gibi bir veri kataloğuyla tümleşir. Azure Market üçüncü taraf satıcı çözümleri bulunur ve bazı satıcılar bilgileri şifrelemek ve şifrelerini çözmek için Azure Synapse ve Azure Databricks ile birlikte çalışırken satır düzeyi ve sütun düzeyinde güvenlik sağlar. Azure Purview, Ocak 2022'de olduğu gibi Blob ve Azure Data Lake Depolama (ADLS) 2. Nesil'de depolanan verilere erişimi denetlemek için erişim ilkeleri için genel bir önizleme başlattı. Bkz. Azure Depolama (önizleme) için veri sahibi tarafından veri kümesi sağlama.

İlke altyapısı, veri ürünlerine ilke uygulamak için Microsoft Entra gruplarını kullanmalıdır. Veri gizliliği sağlayan herhangi bir ilke çözümünün beklentisi, hassas (kişisel verileri) belirteç haline getirmek ve kullanıcının erişmesi gereken sütunları kaldırabilmesi için öznitelik erişim denetimi aracılığıyla her zaman kontrol etmektir.

Belirtildiği gibi, bir ilke altyapısının başarılı olması için veri kataloğuyla tümleştirilmesi ve DevOps'un yeni bir veri kümesi eklemek için REST API kullanması önemlidir. Veri uygulaması ekipleri okuma veri kaynakları oluşturdukça, bunlar veri kataloğuna kaydedilir ve hassas verilerin (kişisel veriler) tanımlanmasına yardımcı olur. İlke altyapısı tanımı içeri aktarmalı ve takımlar erişim ilkelerini ayarlayana kadar verilere tüm erişimi reddetmelidir. Bunların tümü, BT hizmet yönetimi çözümünden rest API iş akışı aracılığıyla yapılmalıdır.

2. Seçenek: Gizli veya altı ve hassas (kişisel veri) sürümleri

Hassas (kişisel veriler) olarak sınıflandırılan her veri ürünü için işlem hattı tarafından iki kopya oluşturulur. Tüm hassas (kişisel veri) sütunlarının kaldırıldığı gizli veya aşağıda sınıflandırılan ve veri ürünü için gizli veya aşağıdaki klasör altında oluşturulan bir sütun. Diğer kopya, tüm hassas verileri içeren veri ürünü için hassas (kişisel veriler) klasöründe oluşturulur. Her klasöre bir Microsoft Entra okuyucu güvenlik grubu ve bir Microsoft Entra yazıcı güvenlik grubu atanır. Kullanıcı, Veri Erişim Yönetimi'ni kullanarak veri ürününe erişim isteyebilir.

Bu, hassas (kişisel veriler) ve gizli veya daha aşağıdan ayrılmayı karşılasa da, hassas (kişisel veriler) için Active Directory geçiş kimlik doğrulaması aracılığıyla erişim izni veren bir kullanıcı tüm satırları sorgulayabilecektir. Satır düzeyi güvenlik gerekiyorsa Seçenek 1: İlke altyapısı (önerilir) veya Seçenek 3: Azure SQL Veritabanı, SQL Yönetilen Örneği veya Azure Synapse Analytics SQL havuzlarını kullanmanız gerekir.

3. Seçenek: Azure SQL Veritabanı, SQL Yönetilen Örneği veya Azure Synapse Analytics SQL havuzları

Veri uygulaması SQL Veritabanı, SQL Yönetilen Örneği veya Azure Synapse Analytics SQL havuzlarını kullanarak veri ürünlerini satır düzeyi güvenlik, sütun düzeyinde güvenlik ve dinamik veri maskelemesi destekleyen bir veritabanına yükler. Veri uygulaması ekipleri farklı Microsoft Entra grupları oluşturur ve verilerin duyarlılığını destekleyen izinler atar.

Bu senaryonun kullanım örneği için veri uygulaması ekiplerinin salt okunur erişime sahip aşağıdaki dört Microsoft Entra grubunu oluşturması gerekir:

Gruplandırma	İzin
DA-AMERICA-HRMANAGER-R	maaş bilgileriyle Kuzey Amerika İk personeli veri varlığını görüntüleyin.
DA-AMERICA-HRGENERAL-R	maaş bilgileri olmadan İk personeli veri varlığını Kuzey Amerika görüntüleyin.
DA-EUROPE-HRMANAGER-R	Maaş bilgileriyle Avrupa İk personel veri varlığını görüntüleyin.
DA-EUROPE-HRGENERAL-R	Maaş bilgileri olmadan Avrupa İk personel veri varlığını görüntüleyin.

İlk kısıtlama düzeyi, hassas verileri ayrıcalıkları olmayan kullanıcılardan gizleyen dinamik veri maskeleme desteği sağlar. Bu yaklaşımın avantajlarından biri, rest API ile veri kümesinin eklemesiyle tümleştirilebiliyor olmasıdır.

İkinci düzey, İk dışı yöneticilerin maaşları görmesini ve satır düzeyi güvenliği kısıtlayarak Avrupa ve Kuzey Amerika ekip üyelerinin görebileceği satırları kısıtlamak için sütun düzeyi güvenlik eklemektir.

Saydam veri şifrelemeye ek olarak, güvenlik katmanı veri sütununu şifrelemek ve okundukça şifresini çözmek olacaktır.

Tablolar Apache Spark bağlayıcısı ile Azure Databricks tarafından kullanılabilir hale getirilebilir: SQL Server ve Azure SQL Veritabanı.

Seçenek 4: Azure Databricks

Dördüncü seçenek, hassas verileri (kişisel veriler) keşfetmek için Azure Databricks'i kullanmaktır. Fernet şifreleme kitaplıkları, kullanıcı tanımlı işlevler (UDF' ler), Databricks gizli dizileri, tablo erişim denetimi ve dinamik görünüm işlevlerinin birleşimini kullanmak sütunları şifrelemeye ve şifresini çözmeye yardımcı olur.

Blog gönderisi olarak, Sütun düzeyinde şifrelemeyi zorunlu kılma ve veri yinelemesini önleme, şunları açıklar:

Bu işlemin ilk adımı, verileri alma sırasında şifreleyerek korumaktır ve olası çözümlerden biri De Fernet Python kitaplığıdır. Fernet, çeşitli standart şifreleme temel bilgileriyle oluşturulan simetrik şifrelemeyi kullanır. Bu kitaplık, veri çerçevesindeki belirli bir sütunu şifrelememizi sağlayacak bir şifreleme UDF'sinde kullanılır. Şifreleme anahtarını depolamak için, yalnızca veri alma işlemimizin erişim izni vermek için erişim denetimleri olan Databricks gizli dizilerini kullanırız. Veriler Delta Lake tablolarımıza yazıldıktan sonra, sosyal güvenlik numarası, telefon numarası, kredi kartı numarası ve diğer tanımlayıcılar gibi değerlerin bulunduğu kişisel veri sütunları yetkisiz bir kullanıcının okuması mümkün olmayacaktır.

Hassas veriler yazıldıktan ve korunduktan sonra, ayrıcalıklı kullanıcıların hassas verileri okuması için bir yol gerekir. Yapılması gereken ilk şey, Databricks üzerinde çalışan Hive örneğine eklemek için kalıcı bir UDF oluşturmaktır. UDF'nin kalıcı olması için Scala'da yazılması gerekir. Neyse ki Fernet,şifresi çözülmüş okumalarınız için kullanabileceğiniz bir Scala uygulamasına da sahiptir. Bu UDF, şifre çözme işlemini gerçekleştirmek için şifrelenmiş yazmada kullanılan gizli diziye de erişir ve bu örnekte kümenin Spark yapılandırmasına eklenir. Bu, anahtara erişimlerini denetlemek için ayrıcalıklı ve ayrıcalıklı olmayan kullanıcılar için küme erişim denetimleri eklememizi gerektirir. UDF oluşturulduktan sonra, bunu ayrıcalıklı kullanıcıların şifresi çözülen verileri görebilmesi için görünüm tanımlarımız içinde kullanabiliriz.

Dinamik görünüm işlevleriyle yalnızca bir görünüm oluşturabilir ve ait oldukları Databricks grubuna göre şifrelenmiş veya şifresi çözülmüş değerleri döndürebilirsiniz.

Önceki örnekte biri Kuzey Amerika diğeri de Avrupa için olan iki dinamik görünüm işlevi oluşturacak ve şifreleme tekniklerini bu not defterine uygulayacaksınız.

Kuzey Amerika görünümü:

-- 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'

Avrupa görünümü:

-- 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'

Bunun çalışması için çalışma alanında Azure Databricks tablosu erişim denetimini etkinleştirir ve aşağıdaki izinleri uygularsınız:

• Görünüme erişim izni verin DA-AMERICA-HRMANAGER-R ve DA-AMERICA-HRGENERAL-R Microsoft Entra gruplarına vhr_us erişim verin.
• Görünüme erişim izni verin DA-EUROPE-HRMANAGER-R ve DA-EUROPE-HRGENERAL-R Microsoft Entra gruplarına vhr_eu erişim verin.

Gizli veya alt çalışma alanında sütunların şifrelendiği ve şifresinin çözülebileceğinden, gizli veya aşağıdaki çalışma alanları Microsoft Entra geçiş kimlik doğrulamasını kullanmaya devam edebilir ve kullanıcıların izinlerine bağlı olarak gölü keşfetmesine izin verebilir.

Tablo erişimi kullanıldığında, erişim gerektiren ekipler Azure Databricks çalışma alanına eklenir. Azure Databricks, Azure Data Lake Depolama eşlemek için hizmet sorumlularını kullanır, ancak verilerin güvenliği Azure Databricks tablosu erişim denetimiyle sağlanır.

Yeni veri ürünleri dağıtılırken DevOps işleminin bir bölümünün, Azure Databricks çalışma alanında tablo izinlerini ayarlamak ve bu izinlere doğru Microsoft Entra gruplarını eklemek için betikleri çalıştırması gerekir.

Dekont

Azure Databricks tablosu erişim denetimi, Microsoft Entra doğrudan kimlik doğrulaması ile birleştirilemiyor. Bu nedenle, bunun yerine yalnızca bir Azure Databricks çalışma alanı ve tablo erişim denetimi kullanabilirsiniz.

Kısıtlanmış veriler

Gizli veya kısıtlanmış verilere yönelik seçenekleri uygulamanın yanı sıra, çok gizli verileri ayrılmış bir veri giriş bölgesinde ve veri yönetimi giriş bölgesinde barındırmanızı da öneririz.

Tam zamanında erişim, şifreleme için müşteri tarafından yönetilen anahtarlar ve giriş bölgesine uygulanan gelen veya giden kısıtlamalar gibi belirli gereksinimlere izin verir. Bu kılavuz, bu türdeki verileri aynı veri giriş bölgesine ancak farklı depolama hesaplarına yerleştirmeyi değerlendirmiştir. Ancak, örneğin ağ güvenlik grupları ve diğer ağ güvenlik gruplarıyla çözüm ağ katmanında karmaşık hale gelebilir.

Ayrılmış 'kısıtlı' veri yönetimi giriş bölgesi, 'kısıtlı' veri giriş bölgesindeki verileri kataloglayacak şekilde bağlanmalıdır. Katalogda bu verileri kimlerin arayabileceğini kısıtlamalıdır.

Sonraki adımlar

• Veri Erişim Yönetimi