Koruyun, Saklayın ve Kanıtlayın
28 dilde daha mevcut
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Data Architect kursunun 5. bölümü olan Veri Kalitesi ve Yönetişim bölümündeki 6 modülden 6.‘sı. Her modül kendi başına okunabilir. Önceki: Onay ve Unutulma Hakkı · Sonraki: sonraki bölüm, Ana Veri ve Kimlik
Bu modülün yanıtladığı soru: Veriyi nasıl korursunuz, gerektiği kadar saklarsınız ve kanıtlarsınız?
Sahipleri ve politikaları belirledik, kötü veriyi dışarıda tuttuk, sözlüğü yazdık, kökeni izledik, önemli olanı sınıflandırdık, yasaları öğrendik ve onayı modelledik. Şimdi bunu işletmemiz gerekiyor. Veri gelir, kullanılır, kopyalanır ve değişir, eskir ve sonunda bir kısmının gitmesi gerekir. Ve bir gün biri soracak: ne olduğunu kanıtlayın.
Yönetişim Veriyi İzler
Bölüm başlığı “Yönetişim Veriyi İzler ”Yönetişimi tek bir özellik olarak düşünmem. Veriye, girdiği andan onunla işimiz bitene kadar ne olduğunu düşünürüm:
Yakalama → Sınıflandırma → Koruma → Kullanım → Saklama → Silme → Denetim
Yedi teknik süreç değil: mimarinin yanıtlaması gereken yedi soru. Yakalamayı ve sınıflandırmayı ele aldık: pahalı hataları dışarıda tutun (2. modül) ve hangi verinin hassas olduğunu bilin (3. modül). Sınıflandırma sonraki her aşamada ne olacağına karar verir; bu yüzden bu modül oradan devam ediyor.
Verinin yaşamı boyunca yedi soru. Araçlar politikayı destekler; onu tanımlamaz.
Koruma: Kontrolü Veriye Uydurun
Bölüm başlığı “Koruma: Kontrolü Veriye Uydurun ”Onu kim görebilir, değiştirebilir, alabilir? Şifrelenmeli mi, canlı ortamın dışında maskelenmeli mi, dışa aktarılabilir mi, bir ajan ona ulaşabilir mi? Salesforce güvenliğinin veri yönetişiminin bir parçası haline geldiği yer burasıdır: paylaşım, nesne ve alan izinleri, şifreleme, maskeleme, entegrasyon erişimi. Bu konular koca kursları dolduruyor; bu yüzden onları yeniden öğretmeyeceğim. Yönetişim noktası şu: koruma sınıflandırmayı ve politikayı izler. Her alan aynı korumaya, her kullanıcı aynı erişime, her aşağı akış sistemi her alana ihtiyaç duymaz.
Şifreleme Bir Kontroldür, Uyumluluk Değil
Bölüm başlığı “Şifreleme Bir Kontroldür, Uyumluluk Değil ”Düzenlemeye tabi veri için bekleyen verinin şifrelenmesi gerekebilir ve pozisyonum şu: Shield, bunun gibi temel düzenleyici gereksinimlerin yanıtıdır. Shield Platform Encryption, bekleyen alanları ve dosyaları şifreler. Ama “şifreledik, o halde uyumluyuz” iki kez yanlıştır. Şifreleme erişim, saklama, denetim, onay, izleme, en aza indirme ve silme arasında bir kontroldür. Ve önceden tasarımda hesaba katmanız gereken işlevsel ödünleşimleri vardır. Varsayılan olasılıksal şemada şifreli bir alan SOQL WHERE, GROUP BY ya da ORDER BY yan tümcelerinde veya veri yönetimi filtrelerinde kullanılamaz; deterministik şifreleme, alana göre filtreleme yapabilmeniz için biraz güçten vazgeçer. Şifreli alanlar ölçüte dayalı paylaşım kurallarını yönlendiremez ve liste görünümlerini onlara göre sıralayamazsınız (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab), İngilizce). Dolayısıyla şifreleme sondaki bir onay kutusu değildir. Bir mimari karardır. Veri güvenliği bölümü daha derine iniyor.
Canlı Ortamın Riskini Sandbox’a Kopyalamayın
Bölüm başlığı “Canlı Ortamın Riskini Sandbox’a Kopyalamayın ”Canlı ortam kilitli. Sonra biri tam bir sandbox’ı yeniliyor ve geliştiriciler, test uzmanları, yükleniciler ve test entegrasyonları artık hiç ihtiyaç duymadıkları gerçek kişisel verilerin kopyalarını tutuyor. Ortam değişti; verinin hassasiyeti değişmedi. Salesforce’un maskeleme araçları tam olarak bunun için var. Bir değişikliğe dikkat edin: Data Mask yönetilen paketinin hizmet ömrü 31 Aralık 2026’da sona eriyor ve halefi Data Mask & Seed (Data Mask (Legacy) (opens in a new tab), İngilizce). Ama araç politikayı destekler ve önce soru gelir: bu ortamın hiç gerçek hassas veriye ihtiyacı var mı? Gerçekçi, hassas olmayan veri testi yapabiliyorsa daha iyi yanıt odur.
Kullanım: İzin Yalnızca İnsanlarla İlgili Değildir
Bölüm başlığı “Kullanım: İzin Yalnızca İnsanlarla İlgili Değildir ”Kullanıcılar, entegrasyonlar, analitik, ortaklar, otomasyon ve ajanlar hepsi veriyi kullanır. Onay (5. modül), sahiplik (1. modül) ve sınıflandırma (3. modül) burada çalışma zamanında buluşur. Bu kullanıcı Alıcının telefon numarasını görmeli mi? Bu entegrasyon onu almalı mı, Snowflake almalı mı, bu ajan temellendirme olarak almalı mı? Yanıt “teknik olarak alabilir” olamaz. Yetenek ile yönetişim arasındaki fark budur: almasının gerekip gerekmediğine mimari karar verir.
Saklama: Her Şeyi Sonsuza Kadar Saklamak Tarafsız Değildir
Bölüm başlığı “Saklama: Her Şeyi Sonsuza Kadar Saklamak Tarafsız Değildir ”Pek çok kuruluşun kazara oluşmuş bir saklama politikası vardır: sonsuza kadar. Kimse karar vermedi; depolama alanı vardı, veri de kaldı. Ama veri saklamak depolama ve performansa mal olur, gizlilik ve güvenlik riskini genişletir, keşif yükümlülükleri ekler ve biri unutulmak istediğinde aramanız gereken daha fazla yer verir. Her önemli kategori için: neden saklıyoruz, ne kadar süre, süreyi ne başlatıyor, yasal bir alt sınır ya da gizlilik açısından bir üst sınır var mı ve sonunda ne oluyor: arşivleme, silme, kimliksizleştirme?
Ve arşivlemek saklamayı çözmekle aynı şey değildir. “Arşivledik.” Saklama gereksinimi ortadan kalktı mı? Gizlilik gereksinimi? Güvenlik? Verinin nerede yaşadığını değiştirdiniz, ne olduğunu değil. Bir arşivin erişim kontrollerine, saklama ve silme kurallarına, keşfe ve denetime ihtiyacı vardır. Kişisel veriyi herkesin unuttuğu bir arşive taşıyın, yönetişim yalnızca kötüleşmiş olur.
Silme: Yaşam Döngüsünün Bir Çıkışa İhtiyacı Vardır
Bölüm başlığı “Silme: Yaşam Döngüsünün Bir Çıkışa İhtiyacı Vardır ”Silme yalnızca bireysel gizlilik talepleri için değildir. Veri saklama süresinin sonuna ulaşır; geçici kayıtlar kullanım sürelerini aşar; arşivlerin süresi dolar; bir süreç belirli bir süreden sonra kimliksizleştirir. Politika ne derse desin, mimarinin bir çıkışa ihtiyacı vardır; yakala → sakla → daha çok sakla → sonsuza kadar sakla değil. Ve 5. modülün gösterdiği gibi, kopyalar başka yerlerde yaşarken Salesforce kaydını silmek yeterli değildir.
Geçmiş de Veridir
Bölüm başlığı “Geçmiş de Veridir ”Bazen güncel değer yeterli değildir. Bir ortağın yasal adı, bir müşterinin sınıflandırması, bir onay durumu, bir finansal öznitelik: iş birimi ya da bir düzenleyici kurum onun daha önce ne olduğunu, ne zaman değiştiğini ve kimin değiştirdiğini bilmek isteyebilir. Bu geçmiş veridir ve kendi saklama kararına ihtiyaç duyar.
Standart alan geçmişi izleme, nesne başına en fazla 20 alanı izler ve değişiklikleri en fazla 18 ay, yalnızca API üzerinden, Data Loader ya da queryAll() ile de en fazla 24 ay saklar (Field History Tracking Overview (opens in a new tab), İngilizce). Uzun metin alanları için de yalnızca alanın düzenlendiğini kaydeder, ne yazdığını değil: kanıtınız buysa bir boşluk. Shield’ın bir parçası olan ya da tek başına satın alınabilen Field Audit Trail, nesne başına en fazla 200 alanı izler ve geçmişi API üzerinden eriştiğiniz bir arşivde siz silene kadar saklar (Field Audit Trail (opens in a new tab), İngilizce). Pozisyonum: varsayılan standart alan geçmişidir; bir düzenleme ya da uyumluluk yükümlülüğü daha uzun, kanıtlanabilir bir geçmiş gerektirdiğinde Field Audit Trail kullanın. “Denetim kulağa iyi geliyor” diye değil.
Denetim ve İzleme Aynı Şey Değildir
Bölüm başlığı “Denetim ve İzleme Aynı Şey Değildir ”Alan geçmişi seçili alanlardaki değişikliklerle ilgili soruları yanıtlar. Daha geniş sorular (kim oturum açtı, kim veri dışa aktardı, hangi API’ler çağrıldı, kim neyi görüntüledi) izlemedir ve bu Event Monitoring’dir. Deneyimime göre genellikle daha fazla düzenlemeye tabi müşterilerde gerekir ve işte bu bölümdeki en güçlü pozisyonum: ihtiyaç duymadan önce kurun ve olayları önceden Splunk ya da başka bir SIEM gibi bir depoya yönlendirin.
Nedeni şu. Olay günlüğü dosyaları eklenti olmadan 1 gün saklanır ve yalnızca bazı olay türleri için; Shield ya da Event Monitoring eklentisiyle varsayılan olarak 30 gün ve saklamayı uzatırsanız 365 güne kadar (Event Monitoring FAQ (opens in a new tab), İngilizce). Daha eskisi, dışa aktarmadıysanız gitmiştir. Ve ücretli günlükler, sözleşmeniz başlamadan önceki hiçbir dönem için alınamaz (aynı SSS): olaydan sonra eklentiyi satın almak geçmişi geri getirmez. Dolayısıyla bir mimarın yapabileceği en kötü konuşmalardan biri şöyledir: “Altı ay önce ne olduğunu görebilir miyiz?” “Hayır.” “Neden?” “Kaydetmiyorduk.” Bir sorunla karşılaşıp sonra bu olayları yakalamadığınızı ve saklamadığınızı öğrenmezsiniz. O zaman yanıt düpedüz yok olmuştur.
İhtiyaç duymadan önce kurun.
Ama “her şeyi günlüğe kaydet” uç noktasına da savrulmayın. Neyi kanıtlamaya çalışıyorsunuz? Hangi olaylar önemli, onlara kimin ihtiyacı var, ne kadar süre, günlükleri kim okuyabilir ve günlüklerin kendisi hassas veri içerebilir mi? Günlüğe kaydetmek veri yaratır ve o verinin de yönetişime ihtiyacı vardır. Ve kanıtın bir sahibe ihtiyacı vardır: depoya kim sahip, uyarıları kim inceliyor, saklamanın çalıştığını kim kontrol ediyor, akışın üç ay önce sessizce durduğunu kim fark ediyor? Sahipsiz teknoloji yönetişim değildir; 1. modülün sahibine, veri sorumlusuna ve muhafızına geri döndük.
Yalnızca Yapılandırmayı Değil, Kontrolü Kanıtlayın
Bölüm başlığı “Yalnızca Yapılandırmayı Değil, Kontrolü Kanıtlayın ”“Alıcı verisi yalnızca durağa atanan ekiplere açıktır.” Bunu nasıl biliyoruz? Güvenlik yapılandırması ne olması gerektiğini gösterir. Operasyonel kanıt (ona gerçekte kim erişti, olağandışı dışa aktarımlar, onu çeken bir entegrasyon, değiştirilen erişim kontrolleri) ne olduğunu gösterir. İyi yönetişim çoğu zaman ikisine de ihtiyaç duyar.
Sınavın ötesinde: yapay zekânın değiştirdikleri. Ajanlar yanıt vermekten eyleme geçtikçe yönetişim, ajanın ne gördüğünün, neye karar verdiğinin ya da ne ürettiğinin ve ne yaptığının, onu kimin ya da neyin başlattığının, hangi politika altında olduğunun kanıtına ihtiyaç duyar. Günlüğe kaydetme mekanizmaları değişecek; gereksinim değişmeyecek: otonom bir eylem önemliyse onu sonradan nasıl yeniden oluşturacağınızı şimdi tasarlayın.
Steve Trucking: Tek Bir Alanda Yaşam Döngüsü
Bölüm başlığı “Steve Trucking: Tek Bir Alanda Yaşam Döngüsü ”Alıcının telefon numarasını alın. Yakalama: ortağın yük listesiyle gelir; sürecin ihtiyaç duyduğu yerde kullanılabilir olduğunu kontrol edin. Sınıflandırma: kişisel veri. Koruma: onu yalnızca operasyonel ihtiyacı olan insanlar ve sistemler alır ve ekipler onu yalnızca kendi durakları için, o gün görür. Kullanım: ekip teslimatı koordine eder; mesajlaşma onu onaylı bir amaç için kullanır; bir ajan onu yalnızca politika izin veriyorsa kullanır. Saklama: onaylı iş ve gizlilik politikasının söylediği süre kadar. Silme ya da kimliksizleştirme: o süre sona erdiğinde ya da geçerli bir talep geldiğinde, haritadaki her kopyada. Denetim: kontrollerin ve işlemlerin gerçekleştiğine dair kanıtı tutun.
Şimdi bir dağıtım merkezi kodunu alın. Onu doğru yakalayın, hassas olmayan referans verisi olarak sınıflandırın, sıradan operasyonel erişimle koruyun, yaygın olarak kullanın, işin ihtiyaç duyduğu kadar saklayın ve önemliyse değişiklikleri denetleyin. Aynı yaşam döngüsü, farklı kontroller. Sınıflandırma bunun içindir.
Yönetişim Hiçbir Zaman Bitmez
Bölüm başlığı “Yönetişim Hiçbir Zaman Bitmez ”Yeni bir düzenleme çıkar. Yeni bir sistem ya da entegrasyon bir kopya daha yaratır. Bir ekip bir alan daha icat eder. Yeni bir platform canlıya geçer. Bir ajan erişim alır. Bir saklama kuralı değişir. Yeni bir Perakende Ortağı gelir. Mimari hareket eder ve yönetişim de onunla birlikte hareket eder. Hedef kusursuz veri, sonsuz kontrol ya da kimsenin okumadığı bir yönetişim belgesi değildir. Veri hakkında, mimarinin içine inşa edilmiş bilinçli kararlardır.
Mimarın Burada Karar Verdikleri
Bölüm başlığı “Mimarın Burada Karar Verdikleri ”- Her veri kategorisinin sınıflandırmaya, politikaya ve gerçek kullanıma göre hangi koruma kontrollerini aldığı; şifrelemenin ödünleşimleri dahil.
- Verinin ve geçmişinin ne kadar süre saklandığı, süreyi neyin başlattığı ve sonunda ne olduğu.
- Standart alan geçmişinin ne zaman yeterli olduğu ve bir düzenlemenin ne zaman Field Audit Trail gerektirdiği.
- Hangi olayların yakalandığı, kanıtın platformun saklama süresinin ötesinde nerede saklandığı ve sahibinin kim olduğu.
- Mimarinin önemli insan, entegrasyon ve ajan eylemlerini sonradan nasıl kanıtladığı.
Bu bölüm tek bir fikirle başladı: yönetişim org’un yanına yazılmaz, içine tasarlanır. Sahipler politikayı belirler, mimarlar uygular. Önemli olduğu yerde kötü veriyi dışarıda tutun. Verinizin ne anlama geldiğini, nereden geldiğini ve ne kadar hassas olduğunu bilin. Yasalara saygı gösterin, onayı modelleyin, kişisel verinin nereye gittiğini kontrol edin. Politikaya göre koruyun, saklayın ve silin. Ve kanıtı kimse istemeden önce yakalayın, çünkü bir olaydan altı ay sonrası, kanıtın yalnızca otuz gün var olduğunu öğrenmek için berbat bir zamandır.
Daha Fazlası
Bölüm başlığı “Daha Fazlası ”- Salesforce Help, General Shield Platform Encryption Considerations (opens in a new tab) ve Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
- Salesforce Help, Field History Tracking Overview (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
- Salesforce Help, Field Audit Trail (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
- Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
- Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.