Salesforce Data Security

Günümüzün dijital dünyasında müşteri verilerinin güvenliği sadece bir tercih değil bir zorunluluktur. Salesforce gibi bulut tabanlı CRM platformları milyonlarca şirketin kritik verilerini barındırırken bu verilerin korunması her zamankinden daha önemli hale gelmiştir. Bu kapsamlı rehberde Salesforce Data Security'nin tüm boyutlarını detaylı örneklerle inceleyeceğiz.

Bir Salesforce yöneticisinin (Admin) en kritik görevlerinden biri doğru kişinin, doğru veriye, doğru zamanda erişmesini sağlamaktır. İşte bu kapsamda yapılan tüm ayarlara Salesforce Security Implementation denir.

Salesforce güvenliği 4 ana katmandan oluşur:

1. Kimlik Doğrulama (Authentication)
2. Yetkilendirme (Authorization)
3. Veri Erişim Seviyeleri (Data Access)
4. Denetim ve İzleme (Auditing & Monitoring)

Bu katmanlar bir soğan gibidir. En dış katman Authentication, içe doğru Authorization, daha da içte Data Access ve en merkezde Auditing & Monitoring bulunur.

Authentication (Kimlik Doğrulama)

Salesforce’ta kimlik doğrulama sisteme giriş yapan kullanıcının gerçekten o kullanıcı olduğunu ispatlamasıdır. Basitçe “Sen kimsin?” sorusuna sistemin tatmin edici bir yanıt almasıdır.

• Kullanıcı Adı ve Şifre (Username + Password): En temel yöntemdir. Salesforce’ta kullanıcı, kullanıcı adı (email formatında) ve şifre ile giriş yapar. Şifre politikaları (Password Policy) ile güçlendirilebilir. Minimum uzunluk, özel karakter zorunluluğu, belirli aralıklarla şifre yenileme, art arda yanlış girişlerde hesap kilitleme vb.
• IP Kısıtlamaları ve Login Hours: Giriş sadece belirli IP aralıklarından veya saatler arasında yapılabilir. Salesforce Setup → Profiles → Login IP Ranges veya Login Hours. Örneğin Destek ekibi sadece ofis ağından giriş yapabilir, evden giriş yapamaz.
• Multi-Factor Authentication (MFA): İkinci bir doğrulama adımı ekler. Kullanıcı adı ve şifre doğru olsa bile ek olarak telefon uygulamasından onay, SMS ile gelen kod vb. Salesforce 1 Şubat 2022 itibariyle MFA kullanımını zorunlu hale getirdi.
• Single Sign-On (SSO): Kullanıcı tek bir oturum açma işlemiyle birden fazla uygulamaya erişebilir. Salesforce SAML (Security Assertion Markup Language), OpenID Connect gibi standartları destekler. Genellikle kurumsal Active Directory ile entegre edilir.

SAML, kimlik doğrulama (authentication) ve yetkilendirme (authorization) bilgilerini farklı sistemler arasında güvenli bir şekilde iletmek için kullanılan bir XML tabanlı standarttır.

OpenID Connect, OAuth 2.0 protokolü üzerine inşa edilmiş modern bir kimlik doğrulama protokolüdür. SAML gibi SSO sağlar ama XML yerine JSON kullanır ve mobil/dijital uygulamalar için daha uygundur.

Yetkilendirme (Authorization)

Kullanıcı doğrulandıktan sonra hangi verilere erişebileceği belirlenir.

1- Profiles

Profiles bir kullanıcının Salesforce üzerinde hangi işlemleri yapabileceğini (Create, Read, Update, Delete – CRUD izinleri) ve hangi alanları görebileceğini veya düzenleyebileceğini belirler.
Yani bir profil kullanıcının uygulamanın kapısındaki ana anahtar gibidir.

• CRUD izinleri (ör. bir kullanıcı Fırsatlar nesnesinde sadece "Oku" yapabiliyor ama "Sil" yapamıyor olabilir)
• Alan bazında görünürlük (Field-Level Security)
• Uygulama, sekme ve kayıt tiplerine erişim
• Login saatleri ve IP kısıtlamaları

