LinkedIn
Instagram
WhatsApp
Telgraf
Google Takvim
Slack Topluluğuna KatılınKullanıcılarınızın yapabileceği e-posta entegrasyonları oluşturun güven
Kullanıcılarınızın gelen kutularına erişmek, ciddi güvenlik riskleri taşır. Saklanan parolalar, aşırı geniş OAuth kapsamları ve rotasyonu yapılmamış jetonlar, kullanıcı güvenini zedeleyen ve GDPR'yi ihlal eden saldırı yüzeyleri oluşturur.
Unipile'ın E-posta API rehberi Entegrasyonun tam resmini kapsar. Bu makale güvenlik katmanına odaklanmaktadır: güvenli bir e-posta API'sinin neleri garanti etmesi gerekir, hangi risklerden kaçınılmalıdır ve Unipile, kullanıcı verilerini tasarıma göre korumak için nasıl yapılandırılmıştır.
Gmail
Görünüm
IMAP
Bir E-posta API'sini "Güvenli" Yapan Nedir?
E-posta API'sinde güvenlik tek bir özellik değildir. Kimlik doğrulama, yetkilendirme, veri işleme ve altyapıyı kapsayan mimari bir seçimdir. Güvenli bir e-posta API'si dört şeyi aynı anda garanti etmelidir.
Kullanıcılar yetkilendirmeyi sağlayıcılarının resmi OAuth akışı aracılığıyla yaparlar. Şifre asla sağlayıcının sunucusundan ayrılmaz veya veritabanınıza kaydedilmez.
Her bağlantılı hesap yalnızca gerçekten ihtiyaç duyduğu izinleri ister - göndermenin gerekmediği durumlarda salt okunur, açıkça gerektiğinde gönderim kapsamı.
Tüm API trafiği TLS 1.2+ kullanır. Depolanan belirteçler sabitken AES-256 ile şifrelenir. E-posta içeriği asla istek yaşam döngüsünün ötesine kaydedilmez.
OAuth 2.0'a karşı şifre saklama
Herhangi bir e-posta entegrasyonundaki en temel güvenlik kararı, kimlik doğrulamanın nasıl yapılacağıdır. Birçok eski IMAP entegrasyonu, kullanıcılardan e-posta parolalarını girmelerini ve bunları saklamalarını ister. Bu yaklaşım tek bir hata noktası oluşturur: bir veritabanı ihlali her kullanıcının gelen kutusunu açığa çıkarır. OAuth 2.0 bunu tamamen ortadan kaldırır. Nasıl olduğunu görün Google OAuth 2.0 ve Microsoft OAuth 2.0 bu akışı uygula.
Token kapsamları: salt okunur'a karşı gönderme
OAuth kapsamları, uygulamanızın bir kullanıcının posta kutusunda tam olarak neler yapabileceğini tanımlar. Daha dar kapsamlar yeterli olduğunda geniş kapsamlar talep etmek ciddi bir güvenlik anti-desenidir. Yalnızca etkinliği kaydetmek için e-postaları okuyan bir CRM için talep etmek gmail.değiştir gereksizdir ve belirtecinizin ele geçirilmesi durumunda kullanıcıları daha büyük risk altına sokar. Eğer uygulamanızın olması gerekiyorsa e-posta gönderme API'si requests, gerekli kapsamların her sağlayıcı için tam bir dökümünü e-posta gönderme API kılavuzumuzda bulabilirsiniz.
| Kapsam | Sağlayıcı | Ne sağlar | Risk seviyesi |
|---|---|---|---|
| gmail.yalnızcaoku | Gmail | E-postaları yalnızca oku | Minimal |
| gmail.gönder | Gmail | Kullanıcı adına gönder | Kapsamlı |
| Mail.Read | Görünüm | E-postaları yalnızca oku | Minimal |
| Mail.Gönder | Görünüm | Kullanıcı adına gönder | Kapsamlı |
| https://mail.google.com/ | Gmail | Tam posta kutusu erişimi | Geniş |
| Mail.ReadWrite | Görünüm | Oku, yaz, sil | Geniş |
Yolda ve depolama alanında şifreleme
Güvenli bir e-posta API'si, tüm API uç noktalarında TLS 1.2 veya daha yüksek sürümünü zorunlu tutar. Düz metin iletişimi kabul edilemez. Aktarım dışındaki kalıcı olması gereken tüm jetonlar veya kimlik bilgileri - örneğin OAuth yenileme jetonları - güçlü bir simetrik şifre (AES-256) kullanılarak depolandığında şifrelenmelidir. Eşit derecede önemli: e-posta içeriğinin kendisi, isteğin gerektirdiğinden fazlası hiçbir zaman saklanmamalıdır. Bir e-postayı kullanıcı arayüzünüzde okumak ve görüntülemek, gövdesini veritabanınızda kalıcı olarak saklamayı gerektirmez.
Kaçınılması Gereken E-posta API Güvenlik Riskleri
E-posta entegrasyonu güvenlik ihlallerinin çoğu egzotik saldırılar değildir; kimlik bilgileri, belirteçler ve verilerin işlenme biçimindeki öngörülebilir hatalardır. Aşağıdaki dört kalıp, e-posta API entegrasyonlarındaki gerçek dünya olaylarının çoğunluğunu oluşturmaktadır.
E-posta şifrenizi kullanıcılardan girmenizi istemek ve (şifrelenmiş olsa bile) saklamak, e-posta entegrasyonundaki en yüksek riskli desendir. Bu, veritabanınızı yüksek değerli bir hedef haline getirir. Bir saldırgan kimlik bilgileri mağazanıza erişim sağlarsa, her kullanıcının gelen kutusuna doğrudan erişim elde eder. Güvenlik riskinin ötesinde, Google ve Microsoft şifre tabanlı Gmail ve Outlook hesaplarına üçüncü taraf uygulamalar tarafından erişimi açıkça yasaklar. Şifreli IMAP, yalnızca OAuth'un gerçekten kullanılamadığı kendi kendine barındırılan veya eski posta sunucuları için kabul edilebilirdir.
Talep ediliyor https://mail.google.com/ (tam Gmail erişimi) yalnızca kullanıcının gönderilmiş klasörünü okumak için bir kapsam anti-deseni. Geniş kapsamlar, bir jeton tehlikeye atıldığında etki alanını artırır ve OAuth onay ekranı sırasında kullanıcı güvenini zedeler - "tüm e-postalarınızı okuyun, yazın, gönderin ve kalıcı olarak silin" ifadesini görenler haklı olarak tereddüt eder. Hem Google hem de Microsoft artık uygulama incelemeleri sırasında gereksiz kapsam kullanımını işaretlemektedir.
OAuth erişim belirteçleri, tasarım gereği kısa ömürlüdür - genellikle Gmail ve Outlook için bir saattir. Yenileme belirteçleri aylarca veya süresiz olarak kalabilir. Yenileme belirteçlerini bir döndürme stratejisi olmadan saklarsanız, sızdırılmış bir yenileme belirteci kullanıcının posta kutusuna uzun süreli erişim sağlar. Bazı entegrasyonlar, erişim belirteçlerini süresi dolduktan çok sonra önbelleğe alır ve geri alma olaylarını (bir kullanıcı Google veya Microsoft hesabı ayarlarından uygulamanızı kaldırdığında) işleyemez.
Uygulama günlükleri genellikle birincil veritabanlarından daha az korumalıdır, daha uzun süre saklanır ve birden çok sisteme (günlük toplayıcılar, izleme hizmetleri, hata izleyiciler) çoğaltılır. Tam e-posta gövdelerini, kişisel veri içeren üstbilgileri veya alıcı listelerini günlüğe kaydetmek, önemli bir GDPR riski oluşturur: kullanıcının asla rıza göstermediği ve denetleyemediği bir bağlamda kişisel verileri işliyorsunuz. Ham API yanıtlarını içeren hata günlükleri istemeden tüm e-posta dizilerini yakalayabilir.
E-posta API Entegrasyonları için GDPR Uyumluluğu
E-posta verileri, GDPR kapsamında en hassas kişisel veri kategorilerinden biridir. Uygulamanız bir API aracılığıyla kullanıcının gelen kutusuna eriştiğinde, veri işleyen konumuna gelirsiniz. Bu, e-posta API mimarinizin desteklemesi gereken barındırma, onay ve silme etrafında somut yasal yükümlülükler oluşturur.
AB kişisel verileri AB'de veya yeterlilik kararı olan ülkelerde kalmalıdır. E-posta API altyapınız AB'de barındırılan uç noktalar sunmalıdır.
Kullanıcılar posta kutularına erişim için açıkça izin vermelidir. OAuth izin ekranı, hangi verilerin hangi amaçla erişileceğini net bir şekilde belirtmelidir.
Bir kullanıcı silme talebinde bulunduğunda veya hesabını bağlantısını kestiğinde, ilişkili tüm belirteçler, önbelleğe alınmış veriler ve kişisel veriler GDPR zaman çizelgeleri dahilinde silinmelidir.
Veri ikametgâhı
GDPR Madde 44'e göre, Avrupa Ekonomik Alanı dışına kişisel veri aktarımı, yeterlilik kararı, Standart Sözleşme Maddeleri (SCC'ler) veya başka geçerli bir yasal mekanizma gerektirir. AB kullanıcılarına hizmet veren e-posta API entegrasyonları için, OAuth token'larını depolayan, e-posta meta verilerini işleyen veya mesaj içeriğini önbelleğe alan altyapı AB'de barındırılmalıdır. AB veri kalıcılığı seçenekleri olmayan bir API sağlayıcısı seçmek, SCC'lere ve ek uyumluluk yüküne güvenmenizi zorunlu kılar. HIPAA benzeri gerekliliklerin geçerli olduğu sağlık veya finansal kullanım durumlarında veri kalıcılığı daha da kritik hale gelir.
E-posta API sağlayıcınız GDPR kapsamında bir alt işlemcidir. Onlarla bir Veri İşleme Sözleşmesi (DPA) yapmanız gerekir ve onların altyapısı, sizin adınıza işledikleri AB kullanıcı verileri için AB veri barındırmayı desteklemelidir.
Kullanıcı onay akışı
OAuth yetkilendirme akışı, doğru tasarlandığı takdirde e-posta erişimi için KVKK onayının teknik uygulaması olarak hizmet vermektedir. Onay ekranı, uygulamanın neye erişeceğini açık bir dille doğru bir şekilde tanımlamalıdır. Gizlilik politikanızda açıklananların ötesinde kapsamlar istemek uyumluluk açığı yaratır. Kullanıcılar bu akışı zorlama olmaksızın tamamlayabilmelidir: E-posta hesabınızı bağlamak, e-posta erişimi gerçekten hizmetin kendisi olmadıkça, temel hizmetinize erişim için zorunlu bir koşul olmamalıdır.
Silme Hakkı - hesap bağlantısının kesilmesi
GDPR Madde 17, kullanıcılara silme hakkı verir. E-posta entegrasyonu bağlamında bu, uygulamanızın, istendiğinde bir kullanıcının e-posta erişimine ait tüm izleri derhal ve tamamen kaldırabilmesi gerektiği anlamına gelir. Bu sadece OAuth belirtecini silmekle ilgili değildir; entegrasyonun yaşam döngüsü boyunca oluşturulan her yapıtı kapsar.
Unipile E-posta API Güvenliğini Nasıl Ele Alıyor
Güvenlik, Unipile'a eklenen bir özellik değil, platformun varsayılan davranışıdır. Unipile, kimlik doğrulama, e-posta verileri güvenliği ve uyumluluk kontrollerinin varsayılan olarak, sonradan eklenmiş değil, yerleşik olarak bulunduğu güvenli bir e-posta API'si sunmak üzere özel olarak tasarlanmıştır. Unipile'ın Gmail, Outlook ve IMAP hesaplarına bağlanma şeklindeki her mimari karar, son kullanıcıların güvenliği ve gizliliğini birincil kısıtlama olarak dikkate alarak alınmıştır.
Unipile, Gmail'e şu şekilde bağlanır: Google OAuth 2.0 ve Outlook ve Microsoft 365'e aracılığıyla Microsoft OAuth 2.0. Kullanıcılarınız doğrudan sağlayıcının resmi onay ekranı aracılığıyla kimlik doğrulaması yapar. Parola asla Unipile'ın altyapısından geçmez. OAuth'un kullanılamadığı IMAP hesaplarında kimlik bilgileri AES-256 ile şifrelenir ve sunulan herhangi bir API yanıtında asla açığa çıkmaz - buna şunlar da dahildir: IMAP API kılavuzu bu mimariyi ayrıntılı olarak ele almaktadır.
Unipile, SaaS uygulamanızın sağladığı özellikler için gerekli olan en dar OAuth kapsamlarını talep eder. Entegrasyonunuz yalnızca bir CRM etkinlik akışını doldurmak için e-postaları okuyorsa, Unipile yalnızca okuma kapsamlarını talep eder. Gönderme kapsamı, yalnızca uygulamanızın açıkça gönderme gerektirmesi durumunda eklenir. Bu, kimlik bilgisi sorunlarının etki alanını azaltır ve doğru bir şekilde onaylanması için uygulamanızın OAuth izin ekranını son kullanıcılar için anlaşılır hale getirir.
AB müşterilerine hizmet veren SaaS ekipleri için Unipile, AB barındırmalı altyapı seçenekleri sunmaktadır. OAuth belirteçleri, bağlı hesap meta verileri ve geçici olarak işlenen herhangi bir e-posta verisi AB yargı yetkisi içinde kalır. Bu, temiz bir GDPR veri işleme kaydı tutmanıza ve sizin adınıza AB kişisel verilerini işleyen herhangi bir işlemci için GDPR Madde 28 uyarınca yasal bir gereklilik olan Unipile ile alt işlemci olarak bir Veri İşleme Sözleşmesi akdetmenize olanak tanır.
Unipile, bağlantılı hesaplar için bir DELETE uç noktası sunar. Bunu çağırmak, sağlayıcı düzeyinde OAuth jetonunu hemen geçersiz kılar, Unipile'ın altyapısındaki tüm ilişkili meta verileri temizler ve aktif webhook aboneliklerini iptal eder. Bu, e-posta erişimiyle ilgili GDPR silme hakkı taleplerini yerine getirmek için temiz, tek API çağrılı bir yol sunar; birden fazla sağlayıcı panelinde manuel temizliğe gerek kalmaz.
Tam API başvuru kılavuzunu okuyun - kimlik doğrulama akışları, jeton yönetimi ve webhook güvenliği.
Uygunluk Sertifikaları
Unipile, güvenli e-posta API entegrasyonları için en ilgili üç uyumluluk çerçevesi olan güvenlik operasyonları, veri koruma ve Google API erişimi konularında bağımsız olarak denetlenmiş ve sertifikalandırılmıştır.
Bağımsız bir üçüncü taraf tarafından denetlenmiştir. Unipile ve#39;un altyapısı genelinde güvenlik, kullanılabilirlik ve gizlilik hizmet güveni kriterlerini kapsar.
AB veri koruma düzenlemelerine tam uyum. Unipile Veri İşleyici olarak hareket eder. Tüm veriler yalnızca AB'de barındırılır. DPA talep üzerine temin edilebilir.
Google Cloud Uygulama Güvenliği Değerlendirmesi. Gmail OAuth kapsamları dahil olmak üzere Google kullanıcı verilerine erişen uygulamalar için güvenlik denetimlerini doğrular.
Unipile üzerine inşa ettiğinizde, güvenli e-posta entegrasyonunuz bu denetimlerden geçen aynı güvenlik kontrollerinden yararlanır. Bu, özellikle CASA Tier II için geçerlidir: CASA sertifikalı güvenli bir e-posta API'si üzerine inşa edilen uygulamalar, e-posta katmanının ayrı bir denetimi olmadan tüm entegrasyon zinciri boyunca kendi uyumluluk durumlarını koruyabilirler.
E-posta API Entegrasyonu İçin Güvenlik Kontrol Listesi
E-posta API entegrasyonunu üretime almadan önce bu kontrol listesini kullanın. Güvenlik açısından entegrasyonun üretime hazır kabul edilebilmesi için tüm maddeler doğrulanmalıdır.
OAuth 2.0, minimal kapsamlar, AB veri yerleşimi, anında hesap bağlantı kesme - hepsi tek bir güvenli e-posta API'sında. Şifreli e-posta erişimi ve parola depolama olmadan Gmail, Outlook ve IMAP'ı bağlayın.
Güvenli E-posta API - SSS
E-posta API güvenliği, OAuth ve uyumlulukla ilgili sık sorulan sorular
IMAP güvenli olabilir, ancak bu tamamen uygulamaya bağlıdır. Protokolün kendisi, doğru şekilde yapılandırıldığında verileri TLS üzerinden iletir, bu nedenle aktarım katmanı sorun değildir. Risk, kimlik bilgilerinin nasıl işlendiğindedir. IMAP, kullanıcı adı ve parola gerektirir - OAuth 2.0'ı destekleyen Gmail ve Outlook'un aksine, IMAP'in yetkilendirilmiş bir standartı yoktur. Bu, uygulamanızın her bağlandığında kullanıcının parolasını saklaması veya alması gerektiği anlamına gelir. Parolalar AES-256 ile şifrelenmişse, parola depolama alanına erişim kısıtlıysa ve parolalar asla günlüğe kaydedilmez veya API yanıtları aracılığıyla gösterilmezse bu yönetilebilir. Gmail ve Outlook için, parola ile IMAP yerine her zaman OAuth 2.0'ı tercih edin - her iki sağlayıcı da üçüncü taraf uygulamalar için bunu gerektirir. Parola ile IMAP yalnızca kendi kendine barındırılan posta sunucuları veya OAuth'un gerçekte mevcut olmadığı eski şirket ortamları için uygundur. Ayrıntılı bilgi için IMAP API kılavuzu.
Bir e-posta API entegrasyonu için HIPAA uyumluluğu sağlanabilir ancak dikkatli bir mimari gerektirir. HIPAA e-posta sağlayıcılarını sertifikalandırmaz - daha ziyade, Korunan Sağlık Bilgilerini (PHI) işleyen herhangi bir sistemin belirli teknik önlemleri uygulamasını gerektirir: aktarım sırasında ve beklemede şifreleme, denetim kontrolleri, erişim kontrolleri ve etkin olmayan oturumlar için otomatik oturum kapatma. Bir e-posta API'si için bu şu anlama gelir: OAuth 2.0 kullanmak, böylece hiçbir parola saklanmaz, belirteçlerin ve önbelleğe alınan meta verilerin beklemede şifrelenmesini sağlamak, PHI içerebilecek e-posta içeriğini asla günlüğe kaydetmemek ve API sağlayıcınızla bir İş Ortağı Anlaşması (BAA) yapmak. Gmail ve Outlook, sağlayıcıdan imzalı bir BAA ile sırasıyla Google Workspace ve Microsoft 365 Business planları altında HIPAA'ya uygun yapılandırmalar sunar. E-posta API katmanınız da sizin adınıza PHI işliyor veya iletiyorsa sizinle bir BAA imzalamalıdır. Pratik açıdan bakıldığında, en güvenli HIPAA yolu e-posta içeriğini geçici olarak ele almaktır - okuyun, işleyin, yüzeye çıkarın - ancak gövdeyi veya ekleri asla kendi veritabanınızda kalıcı hale getirmeyin.
Bir kullanıcının e-postasına erişimi iptal etmek, her ikisinin de gerçekleşmesi gereken iki ayrı eylemi içerir. Öncelikle, belirteç sağlayıcı düzeyinde geçersiz kılın. Gmail için Google'ın jeton iptali uç noktasına çağrı yapın (https://oauth2.googleapis.com/revoke). Outlook için Microsoft'un iptal uç noktasını çağırın veya uygulamayı kullanıcının Microsoft hesabından kaldırın. Jetonu veritabanınızdan silmek yeterli değildir - jeton, açıkça iptal edilene kadar sağlayıcıda geçerliliğini korur. İkinci olarak, tüm yerel verileri temizleyin. Yenileme jetonunu, önbelleğe alınmış tüm erişim jetonlarını, o bağlı hesap için sakladığınız tüm e-posta meta verilerini, webhook aboneliklerini ve bağlı hesap kaydının kendisini silin. Unipile ile tek bir HESAPLARI SİL / {id} Çağrı, her iki adımı da gerçekleştirir; belirteci sağlayıcıda iptal eder ve Unipile'ın altyapısındaki tüm ilişkili verileri aynı anda temizler.
E-posta güvenliği genellikle e-posta iletişiminin kendisini korumak anlamına gelir; spam filtreleme, kimlik avı tespiti, DKIM/SPF/DMARC kimlik doğrulaması ve posta sunucuları arasındaki aktarım sırasında iletinin şifrelenmesi. E-posta API güvenliği tamamen farklı bir katmandır: üçüncü taraf bir uygulamanın bir kullanıcının posta kutusuna programlı olarak nasıl eriştiği, bunun sonucunda hangi verileri işlediği ve bu erişimi nasıl koruduğu ile ilgilidir. Mükemmel e-posta güvenliğiniz (yapılandırılmış DMARC, sunucular arasında zorunlu TLS) olabilir, ancak zayıf e-posta API güvenliğiniz (düz metin olarak saklanan parolalar, aşırı geniş OAuth kapsamları) olabilir. Her ikisi de bağımsız olarak önemlidir. Bu makale API güvenlik katmanına odaklanmaktadır; geliştirme ekibinizin Gmail, Outlook veya IMAP ile bir API aracılığıyla entegre olurken aldığı mimari kararlar.
Unipile, e-posta içeriklerini kalıcı olarak saklamaz. Uygulamanız, e-postaları almak için Unipile API'sini çağırdığında, Unipile veriyi gerçek zamanlı olarak sağlayıcıdan (Gmail, Outlook veya IMAP sunucusu) çeker ve uygulamanıza döndürür. E-posta gövdeleri ve ekleri, istek yaşam döngüsünün ötesinde Unipile'ın altyapısında önbelleğe alınmaz veya saklanmaz. Unipile'ın sakladığı tek şey, bağlantıyı sürdürmek için gereken OAuth belirtecidir (dinlenirken şifrelenmiş) ve temel bağlantılı hesap meta verileridir: sağlayıcı türü, hesap tanımlayıcısı ve bağlantı durumu. Bu mimari, e-posta içeriğinin uygulamanız ve sağlayıcı arasında kalmasını sağlar ve Unipile, bir veri deposundan ziyade güvenli bir aracı görevi görür. Unipile'ın verileri nasıl ele aldığına ilişkin ayrıntılı bilgi için lütfen Geliştirici belgeleri ve Unipile ekibinden bir DPA talep edin.
OAuth 2.0, e-posta entegrasyon güvenliğini dört somut yolla geliştirir. Kimlik bilgisi ifşası yok kullanıcının parolası asla sağlayıcının sunucusundan ayrılmaz - uygulamanız yalnızca kısa ömürlü bir erişim belirteci alır. Granüler izinler OAuth kapsamları, tam posta kutusu kontrolü yerine tam olarak ihtiyacınız olan erişimi (salt okunur, yalnızca gönderme) istemenizi sağlar. İptal Edilebilirlik Kullanıcı, parolasını değiştirmeden herhangi bir zamanda Google veya Microsoft hesap ayarlarından uygulamanızın erişimini kaldırabilir ve belirteç (token) anında geçersiz hale gelir. Kısa ömürlü tokenlar: erişim belirteçleri (genellikle bir saat sonra) sona erer, bu da bir belirtecin ele geçirilmesi durumunda maruz kalma penceresini sınırlar. Bu özellikler, OAuth 2.0'ı üretim SaaS uygulamalarındaki Gmail ve Outlook entegrasyonları için tek kabul edilebilir kimlik doğrulama mekanizması haline getirir. Uygulamanızı nasıl uygulayacağınızı öğrenin Google OAuth 2.0 ve Microsoft OAuth 2.0.
Hala sorularınız mı var? Ekibimiz yardım etmek için burada.
TR 
EN 
FR 
ES 
DE 
IT 
BR 
NL 
PL