İşletmeler için Veri Şifreleme: Müşteri Sohbetleri Rehberi
İşletmeler için veri şifreleme rehberi: WhatsApp, Instagram ve Telegram satıcıları neleri şifrelemeli, durağan ve aktarım farkı, token saklama ve sağlayıcıya sorulacak 10 soru.
Mohamed Rasul
Founder & CEO, Raabt AI

Her WhatsApp siparişi, her Instagram DM'i ve her Telegram destek sohbeti arkasında müşteri verisi bırakır: telefon numaraları, teslimat adresleri, sohbet kayıtları ve kanallarınızı bağlayan erişim tokenları. İşletmeler için veri şifreleme, bu veriyi hem ağlar arasında hareket ederken hem de veritabanlarında ve yedeklerde beklerken, anahtarı olmayan herkes için okunamaz bir şifreli metne dönüştürür.
Önemli Noktalar
- İşletmeler için veri şifrelemenin iki katmanı vardır: aktarım sırasında şifreleme (TLS) hareket hâlindeki veriyi, durağan veri şifreleme (genellikle AES) ise saklanan veriyi korur.
- Kanal erişim tokenları, API anahtarları ve webhook gizli anahtarları birer kimlik bilgisidir. Sızan tek bir token, saldırganın işletmeniz adına hareket etmesine yol açabilir; bu yüzden onları alan düzeyinde şifreleyin.
- Disk şifreleme çalınan bir diski korur, çalışan bir sunucuyu değil. Anahtarları veritabanının dışında tutulan alan düzeyinde şifreleme, sızdırılmış bir veritabanı dökümünde bile o alanları korumaya devam eder.
- AES-256-GCM kimlik doğrulamalı bir şifrelemedir: veriyi gizler, üzerinde oynanıp oynanmadığını fark eder ve aynı anahtarla aynı nonce'un asla tekrar kullanılmamasına dayanır.
- Şifreleme, şifreyi çözmeye yetkili olan hiç kimseyi durdurmaz. Yapay zeka destekli bir otomatik yanıt platformu mesajları yanıtlayabilmek için okumak zorundadır; bu yüzden erişim kontrolü ve saklama süresi en az şifreleme algoritması kadar önemlidir.
Sohbet Odaklı Bir Şirkette İşletmeler için Veri Şifreleme Neleri Kapsamalı?
Satışını sohbet üzerinden yapan bir şirketin, örneğin bir WhatsApp yapay zeka gelen kutusu üzerinden satan bir işletmenin, kendine özgü bir veri envanteri vardır:
- Kimlik bilgileri ve gizli anahtarlar. Facebook Sayfası ve WhatsApp Business erişim tokenları, Telegram bot tokenları, yapay zeka sağlayıcı anahtarları, ödeme sağlayıcı anahtarları ve webhook gizli anahtarları.
- Müşteriye ait kişisel veriler (PII). Telefon numaraları, e-posta adresleri, teslimat adresleri ve müşteri kimlikleri. Sohbet ticaretinde telefon numarası çoğu zaman müşterinin kimliğidir.
- Sohbet kayıtları ve medya. Yazışma dökümleri, sesli notlar, fotoğraflar ve müşterilerin gönderdiği faturalar.
- Personel parolaları. Bunlar şifrelenmemeli, hash'lenmelidir (ayrıntısı aşağıda).
- Personel cihazları. Gelen kutusunu açan ya da dışa aktarılmış dosyaları barındıran dizüstü bilgisayarlar ve telefonlar. FileVault veya BitLocker'ı, cihaz parolalarını ve uzaktan silmeyi açın.
- Kopyalar. Yedekler, CSV dışa aktarımları, loglar ve çoğu zaman üretim ortamından daha az korunan test veritabanları.
Müşteri verisi şifreleme için basit bir kural: erişim sağlayan ya da bir kişiyi tanımlayan her şeyi alan düzeyinde koruyun ve her kopyaya orijinaliyle aynı korumayı verin.
Durağan Veri Şifreleme ile Aktarım Sırasında Şifreleme
Aktarım sırasında şifreleme, veri bir tarayıcı, kendi sunucunuz ve üçüncü taraf API'ler arasında hareket ederken devreye girer. Durağan veri şifreleme ise disklerde, veritabanlarında ve yedeklerde duran veriyi korur; Türkçe kaynaklarda buna "bekleyen veri şifreleme" de denir.
| Kriter | Aktarım sırasında şifreleme | Durağan veri şifreleme |
|---|---|---|
| Neye karşı korur | Dinleme, veriyle oynama, sahte sunucular | Çalınan diskler, sızdırılan dökümler, açıkta kalan yedekler |
| Tipik standart | TLS 1.2 veya TLS 1.3 | AES-256, çoğu zaman AES-256-GCM |
| Nerede geçerli | Tarayıcıdan uygulamaya, webhook'lar, API çağrıları | Disk, veritabanı, tek tek alanlar, yedekler |
| Kapsamadığı | Hedefe varıp şifresi çözülen veri | Çalışan bir uygulamanın o an kullandığı veri |
NIST SP 800-52 Rev. 2, ABD devlet TLS sunucularının TLS 1.2'yi desteklemesini ve Ocak 2024 itibarıyla TLS 1.3'ü de desteklemesini zorunlu kılıyor. Bu, herhangi bir işletme için de mantıklı bir taban çizgisi: TLS 1.2 ve 1.3'ü kabul edin, daha eskisini kapatın.
TLS yalnızca yolculuğu korur. WhatsApp Cloud API, webhook'ları HTTPS üzerinden iletir ve Meta'nın dokümantasyonu Cloud API'nin gelen mesajların şifresini çözdüğünü ve bunları işletmeye aktardığını, mesajları da en fazla 30 gün sakladığını anlatıyor. Ondan sonrası depolama ve erişim kontrollerine kalır.
Disk, Veritabanı ve Alan Düzeyinde Şifreleme
Durağan veri şifreleme katman katman kurulur:
- Disk veya birim şifreleme, çalınan ya da atılan bir diski korur. Sunucu çalışırken işletim sistemi veriyi otomatik olarak çözer, yani sunucunun içine giren bir saldırgan veriyi düz metin olarak görür.
- Veritabanı dosyası şifreleme aynı sınıra takılır: veritabanına sorgu atabilen herkes cevabı düz metin alır.
- Alan düzeyinde şifreleme, bir token ya da telefon numarası gibi belirli sütunları, veritabanına ulaşmadan önce uygulama içinde şifreler. Anahtar başka yerde durduğu için sızdırılan bir döküm ya da kopyalanan bir yedek, o alanlarda yalnızca şifreli metin gösterir.
Bunun bedeli aramadır: şifrelenmiş bir sütun üzerinde normal bir SQL filtresi çalıştıramazsınız. Pratik yaklaşım, alan düzeyinde şifrelemeyi gizli anahtarlara ve yüksek riskli iletişim bilgilerine ayırmaktır. Müşterileri telefon ya da e-posta ile bulması gereken ekipler, şifreli metnin yanına anahtarlı bir hash (kör indeks) yazıp aramayı onun üzerinden yapabilir.
AES-256-GCM: Anahtar Uzunluğu ve Mod
AES, FIPS 197 ile 128, 192 ve 256 bitlik anahtarlar için tanımlanmıştır. AES-256 bunların en uzun olanını kullanır.
Mod seçimi de en az anahtar uzunluğu kadar önemlidir. GCM (NIST SP 800-38D) kimlik doğrulamalı şifreleme sağlar: veriyi gizli tutar ve şifreli metnin değiştirilip değiştirilmediğini tespit eder. Aynı anahtarla aynı nonce'u asla tekrar kullanmayın: nonce tekrarı GCM'nin güvencelerini bozar. Nonce üretimini bakımı yapılan bir kütüphaneye bırakın ve kendi kriptografinizi asla yazmayın.
API Anahtarları ve Erişim Tokenları Güvenli Şekilde Nasıl Saklanır?
Seçimi, orijinal değere geri ihtiyacınız olup olmadığına göre yapın:
- Şifreleyin: başkasına göndermek zorunda olduğunuz gizli değerleri, yani WhatsApp ve Instagram erişim tokenlarını, Telegram bot tokenlarını, yapay zeka sağlayıcı anahtarlarını ve ödeme anahtarlarını. Anahtarı veritabanının dışında tutulan alan düzeyinde AES-GCM kullanın.
- Hash'leyin: yalnızca doğruladığınız gizli değerleri, yani parolaları, partner API anahtarlarını ve tek kullanımlık kodları. Hash geri çözülemez ama kısa veya tahmin edilebilir değerler kaba kuvvetle kırılabilir; bu yüzden parolalarda Argon2id ya da bcrypt gibi yavaş bir hash, kodlarda ise anahtarlı HMAC kullanın.
- Loglardan uzak tutun: hata mesajlarında, analitikte ve URL'lerde görünmesinler.
- Kapsamı daraltın ve döndürün. Bir tokena yalnızca ihtiyacı olan izinleri verin ve erişimi olan biri ayrıldığında tokenları yenileyin.
Durağan veri şifreleme, bir API çağrısı sırasında bellekte çözülmüş hâlde duran tokenı korumaz. Sunucu sıkılaştırması ve en az yetki prensibi bu riski azaltır.
Şifreleme Anahtarı Yönetiminin Temelleri
Şifreleme, ancak anahtarın saklandığı yer kadar güçlüdür. Klasik hata, anahtarı verinin yanında, aynı veritabanında ya da depoya işlenmiş bir yapılandırma dosyasında tutmaktır.
- Anahtarları veriden ayırın. Anahtarları bir secrets manager'da, KMS'te ya da veritabanının erişemeyeceği bir sunucu yapılandırmasında tutun.
- Ölçek büyüdükçe zarf şifrelemeye geçin. Bir ana anahtar, veri anahtarlarını şifreler; böylece ana anahtarı döndürmek her şeyi yeniden şifrelemek anlamına gelmez.
- Amaca özel anahtarlar türetin. Bunun için HKDF gibi bir anahtar türetme fonksiyonu kullanın.
- Döndürme ve kurtarma planı yapın. Kaybolan bir anahtar, yedekler dâhil kaybolan veri demektir.
Erişim Kontrolü ve En Az Yetki Prensibi: Şifreleme Tek Başına Yetmez
Şifreleme, anahtarı olmayanları durdurur; şifreyi çözmeye yetkili kişileri ve sistemleri değil. Yapay zeka destekli bir otomatik yanıt platformu, yanıt yazabilmek için müşterinin mesajını okumak zorundadır, yani sunucuları okunabilir mesajları işler.
Aynı mantık zincirin yukarısı için de geçerli. WhatsApp'ın güvenlik teknik dokümanı, Cloud API kullanan işletmelerle yapılan sohbetleri uçtan uca şifreli saymıyor; çünkü mesajlar doğrudan işletmenin kontrol ettiği bir uç noktaya teslim edilmiyor. Kurulumunuzu seçmeden önce WhatsApp Business Cloud API ile Business uygulaması karşılaştırmamıza göz atın.
Dolayısıyla bir sonraki katman, veriye kimin ulaşabildiğiyle ilgili:
- En az yetki prensibiyle erişim kontrolü: her ekip arkadaşına işini gördüren en dar rolü verin. Sohbetleri yanıtlayan bir temsilcinin faturalandırmaya ihtiyacı yoktur.
- Güçlü oturum açma: ikinci bir doğrulama adımı ekleyin ve çıkışta oturumları iptal edin.
- Kiracı izolasyonu: her istek, çağrıyı yapanın o işletmeye ait olduğunu kanıtlamalı.
- Denetim logları ve saklama süresi: ayrıcalıklı işlemleri kayıt altına alın ve sohbet kayıtlarını yalnızca ihtiyacınız olduğu sürece tutun.
Yedekler, Dışa Aktarımlar ve Saklama Süreleri
Yedekler müşteri verisinin eksiksiz kopyalarıdır ve çoğu zaman üretim ortamından daha uzun saklanıp daha az izlenir. Yedek dosyalarını şifreleyin, kimlerin indirebileceğini kısıtlayın, anahtar kurtarma dâhil geri yükleme tatbikatı yapın ve e-posta ya da sohbet üzerinden paylaşılmış eski CSV dışa aktarımlarını silin.
Şifrelemenin hukuki bir ağırlığı da var. GDPR'ın 32. maddesi şifrelemeyi bir güvenlik tedbiri olarak sayıyor ve 34(3)(a) maddesi, şifreleme sayesinde veri yetkisiz kişiler için anlaşılmaz hâle geldiyse veri sorumlusunun etkilenen kişileri ihlal hakkında bilgilendirmesine gerek bırakmıyor. İhlali öğrendikten sonraki 72 saat içinde denetim otoritesine bildirim yapma yükümlülüğü (33. madde) ise bundan ayrıdır. Suudi Arabistan'ın PDPL'si ve Türkiye'nin KVKK'sı da düzenleyici kuruma 72 saatlik bildirim süresi öngörüyor.
Bunlar genel bilgidir, hukuki tavsiye değildir. GDPR'ın ya da başka bir kanunun sizin için geçerli olup olmadığı ve belirli bir ihlalde istisnanın işleyip işlemediği kendi durumunuza bağlıdır; bu yüzden yetkin bir avukata danışın.
Her Sohbet veya CRM Sağlayıcısına Sorulması Gereken Sorular
Kanallarınızı bağlamadan önce, chatbot sağlayıcısına yönelik bu güvenlik sorularını yazılı bir soru listesi olarak kullanın:
- Uç noktalarınız hangi TLS sürümlerini kabul ediyor?
- Durağan hâlde hangi veriler, hangi katmanda şifreleniyor? Mesaj içeriği buna dâhil mi?
- Kanal tokenları ve API anahtarları alan düzeyinde şifreleniyor mu, anahtar nerede saklanıyor?
- Yedekler şifreli mi ve onlara kimler erişebiliyor?
- Personeliniz konuşmalarımızı okuyabiliyor mu, bu erişim loglanıyor mu?
- Ekibimiz için hangi rolleri ve izinleri tanımlayabiliriz?
- Verimiz diğer müşterilerinizden nasıl izole ediliyor?
- Sohbetlerimiz, sizin ya da yapay zeka sağlayıcılarınız tarafından model eğitiminde kullanılıyor mu?
- Alt işleyicileriniz kimler ve veri nerede saklanıyor?
- DPA imzalar mısınız ve ayrıldıktan sonra veri ne kadar sürede siliniyor?
"Askeri düzeyde şifreleme" ya da "tüm veriler tamamen şifreli" gibi cevaplara şüpheyle yaklaşın. Güvenilir bir sağlayıcı algoritmanın, katmanın ve boşlukların adını koyar.
Raabt Bugün Neleri Şifreliyor ve Koruyor?
Aşağıdaki maddelerin her biri, Raabt'ın Eylül 2026 itibarıyla çalışan kodunu yansıtıyor.
- Alan düzeyinde şifreleme: hassas alanlar uygulama düzeyinde AES-256-GCM ile şifreleniyor. Yeni yazımlar HKDF-SHA256 ile türetilmiş bir anahtar kullanıyor, eski değerler ise bir sonraki kaydedilişlerinde bu anahtarla yeniden şifreleniyor. Uygulama, en az 32 karakterlik bir anahtar olmadan başlamayı reddediyor.
- Neler şifreleniyor: kimlik bilgileri ve tokenlar (Facebook, Instagram, WhatsApp ve Telegram için kanal erişim tokenları, yapay zeka ve ödeme sağlayıcısı API anahtarları, webhook gizli anahtarları) ile seçili iletişim bilgileri (müşteri telefon numaraları, e-postaları ve sipariş adresleri).
- Hash'leme: parolalar Argon2id kullanıyor (19 MiB bellek, 2 iterasyon) ve eski bcrypt hash'leri girişte yükseltiliyor. Partner API anahtarı gizli değerleri yalnızca SHA-256 hash'i olarak saklanıyor.
- Oturum açma: e-posta ve parolayla yapılan girişlerde, herhangi bir oturum açılmadan önce kullanıcının e-postasına gönderilen tek kullanımlık bir kod isteniyor (Google ile girişte bu kod kullanılmıyor). Kodlar yalnızca HMAC-SHA256 hash'i olarak saklanıyor, süresi doluyor ve bir kez çalışıyor.
- Ekip erişimi: bölüm bazlı izinlere sahip dört rol (owner, admin, agent, viewer). Faturalandırma erişimi owner dışındaki rollere devredilemiyor.
- İzolasyon: işletme uç noktaları, çağrıyı yapanın o işletmenin aktif bir üyesi olduğunu doğruluyor; aksi hâlde "bulunamadı" dönüyor.
- Webhook'lar ve medya: Meta webhook'ları geçerli bir X-Hub-Signature-256 imzası olmadan reddediliyor, Telegram webhook'ları gizli bir token gerektiriyor ve ekler yalnızca imzalı, süresi dolan URL'ler üzerinden sunuluyor.
- Altyapı: uygulama doğrudan internete açık değil; genel trafik ona bir Cloudflare Tunnel üzerinden ulaşıyor. Veritabanı hata logları sorgu parametrelerini hiçbir zaman içermiyor, yani telefon numaraları ve e-postalar o loglara düşmüyor.
- Platform yöneticisi denetim logu: platform yöneticisi işlemleri, yalnızca ekleme yapılabilen bir denetim loguna yazılıyor (kim, ne, ne zaman, IP; öncesi/sonrası anlık görüntüleriyle ve gizli değerler maskelenmiş hâlde). Bu, müşteri mesajlarının logu değildir.
Şifrelemenin burada yapamadığı şey: yapay zeka destekli bir gelen kutusu, yanıt yazabilmek için mesaj metnini okumak zorundadır, yani konuşma içeriği sunucuda okunabilir biçimde işlenir. Yukarıdaki erişim kontrolü, saklama süresi ve yedek maddelerinin, seçtiğiniz şifreleme algoritması kadar ağır basmasının sebebi tam olarak budur.
Meta veri silme talepleri, veri silme sayfamızda durum bağlantısı olan bir onay kodu döndürür. Hesap silme işlemi parolanızın yanı sıra e-postayla gönderilen tek kullanımlık bir kod gerektirir; ardından hesap devre dışı bırakılır ve e-postası anonimleştirilir.
İşletmeler için Veri Şifreleme Kontrol Listesi: Küçük Ekipler için Uygulama Sırası
KOBİ'ler için veri şifreleme, en çok zarar verecek şeyden başlayan sabit bir sırayla en iyi sonucu verir:
- Her şeyi yalnızca TLS 1.2 veya 1.3 ile, HTTPS üzerinden sunun.
- Müşteri sohbetlerini açan her cihazda tam disk şifrelemeyi ve ekran kilidini açın.
- Tokenları ve API anahtarlarını, ayrı anahtarlarla alan düzeyinde şifrelemeye taşıyın.
- Parolaları Argon2id ya da bcrypt ile hash'leyin ve ikinci bir giriş adımı ekleyin.
- Müşteri telefon numaralarını, e-postalarını ve adreslerini şifreleyin.
- Yedekleri şifreleyin, en az yetki prensibine göre roller tanımlayın ve sohbet saklama süreleri belirleyin.
- Sağlayıcı sorularını kullandığınız her sohbet, CRM ve yapay zeka aracına gönderin.
Sıkça Sorulan Sorular
İşletmelerde hangi veriler şifrelenmeli?
Erişim sağlayan ya da bir kişiyi tanımlayan her şeyle başlayın: kanal tokenları, API anahtarları, webhook gizli anahtarları ve müşteri telefon numaraları, e-postaları ile adresleri. Ardından sohbet kayıtlarını, personel cihazlarını ve her yedek ile dışa aktarımı kapsayın.
Aktarım sırasında şifreleme ile bekleyen veri şifreleme farkı nedir?
Aktarım sırasında şifreleme, genellikle TLS, cihazlar, sunucular ve API'ler arasında hareket eden veriyi korur. Durağan veri şifreleme, genellikle AES, saklanan veriyi korur.
AES-256 şifreleme müşteri verilerini korumak için yeterli mi?
AES-256 güçlüdür ama zayıf halka nadiren algoritmadır. Sık görülen hata noktaları zayıf anahtar saklama, tekrar kullanılan nonce'lar, personele verilen geniş erişim ve korumasız yedeklerdir.
API anahtarları ve erişim tokenları güvenli şekilde nasıl saklanır?
Tekrar kullanmanız gereken tokenları alan düzeyinde AES-GCM ile şifreleyin ve anahtarı veritabanının dışında tutun. Yalnızca doğruladığınız gizli değerleri, örneğin parolaları ve partner API anahtarlarını, hash'leyin.
HTTPS kullanıyorsam verilerim sunucuda da korunur mu?
Hayır. HTTPS yalnızca aktarım sırasındaki veriyi korur. Sunucuda güvenlik; durağan veri şifrelemeye, erişim kontrolüne ve yedeklerin nasıl yönetildiğine bağlıdır.
Chatbot ve CRM sağlayıcısına hangi güvenlik soruları sorulmalı?
Hangi TLS sürümlerini kabul ettiklerini, durağan hâlde neyin hangi katmanda şifrelendiğini, anahtarların nerede saklandığını, personelin sohbetlere erişiminin loglanıp loglanmadığını, alt işleyicilerinin kimler olduğunu ve verinin nerede tutulduğunu, sohbetlerin yapay zeka modeli eğitiminde kullanılıp kullanılmadığını ve silme süresi içeren bir DPA imzalayıp imzalamayacaklarını sorun.
Sohbetlerinizi, kanal tokenlarını ve seçili müşteri iletişim bilgilerini şifreleyen bir yapay zeka gelen kutusunda yürütmeye hazır mısınız? Ücretsiz başlayın.
Şunlar da ilginizi çekebilir
Benzer etiketlere sahip diğer yazılar.