Bir apartmana giriyorsun kapıdaki anahtarın sadece giriş kapısını ve kendi dairenin kapısını açıyor. Başka dairelerin kapılarını açamazsın. İşte profil bu anahtar setidir.

2- Permission Sets

Permission Set’ler kullanıcının profilini değiştirmeden ek yetkiler vermeye yarar. Bu sayede kullanıcıya geçici veya ek görevler için ekstra erişim sağlanabilir.

• Ek CRUD izinleri
• Ek alan görünürlükleri
• Ek uygulama veya sekme erişimleri
• API, Export gibi yetkiler

Normalde "Standard User" profilinde rapor export etme izni yok. Ama şirkette sadece 3 kişi "Export Reports" yapabilsin istiyorsun. Onlara "Report Export Permission Set" atıyorsun. Böylece sadece onlar ek olarak bu yetkiye sahip oluyor. Örneğin evinde misafir var. Normalde misafir sadece salonu kullanabilir ama sen ona mutfağın anahtarını da veriyorsun. Profil aynı kalıyor ama ek bir anahtar (Permission Set) ile mutfağa girebiliyor.

3- Permission Set Groups

Birden fazla Permission Set’i tek bir paket haline getirip topluca atamanı sağlar. Böylece ayrı ayrı atamak yerine tek seferde kullanıcıya verirsin.

• Büyük ekiplerde erişim yönetimini kolaylaştırır.
• Tek tıkla onlarca permission set atanabilir.
• İzin yönetiminde tutarlılık sağlar.

"Finance Team" için:

"Export Reports" Permission Set

"View All Accounts" Permission Set

"Modify Invoices" Permission Set'lerini vermek istiyoruz. Bunların hepsini tek tek vermek yerine "Finance Access Group" diye bir Permission Set Group oluşturup tek seferde atayabiliriz. Örneğin birine ayrı ayrı televizyon, mutfak, depo anahtarları vermek yerine anahtar çubuğuna hepsini takıp tek paket olarak teslim etmek Permission Set Group oluşturmak gibidir.

4- Roles

Roller veri görünürlüğü hiyerarşisini belirler. Üst roldeki kullanıcı alt roldeki kullanıcıların sahip olduğu kayıtlara erişebilir.

• Kayıt bazında görünürlük (Record-Level Access)
• "Role Hierarchy" üzerinden yukarı doğru veri paylaşımı
• Profilden bağımsız olarak kayıtları görme imkanı

Örnek bir senaryoda Satış Temsilcisi kendi fırsatlarını görür. Satış Müdürü kendi fırsatlarını ve tüm temsilcilerin fırsatlarını görür. Bölge Direktörü tüm bölgelerin satış fırsatlarını görür.

5- Public Groups

Kullanıcıları, rollerini, rollerin altındakileri ve diğer grupları tek bir grup altında toplayarak paylaşım kuralları, klasör erişimi veya onay süreçlerinde kullanabilirsin. Profilden farklı veri görünürlüğü sağlamaz sadece hedef kitlenin belirlenmesini kolaylaştırır.

• Paylaşım Kuralları (Sharing Rules) oluştururken hedef kitlenin kolay seçilmesi
• Dashboard veya rapor klasörlerine topluca erişim verme
• Onay süreçlerinde belirli grup kullanıcılarına görev atama

Örneğin bir arkadaş grubun var. WhatsApp’ta tek tek kişilere mesaj atmak yerine gruba mesaj atıyorsun. Böylece herkes aynı anda erişiyor.

Veri Erişim Seviyeleri (Data Access)

• Object-level (Nesne düzeyi): Profiles & Permission Sets → CRUD / View All / Modify All
• Field-level (Alan düzeyi): Field-Level Security (FLS) → Alan görünürlüğü & düzenleme
• Record-level (Kayıt düzeyi): OWD taban çizgisi + paylaşım mekanizmaları → Hangi kayıtları kimin göreceği

Bir üst katman izin vermiyorsa alttaki katman veremez. Örneğin objeye erişimin yoksa kayıt paylaşılsa bile göremezsin.

1) Organization-Level Security (Organizasyon Düzeyi Güvenlik)

Kullanıcının hangi şartlarda Salesforce’a erişebileceğini belirlemek. Organization katmanı bir kapı görevi görür, içeri girdikten sonra Object → Field → Record katmanları devreye girer.

2) Object-Level Security (Nesne Düzeyi Güvenlik)

Kullanıcının bir nesne üzerinde hangi işlemleri yapabileceğini kontrol eder.

• CRUD İzinleri:
  • Create – Yeni kayıt oluşturma
  • Read – Kayıtları görme
  • Update – Mevcut kayıtları düzenleme
  • Delete – Kayıtları silme
• Özel Nesne Yetkileri:
  • View All – O nesnedeki tüm kayıtları okuma (paylaşım kurallarını bypass eder)
  • Modify All – O nesnedeki tüm kayıtları okuma, düzenleme ve silme (paylaşım kurallarını bypass eder)
• Global Yetkiler:
  • View All Data – Tüm org’daki kayıtları okuma
  • Modify All Data – Tüm org’daki kayıtları okuma, düzenleme, silme

Sağlayan Mekanizmalar:

• Profiles
• Permission Sets
• Permission Set Groups

Örnek Senaryo: “Standard User” profilinde Opportunity nesnesinde sadece Read/Update var. “Export Reports” yetkisi için ayrı bir Permission Set atanır. “Sales Manager” profilinde aynı nesneye Modify All verilir.

3) Field-Level Security (FLS)  (Alan Düzeyi Güvenlik)

Kullanıcının bir nesnedeki belirli alanlara erişimini kontrol eder.

• Read Access: Alanı görebilir.
• Edit Access: Alanı düzenleyebilir.
• FLS, Profiles veya Permission Sets üzerinden ayarlanır.
• API erişimini de kısıtlar → Raporlar, sorgular, dış sistem entegrasyonlarında alan görünmez.

Önemli Not: Page Layout ≠ FLS. Page Layout alanı sadece UI’dan gizler, API’da yine görülebilir. FLS ise tamamen gizler !

4) Record-Level Security (Kayıt Düzeyi Güvenlik)

Kullanıcının hangi kayıtları görebileceğini, düzenleyebileceğini belirler. Temel Mantık olarak önce OWD (Org-Wide Defaults) ile taban erişim belirlenir sonra paylaşım yöntemleriyle genişletilir.

• Org-Wide Defaults (OWD): Her nesne için iki ayrı ayar yapılır; İç kullanıcılar için Default Internal Access, Portal/Experience kullanıcıları için Default External Access.

OWD Değerleri:

• Private: Sadece sahibi ve yöneticiler görür/düzenler.
• Public Read Only: Herkes görebilir ancak sadece sahibi düzenler.
• Public Read/Write: Herkes görebilir ve düzenleyebilir.
• Public Read/Write/Transfer: Lead, Case gibi nesnelerde transfer hakkı.
• Controlled by Parent: Erişim üst (parent) kayıttan gelir.
• Public Full Access: Özel durumlar (Campaign vb.)

Paylaşım Mekanizmaları

OWD’nin üzerine ek erişim verirler.

• Role Hierarchy: Üst roldeki kişi alt roldekilerin kayıtlarını otomatik görür. Müdürlerin ekip kayıtlarını görmesi gerekiyorsa kullanılabilir. Setup → Users → Roles yoluyla ya da Setup → Sharing Settings yoluyla ulaşılır. Role Hierarchy standart objelerde her zaman açıktır, custom objede kapatılabilir. Sadece yukarı doğru çalışır, yan şubedeki kayıtları vermez.
• Sharing Rules: Kayıtları sahibine veya alan değerine göre otomatik belirli gruplara/rollere paylaştırır. Aynı dilimi birçok kişiye her zaman verelim gibi bir ihtiyaç varsa kullanılır. Setup → Security → Sharing Settings → (Object) → New Sharing Rule yoluyla ulaşılır ve eklenir. Sadece Read Only veya Read-Write şeklinde genişletir, delete vermez.
• Manual Sharing: Tek bir kaydı kayıt sayfasındaki Sharing düğmesinden kişi veya gruplarla paylaşabiliriz. Geçici süreliğine tek bir kişiye verilmesi gereken izinler gibi istisna durumlarda kullanılır. Bu buton OWD Private veya Public Read Only iken görünür, Public Read/Write iken çoğu zaman görünmez.
• Teams (Account/Opportunity/Case Team): Belirli kayıtlara ekip üyelerini rol ve erişim seviyesi şeklinde eklersin. Tekrar eden iş birliği için idealdir. Müşteri hesabında sürekli aynı ekiple çalışıyorsanız kullanmak mantıklıdır. Kullanıcı kendi Default Team’ini belirleyebilir.
• Queues: Kayıt önce Queues' e ait olur. Queues üyeleri görür ve Claim/Üstlen yaparak sahiplenir. Setup → Users → Queues şeklinde ulaşılabilir. Account veya Opportunity gibi tüm objelerde yoktur, desteklenen objelerde çalışır. Queues'de iken üyeler görür ve genelde düzenleyebilir, sahiplenince kayıt kişiye geçer.
• Territory Management: Bölge/segment bazlı kapsam tanımlayıp o bölgedeki Accountlar ve bağlı Opportunity’ler için erişim verirsin. Rol hiyerarşisinden bağımsız bir katmandır. Tasarım ve bakım nispeten karmaşıktır; küçük ekiplerde gerekmez.
• Implicit Sharing: Salesforce’un otomatik verdiği ek erişimlerdir; ilişkilere (parent/child) ve sahipliğe göre kendiliğinden oluşur.
• Apex Managed Sharing: Kodla belirli kayıtları dinamik koşullara göre paylaştırırız. Yalnızca genişletir, kısıtlamaz. Bakımı ve testleri gerekir, paylaşım yeniden hesaplamalarını doğru yönetmek önemlidir.

Şimdi bunları pekiştirmek için günlük hayattan örneklerle tamamlayalım;

• Bir bankanın genel müdürlük binasını düşünürsek güvenlikten sorumlu bir kişi var. Bu kişinin amacı doğru kişinin, doğru odaya, doğru zamanda, doğru araçlarla girmesini sağlamak ve her adımı izleyebilmek.
• Binanın bir adı ve tek bir ana girişi var: bu My Domain.
• Çalışanlar turnikeden binanın giriş kartıyla geçiyor: SSO.
• Ancak kasanın olduğu kat gibi kritik bir yere girmek için kart yetmez, parmak izi ya da mobil onay gerekiyor: MFA/High Assurance.
• Bazı ekiplerin yalnızca mesai saatlerinde girmesine izin var: Login Hours.
• “Sadece kampüs içinden giriş” şartı koyduğun alanlar da var: Profile Login IP Ranges.
• Ziyaretçiye içeri almadan önce bir form imzalatmak istersen turnikede kısa bir ekran açılıyor: Login Flow.
• Tüm bu girişlerin süresi, otomatik kapanışı, şüpheli oturumu kilitleme gibi ince ayarlar da Session Settings.

İçeride Kim Ne Yapar (Authorization)

Bu kişi herkese tek tek anahtar vermiyor, göreve göre anahtar seti dağıtıyor. Muhasebe, Çağrı Merkezi, BT Operasyon gibi setler Profile gibidir. Kapıların yani sekmelerin, odaların yani objelerin ve çekmecelerin yani fieldların temel erişimleri buradadır.

Bazı kişilere ek başka anahtar lazım olduğunda profili bozmadan “Kasa Odası Görüntüleme” gibi Permission Set verilir.

Bir departmana başlayana örneğin Finans Ana Anahtar Seti'ni tek seferde vermek için de Permission Set Group kullanılır.

Bu kişi üç katmanla çalışır:

Object-Level Security oda erişimi gibidir: Birinin bir odaya hiç anahtarı yoksa yani o objeye Read yoksa içeride ne var asla göremez. Bazı görevlilerse arşivin her şeyini görebilir/düzenleyebilir: bu View All/Modify All anahtarlarıdır.

Field-Level Security çekmece erişimi gibidir: Odaya girse bile herkes her çekmeceyi açamaz. Örneğin muhasebe çalışanı evrakı görür ama TC kimlik numarası yazan çekmece kilitli kalır.

Record-Level Security çekmecedeki belgeler gibidir: Bu kişi önce binadaki tüm odalar için bir varsayılan bir kapı politikası koyar: OWD.

Bazı odalar Private yalnızca oda sahibi ve üst düzeyler, bazıları Public Read Only herkes bakar sahibi düzenler, bazıları Public Read/Write ekipçe çalışma alanı, bazı odalar da üst katın anahtarıyla açılır: Controlled by Parent.

Bu tabanın üstüne gerektiğinde ek kapılar açılır:

Role Hierarchy buradaki kat sorumlusu, o kattaki tüm odalara otomatik girer yani müdürün ekibin kayıtlarına girmesi gibidir.

Sharing Rules proje odaları gibi sahipliğe, kriterlere göre yalnızca o projenin ekibine otomatik açılır.

Manual Sharing bir toplantı için tek bir odaya geçici ziyaretçi kartı verilmesi gibidir.

Teams ana proje odasına kemik ekip isim isim tanımlıdır herkesin rolüne göre okuma ve yazma hakkı vardır.

Queues bankonun önünde numaratör koyulup gelen dosyalar ortak kuyruğa düşer, uygun görevli claim ederek üstlenir.

Territory Management bölgesel bir ofis şeması, o bölgedeki odalar o ekibe görünür rol hiyerarşisinden bağımsız bir overlay sağlanır.

Implicit Sharing lobinin anahtarını verdiğinde koridordaki dinlenme odası da kendiliğinden açılır ilişkiden doğan otomatik erişim.

Apex Managed Sharing acil etiketi düşen dosya olursa kasa katı mimarlarına otomatik geçiş verilir bu kişi bunu akıllı kilitle yazılımla kurgular.

Restriction Rules görünürlüğü filtreler yanından geçsen bile içini göremezsin yani partner sadece kendi hesabına bağlı Open fırsatları görsün gibi.

Her adımın bir izi vardır bu Auditing & Monitoring ile olur. Turnikelerden geçen herkesin saati, IP’si Login History’ de.

Anahtar odalarını kim değiştirmiş, hangi kapıya yeni kural konmuş: Setup Audit Trail.

Koridor kameraları ve kapı sensörleri Event Monitoring. Örneğin gece yarısı dış kapıdan içeri girip kasadan koliyle çıkmak gibi davranışlar Transaction Security ile anında durdurulur ya da ikinci kimlik doğrulaması istenir.

Tüm güvenlik ayarlarının yıllık muayenesi Health Check.

Çok gizli evraklar şifreli çelik kasalarda bulunur bu Platform Encryption.

Belgelerin üzerinde kim neyi, ne zaman değiştirmiş yazan bir etiketse Field History Tracking.

Yani günün sonunda bu kişinin kuralları şaşmaz. Önce binaya kim girebilir (Authentication), sonra içeride hangi odalara ve çekmecelere yetkisi var (Authorization + Object/Field), ardından hangi dosyayı ne ölçüde görebilir (Record), ve tüm bu yolculuk nasıl kayda alınır (Auditing). Bu akış doğruysa binada yanlış kişinin yanlış evrağa ulaşması neredeyse imkansızdır.